RFC1793 日本語訳
1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. (Format: TXT=78728 bytes) (Updated by RFC3883) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy Request for Comments: 1793 Cascade Category: Standards Track April 1995
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1793年の滝のカテゴリ: 標準化過程1995年4月
Extending OSPF to Support Demand Circuits
要求サーキットを支えるためにOSPFを広げています。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines. The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic.
このメモはOSPFプロトコルへの「要求サーキット」の上の効率的な操作を許す増進を定義します。 要求サーキットはコストが用法で異なるネットワークセグメントです。 料金は、ともに接続時間に基づいていて、バイト/パケットの上で伝えることができます。 要求サーキットに関する例はISDNサーキット、X.25 SVCs、およびダイヤルアップ線を含んでいます。 交通が現在まで持っているOSPFルーティングの周期的な本質は、要求サーキットの基本的なデータリンク接続が絶えずオープンであることを必要としました、求められていない用法料金をもたらして。 そして、ここに説明された変更、OSPFハローズ、要求サーキットの上に抑圧されて、アプリケーション交通を運ばないとき基本的なデータリンク接続が閉じているのを許容しながら、OSPFルーティング情報をリフレッシュしてください。
Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open.
要求サーキットとレギュラー・ネットワークセグメント(例えば、専用線)はどんな方法でも結合できます。 言い換えれば、要求サーキットサポートにはどんな位相的な制限もありません。 しかしながら、どんなOSPFネットワークセグメントも要求サーキットと定義できる間、二地点間ネットワークだけが完全給付を受け取ります。 放送とNBMAネットワークが要求サーキットであると宣言されますが、ルーティングアップデート交通が抑えられますが、ハローズの周期的な発信が抑えられるというわけではないとき(事実上、データリンク接続が絶えず開いたままで残っているのをまだ必要としています)。
While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio.
また、ISDNや、X.25やダイヤルアップなどのコスト意識が高いネットワークリンクによる使用のために主に意図している間、このメモにおける変更は遅い速度専用線やパケットラジオなどの帯域幅で限られたネットワークリンクの上に有用であることが分かるかもしれません。
The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point-
このメモで定義された増進は[1]で定義されるOSPF仕様、および[3](OSPF NSSA領域)、[4](MOSPF)、および[8]で定義されるOSPF拡張子と互換性がある、後方の(OSPF Point
Moy [Page 1] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[1ページ]RFC1793OSPF
to-MultiPoint Interface).
多点へのインタフェース)
This memo provides functionality similar to that specified for RIP in [2], with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, because OSPF employs link-state routing technology as opposed to RIP's Distance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different.
このメモは[2]でRIPに指定されたそれと同様の機能性を提供します、2つの提案が応募超過を扱う(以下のセクション4.3と7を見てください)方法である主な違いで。 しかしながら、OSPFがRIPのDistance Vectorベースと対照的にLinkState方式技術を使うので、要求サーキットの機能性を達成するのに使用されるメカニズムは全く異なっています。
Please send comments to ospf@gated.cornell.edu.
コメントを ospf@gated.cornell.edu に送ってください。
Acknowledgments
承認
The author would like to acknowledge the helpful comments of Fred Baker, Rob Coltun, Dawn Li, Gerry Meyer, Tom Pusateri and Zhaohui Zhang. This memo is a product of the OSPF Working Group.
作者はフレッド・ベイカー、ロブColtun、ドーン・李、ゲリー・マイヤー、トムPusateri、およびZhaohuiチャンの役に立つコメントを承諾したがっています。 このメモはOSPF作業部会の製品です。
Table of Contents
目次
1. Model for demand circuits .............................. 3
2. Modifications to all OSPF routers ...................... 4
2.1 The OSPF Options field ................................. 4
2.2 The LS age field ....................................... 5
2.3 Removing stale DoNotAge LSAs ........................... 6
2.4 A change to the flooding algorithm ..................... 6
2.5 Interoperability with unmodified OSPF routers .......... 7
2.5.1 Indicating across area boundaries ...................... 8
2.5.1.1 Limiting indication-LSA origination .................... 9
3. Modifications to demand circuit endpoints ............. 10
3.1 Interface State machine modifications ................. 10
3.2 Sending and Receiving OSPF Hellos ..................... 11
3.2.1 Negotiating Hello suppression ......................... 11
3.2.2 Neighbor state machine modifications .................. 12
3.3 Flooding over demand circuits ......................... 12
3.4 Virtual link support .................................. 13
3.5 Point-to-MultiPoint Interface support ................. 14
4. Examples .............................................. 15
4.1 Example 1: Sole connectivity through demand circuits .. 15
4.2 Example 2: Demand and non-demand circuits in parallel . 19
4.3 Example 3: Operation when oversubscribed .............. 23
5. Topology recommendations .............................. 25
6. Lost functionality .................................... 25
7. Future work: Oversubscription ......................... 26
8. Unsupported capabilities .............................. 28
A. Format of the OSPF Options field ...................... 30
B. Configurable Parameters ............................... 31
C. Architectural Constants ............................... 31
References ............................................ 32
1. 要求サーキットにモデル化してください… 3 2. すべてのOSPFルータへの変更… 4 2.1 OSPF Options分野… 4 2.2 LSは分野に年をとらせます… 5 2.3 聞き古したDoNotAge LSAsを取り外します… 6 2.4 氾濫アルゴリズムへの変化… 6 変更されていないOSPFルータがある2.5相互運用性… 7 2.5 .1 エリアの境界の向こう側に示します。 8 2.5 .1 .1 指示-LSA創作を制限します… 9 3. サーキット終点を要求する変更… 10 3.1 州マシン変更を連結してください… 10 3.2 送受信OSPFハローズ… 11 3.2 .1 Hello抑圧を交渉します… 11 3.2 .2隣人はマシン変更を述べます… 12 3.3 要求サーキットの上の氾濫… 12 3.4 仮想のリンクサポート… 13 3.5 ポイントからMultiPoint Interfaceへのサポート… 14 4. 例… 15 4.1 例1: 要求サーキットを通した唯一の接続性。 15 4.2 例2: 平行な.194.3Example3の要求と非要求サーキット: 申込みが超過しているときの操作… 23 5. トポロジー推薦… 25 6. 機能性を失います… 25 7. 今後の活動: 応募超過… 26 8. サポートされない能力… 28 OSPF Options分野のA.形式… 30 B.の構成可能なパラメタ… 31 C.の建築定数… 31の参照箇所… 32
Moy [Page 2] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[2ページ]RFC1793OSPF
Security Considerations ............................... 32
Author's Address ...................................... 32
セキュリティ問題… 32作者のアドレス… 32
1. Model for demand circuits
1. 要求サーキットにモデル化してください。
In this memo, demand circuits refer to those network segments whose cost depends on either connect time and/or usage (expressed in terms of bytes or packets). Examples include ISDN circuits and X.25 SVCs. On these circuits, it is desirable for a routing protocol to send as little routing traffic as possible. In fact, when there is no change in network topology it is desirable for a routing protocol to send no routing traffic at all; this allows the underlying data-link connection to be closed when not needed for application data traffic.
このメモでは、要求サーキットは費用を接続時間に依存するそれらのネットワークセグメント、そして/または、用法(バイトかパケットに関して、言い表される)を示します。 例はISDNサーキットとX.25 SVCsを含んでいます。 これらのサーキットでは、ルーティング・プロトコルができるだけほとんどルーティング交通を送らないのは、望ましいです。 全く交通を発送しないルーティング・プロトコルが送るのが、望ましいネットワーク形態における変化が全く事実上ないとき。 これで、アプリケーションデータ通信量に必要でないと、基本的なデータリンク接続は閉店します。
The model used within this memo for the maintenance of demand circuits is as follows. If there is no data to send (either routing protocol traffic or application data), the data-link connection remains closed. As soon as there is data to be sent, an attempt to open the data-link connection is made (e.g., an ISDN or X.25 call is placed). When/if the data-link connection is established, the data is sent, and the connection stays open until some period of time elapses without more data to send. At this point the data-link connection is again closed, in order to conserve cost and resources (see Section 1 of [2]).
要求サーキットのメンテナンスにこのメモの中で使用されたモデルは以下の通りです。 送るデータ(ルーティング・プロトコル交通かアプリケーションデータのどちらか)が全くなければ、データリンク接続は閉じられたままで残っています。 送られるデータがあるとすぐに、データリンク接続を開く試みをします(例えばISDNかX.25電話が出されます)。 データリンク接続であるなら/を設立するとき、データを送ります、そして、いくつかの期間が送るより多くのデータなしで経過するまで、接続は開くままです。 ここにデータリンク接続は再び閉店します、費用と資源を節約するために。([2])のセクション1を見てください。
The "Presumption of Reachability" described in [2] is also used. Even though a circuit's data-link connection may be closed at any particular time, it is assumed by the routing layer (i.e., OSPF) that the circuit is available unless other information, such as a discouraging diagnostic code resulting from an attempted data-link connection, is present.
また、[2]で説明された「可到達性の推定」は使用されます。 サーキットのデータリンク接続は特定の何時でも閉店するかもしれませんが、他の情報が試みられたデータリンク接続から生じるがっかりしている診断コードのように存在していない場合サーキットが利用可能であるとルーティング層(すなわち、OSPF)によって思われます。
It may be possible that a data-link connection cannot be established due to resource shortages. For example, a router with a single basic rate ISDN interface cannot open more than two simultaneous ISDN data-link connections (one for each B channel), and limitations in interface firmware and/or switch capacity may limit the number of X.25 SVCs simultaneously supported. When a router cannot simultaneously open all of its circuits' underlying data-link connections due to resource limitations, we say that the router is oversubscribed. In these cases, datagrams to be forwarded out the (temporarily unopenable) data-link connections are discarded, instead of being queued. Note also that this temporary inability to open data-link connections due to oversubscription is NOT reported by the OSPF routing system as unreachability; see Section 4.3 for more information.
リソース不足のためデータリンク接続を確立できないのは可能であるかもしれません。 例えば、単一の基本料金ISDNインタフェースがあるルータは2人以上の同時のISDNデータリンク接続(各Bチャネルあたり1つ)を開くことができません、そして、インタフェースファームウェア、そして/または、スイッチ容量における制限は同時に支持されたX.25 SVCsの数を制限するかもしれません。 ルータが同時にリソース制限によるサーキットの基本的なデータリンク接続のすべてを開くことができないなら、私たちは、ルータが申込みが超過していると言います。 これらの場合では、列に並ばせられることの代わりに(一時「非-開-可能」)のデータリンク接続から進められるデータグラムは捨てられます。 また、応募超過によるデータリンク接続を開くことができないこの一時的なことが「非-可到達性」としてOSPFルーティングシステムによって報告されないことに注意してください。 詳しい情報に関してセクション4.3を見てください。
Moy [Page 3] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[3ページ]RFC1793OSPF
Either end of a demand circuit may attempt to open the data-link connection. When both ends attempt to open the connection simultaneously, there is the possibility of call collision. Not all data-links specify how call collisions are handled. Also, while OSPF requires that all periodic timers be randomized to avoid synchronization (see Section 4.4 of [1]), if call attempts are strictly data-driven there may still be insufficient spacing of call attempts to avoid collisions on some data-links. For these reasons, for those data-links without collision detection/avoidance support, it is suggested (but not specified herein) that an exponential backoff scheme for call retries be employed at the data-link layer. Besides helping with call collisions, such a scheme could minimize charges (if they exist) for failed call attempts.
要求サーキットのどちらの端も、データリンク接続を開くのを試みるかもしれません。 両端が、同時に接続を開くのを試みるとき、呼び出し衝突の可能性があります。 すべてのデータ・リンクが呼び出し衝突がどう扱われるかを指定するというわけではありません。 また、OSPFがすべてそんなに周期的なタイマを必要としている間、ランダマイズされます。([1])のセクション4.4を見てください、同期を避けてください、そして、呼び出し試みが厳密に、そこのデータ駆動型がまだいくつかのデータ・リンクの上で衝突を避ける呼び出し試みの不十分なスペースであるかもしれないということであるなら。 これらの理由、衝突検出/回避サポートのないそれらのデータ・リンクに関しては、呼び出し再試行の指数のbackoff計画がデータ・リンク層で使われることが提案されます(しかし、ここに指定されません)。 呼び出し衝突で助けること以外に、そのような計画は失敗した呼び出し試みのために、告発(存在しているなら)を最小にするかもしれません。
As a result of the physical implementation of some demand circuits, only one end of the circuit may be capable of opening the data-link connection. For example, some async modems can initiate calls, but cannot accept incoming calls. In these cases, since connection initiation in this memo is data-driven, care must be taken to ensure that the initiating application party is located at the calling end of the demand circuit.
いくつかの物理的な実現の結果、サーキットからサーキット、片端だけを要求してください。データリンク接続を開いてもよいです。 例えば、モデムが開始できるいくらかのasyncは呼びますが、かかってきた電話を受け入れることができません。 このメモにおける接続開始以来のこれらの場合には、データ駆動型があって、注意は取って、開始アプリケーションがパーティーへ行くのを保証するのが要求サーキットの呼ぶ端に位置しているということであるに違いありません。
2. Modifications to all OSPF routers
2. すべてのOSPFルータへの変更
While most of the modifications to support demand circuits are isolated to the demand circuit endpoints (see Section 3), there are changes required of all OSPF routers. These changes are described in the subsections below.
支持する変更の大部分は、サーキットが要求サーキット終点に隔離されるのを(セクション3を見てください)要求しますが、すべてのOSPFルータについて必要である変化があります。 これらの変化は以下の小区分で説明されます。
2.1. The OSPF Options field
2.1. OSPF Options分野
A new bit is added to the OSPF Options field to support the demand
circuit extensions. This bit is called the "DC-bit". The resulting
format of the Options field is described in Appendix A.
新しいビットは、要求サーキット拡大を支持するためにOSPF Options分野に加えられます。 このビットは「DC-ビット」と呼ばれます。 Options分野の結果として起こる形式はAppendix Aで説明されます。
A router implementing the functionality described in Section 2 of
this memo sets the DC-bit in the Options field of all LSAs that it
originates. This is regardless of the LSAs' LS type, and also
regardless of whether the router implements the more substantial
modifications required of demand circuit endpoints (see Section
3). Setting the DC-bit in self-originated LSAs tells the rest of
the routing domain that the router can correctly process DoNotAge
LSAs (see Sections 2.2, 2.3 and 2.5).
このメモのセクション2で説明された機能性を実行するルータはそれが溯源するすべてのLSAsのOptions分野にDC-ビットをはめ込みます。 これはLSAsのLSタイプにかかわらずあって、ルータが、より実質的な変更を実行するかどうかにかかわらずも要求サーキット終点を要求されます(セクション3を見てください)。 自己によって溯源されたLSAsにDC-ビットをはめ込むのは、ルータが正しくDoNotAge LSAsを処理できる(セクション2.2、2.3、および2.5を見る)と経路ドメインの残りに言います。
There is a single exception to the above rule. A router
implementing Section 2 of this memo may sometimes originate an
"indication-LSA"; these LSAs always have the DC-bit clear.
Indication-LSAs are used to convey across area boundaries the
上の規則へのただ一つの例外があります。 このメモのセクション2を実行するルータは時々「指示-LSA」を溯源するかもしれません。 これらのLSAsで、DC-ビットはいつも明確になります。 指示-LSAsは、領域の向こう側に境界を伝えるのに使用されます。
Moy [Page 4] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[4ページ]RFC1793OSPF
existence of routers incapable of DoNotAge processing; see Section
2.5.1 for details.
DoNotAge処理で不可能なルータの存在。 詳細に関してセクション2.5.1を見てください。
2.2. The LS age field
2.2. LS時代分野
The semantics of the LSA's LS age field are changed, allowing the
high bit of the LS age field to be set. This bit is called
"DoNotAge"; see Appendix C for its formal definition. LSAs whose
LS age field have the DoNotAge bit set are not aged while they are
held in the link state database, which means that they do not have
to be refreshed every LSRefreshInterval as is done with all other
OSPF LSAs.
LSAのLS時代分野の意味論を変えます、LS時代分野の高いビットが設定されるのを許容して。 このビットは"DoNotAge"と呼ばれます。 公式の定義に関してAppendix Cを見てください。 彼らはリンク州のデータベースに保持されますが、LS時代分野でDoNotAgeビットを設定するLSAs老いない、彼らがリフレッシュされる必要はないことを意味するもの。他のすべてのOSPF LSAsと共に行われるあらゆるLSRefreshInterval。
By convention, in the rest of this memo we will express LS age
fields having the DoNotAge bit set as "DoNotAge+x", while an LS
age expressed as just "x" is assumed to not have the DoNotAge bit
set. LSAs having DoNotAge set are also sometimes referred to as
"DoNotAge LSAs".
コンベンションで、このメモの残りでは、私たちは「DoNotAge+x」としてDoNotAgeビットを設定するLS時代分野を言い表すつもりです、まさしく「x」にはDoNotAgeビットがないと思われて、表されたLS時代はセットしましたが。 また、DoNotAgeを用意ができさせるLSAsは時々「DoNotAge LSAs」と呼ばれます。
When comparing two LSA instances to see which one is most recent,
the two LSAs' LS age fields are compared whenever the LS sequence
numbers and LS checksums are found identical (see Section 13.1 of
[1]). Before comparing, the LS age fields must have their DoNotAge
bits masked off. For example, in determining which LSA is more
recent, LS ages of 1 and DoNotAge+1 are considered equivalent; an
LSA flooded with LS age of 1 may be acknowledged with a Link State
Acknowledgement listing an LS age of DoNotAge+1, or vice versa. In
particular, DoNotAge+MaxAge is equivalent to MaxAge; however for
backward-compatibility the MaxAge form should always be used when
flushing LSAs from the routing domain (see Section 14.1 of [1]).
1つがどれであるかを最新の状態で確認するために2つのLSA例を比較するとき、LS一連番号とLSチェックサムが同じであることがわかるときはいつも、2LSAsのLS時代分野は比較されます。([1])のセクション13.1を見てください。 比較する前に、LS時代分野はビットがマスクをかけたそれらのDoNotAgeを休みにしなければなりません。 例えば、どちらのLSAが、より最近であるかを決定する際に、1とDoNotAge+1のLS時代は同等であると考えられます。 Link州AcknowledgementがDoNotAge+1のLS時代を記載している状態で、1LS歳で水につかっているLSAは承認されるかもしれませんか、逆もまた同様です。 DoNotAge+MaxAgeはMaxAgeに特に、同等です。 しかしながら、後方の互換性のために、経路ドメインからLSAsを洗い流すとき、MaxAgeフォームはいつも使用されるべきです。([1])のセクション14.1を見てください。
Thus, the set of allowable values for the LS age field fall into
the two ranges: 0 through MaxAge and DoNotAge through
DoNotAge+MaxAge. (Previously the LS age field could not exceed
the value of MaxAge.) Any LS age field not falling into these two
ranges should be considered to be equal to MaxAge.
したがって、LSの2への分野落下期間の許容量のセットは及びます: 0 DoNotAge+MaxAgeを通したMaxAgeとDoNotAgeを通して。 (以前に、LS時代分野はMaxAgeの値を超えることができませんでした。) これらの2つの範囲に落ちないどんなLS時代分野もMaxAgeと等しいと考えられるべきです。
When an LSA is flooded out an interface, the constant
InfTransDelay is added to the LSA's LS age field. This happens
even if the DoNotAge bit is set; in this case the LS age field is
not allowed to exceed DoNotAge+MaxAge. If the LS age field reaches
DoNotAge+MaxAge during flooding, the LSA is flushed from the
routing domain. This preserves the protection in [1] afforded
against flooding loops.
LSAが水浸しにされるとき、インタフェースであり、一定のInfTransDelayはLSAのLS時代分野に加えられます。 DoNotAgeビットが設定されても、これは起こります。 この場合、LS時代分野はDoNotAge+MaxAgeを超えることができません。 LS時代分野が氾濫の間、DoNotAge+MaxAgeに達するなら、LSAは経路ドメインから洗い流されます。 これは氾濫輪に対して都合された[1]に保護を保存します。
The LS age field is not checksum protected. Errors in a router's
memory may mistakenly set an LSA's DoNotAge bit, stopping the
aging of the LSA. However, a router should note that its own
LS時代分野は保護されたチェックサムではありません。 LSAの年をとることを止めて、ルータのメモリにおける誤りはLSAのDoNotAgeビットを誤って設定するかもしれません。 しかしながら、ルータがそれに注意するべきである、それ自身
Moy [Page 5] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[5ページ]RFC1793OSPF
self-originated LSAs should never have the DoNotAge bit set in its
own database. This means that in any case the router's self-
originated LSAs will be refreshed every LSRefreshInterval. As
this refresh is flooded throughout the OSPF routing domain, it
will replace any LSA copies in other routers' databases whose
DoNotAge bits were mistakenly set.
自己によって溯源されたLSAsはそれ自身のデータベースにDoNotAgeビットを決して設定させるはずがありません。 これは、どのような場合でも、ルータの自己の溯源されたLSAsがリフレッシュされることを意味します。あらゆるLSRefreshInterval。 これとして、リフレッシュしてください、OSPF経路ドメイン中で水につかって、それはDoNotAgeビットが誤って設定された他のルータのデータベースでのどんなLSAコピーも取り替えるでしょう。
2.3. Removing stale DoNotAge LSAs
2.3. 聞き古したDoNotAge LSAsを取り外します。
Because LSAs with the DoNotAge bit set are never aged, they can
stay in the link state database even when the originator of the
LSA no longer exists. To ensure that these LSAs are eventually
flushed from the routing domain, and that the size of the link
state database doesn't grow without bound, routers are required to
flush a DoNotAge LSA if BOTH of the following conditions are met:
DoNotAgeビットがセットしたことでのLSAsが決して熟成しないので、LSAの創始者がもう存在しないと、彼らはリンク州のデータベースに滞在できます。 これらのLSAsが結局、経路ドメインから洗い流されて、リンク州のデータベースのサイズがバウンドなしで成長しないのを保証するために、以下の条件のBOTHが会われるなら、ルータがDoNotAge LSAを洗い流すのに必要です:
(1) The LSA has been in the router's database for at least
MaxAge seconds.
(1) LSAが少なくともMaxAge秒の間、ルータのデータベースにあります。
(2) The originator of the LSA has been unreachable (according to
the routing calculations specified by Section 16 of [1]) for
at least MaxAge seconds.
(2) LSAの創始者は手が届きません。(ルーティングによると、計算は少なくともMaxAge秒の間の[1])のセクション16で指定しました。
For an example, see Time T8 in the example of Section 4.1. Note
that the above functionality is an exception to the general OSPF
rule that a router can only flush (i.e., prematurely age; see
Section 14.1 of [1]) its own self-originated LSAs. The above
functionality pertains only to DoNotAge LSAs. An LSA having
DoNotAge clear still can be prematurely aged only by its
originator; otherwise, the LSA must age naturally to MaxAge before
being removed from the routing domain.
例に関しては、セクション4.1に関する例でTime T8を見てください。 上記の機能性がルータが平らにだけそうすることができるという一般的なOSPF規則への例外であることに注意してください。(すなわち、早まって、年をとってください;、[1]) それ自身の自己によって溯源されたLSAsのセクション14.1を見てください。 上記の機能性はDoNotAge LSAsだけに関係します。 単に創始者は早まって、DoNotAgeを明確にするLSAをまだ熟成させることができます。 さもなければ、経路ドメインから取り除く前にLSAは自然にMaxAgeに年をとらなければなりません。
An interval as long as MaxAge has been chosen to avoid any
possibility of thrashing (i.e., flushing an LSA only to have it
reoriginated soon afterwards). Note that by the above rules, a
DoNotAge LSA will be removed from the routing domain no faster
than if it were being aged naturally (i.e., if DoNotAge were not
set).
MaxAgeとしての長い同じくらい間隔は、打つことのどんな可能性も避けるために選ばれました(すなわち、LSAを洗い流しますその後すぐそれを再由来させる)。 上の規則で、DoNotAge LSAが経路ドメインから、より速く取り外されないことに注意してください、それが自然に熟成していたなら(すなわち、DoNotAgeが用意ができていなかったなら)。
2.4. A change to the flooding algorithm
2.4. 氾濫アルゴリズムへの変化
The following change is made to the OSPF flooding algorithm. When
a Link State Update Packet is received that contains an LSA
instance which is actually less recent than the the router's
current database copy, the router must now process the LSA as
follows (modifying Step 8 of Section 13 in [1] accordingly):
以下の変更をOSPF氾濫アルゴリズムにします。 Link州Update Packetが受け取られているとき、それは実際にルータの現在のデータベースコピーより最近でないLSA例を含んでいて、ルータは今、以下のLSAを処理しなければなりません([1]でそれに従って、セクション13のStep8を変更して):
Moy [Page 6] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[6ページ]RFC1793OSPF
o If the database copy has LS age equal to MaxAge and LS
sequence number equal to MaxSequenceNumber, simply discard
the received LSA without acknowledging it. (In this case,
the LSA's sequence number is wrapping, and the
MaxSequenceNumber LSA must be completely flushed before any
new LSAs can be introduced). This is identical to the
behavior specified by Step 8 of Section 13 in [1].
o データベースコピーにMaxAgeと等しいLS年令とLS一連番号があるなら、それを承認しないで、MaxSequenceNumberと等しくて、単に容認されたLSAを捨ててください。 (この場合LSAの一連番号はラッピングです、そして、どんな新しいLSAsも導入できる前にMaxSequenceNumber LSAを完全に洗い流さなければなりません。) これは[1]でセクション13のStep8によって指定された振舞いと同じです。
o Otherwise, send the database copy back to the sending
neighbor, encapsulated within a Link State Update Packet. In
so doing, do not put the database copy of the LSA on the
neighbor's link state retransmission list, and do not
acknowledge the received (less recent) LSA instance.
o さもなければ、Link州Update Packetの中で要約された送付隣人にデータベースコピーを送り返してください。 そうする際に、隣人のリンク州の「再-トランスミッション」リストにLSAのデータベースコピーを載せないでください、そして、容認された(それほど最近でない)LSA例を承認しないでください。
This change is necessary to support flooding over demand circuits.
For example, see Time T4 in the example of Section 4.2.
この変化が、要求サーキットの上に浸水するのを支持するのに必要です。 例えば、セクション4.2に関する例でTime T4を見てください。
However, this change is beneficial when flooding over non-demand
interfaces as well. For this reason, the flooding change pertains
to all interfaces, not just interfaces to demand circuits. The
main example involves MaxAge LSAs. There are times when MaxAge
LSAs stay in a router's database for extended intervals: 1) when
they are stuck in a retransmission queue on a slow link or 2) when
a router is not properly flushing them from its database, due to
software bugs. The prolonged existence of these MaxAge LSAs can
inhibit the flooding of new instances of the LSA. New instances
typically start with the initial LS sequence number, and are
treated as less recent (and hence discarded) by routers still
holding MaxAge instances. However, with the above change to
flooding, a router with a MaxAge instance will respond back with
the MaxAge instance. This will get back to the LSA's originator,
which will then pick the next highest LS sequence number and
reflood, overwriting the MaxAge instance.
しかしながら、また、非要求インタフェースの上で浸水するとき、この変化は有益です。 この理由で、氾濫変化は、サーキットを要求するためにインタフェースだけではなく、すべてのインタフェースに関係します。 主な例はMaxAge LSAsにかかわります。 MaxAge LSAsが延ばされた間隔の間にルータのデータベースに滞在する回があります: 1) それらはいつ再送キューで遅いリンクに張り付けられるか、そして、2) ルータがデータベースからそれらを適切に洗い流していないとき、ソフトウェアへの支払われるべきものは急いで去ります。 これらのMaxAge LSAsの長引いている存在はLSAの新しい例の氾濫を抑制できます。 新しい例は、初期のLS一連番号から通常始まって、まだ成立しているそれほどルータによる最近(そして、したがって、捨てられる)でないMaxAge例として扱われます。 しかしながら、氾濫への上の変化で、MaxAge例があるルータはMaxAge例がある後部を反応させるでしょう。 これはLSAの創始者に折り返し連絡するでしょう、MaxAge例を上書きして。(次に、その創始者は、次の最も高いLS一連番号と再冠水を選ぶでしょう)。
This change will be included in future revisions of the base OSPF
specification [1].
この変化はベースOSPF仕様[1]の今後の改正に含まれるでしょう。
2.5. Interoperability with unmodified OSPF routers
2.5. 変更されていないOSPFルータがある相互運用性
Unmodified OSPF routers will probably treat DoNotAge LSAs as if
they had LS age of MaxAge. At the very worst, this will cause
continual retransmissions of the DoNotAge LSAs. (An example
scenario follows. Suppose Routers A and B are connected by a
point-to-point link. Router A implements the demand circuit
extensions, Router B does not. Neither one treats their connecting
link as a demand circuit. At some point in time, Router A receives
from another neighbor via flooding a DoNotAge LSA. The DoNotAge
LSA is then flooded by Router A to Router B. Router B, not
まるで彼らにはMaxAgeのLS時代があるかのように変更されていないOSPFルータはたぶんDoNotAge LSAsを扱うでしょう。 非常に最も悪いところでは、これはDoNotAge LSAsの絶え間ない「再-トランスミッション」を引き起こすでしょう。 (いくつかでは、時間内に. DoNotAge LSA DoNotAge LSAをあふれさせることを通してRouter Aが別の隣人から受けるポイントはB.Router Bがその時RouterへのRouter Aで浸水したということです。例のシナリオは従います。どちらも要求サーキットとしてそれらの結合リンクを扱わないと仮定してください。Routers AとBはポイントツーポイント接続によって接続されます。ルータAは要求サーキット拡大、Bが実行しないRouterを実行します。
Moy [Page 7] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[7ページ]RFC1793OSPF
understanding DoNotAge LSAs, treats it as a MaxAge LSA and
acknowledges it as such to Router A. Router A receives the
acknowledgment, but notices that the acknowledgment is for a
different instance, and so starts retransmitting the LSA.)
DoNotAge LSAsを理解していますが、MaxAge LSAとしてそれを扱って、Router A.Router Aへのそのようなものが承認を受けるときそれを承認しますが、承認が異なった例のためのものであるのに気付いて、LSAを再送し始める、)。
However, to avoid this confusion, DoNotAge LSAs will be allowed in
an OSPF area if and only if, in the area's link state database,
all LSAs have the DC-bit set in their Options field (see Section
2.1). Note that it is not required that the LSAs' Advertising
Router be reachable; if any LSA is found not having its DC-bit set
(regardless of reachability), then the router should flush (i.e.,
prematurely age; see Section 14.1 of [1]) from the area all
DoNotAge LSAs. These LSAs will then be reoriginated at their
sources, this time with DoNotAge clear. Like the change in
Section 2.3, this change is an exception to the general OSPF rule
that a router can only flush its own self-originated LSAs. Both
changes pertain only to DoNotAge LSAs, and in both cases a flushed
LSA's LS age field should be set to MaxAge and not
DoNotAge+MaxAge.
そして、しかしながら、この混乱を避けるために、DoNotAge LSAsがOSPF領域に許容される、領域のリンク州のデータベースのすべてのLSAsにDC-ビットがある場合にだけ、彼らのOptions分野にセットしてください(セクション2.1を見てください)。 LSAsのAdvertising Routerが届いているのが必要でないことに注意してください。 何かLSAがDC-ビットを設定させないのが(可到達性にかかわらず)見つけられるなら、ルータは洗い流されるべきです。(すなわち、早まって、年をとってください;、領域DoNotAge LSAsからの[1])のセクション14.1を見てください。 そして、これらのLSAsは彼らのソース、DoNotAgeが明確のこの時に再由来されるでしょう。 セクション2.3における変化のように、この変化はルータがそれ自身の自己によって溯源されたLSAsを洗い流すことができるだけであるという一般的なOSPF規則への例外です。 両方の変化はDoNotAge LSAsだけに関係します、そして、aが洗い流した両方の場合では、LSAのLS時代分野はDoNotAge+MaxAgeではなく、MaxAgeに設定されるべきです。
2.5.1. Indicating across area boundaries
2.5.1. 領域の向こう側に境界を示します。
AS-external-LSAs are flooded throughout the entire OSPF routing
domain, excepting only OSPF stub areas and NSSAs. For that
reason, if an OSPF router that is incapable of DoNotAge
processing exists in any "regular" area (i.e., an area that is
not a stub nor an NSSA), no AS-external-LSA can have DoNotAge
set. This memo simplifies that requirement by broadening it to
the following rule: LSAs in regular OSPF areas are allowed to
have DoNotAge set if and only if every router in the OSPF
domain (excepting those in stub areas and NSSAs) is capable of
DoNotAge processing. The rest of this section describes how the
rule is implemented.
OSPFスタッブ領域とNSSAsだけを除いて、ASの外部のLSAsは全体のOSPF経路ドメイン中で水につかっています。 その理由で、DoNotAge処理で不可能なOSPFルータがどんな「通常」の領域(すなわち、スタッブかNSSAでない領域)にも存在しているなら、どんなASの外部のLSAもDoNotAgeを用意ができさせることができません。 このメモは以下の規則にそれを広くすることによって、その要件を簡素化します: そして、通常のOSPF領域のLSAsがDoNotAgeを用意ができさせることができる、OSPFドメイン(スタッブ領域でそれらを除いて、NSSAs)のあらゆるルータはDoNotAge処理ができる場合にだけ。 このセクションの残りは規則がどう実行されるかを説明します。
As described above in Sections 2.1 and 2.5, a router indicates
that it is capable of DoNotAge processing by setting the DC-bit
in the LSAs that it originates. However, there is a problem. It
is possible that, in all areas to which Router X directly
attaches, all the routers are capable of DoNotAge processing,
yet there is some router in a remote "regular" area that cannot
process DoNotAge LSAs. This information must then be conveyed
to Router X, so that it does not mistakenly flood/create
DoNotAge LSAs.
セクション2.1と2.5で上で説明されるように、ルータは、それはそれが溯源するLSAsにDC-ビットをはめ込むことによってDoNotAge処理ができるのを示します。 しかしながら、問題があります。 Router Xが直接付くすべての領域にすべてのルータはDoNotAge処理ができますが、何らかのルータがDoNotAge LSAsを処理できない遠く離れた「通常」の領域にあるのは、可能です。 次に、この情報をRouter Xに伝えなければならないので、それは、DoNotAge LSAsを誤ってあふれるか、または作成しません。
The solution is as follows. Area border routers transmit the
existence of DoNotAge-incapable routers across area boundaries,
using "indication-LSAs". Indication-LSAs are type-4-summary
LSAs (also called ASBR-summary-LSAs), listing the area border
解決策は以下の通りです。 「指示-LSAs」を使用して、境界ルータはDoNotAge不可能なルータの存在をエリアの境界の向こう側に伝えます。 領域の境界を記載して、指示-LSAsはタイプ4概要LSAs(また、ASBRの要約のLSAsと呼ばれる)です。
Moy [Page 8] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[8ページ]RFC1793OSPF
router itself as the described ASBR, with the LSA's cost set to
LSInfinity and the DC-bit clear. Note that indication-LSAs
convey no additional information; in particular, they are used
even if the area border router is not really an AS boundary
router (ASBR).
LSInfinityに設定されたLSAの費用とDC-ビットが明確の説明されたASBRとしてのルータ自体。 指示-LSAsが追加情報を全く伝えないことに注意してください。 それらは境界ルータが本当にAS境界ルータ(ASBR)でなくても特に、使用されています。
Taking indication-LSAs into account, the rule as to whether
DoNotAge LSAs are allowed in any particular area is EXACTLY the
same as given previously in Section 2.5, namely: DoNotAge LSAs
will be allowed in an OSPF area if and only if, in the area's
link state database, all LSAs have the DC-bit set in their
Options field.
取りアカウント、DoNotAge LSAsによる何か特定の領域に許容されているのが、中に以前に、与えるのと同じEXACTLYであるということであるかどうかに関する規則への指示-LSAsセクション2.5 すなわち: DoNotAge LSAsがOSPF領域に許容される、単に、領域のものがリンクするコネはデータベース(LSAsがDC-ビットに彼らのOptions分野に設定させるすべて)を述べます。
Through origination of indication-LSAs, the existence of
DoNotAge-incapable routers can be viewed as going from non-
backbone regular areas, to the backbone area and from there to
all other regular areas. The following two cases summarize the
requirements for an area border router to originate
indication-LSAs:
指示-LSAsの創作で、非背骨の通常の領域から行くとDoNotAge不可能なルータの存在を見なすことができます、背骨領域とそこから通常の他のすべての領域まで。 以下の2つのケースが境界ルータが指示-LSAsを溯源するという要件をまとめます:
(1) Suppose an area border router (Router X) is connected to
a regular non-backbone OSPF area (Area A). Furthermore,
assume that Area A has LSAs with the DC-bit clear, other
than indication-LSAs. Then Router X should originate
indication-LSAs into all other directly-connected
"regular" areas, including the backbone area, keeping
the guidelines of Section 2.5.1.1 in mind.
(1) 境界ルータ(ルータX)が通常の非背骨OSPF領域(領域A)に関連づけられると仮定してください。 その上、指示-LSAsを除いて、Area AにはDC-ビットが明確な状態でLSAsがあると仮定してください。 そして、Router Xは念頭でセクション2.5.1のガイドラインを保つ背骨領域を含む他のすべての直接接続された「通常」の領域への指示-LSAs.1を溯源するはずです。
(2) Suppose an area border router (Router X) is connected to
the backbone OSPF area (Area 0.0.0.0). Furthermore,
assume that the backbone has LSAs with the DC-bit clear
that are either a) not indication-LSAs or b)
indication-LSAs that have been originated by routers
other than Router X itself. Then Router X should
originate indication-LSAs into all other directly-
connected "regular" non-backbone areas, keeping the
guidelines of Section 2.5.1.1 in mind.
(2) 境界ルータ(ルータX)が背骨OSPF領域に関連づけられると仮定してください、(領域、0.0、.0、.0、) その上、背骨がDC-ビットが明確のRouter X自身以外のルータによって溯源されたa)指示-LSAsでないb)指示-LSAsのどちらかであるLSAsを持っていると仮定してください。 そして、Router Xは念頭でセクション2.5.1のガイドラインを保つ他の直接接続された「通常」の非背骨領域へのすべて、指示-LSAs.1を溯源するはずです。
2.5.1.1. Limiting indication-LSA origination
2.5.1.1. 指示-LSA創作を制限します。
To limit the number of indication-LSAs originated, the
following guidelines should be observed by an area border
router (Router X) when originating indication-LSAs. First,
indication-LSAs are not originated into an Area A when A
already has LSAs with DC-bit clear other than indication-
LSAs. Second, if another area border router has originated a
indication-LSA into Area A, and that area border router has
a higher OSPF Router ID than Router X (same tie-breaker as
Moy [Page 9] RFC 1793 OSPF over Demand Circuits April 1995
for forwarding address origination; see Section 12.4.5 of
[1]), then Router X should not originate an indication-LSA
into Area A.
As an example, suppose that three regular OSPF areas (Areas
A, B and C) are connected by routers X, Y and Z
(respectively) to the backbone area. Furthermore, suppose
that all routers are capable of DoNotAge processing, except
for routers in Areas A and B. Finally, suppose that Router
Z has a higher Router ID than Y, which in turn has a higher
Router ID than X. In this case, two indication-LSAs will be
generated (if the rules of Section 2.5.1 and the guidelines
of the preceding paragraph are followed): Router Y will
originate an indication-LSA into the backbone, and Router Z
will originate an indication-LSA into Area C.
3. Modifications to demand circuit endpoints
The following subsections detail the modifications required of the routers at the endpoints of demand circuits. These consist of modifications to two main pieces of OSPF: 1) sending and receiving Hello Packets over demand circuits and 2) flooding LSAs over demand circuits.
An additional OSPF interface configuration parameter, ospfIfDemand, is defined to indicate whether an OSPF interface connects to a demand circuit (see Appendix B). Two routers connecting to a common network segment need not agree on that segment's demand circuit status. However, to get full benefit of the demand circuit extensions, the two ends of a point-to-point link must both agree to treat the link as a demand circuit (see Section 3.2).
3.1. Interface State machine modifications
An OSPF point-to-point interface connecting to a demand circuit is
considered to be in state "Point-to-point" if and only if its
associated neighbor is in state "1-Way" or greater; otherwise the
interface is considered to be in state "Down". Hellos are sent out
such an interface when it is in "Down" state, at the reduced
interval of PollInterval. If the negotiation in Section 3.2.1
succeeds, Hellos will cease to be sent out the interface whenever
the associated neighbor reaches state "Full".
Note that as a result, an "LLDown" event for the point-to-point
demand circuit's neighbor forces both the neighbor and the
interface into state "Down" (see Section 3.2.2).
Moy [Page 10] RFC 1793 OSPF over Demand Circuits April 1995
For OSPF broadcast and NBMA networks that have been configured as
demand circuits, there are no changes to the Interface State
Machine.
3.2. Sending and Receiving OSPF Hellos
The following sections describe the required modifications to OSPF
Hello Packet processing on point-to-point demand circuits.
For OSPF broadcast and NBMA networks that have been configured as
demand circuits, there is no change to the sending and receiving
of Hellos, nor are there any changes to the Neighbor State
Machine. This is because the proper operation of the Designated
Router election algorithm requires periodic exchange of Hello
Packets.
3.2.1. Negotiating Hello suppression
On point-to-point demand circuits, both endpoints must agree to
suppress the sending of Hello Packets. To ensure this
agreement, a router sets the DC-bit in OSPF Hellos and Database
Description Packets sent out the demand interface. Receiving
an Hello or a Database Description Packet with the DC-bit set
indicates agreement. Receiving an Hello with the DC-bit clear
and also listing the router's Router ID in the body of the
Hello message, or a Database Description Packet with the DC-bit
clear (either one indicating bidirectional connectivity)
indicates that the other end refuses to suppress Hellos. In
these latter cases, the router reverts to the normal periodic
sending of Hello Packets out the interface (see Section 9.5 of
[1]).
A demand point-to-point circuit need be configured in only one
of the two endpoints (see Section 4.1). If a router
implementing Sections 2 and 3 of this memo receives an Hello
Packet with the DC-bit set, it should treat the point-to-point
link as a demand circuit, making the appropriate changes to its
Hello Processing (see Section 3.2.2) and flooding (see Section
3.3).
Even if the above negotiation fails, the router should continue
setting the DC-bit in its Hellos and Database Descriptions (the
neighbor will just ignore the bit). The router will then
automatically attempt to renegotiate Hello suppression whenever
the link goes down and comes back up. For example, if the
neighboring router is rebooted with software that is capable of
operating over demand circuits (i.e., implements Sections 2 and
3 of this memo), a future negotiation will succeed.
Moy [Page 11] RFC 1793 OSPF over Demand Circuits April 1995
Also, even if the negotiation to suppress Hellos fails, the
flooding modifications described in Section 3.3 are still
performed over the link.
3.2.2. Neighbor state machine modifications
When the above negotiation succeeds, Hello Packets are sent
over point-to-point demand circuits only until initial link-
state database synchronization is achieved with the neighbor
(i.e., the state of the neighbor connection reaches "Full", as
defined in Section 10.1 of [1]). After this, Hellos are
suppressed and the data-link connection to the neighbor is
assumed available until evidence is received to the contrary.
When the router finds that the neighbor is no longer available,
presumably from something like a discouraging diagnostic code
contained in a response to a failed call request, the neighbor
connection transitions back to "Down" and Hellos are sent
periodically (at Intervals of PollInterval) in an attempt to
restart synchronization with the neighbor.
This requires changes to the OSPF Neighbor State Machine (see
Section 10.3 of [1]). The receipt of Hellos from demand circuit
neighbors in state "Loading" or "Full" can no longer be
required. In other words, the InactivityTimer event defined in
Section 10.2 of [1] has no effect on demand circuit neighbors
in state "Loading" or "Full". An additional clarification is
needed in the Neighbor State Machine's LLDown event. For demand
circuits, this event should be mapped into the "discouraging
diagnostic code" discussed previously in Section 1, and should
not be generated when the data-link connection has been closed
simply to save resources. Nor should LLDown be generated if a
data-link connection fails due to temporary lack of resources.
3.3. Flooding over demand circuits
Flooding over demand circuits (point-to-point or otherwise) is
modified if and only if all routers have indicated that they can
process LSAs having DoNotAge set. This is determined by examining
the link state database of the OSPF area containing the demand
circuit. All LSAs in the database must have the DC-bit set. If
one or more LSAs have the DC-bit clear, flooding over demand
circuits is unchanged from [1]. Otherwise, flooding is changed as
follows.
(1) Only truly changed LSAs are flooded over demand circuits.
When a router receives a new LSA instance, it checks first
to see whether the contents have changed. If not, the new
LSA is simply a periodic refresh and it is not flooded out
Moy [Page 12] RFC 1793 OSPF over Demand Circuits April 1995
attached demand circuits (it is still flooded out other
interfaces however). This check should be performed in Step
5b of Section 13 in [1]. When comparing an LSA to its
previous instance, the following are all considered to be
changes in contents:
o The LSA's Options field has changed.
o One or both of the LSA instances has LS age set to
MaxAge (or DoNotAge+MaxAge).
o The length field in the LSA header has changed.
o The contents of the LSA, excluding the 20-byte link
state header, have changed. Note that this excludes
changes in LS Sequence Number and LS Checksum.
(2) When it has been decided to flood an LSA over a demand
circuit, DoNotAge should be set in the copy of the LSA that
is flooded out the demand interface. (There is one
exception: DoNotAge should not be set if the LSA's LS age is
equal to MaxAge.) Setting DoNotAge will cause the routers on
the other side of the demand circuit to hold the LSA in
their databases indefinitely, removing the need for periodic
refresh. Note that it is perfectly possible that DoNotAge
will already be set. This simply indicates that the LSA has
already been flooded over demand circuits. In any case, the
flooded copy's LS age field must also be incremented by
InfTransDelay (see Step 5 of Section 13.3 in [1], and
Section 2.2 of this memo), as protection against flooding
loops.
The previous paragraph also pertains to LSAs flooded over
demand circuits in response to Link State Requests. It also
pertains to LSAs that are retransmitted over demand
circuits.
3.4. Virtual link support
OSPF virtual links are essentially unnumbered point-to-point links
(see Section 15 of [1]). Accordingly, demand circuit support for
virtual links resembles that described for point-to-point links in
the previous sections. The main difference is that a router
implementing Sections 2 and 3 of this memo, and supporting virtual
links, always treats virtual links as if they were demand
circuits. Otherwise, when a virtual link's underlying physical
path contains one or more demand circuits, periodic OSPF protocol
exchanges over the virtual link would unnecessarily keep the
Moy [Page 13] RFC 1793 OSPF over Demand Circuits April 1995
underlying demand circuits open.
Demand circuit support on virtual links can be summarized as
follows:
o Instead of modifying the Interface state machine for virtual
links as was done for point-to-point links in Section 3.1,
the Interface state machine for virtual links remains
unchanged. A virtual link is considered to be in state
"Point-to-point" if an intra-area path (through the virtual
link's transit area) exists to the other endpoint. Otherwise
it is considered to be in state "Down". See Section 15 of
[1] for more details.
o Virtual links are always treated as demand circuits. In
particular, over virtual links a router always negotiates to
suppress the sending of Hellos. See Sections 3.2.1 and 3.2.2
for details.
o In the demand circuit support over virtual links, there is
no "discouraging diagnostic code" as described in Section 1.
Instead, the connection is considered to exist if and only
if an intra-area path (through the virtual link's transit
area) exists to the other endpoint. See Section 15 of [1]
for more details.
o Since virtual links are always treated as demand circuits,
flooding over virtual links always proceeds as in Section
3.3.
3.5. Point-to-MultiPoint Interface support
The OSPF Point-to-MultiPoint interface has recently been developed
for use with non-mesh-connected network segments. A common example
is a Frame Relay subnet where PVCs are provisioned between some
pairs of routers, but not all pairs. In this case the Point-to-
Multipoint interface represents the single physical interface to
the Frame relay network, over which multiple point-to-point OSPF
conversations (one on each PVC) are taking place. For more
information on the Point-to-MultiPoint interface, see [8].
Since an OSPF Point-to-MultiPoint interface essentially consists
of multiple point-to-point links, demand circuit support on the
Point-to-Multipoint interface strongly resembles demand circuit
support for point-to-point links. However, since the Point-to-
MultiPoint interface requires commonality of its component point-
to-point links' configurations, there are some differences.
Moy [Page 14] RFC 1793 OSPF over Demand Circuits April 1995
Demand circuit support on Point-to-Multipoint interfaces can be
summarized as follows:
o Instead of modifying the Interface state machine for Point-
to-Multipoint interfaces as was done for point-to-point
links in Section 3.1, the Interface state machine for
Point-to-Multipoint interfaces remains unchanged.
o When ospfIfDemand is set on a Point-to-MultiPoint interface,
the router tries to negotiate Hello suppression separately
on each of interface's component point-to-point links. This
negotiation proceeds as in Section 3.2.1. Negotiation may
fail on some component point-to-point links, and succeed on
others. This is acceptable. On those component links where
the negotiation fails, Hellos will always be sent;
otherwise, Hellos will cease to be sent when the Database
Description process completes on the component link (see
Section 3.2.2).
o Section 3.3 defines the demand circuit flooding behavior for
all OSPF interface types. This includes Point-to-Multipoint
interfaces.
4. Examples
This section gives three examples of the operation over demand circuits. The first example is probably the most common and certainly the most basic. It shows a single point-to-point demand circuit connecting two routers. The second illustrates what happens when demand circuits and leased lines are used in parallel. The third explains what happens when a router has multiple demand circuits and cannot keep them all open (for resource reasons) at the same time.
4.1. Example 1: Sole connectivity through demand circuits
Figure 1 shows a sample internetwork with a single demand circuit
providing connectivity to the LAN containing Host H2. Assume that
all three routers (RTA, RTB and RTC) have implemented the
functionality in Section 2 of this memo, and thus will be setting
the DC-bit in their LSAs. Furthermore assume that Router RTB has
been configured to treat the link to Router RTC as a demand
circuit, but Router RTC has not been so configured. Finally assume
that the LAN interface connecting Router RTA to Host H1 is
initially down.
The following sequence of events may then transpire, starting with
Router RTB booting and bringing up its link to Router RTC:
Moy [Page 15] RFC 1793 OSPF over Demand Circuits April 1995
Time T0: RTB negotiates Hello suppression
Router RTB will start sending Hellos over the demand circuit
with the DC-bit set in the Hello's Options field. Because
RTC is not configured to treat the link as a demand circuit,
the first Hello that RTB receives from RTC may not have the
DC-bit set. However, subsequent Hellos and Database
Description Packets received from RTC will have the DC-bit
set, indicating that the two routers have agreed that the
link will be treated as a demand circuit. The entire
negotiation is pictured in Figure 2. Note that if RTC were
unable or unwilling to suppress Hellos on the link, the
initial Database Description sent from Router RTC to RTB
would have the DC-bit clear, forcing Router RTB to revert to
the periodic sending of Hellos specified in Section 9.5 of
[1].
Time T1: Database exchange over demand circuit
The initial synchronization of link state databases (the
Database Exchange Process) over the demand circuit then
occurs as over any point-to-point link, with one exception.
LSAs included in Link State Updates Packets sent over the
+ + +
| +---+ | |
+--+ |---|RTA|---| | +--+
|H1|---| +---+ | |---|H2|
+--+ | | +---+ ODL +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ +---+ |
+ +
Figure 1: In the example of Section 4.1,
a single demand circuit (labeled
ODL) bisects an internetwork.
Moy [Page 16] RFC 1793 OSPF over Demand Circuits April 1995
+---+ +---+
|RTB| |RTC|
+---+ +---+
Hello (DC-bit set)
------------------------------------->
Hello (DC-bit clear)
<-------------------------------------
Hello (DC-bit set, RTC seen)
------------------------------------->
Database Description (DC-bit set)
<-------------------------------------
Figure 2: Successful negotiation of Hello
suppression.
demand circuit (in response to Link State Request Packets),
will have the DoNotAge bit set in their LS age field. So,
after the Database Exchange Process is finished, all routers
will have 3 LSAs in their link state databases (router-LSAs
for Routers RTA, RTB and RTC), but the LS age fields
belonging to the LSAs will vary depending on which side of
the demand circuit they were originated from (see Table 1).
For example, all routers other than Router RTC have the
DoNotAge bit set in Router RTC's router-LSA; this removes
the need for Router RTC to refresh its router-LSA over the
demand circuit.
LS age
LSA in RTB in RTC
______________________________________________
RTA's Router-LSA 1000 DoNotAge+1001
RTB's Router-LSA 10 DoNotAge+11
RTC's Router-LSA DoNotAge+11 10
Table 1: After Time T1 in Section 4.1,
possible LS age fields on either
side of the demand circuit
Time T2: Hello traffic ceases
After the Database Exchange Process has completed, no Hellos
are sent over the demand circuit. If there is no application
data to be sent over the demand circuit, the circuit will be
idle.
Moy [Page 17] RFC 1793 OSPF over Demand Circuits April 1995
Time T3: Underlying data-link connection torn down
After some period of inactivity, the underlying data-link
connection will be torn down (e.g., an ISDN call would be
cleared) in order to save connect charges. This will be
transparent to the OSPF routing; no LSAs or routing table
entries will change as a result.
Time T4: Router RTA's LSA is refreshed
At some point Router RTA will refresh its own router-LSA
(i.e., when the LSA's LS age hits LSRefreshInterval). This
refresh will be flooded to Router RTB, who will look at it
and decide NOT to flood it over the demand circuit to Router
RTC, because the LSA's contents have not really changed
(only the LS Sequence Number). At this point, the LS
sequence numbers that the routers have for RTA's router-LSA
differ depending on which side of the demand circuit the
routers lie. Because there is still no application traffic,
the underlying data-link connection remains disconnected.
Time T5: Router RTA's LAN interface comes up
When Router RTA's LAN interface (connecting to Host H1)
comes up, RTA will originate a new router-LSA. This router-
LSA WILL be flooded over the demand circuit because its
contents have now changed. The underlying data-link
connection will have to be brought up to flood the LSA.
After flooding, routers on both sides of the demand circuit
will again agree on the LS Sequence Number for RTA's
router-LSA.
Time T6: Underlying data-link connection is torn down again
Assuming that there is still no application traffic
transiting the demand circuit, the underlying data-link
connection will again be torn down after some period of
inactivity.
Time T7: File transfer started between Hosts H1 and H2
As soon as application data needs to be sent across the
demand circuit the underlying data-link connection is
brought back up.
Moy [Page 18] RFC 1793 OSPF over Demand Circuits April 1995
Time T8: Physical link becomes inoperative
If an indication is received from the data-link or physical
layers indicating that the demand circuit can no longer be
established, Routers RTB and RTC declare their point-to-
point interfaces down, and originate new router-LSAs. Both
routers will attempt to bring the connection back up by
sending Hellos at the reduced rate of PollInterval. Note
that while the connection is inoperative, Routers RTA and
RTB will continue to have an old router-LSA for RTC in their
link state database, and this LSA will not age out because
it has the DoNotAge bit set. However, according to Section
2.3 they will flush Router RTC's router-LSA if the demand
circuit remains inoperative for longer than MaxAge.
4.2. Example 2: Demand and non-demand circuits in parallel
4.2. 例2: 平行な要求と非要求サーキット
This example demonstrates the demand circuit functionality when
both demand circuits and non-demand circuits (e.g., leased lines)
are used to interconnect regions of an internetwork. Such an
internetwork is shown in Figure 3. Host H1 can communicate with
Host H2 either over the demand link between Routers RTB and RTC,
or over the leased line between Routers RTB and RTD.
要求サーキットと非要求サーキット(例えば、専用線)の両方がインターネットワークの領域とインタコネクトするのに使用されるとき、この例は要求サーキットの機能性を示します。 そのようなインターネットワークは図3に示されます。 ホストH1はRouters RTBとRTCとの要求リンクの上、または、Routers RTBとRTDの間の専用線の上にHost H2とコミュニケートできます。
Because the basic properties of the demand circuit functionality
were presented in the previous example, this example will only
address the unique issues involved when using both demand and
non-demand circuits in parallel.
要求サーキットの機能性の基礎特性が前の例に提示されたので、この例は要求と平行な非要求サーキットの両方を使用するときかかわるユニークな問題を記述するだけでしょう。
Assume that Routers RTB and RTY are initially powered off, but
that all other routers and their attached links are both
operational and implement the demand circuit modifications to
OSPF. Throughout the example, a TCP connection between Hosts H1
and H2 is transmitting data. Furthermore, assume that the cost of
the demand circuit from RTB to RTC has been set considerably
higher than the cost of the leased line between RTB and RTD; for
this reason traffic between Hosts H1 and H2 will always be sent
over the leased line when it is operational.
他のすべてのルータとそれらの付属リンクがともに操作上であり、OSPFへの要求サーキット変更を実行していなかったならそのRouters RTBとRTYが初めは動かされると仮定してください。 例中では、Hosts H1とH2とのTCP接続はデータを送っています。 その上、RTBからRTCまでの要求サーキットの費用がRTBとRTDの間の専用線の費用よりかなり高いセットであると仮定してください。 この理由で、それが操作上であるときに、いつもHosts H1とH2の間の交通を専用線の上に送るでしょう。
Moy [Page 19] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[19ページ]RFC1793OSPF
The following events may then transpire:
次に、以下の出来事は蒸散するかもしれません:
+
+---+ |
|RTC|--| +
+---+ | +---+ |
+ / |--|RTE|--| +--+
+--+ | /ODL | +---+ |--|H2|
|H1|----| +---+ +---+/ | + +--+
+--+ |--|RTA|-------|RTB| |
| +---+ +---+\ | +
+ \ | +---+ |
\ |--|RTY|--|
+---+ | +---+ |
|RTD|--| +
+---+ |
+
+ +---+ | |RTC|--| + +---+ | +---+ | + / |--|RTE|--| +--+ +--+ | /ODL| +---+ |--|H2| |H1|----| +---+ +---+/ | + +--+ +--+ |--|RTA|-------|RTB| | | +---+ +---+\ | + + \ | +---+ | \ |--|RTY|--| +---+ | +---+ | |RTD|--| + +---+ | +
Figure 3: Example 2's internetwork.
図3: 例2のインターネットワーク。
Vertical lines are LAN segments. Six routers
are pictured, Routers RTA-RTE and RTY.
RTB has three serial line interfaces, two of
which are leased lines and the third (connecting to
RTC) a demand circuit. Two hosts, H1 and
H2, are pictured to illustrate the effect of
application traffic.
縦線はLANセグメントです。 Routers RTA-RTEとRTY、6つのルータが描写されています。 RTBには3つのシリアル・ラインのインタフェースがあります、そして、3番目には、(RTCに接続します)要求サーキットがあります。(2つのそれがインタフェースのための専用線です)。 2人のホスト(H1とH2)が、アプリケーション交通の効果を例証するために描写されます。
Time T0: Router RTB comes up.
時間T0: ルータRTBは来ます。
Assume RTB supports the demand circuit OSPF modifications.
When Router RTB comes up and establishes links to Routers
RTC and RTD, it will flood the same information over both.
However, LSAs sent over the demand circuit (to Router RTC)
will have the DoNotAge bit set, while those sent over the
leased line to Router RTD will not. Because the DoNotAge bit
is not taken into account when comparing LSA instances, the
routers on the right side of RTB (RTC, RTE and RTD) may or
may not have the DoNotAge bit set in their database copies
of RTA's and RTB's router-LSAs. This depends on whether the
LSAs sent over the demand link reach the routers before
those sent over the leased line. One possibility is pictured
in Table 2.
RTBが要求サーキットOSPF変更を支持すると仮定してください。 Router RTBがRouters RTCとRTDへのリンクを来て、設立すると、それは両方の上に同じ情報をあふれさせるでしょう。 しかしながら、LSAsはサーキット(Router RTCへの)でDoNotAgeビットが設定する要求を移動しました、Router RTDへの専用線の上に送られたものがそうしないでしょうが。 LSA例を比較するとき、DoNotAgeビットが考慮に入れられないので、RTB(RTC、RTE、およびRTD)の右側のルータで、RTAとRTBのルータ-LSAsに関するそれらのデータベースコピーにDoNotAgeビットを設定するかもしれません。 これはものが専用線を移動する前に要求リンクの上に送られたLSAsがルータに達するかどうかによります。 1つの可能性がTable2に描写されます。
Moy [Page 20] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[20ページ]RFC1793OSPF
LS age
LSA in RTC in RTD in RTE
________________________________________________
RTA's Router-LSA DoNotAge+20 21 21
RTB's Router-LSA DoNotAge+5 6 6
RTEのRTDのRTCにおけるLS時代LSA________________________________________________ RTAのルータLSA DoNotAge+20 21 21RTBのルータLSA DoNotAge+5 6 6
Table 2: After Time T0 in Example 2, LS age
fields on the right side of Router RTB.
テーブル2: Example2のTime T0の後に、LSはRouter RTBの右側の分野に年をとらせます。
LS age
LSA in RTC in RTD in RTE
_______________________________________________
RTA's Router-LSA 5 6 6
RTB's Router-LSA DoNotAge+5 1785 1785
RTEのRTDのRTCにおけるLS時代LSA_______________________________________________ RTAのルータ-LSA5 6 6RTBのルータLSA DoNotAge+5 1785 1785
Table 3: After Time T2 in Example 2, LS age
fields on the right side of Router RTB.
テーブル3: Example2のTime T2の後に、LSはRouter RTBの右側の分野に年をとらせます。
LS age
LSA in RTC in RTD in RTE
_______________________________________________________
RTA's Router-LSA 325 326 326
RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6
RTEのRTDのRTCにおけるLS時代LSA_______________________________________________________ RTAのルータ-LSA325 326 326RTBのルータLSA DoNotAge+5DoNotAge+6DoNotAge+6
Table 4: After Time T3 in Example 2, LS age
fields on the right side of Router RTB.
テーブル4: Example2のTime T3の後に、LSはRouter RTBの右側の分野に年をとらせます。
LS age
LSA in RTC in RTD in RTE
_______________________________________________________
RTA's Router-LSA DoNotAge+7 DoNotAge+8 DoNotAge+8
RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6
RTEのRTDのRTCにおけるLS時代LSA_______________________________________________________ RTAのルータLSA DoNotAge+7DoNotAge+8DoNotAge+8RTBのルータLSA DoNotAge+5DoNotAge+6DoNotAge+6
Table 5: After Time T4 in Example 2, LS age
fields on the right side of Router RTB.
テーブル5: Example2のTime T4の後に、LSはRouter RTBの右側の分野に年をとらせます。
Moy [Page 21] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[21ページ]RFC1793OSPF
Time T1: Underlying data-link connection is torn down.
時間T1: 基本的なデータリンク接続を取りこわします。
All application traffic is flowing over the leased line
connecting Routers RTB and RTD instead of the demand
circuit, due to the leased line's lesser OSPF cost. After
some period of inactivity, the data-link connection
underlying the demand circuit will be torn down. This does
not affect the OSPF database or the routers' routing tables.
すべてのアプリケーション交通が要求サーキットの代わりにRouters RTBとRTDを接続しながら、専用線の上に流れています、専用線の、より少ないOSPF費用のため。 いつかの期間の不活発の後に、要求サーキットの基礎となるデータリンク接続を取りこわすでしょう。 これはOSPFデータベースかルータの経路指定テーブルに影響しません。
Time T2: Router RTA refreshes its router-LSA.
時間T2: ルータRTAはルータ-LSAをリフレッシュします。
When Router RTA refreshes its router-LSA (as all routers do
every LSRefreshInterval), Router RTB floods the refreshed
LSA over the leased line but not over the demand circuit,
because the contents of the LSA have not changed. This new
LSA will not have the DoNotAge bit set, and will replace the
old instances (whether or not they have the DoNotAge bit
set) by virtue of its higher LS Sequence number. This is
pictured in Table 3.
専用線の上に壮快なLSAをあふれさせますが、Router RTAがルータ-LSAをリフレッシュするとき(すべてのルータがあらゆるLSRefreshIntervalをするとき)、Router RTBは要求サーキットの上にあふれるというわけではありません、LSAの内容が変化していないので。 この新しいLSAはDoNotAgeビットを設定させないで、より大きいLS Sequence番号によって古い例(それらがDoNotAgeビットを設定させるか否かに関係なく)を置き換えるでしょう。 これはTable3に描写されます。
Time T3: Leased line becomes inoperational.
時間T3: 専用線はinoperationalになります。
When the leased line becomes inoperational, the data-link
connection underlying the demand circuit will be reopened,
in order to flood a new (and changed) router-LSA for RTB and
also to carry the application traffic between Hosts H1 and
H2. After flooding the new LSA, all routers on the right
side of the demand circuit will have DoNotAge set in their
copy of RTB's router-LSA and DoNotAge clear in their copy of
RTA's router-LSA (see Table 4).
専用線がinoperationalになるとき、要求サーキットの基礎となるデータリンク接続は、RTBのための新しい(そして、変える)ルータ-LSAをあふれさせて、また、Hosts H1とH2の間のアプリケーション交通を運ぶために再開するでしょう。 新しいLSAをあふれさせた後に、要求サーキットの右側のすべてのルータで、RTBのルータ-LSAとDoNotAgeに関するそれらのコピーで用意ができているDoNotAgeはRTAのルータ-LSAに関するそれらのコピーで明確になるでしょう(Table4を見てください)。
Time T4: In Router RTE, Router RTA's router-LSA times out.
時間T4: Router RTE、Router RTAのルータ-LSA回のアウトで。
Refreshes of Router RTA's router-LSA are not being flooded
over the demand circuit. However, RTA's router-LSA is aging
in all of the routers to the right of the demand circuit.
For this reason, the router-LSA will eventually be aged out
and reflooded (by router RTE in our example). Because this
aged out LSA constitutes a real change (see Section 3.3), it
is flooded over the demand circuit from Router RTC to RTB.
There are then two possible scenarios. First, the LS
Sequence number for RTA's router-LSA may be larger on RTB's
side of the demand link. In this case, when router RTB
receives the flushed LSA it will respond by flooding back
the more recent instance (see Section 2.4). If instead the
LS sequence numbers are the same, the flushed LSA will be
flooded all the way back to Router RTA, which will then be
forced to reoriginate the LSA.
リフレッシュ、Router RTAのものでは、要求サーキットの上にルータ-LSAは水につかっている状態ではありません。 しかしながら、RTAのルータ-LSAはルータで要求サーキットの右に全部で老朽化しています。 この理由で、ルータ-LSAは結局、外で熟成して、「再-あふれ」るでしょう(私たちの例のルータRTE)。 この老いている出ているLSAが本当の変化を構成するので(セクション3.3を見てください)、それは要求サーキットの上にRouter RTCからRTBまで水につかっています。 その時、2つの可能なシナリオがあります。 まず最初に、RTBの要求リンクの側面では、RTAのルータ-LSAのLS Sequence番号が、より大きいかもしれません。 ルータRTBがこの場合紅潮LSAを受けるとき、それは氾濫後部のそばで、より最近の例を反応させるでしょう(セクション2.4を見てください)。 LS一連番号が代わりに同じであるなら、紅潮LSAはRouter RTAまでのいっぱいに水につかるようになるでしょう。(次に、Router RTAはやむを得ずLSAを再由来するでしょう)。
Moy [Page 22] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[22ページ]RFC1793OSPF
In any case, after a small period all the routers on the
right side of the demand link will have the DoNotAge bit set
in their copy of RTA's router-LSA (see Table 5). In the
small interval between the flushing and waiting for a new
instance of the LSA, there will be a temporary loss of
connectivity between Hosts H1 and H2.
どのような場合でも、小さい期間の後に、要求リンクの右側のすべてのルータはRTAのルータ-LSAに関するそれらのコピーにDoNotAgeビットを設定するでしょう(Table5を見てください)。 LSAの新しい例の洗い流すのと待ちの小さい間隔に、Hosts H1とH2の間には、接続性の一時的な損失があるでしょう。
Time T5: A non-supporting router joins.
時間T5: 非サポートルータは接合します。
Suppose Router RTY now becomes operational, and does not
support the demand circuit OSPF extensions. Router RTY's
router-LSA then will not have the DC-bit set in its Options
field, and as the router-LSA is flooded throughout the
internetwork it flushes all LSAs having the DoNotAge bit set
and causes the flooding behavior over the demand circuit to
revert back to the normal flooding behavior defined in [1].
However, although all LSAs will now be flooded over the
demand circuit, regardless of whether their contents have
really changed, Hellos will still continue to be suppressed
on the demand circuit (see Section 3.2.2).
Router RTYが現在操作上になって、要求サーキットOSPF拡張子をサポートしないと仮定してください。 次に、ルータRTYのルータ-LSAがOptions分野にDC-ビットを設定させないで、ルータ-LSAがインターネットワーク中で水につかっているとき、それで、DoNotAgeビットを設定させるすべてのLSAsを洗い流して、要求サーキットの上の氾濫の振舞いは[1]で定義された通常の氾濫の振舞いに戻って戻ります。 しかしながら、彼らの内容が本当に変化したかどうかにかかわらずすべてのLSAsが現在要求サーキットの上に水につかるでしょうが、それでも、ハローズは、要求サーキットの上に抑圧され続けるでしょう(セクション3.2.2を見てください)。
4.3. Example 3: Operation when oversubscribed
4.3. 例3: 申込みが超過しているときの操作
The following example shows the behavior of the demand circuit
extensions in the presence of oversubscribed interfaces. Note that
the example's topology excludes the possibility of alternative
paths. The combination of oversubscription and redundant topology
(i.e., alternative paths) poses special problems for the demand
circuit extensions. These problems are discussed later in Section
7.
以下の例は申込みが超過しているインタフェースの面前で要求サーキット拡大の振舞いを示しています。 例のトポロジーが迂回経路の可能性を除くことに注意してください。 応募超過と余分なトポロジー(すなわち、迂回経路)の組み合わせは要求サーキット拡大のために特別な問題を引き起こします。 後でセクション7でこれらの問題について議論します。
Figure 4 shows a single Router (RT1) connected via demand circuits
to three other routers (RT2-RT4). Assume that RT1 can only have
two out of three underlying data-link connections open at once.
This may be due to one of the following reasons: Router RT1 may be
using a single Basic Rate ISDN interface (2 B channels) to support
all three demand circuits, or, RT1 may be connected to a data-link
switch (e.g., an X.25 or Frame relay switch) that is only capable
of so many simultaneous data-link connections.
図4は、(RT1)が他の3つのルータ(RT2-RT4)への要求サーキットを通して接続したのを独身のRouterに示します。 RT1がすぐにオープンな3人の基本的なデータリンク接続のうちの2しか持つことができないと仮定してください。 これは以下の理由の1つのためであるかもしれません: ルータRT1がすべての3個の要求サーキットを支えるのに、単一のBasic Rate ISDNインタフェース(2つのBチャネル)を使用しているかもしれませんか、またはRT1は単にとても多くの同時のデータリンク接続ができるデータ・リンクスイッチ(例えば、X.25かFrameリレースイッチ)に接続されるかもしれません。
The following events may transpire, starting with Router RT1
coming up.
来るRouter RT1から始まって、以下の出来事は蒸散するかもしれません。
Moy [Page 23] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[23ページ]RFC1793OSPF
Time T0: Router RT1 comes up.
時間T0: ルータRT1は来ます。
Router RT1 attempts to establish neighbor connections and
synchronize OSPF databases with routers RT2-RT4. But,
ルータRT1は隣人接続を確立して、OSPFデータベースをルータRT2-RT4と同期させるのを試みます。 しかし
+ +--+
+---+ |--|H2|
+---------|RT2|--| +--+
/ +---+ |
/ ODL +
+--+ + /
|H1|--| / +
+--+ | +---+ ODL +---+ | +--+
|--|RT1|------------|RT3|--|--|H3|
| +---+ +---+ | +--+
| \ +
+ \ODL
\ + +--+
\ +---+ |--|H4|
+--------|RT4|--| +--+
+---+ |
+
+ +--+ +---+ |--|H2| +---------|RT2|--| +--+ / +---+ | /ODL++--+ + /|H1|--| / + +--+ | +---+ ODL+---+ | +--+ |--|RT1|------------|RT3|--|--|H3| | +---+ +---+ | +--+ | \++\ODL\++--+ \+---+ |--|H4| +--------|RT4|--| +--+ +---+ | +
Figure 4: Example 3's internetwork.
図4: 例3のインターネットワーク。
because it cannot have data-link connections open to all
three at once, it will synchronize with RT2 and RT3, while
Hellos sent to RT4 will be discarded (see Section 1).
すぐにすべての3にオープンなデータリンク接続を持つことができないので、RT2とRT3に連動するでしょう、RT4に送られたハローズは捨てられるでしょうが(セクション1を見てください)。
Time T1: Data-link connection to RT2 closed due to inactivity.
時間T1: RT2へのデータリンク接続は不活発のため閉じました。
Assuming that no application traffic is being sent to/from
Host H2, the underlying data-link connection to RT2 will
eventually close due to inactivity. This will allow RT1 to
finally synchronize with RT4; the next Hello that RT1
attempts to send to RT4 will cause that data-link connection
to open and synchronization with RT4 will ensue. Note that,
until this time, H4 will have been considered unreachable by
OSPF routing. However, data traffic would not have been
deliverable to H4 until now in any case.
どんなアプリケーション交通もHost H2からの/に送らないことにされるのであると仮定すると、RT2への基本的なデータリンク接続は結局、不活発のため閉じるでしょう。 これで、RT1は最終的にRT4に連動できるでしょう。 RT1がRT4に送るのを試みる次のHelloはRT4との開くデータリンク接続と同期を続かせてくださいだろう。 H4が今回手が届かないとOSPFルーティングで考えられてしまうだろうまで、それに注意してください。 しかしながら、どのような場合でも、データ通信量は現在までのH4への提出物でないでしょう。
Moy [Page 24] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[24ページ]RFC1793OSPF
Time T2: RT2's LAN interface becomes inoperational
時間T2: RT2のLANインタフェースはinoperationalになります。
This causes RT2 to reissue its router-LSA. However, it may
be unable to flood it to RT1 if RT1 already has data-link
connections open to RT3 and RT4. While the data-link
connection from RT2 to RT1 cannot be opened due to resource
shortages, the new router-LSA will be continually
retransmitted (and dropped by RT2's ISDN interface; see
Section 1). This means that the routers RT1, RT3 and RT4
will not detect the unreachability of Host H2 until a data-
link connection on RT1 becomes available.
これで、RT2はルータ-LSAを再発行します。 しかしながら、RT1にRT3とRT4にオープンなデータリンク接続が既にいるなら、RT1へそれをあふれさせることができないかもしれません。 リソース不足のためRT2からRT1までのデータリンク接続を開くことができませんが、新しいルータ-LSAは絶えず再送されるでしょう(そして、RT2のISDNインタフェース; セクション1を見るのに立ち寄ります)。 RT1におけるデータリンク結合が利用可能になるまで、これは、ルータのRT1、RT3、およびRT4がHost H2の「非-可到達性」を検出しないことを意味します。
5. Topology recommendations
5. トポロジー推薦
Because LSAs indicating topology changes are still flooded over demand circuits, it is still advantageous to design networks so that the demand circuits are isolated from as many topology changes as possible. In OSPF, this is done by encasing the demand circuits within OSPF stub areas or within NSSAs (see [3]). In both cases, this isolates the demand circuits from AS external routing changes, which in many networks are the most frequent (see [6]). Stub areas can even isolate the demand circuits from changes in other OSPF areas.
トポロジー変化を示すLSAsが要求サーキットの上にまだ水につかっているので、ネットワークを設計するのがまだ有利であるので、要求サーキットはできるだけ多くのトポロジー変化から隔離されます。 OSPFでは、OSPFスタッブ領域以内かNSSAsの中で要求サーキットをケースに入れることによって、これをします。([3])を見てください。 どちらの場合も、これはASの外部のルーティング変化から要求サーキットを隔離します。(変化は多くのネットワークが最も頻繁です)。([6])を見てください。 スタッブ領域は他のOSPF領域の変化から要求サーキットを隔離さえできます。
Also, considering the interoperation of OSPF routers supporting demand circuits and those that do not (see Section 2.5), isolated stub areas or NSSAs can be converted independently to support demand circuits. In contrast, regular OSPF areas must all be converted before the functionality can take effect in any particular regular OSPF area.
また、要求サーキットを支えるために独自に要求サーキットを支えるOSPFルータとそうしないそれら(セクション2.5を見る)か、孤立しているスタッブ領域かNSSAsのinteroperationを考えるのを変換できます。 対照的に、機能性がどんな特定の通常のOSPF領域でも実施できる前に通常のOSPF領域をすべて変換しなければなりません。
6. Lost functionality
6. 無くなっている機能性
The enhancements defined in this memo to support demand circuits come at some cost. Although we gain an efficient use of demand circuits, holding them open only when there is actual application data to send, we lose the following:
要求サーキットを支えるためにこのメモで定義された増進は何らかの費用で来ます。 私たちが要求サーキットの効率的な使用を獲得しますが、そこであるのにだけそれらを開けておくのが、送る本番適用データである、私たちは以下を失います:
Robustness
In regular OSPF [1], all LSAs are refreshed every
LSRefreshInterval. This provides protection against routers
losing LSAs from (or LSAs getting corrupted in) their link state
databases due to software errors, etc. Over demand circuits
this periodic refresh is removed, and we depend on routers
correctly holding LSAs marked with DoNotAge in their databases
indefinitely.
丈夫さのIn通常のOSPF[1]、すべてのLSAsが壮快です。あらゆるLSRefreshInterval。 これはソフトウェア誤りなどのため彼らの(または、得るのが崩壊したLSAs)リンク州のデータベースからルータの損をしているLSAsに対する保護を提供します。 終わっている、これほど周期的なサーキットがリフレッシュする要求は移されて、私たちはDoNotAgeと共に彼らのデータベースでLSAsを無期限にマークするように正しく主張するルータを当てにします。
Moy [Page 25] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[25ページ]RFC1793OSPF
Database Checksum
OSPF supplies network management variables, namely
ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing a
network management station to verify OSPF database
synchronization among routers. However, these variables are sums
of the individual LSAs' LS checksum fields, which are no longer
guaranteed to be identical across demand circuits (because the
LS checksum covers the LS Sequence Number, which will in general
differ across demand circuits). This means that these variables
can no longer be used to verify database synchronization in OSPF
networks containing demand circuits.
データベースChecksum OSPFはネットワークマネージメントステーションにルータの中でOSPFデータベース同期について確かめさせる[7]のネットワークマネージメント変数、すなわち、ospfExternLSACksumSum、およびospfAreaLSACksumSumを供給します。 しかしながら、これらの変数は個々のLSAsのLSチェックサム分野の合計(LSチェックサムがLS Sequence Numberを覆っているので)です。(分野は、要求サーキットの向こう側に同じになるようにもう保証されません)。一般に、LS Sequence Numberは要求サーキットの向こう側に異なるでしょう。 これは、要求サーキットを含むOSPFネットワークでデータベース同期について確かめるのにもうこれらの変数を使用できないことを意味します。
7. Future work: Oversubscription
7. 今後の活動: 応募超過
An internetwork is oversubscribed when not all of its demand circuits' underlying connections can be open at once, due to resource limitations. These internetworks were addressed in Section 4.3. However, when all possible sources in the internetwork are active at once, problems can occur which are not addressed in this memo:
要求サーキットのどんな基本的な接続皆、もすぐに開くはずがないとき、インターネットワークは申込みが超過しています、リソース制限のため。 これらのインターネットワークはセクション4.3に記述されました。 しかしながら、インターネットワークにおけるすべての可能なソースがすぐに活発であるときに、このメモに記述されない問題は起こることができます:
(1) There is a network design problem. Does a subset of demand
circuits exist such that a) their data-link connections can be
open simultaneously and b) they can provide connectivity for all
possible sources? This requires that (at least) a spanning tree
be formed out of established connections. Figure 4 shows an
example where this is not possible; Hosts H1 through H4 cannot
simultaneously talk, since Router RT1 is limited to two
simultaneously open demand circuits.
(1) ネットワーク設計上の問題があります。 要求サーキットの部分集合は、a) 彼らのデータリンク接続が同時に、オープンである場合があり、b) 彼らがすべての可能なソースに接続性を提供できるように、存在していますか? これは、(少なくとも)スパニングツリーが確立した接続から形成されるのを必要とします。 図4は、これがどこで可能でないかを例に示します。 Router RT1が2個の同時に開いている要求サーキットに制限されるのでH1からH4が同時に話すことができないホスト。
(2) Even if it is possible that a spanning tree can form, will one?
Given the model in Section 1, demand circuits are brought up
when needed for data traffic, and stay established as long as
data traffic is present. One example is shown in Figure 5. Four
routers are interconnected via demand circuits, with each router
being able to establish a circuit to any other. However, we
assume that each router can only have two circuits open at once
(e.g., the routers could be using Basic Rate ISDN). In this
case, one would hope that the data-link connections in Figure 5a
would form. But the connections in Figure 5b are equally
likely, which leave Host H2 unable to communicate.
(2) スパニングツリーがそうすることができるのが可能であっても、形成してくれるんでしょう? セクション1のモデルを考えて、データ通信量、およびデータ通信量が存在している限り、確立された滞在に必要であると、要求サーキットは持って来られます。 1つの例が図5に示されます。 それぞれのルータがサーキットをいかなる他のも確立できる状態で、4つのルータが要求サーキットを通してインタコネクトされます。 しかしながら、私たちは、各ルータがすぐに開いている2個のサーキットしか持つことができないと思います(例えば、ルータはBasic Rate ISDNを使用しているかもしれません)。 この場合、人は、図5aにおけるデータリンク接続が形成することを望んでいるでしょう。 しかし、図5bにおける接続は等しくありそうです(交信できない状態でHost H2を残します)。
One possible approach to this problem would be for a) the OSPF
database to indicate which demand circuits have actually been
established and b) implement a distributed spanning tree
construction (see for example Chapter 5.2.2 of [9]) when
necessary.
この問題への1つの可能なアプローチはa) OSPFデータベースが、どれが、サーキットが実際に確立されたのを要求するかを示すだろうことです、そして、b)は分配されたスパニングツリー工事を実行します。(必要であるときには[9])について例えば第5.2章の.2を見てください。
Moy [Page 26] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[26ページ]RFC1793OSPF
(3) Even when a spanning tree has been built, will it be used?
Routers implementing the functionality described in this memo do
not necessarily know which data-link connections are established
at any one time. In fact, they view all demand circuits as being
equally available, whether or not they are currently
established. So for example, even when the established
connections form the pattern in Figure 5a, Router RT1 may still
believe that the best path to Router RT3 is through the direct
demand circuit. However, this circuit cannot be established due
to resource shortages.
(3) スパニングツリーが築き上げられたときさえ、それは使用されるでしょうか? このメモで説明された機能性を実行するルータは、どのデータリンク接続がいかなる時も確立されるかを必ず知っているというわけではありません。 事実上、彼らはそれらが現在設立されるか否かに関係なく、等しく利用可能であるとすべての要求サーキットをみなします。 それで、例えば、確立した接続が図5aのパターンを形成さえするとき、Router RT1は、直接需要サーキットを通してRouter RT3への最も良い経路があるとまだ信じているかもしれません。 しかしながら、リソース不足のためこのサーキットを確立できません。
+--+ + + +--+
|H1|--| +---+ ODL +---+ |--|H2|
+--+ |--|RT1|-------|RT2|--| +--+
| +---+ +---+ |
+ | \ / | +
| \ / |
| \ / |
|ODL / |ODL
| / \ODL |
| / \ |
+ | /ODL \ | +
+--+ | +---+ +---+ | +--+
|H4|--|--|RT4|-------|RT3|--|--|H3|
+--+ | +---+ ODL +---+ | +--+
+ +
+--+ + + +--+ |H1|--| +---+ ODL+---+ |--|H2| +--+ |--|RT1|-------|RT2|--| +--+ | +---+ +---+ | + | \ / | + | \ / | | \ / | |ODL/|ODL| /\ODL| | / \ | + | /ODL\| + +--+ | +---+ +---+ | +--+ |H4|--|--|RT4|-------|RT3|--|--|H3| +--+ | +---+ ODL+---+ | +--+ + +
Figure 5: Example of an oversubscribed
internetwork
図5: 申込みが超過しているインターネットワークに関する例
Moy [Page 27] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[27ページ]RFC1793OSPF
+---+ +---+ +---+ +---+
|RT1|-------|RT2| |RT1| |RT2|
+---+ +---+ +---+ +---+
| | | \
| | | \
| | | \
| | | \
| | | \
| | | \
| | | \
+---+ +---+ +---+ +---+
|RT4|-------|RT3| |RT4|-------|RT3|
+---+ +---+ +---+ +---+
+---+ +---+ +---+ +---+ |RT1|-------|RT2| |RT1| |RT2| +---+ +---+ +---+ +---+ | | | \ | | | \ | | | \ | | | \ | | | \ | | | \ | | | \ +---+ +---+ +---+ +---+ |RT4|-------|RT3| |RT4|-------|RT3| +---+ +---+ +---+ +---+
Figure 5a: One possible Figure 5b: Another possible
pattern of data-link pattern of data-link
connections connections
図5a: 1可能な図5b: データリンク接続接続のデータ・リンク模範の別の可能なパターン
On possible approach to this problem is to increase the OSPF cost of demand circuits that are currently discarding application packets (i.e., can't be established) due to resource shortages. This may help the routing find paths that can actually deliver the packets. On the downside, it would create more routing traffic. Also, unwanted routing oscillations may result when you start varying routing metrics to reflect dynamic network conditions; see [10].
この問題への可能なアプローチには、増加には現在リソース不足のため、アプリケーションパケット(すなわち、設立できない)を捨てている要求サーキットのOSPF費用があります。 これは、ルーティングが実際にパケットを届けることができる経路を見つけるのを助けるかもしれません。 下落傾向に、それは、より多くのルーティング交通を引き起こすでしょう。 また、あなたがダイナミックなネットワーク状態を反映するためにルーティング測定基準を変え始めるとき、求められていないルーティング振動は結果として生じるかもしれません。 [10]を見てください。
8. Unsupported capabilities
8. サポートされない能力
The following possible capabilities associated with demand circuit routing have explicitly not been supported by this memo:
要求サーキットルーティングに関連している以下の可能な能力はこのメモで明らかに支持されていません:
o When the topology of an OSPF area changes, the changes are
flooded over the area's demand circuits, even if this requires
(re)establishing the demand circuits' data-link connections. One
might imagine a routing system where the flooding of topology
changes over demand circuits were delayed until the demand
circuits were (re)opened for application traffic. However, this
capability is unsupported because delaying the flooding in this
manner would sometimes impair the ability to discover new
network destinations.
o OSPF領域のトポロジーが変化するとき、変化は領域の要求サーキットの上に水につかっています、これが、要求サーキットのデータリンク接続を確立するのを必要としても(re)。 人は要求サーキットの上のトポロジー変化の氾濫が要求サーキットがアプリケーション交通に開かれた(re)になるまで遅れたルーティングシステムを想像するかもしれません。 氾濫を遅らせると、新しいネットワークの目的地を発見する能力はこの様に時々損なわれるでしょう、しかしながら、したがって、この能力がサポートされないです。
o Refining the previous capability, one might imagine that the
network administrator would be able to configure for each demand
interface whether flooding should be immediate, or whether it
should be delayed until the data-link connection is established
for application traffic. This would allow certain "application-
specific" routing behaviors. For example, a demand circuit may
connect a collection of client-based subnets to a collection of
o 前の能力を洗練して、人は、ネットワーク管理者が、氾濫が即座であるべきであるかどうか、またはデータリンク接続がアプリケーション交通に確立されるまでそれが遅れるべきであるかどうかをそれぞれの要求インタフェースに構成できると想像するかもしれません。 これはある「アプリケーション特有」のルーティングの振舞いを許容するでしょう。 例えば、サーキットが収集へのクライアントベースのサブネットの収集を接続するかもしれない要求
Moy [Page 28] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[28ページ]RFC1793OSPF
server-based subnets. If the client end was configured to delay
flooding, while the server end was configured to flood changes
immediately, then new servers would be discovered promptly while
clients might not be discovered until they initiate
conversations. However, this capability is unsupported because
of the increased complexity of (and possibility for error in)
the network configuration.
サーバベースのサブネット。 クライアント終わりがサーバ終わりがすぐに変化をあふれさせるように構成されていた間、浸水するのを遅らせるために構成されるなら、彼らが会話を開始するまで、クライアントは発見されないかもしれませんが、新しいサーバは即座に発見されるでしょうに。 しかしながら、この能力は(そして、中の誤りのための可能性)ネットワーク・コンフィギュレーションの増加する複雑さのためにサポートされないです。
Moy [Page 29] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[29ページ]RFC1793OSPF
A. Format of the OSPF Options field
A。 OSPF Options分野の形式
The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain.
OSPF Options分野はOSPF Helloパケット、Database記述パケット、およびすべてのLSAsに存在しています。 Options分野は、OSPFルータが(または、サポートでない)任意の能力を支持して、それらの能力レベルを他のOSPFルータに伝えるのを可能にします。 このメカニズムを通して、異なった能力のルータはOSPF経路ドメインの中で複雑であることができます。
The memo defines one of the Option bits: the DC-bit (for Demand Circuit capability). The DC-bit is set in a router's self-originated LSAs if and only if it supports the functionality defined in Section 2 of this memo. Note that this does not necessarily mean that the router can be the endpoint of a demand circuit, but only that it can properly process LSAs having the DoNotAge bit set. In contrast, the DC-bit is set in Hello Packets and Database Description Packets sent out an interface if and only if the router wants to treat the attached point-to-point network as a demand circuit (see Section 3.2.1).
メモはOptionビットの1つを定義します: DC-ビット(Demand Circuit能力のための)。 そして、DC-ビットがルータの自己によって溯源されたLSAsに設定される、このメモのセクション2で定義された機能性を支持する場合にだけ。 これが、必ずルータが要求サーキットの終点であるかもしれませんが、適切にDoNotAgeビットを設定させるLSAsは処理できるだけであることを意味するというわけではないことに注意してください。 そして、対照的に、DC-ビットがHello Packetsに設定されて、Database記述Packetsがインタフェースを出した、要求サーキット(セクション3.2.1を見る)として付属二地点間ネットワークを扱うルータ必需品である場合にだけ。
The addition of the DC-bit makes the current assignment of the OSPF Options field as follows:
DC-ビットの添加で、OSPF Options分野の現在の課題は以下の通りになります:
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | T |
+------------------------------------+
+------------------------------------+ | * | * | DC| EA| N/P| M.C.| E| T| +------------------------------------+
Figure 5: The OSPF Options field
図5: OSPF Options分野
T-bit
This bit describes TOS-based routing capability, as specified in
[1].
T-ビットThisビットは[1]で指定されるようにTOSベースのルーティング能力について説明します。
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in [1].
電子ビットThisビットはASの外部のLSAsが[1]で説明されるように水につかっている方法を述べます。
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [4].
ビットThisビットM.C.は、IPマルチキャストデータグラムが[4]の仕様通りに進められるかどうか説明します。
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[3].
PでN/噛み付いているThisビットは[3]で指定されるようにType-7 LSAsの取り扱いについて説明します。
Moy [Page 30] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[30ページ]RFC1793OSPF
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs, as specified in [5].
EA-ビットThisビットは[5]で指定されるように受信するルータの意欲と前進のExternal属性LSAsについて説明します。
DC-bit
This bit describes the handling of demand circuits, as specified
in this memo. Its setting in Hellos and Database Description
Packets is described in Sections 3.2.1 and 3.2.2. Its setting in
LSAs is described in Sections 2.1 and 2.5.
DC-ビットThisビットはこのメモで指定されるように要求サーキットの取り扱いについて説明します。 ハローズとDatabase記述Packetsにセットするのはセクション3.2.1と3.2で.2に説明されます。 LSAsにセットするのはセクション2.1と2.5で説明されます。
B. Configurable Parameters
B。 構成可能なパラメタ
This memo defines a single additional configuration parameter for OSPF interfaces. In addition, the OSPF Interface configuration parameter PollInterval, previously used only on NBMA networks, is now also used on point-to-point networks (see Sections 3.1 and 3.2.2).
このメモはOSPFインタフェースのためのただ一つの追加設定パラメータを定義します。 また、さらに、以前にNBMAネットワークだけで使用されたOSPF Interface設定パラメータPollIntervalは現在、二地点間ネットワークで使用されます(セクション3.1と3.2.2を見てください)。
ospfIfDemand
Indicates whether the interface connects to a demand circuit.
When set to TRUE, the procedures described in Section 3 of this
memo are followed, in order to send a minimum of routing traffic
over the demand circuit. On point-to-point networks, this allows
the circuit to be closed when not carrying application traffic.
When a broadcast or NBMA interface is configured to connect to a
demand circuit (see Section 1.2 of [1]), the data-link
connections will be kept open constantly due to OSPF Hello
traffic, but the amount of flooding traffic will still be
greatly reduced.
インタフェースがaに接続するか否かに関係なく、ospfIfDemand Indicatesはサーキットを要求します。 TRUEに設定されると、このメモのセクション3で説明された手順は従われています、最小ルーティング交通を要求サーキットの上に送るために。 アプリケーション交通を運ばないとき、二地点間ネットワークでは、これで、サーキットは閉じます。 放送かNBMAがいつ連結するかは、要求サーキットに接続するために構成されます。([1])のセクション1.2を見なさい、ただし、データリンク接続はOSPF Hello交通のため絶えず開いた状態で保たれるでしょうが、それでも、氾濫交通の量は大いに減少するでしょう。
C. Architectural Constants
C。 建築定数
This memo defines a single additional OSPF architectural constant.
このメモはただ一つの追加OSPF建築定数を定義します。
DoNotAge
Equal to the hexadecimal value 0x8000, which is the high bit of
the 16-bit LS age field in OSPF LSAs. When this bit is set in
the LS age field, the LSA is not aged as it is held in the
router's link state database. This allows the elimination of the
periodic LSA refresh over demand circuits. See Section 2.2 for
more information on processing the DoNotAge bit.
16進へのDoNotAge Equalは0×8000を評価します。(0×8000はOSPF LSAsの16ビットのLS時代分野の高いビットです)。 LSA老いないそれがルータのリンク州のデータベースに保持されるときこのビットがLS時代分野に設定されるとき。 これはLSAが要求サーキットの上にリフレッシュする周期的除去を許容します。 DoNotAgeビットを処理する詳しい情報に関してセクション2.2を見てください。
Moy [Page 31] RFC 1793 OSPF over Demand Circuits April 1995
要求サーキット1995年4月の上のMoy[31ページ]RFC1793OSPF
References
参照
[1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
[1]Moy、J.、「OSPF、バージョン2インチ、RFC1583、Proteon Inc.、1994インチ年3月。
[2] Meyer, G., "Extensions to RIP to Support Demand Circuits", RFC
1582, Spider Systems, February 1994.
[2] マイヤー、G.、「要求サーキットを支えるために裂く拡大」、RFC1582、クモのシステム、1994年2月。
[3] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
RainbowBridge Communications, Stanford University, March 1994.
フラー、[3]Coltun、R.、およびRFC1587、RainbowBridgeコミュニケーション、スタンフォード大学、1994年3月対「OSPF NSSAオプション」
[4] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,
March 1994.
[4]Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、Proteon Inc.、1994年3月。
[5] Ferguson, D., "The OSPF External Attributes LSA", Work in
Progress.
[5] ファーガソン、D.、「OSPFの外部の属性LSA」が進行中で働いています。
[6] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon,
Inc., July 1991.
[6]Moy、J.、エディタ、「OSPFプロトコル分析」、RFC1245、Proteon Inc.、1991年7月。
[7] Baker F. and R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1253, ACC, University of Maryland, August 1991.
[7] ベイカーF.とR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1253、ACC、メリーランド大学、1991年8月。
[8] Baker F., "OSPF Point-to-MultiPoint Interface", Work in Progress.
[8] ベイカーF.、「OSPFポイントツーマルチポイントインタフェース」が進行中で働いています。
[9] Bertsekas, D., and R. Gallager, "Data Networks", Prentice Hall,
Inc., 1992.
[9] Bertsekas、D.とR.Gallager、「データ網」新米のホールInc.、1992
[10] Khanna, A., "Short-Term Modifications to Routing and Congestion
Control", BBN Report 6714, BBN, February 1988.
[10]Khanna、A.、「ルート設定と混雑コントロールへの短期的な変更」、BBNレポート6714、BBN、1988年2月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
John Moy Cascade Communications Corp. 5 Carlisle Road Westford, MA 01886
ジョンMoyは社5のカーライルRoadウェストフォード、Communications MA 01886をどっと落させています。
Phone: 508-692-2600 Ext. 394 Fax: 508-692-9214 EMail: jmoy@casc.com
以下に電話をしてください。 508-692-2600 Ext。 394 Fax: 508-692-9214 メールしてください: jmoy@casc.com
Moy [Page 32]
Moy[32ページ]
一覧
スポンサーリンク
