RFC1245 日本語訳
1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT=26160, PS=33546, PDF=31723 bytes) (Also RFC1247, RFC1246) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy, Editor
Request for Comments: 1245 Proteon, Inc.
July 1991
ワーキンググループJ.Moy、コメントを求めるエディタ要求をネットワークでつないでください: 1245 Proteon Inc.1991年7月
OSPF protocol analysis
OSPFプロトコル分析
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify any Internet standard. Distribution of this memo is unlimited. Please send comments to ospf@trantor.umd.edu.
このメモはインターネットコミュニティのための情報を提供します。 それは少しのインターネット標準も指定しません。 このメモの分配は無制限です。 コメントを ospf@trantor.umd.edu に送ってください。
Abstract
要約
This is the first of two reports on the OSPF protocol. These reports are required by the IAB/ IESG in order for an Internet routing protocol to advance to Draft Standard Status. OSPF is a TCP/IP routing protocol, designed to be used internal to an Autonomous System (in other words, OSPF is an Interior Gateway Protocol).
これはOSPFプロトコルに関する2つのレポートの1番目です。 これらのレポートは、Draft Standard Statusに達するためにインターネットルーティング・プロトコルにおいて、整然としているIAB/ IESGによって必要とされます。 OSPFはAutonomous Systemに内部で使用されるように設計されたTCP/IPルーティング・プロトコル(言い換えれば、OSPFはInteriorゲートウェイプロトコルである)です。
Version 1 of the OSPF protocol was published in RFC 1131. Since then OSPF version 2 has been developed. Version 2 has been documented in RFC 1247. The changes between version 1 and version 2 of the OSPF protocol are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of this report.
OSPFプロトコルのバージョン1はRFC1131で発行されました。 それ以来、OSPFバージョン2を開発してあります。 バージョン2はRFC1247に記録されました。 OSPFプロトコルのバージョン1とバージョン2の間の変化はRFC1247のAppendix Fで説明されます。 それはこのレポートの対象であるOSPFバージョン2です。
This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet.
このレポートは、OSPF V2に関する重要な特色をまとめるのを試みます。 また、それは、プロトコルがどうインターネットを実行して、計量するかを分析するのを試みます。
1.0 Introduction
1.0 序論
This document addresses, for OSPF V2, the requirements set forth by the IAB/IESG for an Internet routing protocol to advance to Draft Standard state. This requirements are briefly summarized below. The remaining sections of this report document how OSPF V2 satisfies these requirements:
このドキュメントアドレス、OSPF V2に関して、インターネットルーティング・プロトコルがDraft Standard状態に達するように、要件はIAB/IESGで旅に出ます。 この要件は簡潔に以下へまとめられます。 このレポートの残っているセクションはOSPF V2がどうこれらの要件を満たすかを記録します:
o What are the key features and algorithms of the protocol?
o プロトコルの重要な特色とアルゴリズムは何ですか?
o How much link bandwidth, router memory and router CPU cycles does the protocol consume under normal conditions?
o プロトコルは正常な状況ではどのくらいのリンク帯域幅、ルータメモリ、およびルータCPUサイクルを費やしますか?
o For these metrics, how does the usage scale as the routing environment grows? This should include topologies at least an order
o これらの測定基準のために、ルーティング環境が成長するとき、用法はどのように比例しますか? これがtopologiesするべきである、インクルードは少なくともオーダーをtopologiesします。
[Moy] [Page 1] RFC 1245 OSPF protocol analysis July 1991
[Moy][1ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
of magnitude larger than the current environment.
現在の環境より大きい大きさについて。
o What are the limits of the protocol for these metrics? (I.e., when will the routing protocol break?)
o これらの測定基準のためのプロトコルの限界はどのくらいですか? (ルーティング・プロトコルはいつすなわち、壊れるでしょうか?)
o For what environments is the protocol well suited, and for what is it not suitable?
o プロトコルはどんな環境によく合っているか、そして、それは何に適していませんか?
1.1 Acknowledgments
1.1 承認
The OSPF protocol has been developed by the OSPF Working Group of the Internet Engineering Task Force.
OSPFプロトコルはインターネット・エンジニアリング・タスク・フォースのOSPF作業部会によって開発されました。
2.0 Key features of the OSPF protocol
2.0 OSPFプロトコルの主要な特徴
This section summarizes the key features of the OSPF protocol. OSPF is an Internal gateway protocol; it is designed to be used internal to a single Autonomous System. OSPF uses link-state or SPF-based technology (as compared to the distance-vector or Bellman-Ford technology found in routing protocols such as RIP). Individual link state advertisements (LSAs) describe pieces of the OSPF routing domain (Autonomous System). These LSAs are flooded throughout the routing domain, forming the link state database. Each router has an identical link state database; synchronization of link state databases is maintained via a reliable flooding algorithm. From this link state database, each router builds a routing table by calculating a shortest-path tree, with the root of the tree being the calculating router itself. This calculation is commonly referred to as the Dijkstra procedure.
このセクションはOSPFプロトコルに関する重要な特色をまとめます。 OSPFはInternalゲートウェイプロトコルです。 それは、独身のAutonomous Systemに内部で使用されるように設計されています。 OSPFはリンク状態かSPFベースの技術を使用します(RIPなどのルーティング・プロトコルで見つけられた距離ベクトルかBellman-フォード技術と比べて)。 個々のリンク州の広告(LSAs)はOSPF経路ドメイン(自治のSystem)の断片について説明します。 リンク州のデータベースを形成して、これらのLSAsは経路ドメイン中で水につかっています。 各ルータには、同じリンク州のデータベースがあります。 リンク州のデータベースの同期は信頼できる氾濫アルゴリズムで維持されます。 このリンク州のデータベースから、各ルータは最短パス木について計算することによって、経路指定テーブルを組立てます、計算のルータ自体である木の根で。 この計算は一般的にダイクストラ手順と呼ばれます。
Link state advertisements are small. Each advertisement describes a small pieces of the OSPF routing domain, namely either: the neighborhood of a single router, the neighborhood of a single transit network, a single inter-area route (see below) or a single external route.
リンク州の広告は小さいです。 各広告はOSPF経路ドメイン、すなわち、小さい片のどちらかについて説明します: ただ一つのルータ(ただ一つのトランジットネットワーク、ただ一つの相互領域ルート(以下を見る)またはただ一つの外部経路の近所)の近所。
The other key features of the OSPF protocol are:
OSPFプロトコルに関する他の重要な特色は以下の通りです。
o Adjacency bringup. Certain pairs of OSPF routers become "adjacent". As an adjacency is formed, the two routers synchronize their link state databases by exchanging database summaries in the form of OSPF Database Exchange packets. Adjacent routers then maintain syn- chronization of their link state databases through the reliable flooding algorithm. Routers connected by serial lines always become adjacent. On multi-access networks (e.g., ethernets or X.25 PDNs), all routers attached to the network become adjacent to both the Designated Router and the Backup Designated router.
o 隣接番組bringup。 OSPFルータのある組は「隣接する」ようになります。 隣接番組が形成されるとき、2つのルータが、OSPF Database Exchangeパケットの形でデータベース概要を交換することによって、それらのリンク州のデータベースを同期させます。 そして、隣接しているルータは信頼できる氾濫アルゴリズムでそれらのリンク州のデータベースのsyn- chronizationを維持します。 シリアル・ラインによって接続されたルータはいつも隣接するようになります。 マルチアクセスネットワーク(例えば、イーサネットかX.25 PDNs)では、ネットワークに付けられたすべてのルータがDesignated RouterとBackup Designatedルータの両方に隣接してなります。
o Designated router. A Designated Router is elected on all multi-access networks (e.g., ethernets or X.25 PDNs). The network's Designated
o 代表ルータ。 Designated Routerはすべてのマルチアクセスネットワーク(例えば、イーサネットかX.25 PDNs)で選出されます。 ネットワークのDesignated
[Moy] [Page 2] RFC 1245 OSPF protocol analysis July 1991
[Moy][2ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
Router originates the network LSA describing the network's local environment. It also plays a special role in the flooding algorithm, since all routers on the network are synchronizing their link state databases by sending and receiving LSAs to/from the Designated Router during the flooding process.
ルータはネットワークの地方の環境について説明するネットワークLSAを溯源します。 また、それは氾濫アルゴリズムにおける特別な役割を果たします、ネットワークのすべてのルータが氾濫の過程の間、それらのリンク州のデータベースをDesignated Routerからの/と送受信LSAsで同期させているので。
o Backup Designated Router. A Backup Designated Router is elected on multi-access networks to speed/ease the transition of Designated Routers when the current Designated Router disappears. In that event, the Backup DR takes over, and does not need to go through the adjacency bringup process on the LAN (since it already had done this in its Backup capacity). Also, even before the disappearance of the Designated Router is noticed, the Backup DR will enable the reliable flooding algorithm to proceed in the DR's absence.
o 代表ルータのバックアップをとってください。 現在のDesignated Routerが見えなくなるとき、Backup Designated Routerは、Designated Routersの変遷を促進するか、または緩和するためにマルチアクセスネットワークで選出されます。 その場合には、Backup DRは引き継いで、LANの隣接番組bringupの過程に直面する必要はありません(Backup立場で既にこれをしたので)。 また、Designated Routerの消滅が気付かれる前にさえBackup DRは、信頼できる氾濫アルゴリズムがDRの不在で続くのを可能にするでしょう。
o Non-broadcast multi-access network support. OSPF treats these networks (e.g., X.25 PDNs) pretty much as if they were LANs (i.e., a DR is elected, and a network LSA is generated). Additional configuration information is needed however for routers attached to these network to initially find each other.
o 非放送マルチアクセスネットワークサポート。 OSPFはまるでほとんど彼らがLANであるかのようにこれらのネットワーク(例えば、X.25 PDNs)を扱います(すなわち、DRが選出されます、そして、ネットワークLSAは発生します)。 しかしながら、追加設定情報が初めは互いを見つけるためにこれらのネットワークに付けられたルータに必要です。
o OSPF areas. OSPF allows the Autonomous Systems to be broken up into regions call areas. This is useful for several reasons. First, it provides an extra level of routing protection: routing within an area is protected from all information external to the area. Second, by splitting an Autonomous System into areas the cost of the Dijkstra procedure (in terms of CPU cycles) is reduced.
o OSPF領域。 OSPFは領域の呼び出し地域にAutonomous Systemsを壊れさせます。 これはいくつかの理由の役に立ちます。 まず最初に、余分なレベルのルーティング保護を提供します: 領域の中のルーティングはその領域への外部のすべての情報から保護されます。 2番目に、Autonomous Systemを領域に分割することによって、ダイクストラ手順(CPUサイクルに関する)のコストは削減されます。
o Flexible import of external routing information. In OSPF, each external route is imported into the Autonomous System in a separate LSA. This reduces the amount of flooding traffic (since external routes change often, and you want to only flood the changes). It also enables partial routing table updates when only a single external route changes. OSPF external LSAs also provide the following features. A forwarding address can be included in the external LSA, eliminating extra-hops at the edge of the Autonomous System. There are two levels of external metrics that can be specified, type 1 and type 2. Also, external routes can be tagged with a 32-bit number (the external route tag; commonly used as an AS number of the route's origin), simplifying external route management in a transit Autonomous System.
o 外部のルーティング情報のフレキシブルな輸入。 OSPFでは、別々のLSAのAutonomous Systemに各外部経路を輸入します。 これは氾濫交通の量を減少させます(外部経路がしばしば変化して、あなたが変化をあふれさせるだけでありたいので)。 また、ただ一つの外部経路だけが変化すると、それは部分的な経路指定テーブルアップデートを可能にします。 また、OSPFの外部のLSAsは以下の特徴を提供します。 Autonomous Systemの縁で余分なホップを排除して、外部のLSAにフォーワーディング・アドレスを含むことができます。 指定されて、1をタイプして、2をタイプできる2つのレベルの外部の測定基準が、あります。 また、32ビットの数(外部経路タグ; ルートの起源のAS番号として一般的に使用される)で外部経路にタグ付けをすることができます、トランジットAutonomous Systemにおける外部経路管理を簡素化して。
o Four level routing hierarchy. OSPF has a four level routing hierarchy, or trust model: intra-area, inter-area, external type 1 and external type 2 routes. This enables multiple levels of routing protection, and simplifies routing management in an Autonomous System.
o 4はルーティング階層構造を平らにします。 OSPFには、4の平らなルーティング階層構造、または信用モデルがあります: イントラ領域、相互領域、外部のタイプ1、および外部のタイプ2ルート。 これは、複数のレベルのルーティング保護を可能にして、Autonomous Systemでのルーティング管理を簡素化します。
[Moy] [Page 3] RFC 1245 OSPF protocol analysis July 1991
[Moy][3ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
o Virtual links. By allowing the configuration of virtual links, OSPF removes topological restrictions on area layout in an Autonomous System.
o 仮想のリンク。 仮想のリンクの構成を許すことによって、OSPFはAutonomous Systemの領域レイアウトのときに位相的な制限を取り除きます。
o Authentication of routing protocol exchanges. Every time an OSPF router receives a routing protocol packet, it authenticates the packet before processing it further.
o ルーティング・プロトコル交換の認証。 OSPFルータがルーティング・プロトコルパケットを受けるときはいつも、さらにそれを処理する前に、それはパケットを認証します。
o Flexible routing metric. In OSPF, metric are assigned to outbound router interfaces. The cost of a path is then the sum of the path's component interfaces. The routing metric itself can be assigned by the system administrator to indicate any combination of network characteristics (e.g., delay, bandwidth, dollar cost, etc.).
o フレキシブルなルーティング、メートル法です。 OSPFでは、メートル法であることは、外国行きに割り当てられて、ルータが連結するということです。 そして、経路の費用は経路のコンポーネントインタフェースの合計です。 ルーティング、メートル法、それ自体、システム管理者は、ネットワークの特性(例えば、遅れ、帯域幅、ドル費用など)のどんな組み合わせも示すために割り当てることができます。
o Equal-cost multipath. When multiple best cost routes to a destination exist, OSPF finds them and they can be then used to load share traffic to the destination.
o 等価コストマルチパス。 目的地への複数の最も良い費用ルートが存在していると、OSPFはそれらを見つけます、そして、次に、目的地へのシェア交通をロードするのにそれらは使用できます。
o TOS-based routing. Separate sets of routes can be calculated for each IP type of service. For example, low delay traffic could be routed on one path, while high bandwidth traffic is routed on another. This is done by (optionally) assigning, to each outgoing router interface, one metric for each IP TOS.
o TOSベースのルーティング。 それぞれのIPタイプのサービスのために別々のセットのルートを計算できます。 例えば、1つの経路で低い遅れ交通を発送できましたが、高帯域交通は別のもので発送されます。 (任意に)各IP TOSにおける、メートル法の1つをそれぞれの外向的なルータインタフェースに割り当てることによって、これをします。
o Variable-length subnet support. OSPF includes support for variable- length subnet masks by carrying a network mask with each advertised destination.
o 可変長のサブネットサポート。 OSPFは、それぞれの広告を出している目的地があるネットワークマスクを運ぶことによって、可変長さのサブネットマスクのサポートを含んでいます。
o Stub area support. To support routers having insufficient memory, areas can be configured as stubs. External LSAs (often making up the bulk of the Autonomous System) are not flooded into/throughout stub areas. Routing to external destinations in stub areas is based solely on default.
o 領域サポートを引き抜いてください。 不十分な記憶力を持っているルータを支持するために、スタッブとして領域を構成できます。 外部のLSAs(しばしばAutonomous Systemの嵩を補う)はスタッブ領域中に/へあふれません。 スタッブ領域の外部の目的地へのルート設定は唯一デフォルトに基づいています。
3.0 Cost of the protocol
3.0 プロトコルの費用
This section attempts to analyze how the OSPF protocol will perform and scale in the Internet. In this analysis, we will concentrate on the following four areas:
このセクションは、OSPFプロトコルがどうインターネットを実行して、計量するかを分析するのを試みます。 この分析では、私たちは以下の4つの領域に集中するつもりです:
o Link bandwidth. In OSPF, a reliable flooding mechanism is used to ensure that router link state databases are remained synchronized. Individual components of the link state databases (the LSAs) are refreshed infrequently (every 30 minutes), at least in the absence of topological changes. Still, as the size of the database increases, the amount of link bandwidth used by the flooding procedure also increases.
o 帯域幅をリンクしてください。 OSPFでは、ルータリンク州のデータベースをある使用される確実にする信頼できる氾濫メカニズムは連動したままで残っていました。 リンク州のデータベース(LSAs)の個々の成分はまれに(30分毎)リフレッシュされます、少なくとも位相的な変化がないとき。 それでも、また、データベースのサイズが増加するのに従って、氾濫手順で使用されるリンク帯域幅の量は増加します。
[Moy] [Page 4] RFC 1245 OSPF protocol analysis July 1991
[Moy][4ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
o Router memory. The size of an OSPF link state database can get quite large, especially in the presence of many external LSAs. This imposes requirements on the amount of router memory available.
o ルータメモリ。 OSPFリンク州のデータベースのサイズは特に多くの外部のLSAsの面前でかなり大きくなることができます。 これはルータメモリの有効な量に要件を課します。
o CPU usage. In OSPF, this is dominated by the length of time it takes to run the shortest path calculation (Dijkstra procedure). This is a function of the number of routers in the OSPF system.
o CPU用法。 OSPFでは、これは最短パス計算(ダイクストラ手順)を走らせるにはかかる時間の長さによって支配されます。 これはOSPFシステムのルータの数の関数です。
o Role of the Designated Router. The Designated router receives and sends more packets on a multi-access networks than the other routers connected to the network. Also, there is some time involved in cutting over to a new Designated Router after the old one fails (especially when both the Backup Designated Router and the Designated Router fail at the same time). For this reason, it is possible that you may want to limit the number of routers connected to a single network.
o 代表ルータの役割。 Designatedルータは、マルチアクセスネットワークの他のルータがネットワークに関させたより多くのパケットを受けて、送ります。 また、古い方が失敗した(特にBackup Designated RouterとDesignated Routerの両方が同時に失敗すると)後に新しいDesignated Routerへのカットオーバーするのにかかわるいくらかの時間があります。 この理由で、あなたがただ一つのネットワークに関連づけられたルータの数を制限したがっているのは、可能です。
The remaining section will analyze these areas, estimating how much resources the OSPF protocol will consume, both now and in the future. To aid in this analysis, the next section will present some data that have been collected in actual OSPF field deployments.
残っているセクションはこれらの領域を分析するでしょう、OSPFプロトコルが消費するどのくらいのリソースを見積もっていて、現在と将来。 この分析で支援するために、次のセクションは実際のOSPF分野展開で集められたいくつかのデータを提示するでしょう。
3.1 Operational data
3.1 操作上のデータ
The OSPF protocol has been deployed in a number of places in the Internet. For a summary of this deployment, see [1]. Some statistics have been gathered from this operational experience, via local network management facilities. Some of these statistics are presented in the following table:
OSPFプロトコルはインターネットの多くの場所で配備されました。 この展開の概要に関しては、[1]を見てください。 企業内情報通信網管理施設を通ってこの運用経験からいくつかの統計を集めてあります。 これらの統計のいくつかが以下のテーブルに提示されます:
TABLE 1. Pertinent operational statistics
1を見送ってください。 適切な操作上の統計
Statistic BARRNet NSI OARnet ___________________________________________________________________ Data gathering (duration) 99 hrs 277 hrs 28 hrs Dijkstra frequency 50 min 25 min 13 min External incremental frequency 1.2 min .98 min not gathered Database turnover 29.7 min 30.9 min 28.2 min LSAs per packet 3.38 3.16 2.99 Flooding retransmits 1.3% 1.4% .7%
統計値BARRNet NSI OARnet___________________________________________________________________ 1 3.38 3.16 2.99Floodingが1.3%1.4%.7%再送するパケットあたりの99時間277時間28時間の25分の50分のデータ集会(持続時間)ダイクストラ頻度の13分のExternalの増加の頻度の.98分の1.2分集まっていないDatabase取引高の29.7分30.9分28.2分のLSAs
The first line in the above table show the length of time that statistics were gathered on the three networks. A brief description of the other statistics follows:
統計が3つのネットワークに集められた時間の長さの上のテーブルショーにおける最初の線。 他の統計の簡単な説明は続きます:
[Moy] [Page 5] RFC 1245 OSPF protocol analysis July 1991
[Moy][5ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
o Dijkstra frequency. In OSPF, the Dijkstra calculation involves only those routers and transit networks belonging to the AS. The Dijkstra is run only when something in the system changes (like a serial line between two routers goes down). Note that in these operational systems, the Dijkstra process runs only infrequently (the most frequent being every 13 minutes).
o ダイクストラ頻度。 OSPFに、ダイクストラの計算はASに属すそれらのルータと輸送網だけにかかわります。 システムの何かが変化するときだけ(2つのルータの間のシリアル・ラインが落ちるように)、ダイクストラは車で送られます。 これらの基幹系システムでは、ダイクストラの過程がまれに(最も頻繁な13分毎であるのに)だけ走ることに注意してください。
o External incremental frequency. In OSPF, when an external route changes only its entry in the routing table is recalculated. These are called external incremental updates. Note that these happen much more frequently than the Dijkstra procedure. (in other words, incremental updates are saving quite a bit of processor time).
o 外部の増加の頻度。 外部経路が変化するとき、OSPFでは、経路指定テーブルのエントリーだけが再計算されます。 これらは外部のアップデート増加と呼ばれます。 これらがダイクストラ手順よりはるかに頻繁に起こることに注意してください。 (言い換えれば、アップデート増加はかなりのプロセッサ時間を節約しています。)
o Database turnover. In OSPF, link state advertisements are refreshed at a minimum of every 30 minutes. New advertisement instances are sent out more frequently when some part of the topology changes. The table shows that, even taking topological changes into account, on average an advertisement is updated close to only every 30 minutes. This statistic will be used in the link bandwidth calculations below. Note that NSI actually shows advertisements updated every 30.7 (> 30) minutes. This probably means that at one time earlier in the measurement period, NSI had a smaller link state database that it did at the end.
o データベース取引高OSPFでは、リンク州の広告は最小あらゆる30分にリフレッシュされます。 トポロジーの何らかの部分が変化するとき、より頻繁に新しい広告例を出します。 テーブルは、位相的な変化を考慮に入れさえして、平均的に、30分毎の近く間広告をアップデートするのを示します。 この統計値は以下でのリンク帯域幅計算に使用されるでしょう。 NSIが実際に30.7(>30)分毎にアップデートされた広告を示すことに注意してください。 NSIには、これは測定時代に前にひところたぶんそれを意味して、それが終わりにしたより小さいリンク州のデータベースがありました。
o LSAs per packet. In OSPF, multiple LSAs can be included in either Link State Update or Link State Acknowledgment packets.The table shows that, on average, around 3 LSAs are carried in a single packet. This statistic is used when calculating the header overhead in the link bandwidth calculation below. This statistic was derived by diving the number of LSAs flooded by the number of (non-hello) multicasts sent.
o 1パケットあたりのLSAs。 OSPFでは、Link州Updateに複数のLSAsを含むことができますか、またはLink州Acknowledgment packets.Theテーブルは、およそ3LSAsが単一のパケットで平均で運ばれるのを示します。 以下でのリンク帯域幅計算におけるヘッダーオーバーヘッドについて計算するとき、この統計値は使用されています。 この統計値が数に従ってLSAsの数が浸水したダイビングによって引き出された、(非、こんにちは、)、マルチキャストは発信しました。
o Flooding retransmits. This counts both retransmission of LS Update packets and Link State Acknowledgment packets, as a percentage of the original multicast flooded packets. The table shows that flooding is working well, and that retransmits can be ignored in the link bandwidth calculation below.
o 氾濫は再送されます。 これはLS Updateパケットの「再-トランスミッション」とLink州Acknowledgmentパケットの両方を数えます、オリジナルのマルチキャストの割合がパケットをあふれさせたので。 以下でのリンク帯域幅計算で氾濫がよく扱っていて、それが再送するテーブルショーを無視できます。
3.2 Link bandwidth
3.2 リンク帯域幅
In this section we attempt to calculate how much link bandwidth is consumed by the OSPF flooding process. The amount of link bandwidth consumed increases linearly with the number of advertisements present in the OSPF database.We assume that the majority of advertisements in the database will be AS external LSAs (operationally this is true, see [1]).
このセクションでは、私たちは、どのくらいのリンク帯域幅がOSPF氾濫工程で消費されるかを見込むのを試みます。 広告の数が存在していた状態で消費された増加がOSPF database.Weで直線的であるリンク帯域幅の量は、データベースにおける広告の大部分がASの外部のLSAsになると仮定します。(これは操作上、本当であり、[1])を考えてください。
From the statistics presented in Section 3.1, any particular advertisement is flooded (on average) every 30 minutes. In addition,
セクション3.1に提示された統計から、どんな特定の広告も(平均的に)30分毎に水につかっています。 さらに
[Moy] [Page 6] RFC 1245 OSPF protocol analysis July 1991
[Moy][6ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
three advertisements fit in a single packet. (This packet could be either a Link State Update packet or a Link State Acknowledgment packet; in this analysis we select the Link State Update packet, which is the larger). An AS external LSA is 36 bytes long. Adding one third of a packet header (IP header plus OSPF Update packet) yields 52 bytes. Transmitting this amount of data every 30 minutes gives an average rate of 23/100 bits/second.
3つの広告が単一のパケットをうまくはめ込みます。 (このパケットは、Link州UpdateパケットかLink州Acknowledgmentパケットのどちらかであるかもしれません; この分析では、私たちはLink州Updateパケットを選択します。)(パケットは、より大きいです)。 ASの外部のLSAは36バイト長です。 パケットのヘッダー(IPヘッダープラスOSPF Updateパケット)の付加onethirdは52バイトもたらします。 30分毎にこのデータ量を伝えると、23/100ビット/秒の平均相場は与えられます。
If you want to limit your routing traffic to 5% of the link's total bandwidth, you get the following maximums for database size:
リンクの総帯域幅の5%へのあなたのルーティング交通を制限したいなら、あなたはデータベースサイズのために以下の最大を得ます:
TABLE 2. Database size as a function of link speed (5% utilization)
2を見送ってください。 リンク速度の関数としてのデータベースサイズ(5%の利用)
Speed # external advertisements
_____________________________________
9.6 Kb 2087
56 Kb 12,174
#外部の広告を促進してください。_____________________________________ 9.6KB2087 56KB12,174
Higher line speeds have not been included, because other factors will then limit database size (like router memory) before line speed becomes a factor. Note that in the above calculation, the size of the data link header was not taken into account. Also, note that while the OSPF database is likely to be mostly external LSAs, other LSAs have a size also. As a ballpark estimate, router links and network links are generally three times as large as an AS external link, with summary link advertisements being the same size as external link LSAs.
より高いライン・スピードは含まれていません、次に、ライン・スピードが要素になる前に他の要素がデータベースサイズ(ルータメモリのような)を制限するので。 上の計算では、データ・リンクヘッダーのサイズが考慮に入れられなかったことに注意してください。 また、OSPFデータベースがほとんど外部のLSAsである傾向がある間他のLSAsにはサイズもあることに注意してください。 球場見積りとして、一般に、ルータリンクとネットワークリンクはASの外部のリンクの3倍大きいです、外部のリンクLSAsと同じサイズである概要リンク広告で。
OSPF consumes considerably less link bandwidth than RIP. This has been shown experimentally in the NSI network. See Jeffrey Burgan's "NASA Sciences Internet" report in [3].
OSPFはRIPよりかなり少ないリンク帯域幅を消費します。 これはNSIネットワークで実験的に示されました。 [3]で「NASA科学インターネット」というジェフリー・ブルガンのレポートを見てください。
3.3 Router memory
3.3 ルータメモリ
Memory requirements in OSPF are dominated by the size of the link state database. As in the previous section, it is probably safe to assume that most of the advertisements in the database are external LSAs. While an external LSA is 36 bytes long, it is generally stored by an OSPF implementation together with some support data. So a good estimate of router memory consumed by an external LSA is probably 64 bytes. So a database having 10,000 external LSAs will consume 640K bytes of router memory. OSPF definitely requires more memory than RIP.
OSPFのメモリ要件はリンク州のデータベースのサイズによって支配されます。 前項のように、データベースにおける広告の大部分が外部のLSAsであると仮定するのはたぶん安全です。 外部のLSAが36バイト長である間、一般に、それはOSPF実現でいくつかのサポートデータと共に格納されます。 それで、外部のLSAによって消費されたルータメモリの良い見積りはたぶん64バイトです。 それで、1万外部のLSAsを持っているデータベースは640Kのバイトのルータメモリを消費するでしょう。 OSPFは確実にRIPより多くのメモリを必要とします。
Using the Proteon P4200 implementation as an example, the P4200 has 2Mbytes of memory. This is shared between instruction, data and packet buffer memory. The P4200 has enough memory to store 10, 000 external
例としてProteon P4200実現を使用して、P4200にはメモリの2Mbytesがあります。 これは指示と、データとパケットバッファメモリの間で共有されます。 P4200は10、000を格納できるくらいの記憶力を外部にします。
[Moy] [Page 7] RFC 1245 OSPF protocol analysis July 1991
[Moy][7ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
LSAs, and still have enough packet buffer memory available to run a reasonable number of interfaces.
LSAs、およびスチール写真はそうしました。相当な数のインタフェースを走らせるために利用可能な十分なパケットバッファメモリ。
Also, note that while the OSPF database is likely to be mostly external LSAs, other LSAs have a size also. As a ballpark estimate, router links and network links consume generally three times as much memory as an AS external link, with summary link advertisements being the same size as external link LSAs.
また、OSPFデータベースがほとんど外部のLSAsである傾向がある間他のLSAsにはサイズもあることに注意してください。 球場見積りとして、ルータリンクとネットワークリンクは一般に、ASの外部のリンクの3倍のメモリを消費します、外部のリンクLSAsと同じサイズである概要リンク広告で。
3.4 Router CPU
3.4 ルータCPU
Assume that, as the size of the OSPF routing domain grows, the number of interfaces per router stays bounded. Then the Dijkstra calculation is of order (n * log (n)), where n is the number of routers in the routing domain. (This is the complexity of the Dijkstra algorithm in a sparse network). Of course, it is implementation specific as to how expensive the Dijkstra really is.
OSPF経路ドメインのサイズが成長するのに従ってルータ滞在あたりのインタフェースの数がバウンドしたと仮定してください。 次に、ダイクストラの計算はオーダーのそうです。(n*ログ(n))。(そこでは、nが経路ドメインのルータの数です)。 (これはまばらなネットワークで、ダイクストラアルゴリズムの複雑さです。) もちろん、それはダイクストラが本当にどれくらい高価であるかに関して特定の実現です。
We have no experimental numbers for the cost of the Dijkstra calculation in a real OSPF implementation. However, Steve Deering presented results for the Dijkstra calculation in the "MOSPF meeting report" in [3]. Steve's calculation was done on a DEC 5000 (10 mips processor), using the Stanford internet as a model. His graphs are based on numbers of networks, not number of routers. However, if we extrapolate that the ratio of routers to networks remains the same, the time to run Dijkstra for 200 routers in Steve's implementation was around 15 milliseconds.
私たちには、本当のOSPF実現における、ダイクストラの計算の費用のどんな実験数もありません。 しかしながら、スティーブ・デアリングは[3]の「MOSPFミーティングレポート」におけるダイクストラの計算のために結果を提示しました。 モデルとしてスタンフォードインターネットを使用して、5000(10mipsプロセッサ)年12月にスティーブの計算をしました。 彼のグラフはルータの数ではなく、ネットワークの数に基づいています。 しかしながら、私たちがそれを推定するなら、ルータ対ネットワークの比率は同じままで残っています、スティーブの実現における200のルータのためにダイクストラを車で送るのが、およそ15ミリセカンドであった時代に。
This seems a reasonable cost, particularly when you notice that the Dijkstra calculation is run very infrequently in operational deployments. In the three networks presented in Section 3.1, Dijkstra was run on average only every 13 to 50 minutes. Since the Dijkstra is run so infrequently, it seems likely that OSPF overall consumes less CPU than RIP (because of RIP's frequent updates, requiring routing table lookups).
特にあなたが、ダイクストラの計算が操作上の展開で非常にまれに走るのに気付くと、これは手頃な費用に見えます。 セクション3.1に提示された3つのネットワークでは、ダイクストラは13〜50分毎に平均的に車で送られました。 ダイクストラが非常にまれに車で送られるので、RIP(RIPの頻繁なアップデートのために経路指定テーブルルックアップを必要とする)より少ないCPUが全体的に見てOSPFは消費されそうです。
As another example, the routing algorithm in MILNET is SPF-based. MILNET's current size is 230 nodes, and the routing calculation still consumes less than 5% of the MILNET switches' processor bandwidth [4]. Because the routing algorithm in the MILNET adapts to network load, it runs the Dijkstra process quite frequently (on the order of seconds as compared to OSPF's minutes). However, it should be noted that the routing algorithm in MILNET incrementally updates the SPF-tree, while OSPF rebuilds it from scratch at each Dijkstra calculation
別の例として、MILNETのルーティング・アルゴリズムはSPFベースです。 MILNETの現在のサイズは230のノードです、そして、ルーティング計算はまだMILNETスイッチのプロセッサ帯域幅[4]の5%未満を消費しています。 MILNETのルーティング・アルゴリズムがネットワーク負荷に順応するので、それはダイクストラの過程をかなり頻繁(比較されるとしての秒のOSPFの数分までの注文に関して)に走らせます。 しかしながら、MILNETのルーティング・アルゴリズムがSPF-木を増加してアップデートすることに注意されるべきです、OSPFはそれぞれのダイクストラの計算のときに最初から、それを再建しますが
OSPF's Area capability provides a way to reduce Dijkstra overhead, if it becomes a burden. The routing domain can be split into areas. The extent of the Dijkstra calculation (and its complexity) is limited to a single
負担になるなら、OSPFのArea能力はダイクストラオーバーヘッドを下げる方法を提供します。 経路ドメインを領域に分けることができます。 ダイクストラの計算(そして、複雑さ)の範囲はシングルに制限されます。
[Moy] [Page 8] RFC 1245 OSPF protocol analysis July 1991
[Moy][8ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
area at a time.
一度に領域。
3.5 Role of Designated Router
3.5 代表ルータの役割
This section explores the number of routers that can be attached to a single network. As the number of routers attached to a network grows, so does the amount of OSPF routing traffic seen on the network. Some of this is Hello traffic, which is generally multicast by each router every 10 seconds. This burden is borne by all routers attached to the network. However, because of its special role in the flooding process, the Designated router ends up sending more Link State Updates than the other routers on the network. Also, the Designated Router receives Link State Acknowledgments from all attached routers, while the other routers just receive them from the DR. (Although it is important to note that the rate of Link State Acknowledgments will generally be limited to one per second from each router, because acknowledgments are generally delayed.)
このセクションはただ一つのネットワークに付けることができるルータの数について調査します。 ネットワークに付けられたルータの数が成長するとき、ネットワークで見られたOSPFルーティング交通の量もそうします。 この何かがHello交通です。(一般に、その交通は各ルータによる10秒毎のマルチキャストです)。 この負担はネットワークに付けられたすべてのルータによって持たれています。 しかしながら、氾濫の過程における特別な役割のために、Designatedルータは結局、他のルータより多くのLink州Updatesをネットワークに送ります。 また、Designated Routerはすべての付属ルータからLink州Acknowledgmentsを受けます、他のルータがDRからそれらをただ受けますが。(それに注意するのが重要ですが、一般に、Link州Acknowledgmentsのレートは各ルータから1秒あたり1つに制限されるでしょう、承認が一般に遅れるので。)
So, if the amount of protocol traffic on the LAN becomes a limiting factor, the limit is likely to be detected in the Designated Router first. However, such a limit is not expected to be reached in practice. The amount of routing protocol traffic generated by OSPF has been shown to be small (see Section 3.2). Also, if need be OSPF's hello timers can be configured to reduce the amount of protocol traffic on the network. Note that more than 50 routers have been simulated attached to a single LAN (see [1]). Also, in interoperability testing 13 routers have been attached to a single ethernet with no problems encountered.
それで、LANにおけるプロトコル交通の量が限定因子になるなら、限界は最初に、Designated Routerに検出されそうです。 しかしながら、実際にはそのような限界によって達せられないと予想されます。 OSPFによって発生するルーティング・プロトコル交通の量は、小さくなるように示されました(セクション3.2を見てください)。 必要ならOSPFのもの、もこんにちは、ネットワークにおけるプロトコル交通の量を減少させるためにタイマを構成できます。 50以上のルータがシミュレートされたというメモは単一のLANに付きました。([1])を見てください。 また、相互運用性テストで、問題が全く行きあたられていなく、13のルータがただ一つのイーサネットに付けられています。
Another factor in the number of routers attached to a single network is the cutover time when the Designated Router fails. OSPF has a Backup Designated Router so that the cutover does not have to wait for the new DR to synchronize (the adjacency bring-up process mentioned earlier) with all the other routers on the LAN; as a Backup DR it had already synchronized. However, in those rare cases when both DR and Backup DR crash at the same time, the new DR will have to synchronize (via the adjacency bring-up process) with all other routers before becoming functional. Field experience show that this synchronization process takes place in a timely fashion (see the OARnet report in [1]). However, this may be an issue in systems that have many routers attached to a single network.
ただ一つのネットワークに付けられたルータの数の別の要素はDesignated Routerが失敗するカットオーバ時です。 OSPFにはBackup Designated Routerがあるので、カットオーバはLANに関する他のすべてのルータで連動する新しいDR(隣接番組は、より早く言及された過程を持って来る)を待つ必要はありません。 Backup DRとして、それは既に連動しました。 しかしながら、DRとBackup DRの両方が同時にクラッシュするときのそれらのまれなケースでは、新しいDRは機能的になる前の他のすべてのルータに連動しなければならないでしょう(隣接番組で、過程を持って来てください)。 実地経験は、この同期の過程が直ちに行われるのを示します。([1])でOARnetレポートを見てください。 しかしながら、これは多くのルータをただ一つのネットワークに付けるシステムの問題であるかもしれません。
In the unlikely event that the number of routers attached to a LAN becomes a problem, either due to the amount of routing protocol traffic or the cutover time, the LAN can be split into separate pieces (similar to splitting up the AS into separate areas).
ありそうもない出来事では、ルータの数がLANに付いたのは問題になります、ルーティング・プロトコル交通の量かカットオーバ時間のためLANは別々の断片(ASを分離した部分に分けるのと同様の)に分けることができます。
[Moy] [Page 9] RFC 1245 OSPF protocol analysis July 1991
[Moy][9ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
3.6 Summary
3.6 概要
In summary, it seems like the most likely limitation to the size of an OSPF system is available router memory. We have given as 10,000 as the number of external LSAs that can be supported by the memory available in one configuration of a particular implementation (the Proteon P4200). Other implementations may vary; nowadays routers are being built with more and more memory. Note that 10,000 routes is considerably larger than the largest field implementation (BARRNet; which at 1816 external LSAs is still very large).
概要では、OSPFシステムのサイズへの最もありそうな制限が利用可能なルータメモリであるように見えます。 私たちには、特定の実現(Proteon P4200)の1つの構成で利用可能なそれを支持できる外部のLSAsの数としての1万として与えられた記憶力があります。 他の実現は異なるかもしれません。 この頃は、ルータはますます多くのメモリで築き上げられています。 1万のルートが最も大きい分野実現(BARRNet;1816外部のLSAsでまだ非常に大きい )よりかなり大きいことに注意してください。
Note that there may be ways to reduce database size in a routing domain. First, the domain can make use of default routing, reducing the number of external routes that need to be imported. Secondly, an EGP can be used that will transport its own information through the AS instead of relying on the IGP (OSPF in this case) to do transfer the information for it (the EGP). Thirdly, routers having insufficient memory may be able to be assigned to stub areas (whose databases are drastically smaller). Lastly, if the Internet went away from a flat address space the amount of external information imported into an OSPF domain could be reduced drastically.
経路ドメインでデータベースサイズを減少させる方法があるかもしれないことに注意してください。 まず最初に、輸入される必要がある外部経路の数を減少させて、ドメインはデフォルトルーティングを利用できます。 第二に、それ(EGP)のための情報を移すために、IGP(この場合、OSPF)を当てにすることの代わりにASを通してそれ自身の情報を輸送するEGPは使用できます。 三番目に、不十分な記憶力を持っているルータは、領域(データベースは抜本的に小さい)を引き抜くために割り当てることができるかもしれません。 最後に、インターネットがフラットアドレス空間から遠ざかるなら、OSPFドメインに輸入された外部の情報の量は抜本的に減少できるでしょうに。
While not as likely, there could be other issues that would limit the size of an OSPF routing domain. If there are slow lines (like 9600 baud), the size of the database will be limited (see Section 3.2). Dijkstra may get to be expensive when there are hundreds of routers in the OSPF domain; although at this point the domain can be split into areas. Finally, when there are many routers attached to a single network, there may be undue burden imposed upon the Designated Router; although at that point a LAN can be split into separate LANs.
ありそうでない間、OSPF経路ドメインのサイズを制限する他の問題があるかもしれません。 遅い線(9600年のボーのような)があると、データベースのサイズは制限されるでしょう(セクション3.2を見てください)。 ダイクストラは、何百ものルータがOSPFドメインにあるとき、高価であり始めるかもしれません。 ここにドメインを領域に分けることができますが。 ただ一つのネットワークに付けられた多くのルータがあるとき、最終的に、Designated Routerに課された不当な負担があるかもしれません。 その時、LANを別々のLANに分けることができますが。
4.0 Suitable environments
4.0 適当な環境
Suitable environments for the OSPF protocol range from large to small. OSPF is particular suited for transit Autonomous Systems for the following reasons. OSPF can accommodate a large number of external routes. In OSPF the import of external information is very flexible, having provisions for a forwarding address, two levels of external metrics, and the ability to tag external routes with their AS number for easy management. Also OSPF's ability to do partial updates when external information changes is very useful on these networks.
OSPFプロトコルのための適当な環境は大きいのから小さくなるまで及びます。 OSPFは以下の理由によるトランジットAutonomous Systemsに合った状態で特定です。 OSPFは多くの外部経路に対応できます。 OSPFでは、外部の情報の輸入は非常にフレキシブルです、フォーワーディング・アドレスのための条項、2つのレベルの外部の測定基準、およびそれらの簡単な管理のAS番号を外部経路にタグ付けする能力を持っていて。 外部の情報が変化するとき部分的なアップデートをするOSPFのも性能はこれらのネットワークで非常に役に立ちます。
OSPF is also suited for smaller, either stand alone or stub Autonomous Systems, because of its wide array of features: fast convergence, equal-cost-multipath, TOS routing, areas, etc.
また、OSPFのために、より小さく適合されていて、どちらかがスタンドアロンであるか特徴の広い勢ぞろいのためにスタッブはAutonomous Systemsです: 速い集合、等しい費用多重通路、TOSルーティング、領域など
[Moy] [Page 10] RFC 1245 OSPF protocol analysis July 1991
[Moy][10ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
5.0 Unsuitable environments
5.0 不適当な環境
OSPF has a very limited ability to express policy. Basically, its only policy mechanisms are in the establishment of a four level routing hierarchy: intra-area, inter-area, type 1 and type 2 external routes. A system wanting more sophisticated policies would have to be split up into separate ASes, running a policy-based EGP between them.
OSPFには、方針を言い表す非常に限られた能力があります。 基本的に、唯一の方針メカニズムが4の平らなルーティング階層構造の確立中です: イントラ領域、相互領域は、1をタイプして、2個の外部経路をタイプします。 より高度な方針を必要とするシステムは別々のASesに分けられなければならないでしょう、彼らの間の方針ベースのEGPを実行して。
6.0 Reference Documents
6.0 参照ドキュメント
The following documents have been referenced by this report:
以下のドキュメントはこのレポートによって参照をつけられました:
[1] Moy, J., "Experience with the OSPF protocol", RFC 1246, July 1991.
Moy(J.)が「OSPFプロトコルで経験する」[1]、RFC1246、1991年7月。
[2] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[2]Moy、J.、「OSPF、バージョン2インチ、RFC1247、1991インチ年7月。
[3] Corporation for National Research Initiatives, "Proceedings of the
Eighteenth Internet Engineering Task Force", University of British
Columbia, July 30-August 3, 1990.
[3] 国家の研究イニシアチブ、「第18インターネット・エンジニアリング・タスク・フォースの議事」、ブリティッシュ・コロンビア大学、1990 7月30日〜8月3日の社。
[Moy] [Page 11] RFC 1245 OSPF protocol analysis July 1991
[Moy][11ページ]RFC1245OSPFは1991年7月に分析について議定書の中で述べます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
John Moy Proteon Inc. 2 Technology Drive Westborough, MA 01581
Driveウェストボーラフ、ジョンMoy Proteon Inc.2Technology MA 01581
Phone: (508) 898-2800 Email: jmoy@proteon.com
以下に電話をしてください。 (508) 898-2800 メールしてください: jmoy@proteon.com
[Moy] [Page 12]
[Moy][12ページ]
一覧
スポンサーリンク
