[要約] RFC 5820は、モバイルアドホックネットワーキングをサポートするためのOSPFの拡張に関するものです。このRFCの目的は、モバイルデバイス間の通信を効率的に管理し、ネットワークの信頼性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) A. Roy, Ed.
Request for Comments: 5820 Cisco Systems
Category: Experimental M. Chandra, Ed.
ISSN: 2070-1721 March 2010
Extensions to OSPF to Support Mobile Ad Hoc Networking
モバイルアドホックネットワーキングをサポートするためのOSPFへの拡張
Abstract
概要
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs.
このドキュメントでは、モバイルアドホックネットワーク（MANETS）をサポートするためのOSPFへの拡張について説明しています。OSPF-OR（OSPFを重複するリレー）と呼ばれる拡張機能には、リンク局所シグナル伝達（LLS）のメカニズム、OSPF-Manetインターフェイス、増分状態の変化のみを送信することでハローパケットのサイズを縮小する簡単な手法、およびルーティングアップデートの最適化された洪水の方法。OSPF-ORは、より大きなマネットをサポートするために不必要な隣接を減らす手段も提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5820.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5820で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Problem Statement ..........................................4
1.2. Motivation for Extending OSPF to Support MANETs ............5
2. Requirements Notation ...........................................5
3. Proposed Enhancements ...........................................5
3.1. OSPF-MANET Interface .......................................7
3.1.1. Interface Operation .................................8
3.1.2. LSA Formats and Examples ............................8
3.2. Incremental OSPF-MANET Hellos .............................12
3.2.1. The I Option Bit ...................................12
3.2.2. State Check Sequence TLV (SCS TLV) .................12
3.2.3. Neighbor Drop TLV ..................................13
3.2.4. Request From TLV (RF TLV) ..........................14
3.2.5. Full State For TLV (FSF TLV) .......................14
3.2.6. Neighbor Adjacencies ...............................15
3.2.7. Sending Hellos .....................................16
3.2.8. Receiving Hellos ...................................17
3.2.9. Interoperability ...................................19
3.2.10. Support for OSPF Graceful Restart .................19
3.3. Optimized Flooding (Overlapping Relays) ...................20
3.3.1. Operation Overview .................................20
3.3.2. Determination of Overlapping Relays ................21
3.3.3. Terminology ........................................21
3.3.4. Overlapping Relay Discovery Process ................22
3.3.5. The F Option Bit ...................................23
3.3.6. Active Overlapping Relay TLV (AOR TLV) .............23
3.3.7. Willingness TLV ....................................24
3.3.8. Flooding and Relay Decisions .......................25
3.3.9. Intelligent Transmission of Link State
Acknowledgments ....................................26
3.3.10. Important Timers ..................................27
3.3.11. Miscellaneous Protocol Considerations .............28
3.3.12. Interoperability ..................................28
3.4. New Bits in LLS Type 1 Extended Options and Flags .........29
3.5. Smart Peering .............................................29
3.5.1. Rationale for Smart Peering ........................29
3.5.2. Previous Related Work ..............................30
3.5.3. Smart Peering Solution .............................30
3.5.4. Advertising 2-Way Links in Router-LSAs .............33
4. Security Considerations ........................................36
5. IANA Considerations ............................................38
6. Contributors ...................................................39
7. Acknowledgments ................................................39
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................40
Mobile ad hoc networks (MANETs) have been an area of study for some time within various working groups and areas within the IETF, various military branches, and various government agencies. Recently, networks with mobile ad hoc requirements have been proposed and are being seriously considered for deployment in the near term, which means the concepts and research now need to be applied to deployed networks. Towards that end, this document applies many of the principles and concepts learned through prior work to [OSPFv3], along with new concepts based on current requirements.
モバイルアドホックネットワーク（MANETS）は、IETF、さまざまな軍事部門、およびさまざまな政府機関内のさまざまなワーキンググループおよびエリア内でしばらくの間研究分野でした。最近、モバイルアドホック要件を備えたネットワークが提案されており、短期的に展開するために真剣に検討されています。つまり、概念と研究を展開したネットワークに適用する必要があります。その目的に向けて、このドキュメントは、現在の要件に基づいた新しい概念とともに、以前の研究を通じて学んだ原則と概念の多くを[OSPFV3]に適用します。
MANETs are synonymous with packet radio networks, which have been around since the 1960s in a limited military capacity. With the boom in mobile devices and wireless communications, MANETs are finding scope in commercial and military environments. The aim of these networks is to support robust and efficient communication in a mobile wireless network by incorporating routing functionality into mobile nodes.
マネは、1960年代以降、軍事能力が限られているため、パケットラジオネットワークと同義です。モバイルデバイスとワイヤレス通信のブームにより、マネは商業環境および軍事環境で範囲を見つけています。これらのネットワークの目的は、ルーティング機能をモバイルノードに組み込むことにより、モバイルワイヤレスネットワークでの堅牢で効率的な通信をサポートすることです。
A MANET is an autonomous set of nodes distributed over a wide geographical area that communicate over bandwidth-constrained wireless links. Each node may represent a transmitter, receiver, or relay station with varying physical capabilities. Packets may traverse through several intermediate (relay) nodes before reaching their destination. These networks typically lack infrastructure: nodes are mobile, and there is no central hub or controller; thus, there is no fixed network topology. Moreover, MANETs must contend with a difficult and variable communication environment. Packet transmissions are plagued by the usual problems of radio communication, which include propagation path loss, signal multipath and fading, and thermal noise. These effects vary with terminal movement, which also induces Doppler spreading in the frequency of the transmitted signal. Finally, transmissions from neighboring terminals, known as multi-access interference, hostile jammers, and impulsive interference, e.g., ignition systems, generators, and other non-similar in-band communications, may contribute additional interference.
MANETは、帯域幅が制約されたワイヤレスリンクを介して通信する広い地理的領域に分布するノードの自律的なセットです。各ノードは、さまざまな物理機能を備えた送信機、受信機、またはリレーステーションを表す場合があります。パケットは、宛先に到達する前に、いくつかの中間（リレー）ノードを通過する場合があります。これらのネットワークには通常、インフラストラクチャがありません。ノードはモバイルであり、中央ハブやコントローラーはありません。したがって、固定ネットワークトポロジはありません。さらに、マネは困難で可変的なコミュニケーション環境と対戦しなければなりません。パケット送信は、伝播パスの損失、信号マルチパスとフェード、および熱ノイズなど、ラジオ通信の通常の問題に悩まされています。これらの効果は、末端の動きによって異なり、透過信号の周波数でドップラーの拡散を誘導します。最後に、マルチアクセス干渉、敵対的なジャマー、および衝動的な干渉として知られる隣接端子からの送信は、例えば、点火システム、発電機、およびその他の非類似のインバンド通信が追加の干渉に寄与する可能性があります。
Given this nature of MANETs, the existence of a communication link between a pair of nodes is a function of their variable link quality, including signal strength and bandwidth. Thus, routing paths vary, based on environment and the resulting network topology. In such networks, the topology may be stable for periods of time and then suddenly become unpredictable. Since MANETs are typically decentralized systems, there are no central controllers or specially designated routers to determine the routing paths as the topology changes. All of the routing decisions and forwarding (relaying) of packets must be done by the nodes themselves, and communication is on a peer-to-peer basis.
このマネの性質を考えると、ノードのペア間の通信リンクの存在は、信号強度や帯域幅を含む可変リンク品質の関数です。したがって、ルーティングパスは、環境と結果のネットワークトポロジに基づいて異なります。このようなネットワークでは、トポロジーは期間安定している可能性があり、その後突然予測不可能になります。マネは通常、分散型システムであるため、トポロジが変化するにつれてルーティングパスを決定するための中央コントローラーまたは特別に指定されたルーターはありません。ルーティングの決定とパケットの転送（中継）は、ノード自体によって行われなければならず、通信はピアツーピアベースで行われます。
The motivation to extend a standard protocol, OSPF (described in [OSPF] and [OSPFv3]), to operate on MANETs is twofold. The primary reason is for interoperability -- MANET devices need to be able to work when plugged into a wireline network in as many cases as possible. The junction point between a MANET and wire-line network should also be as fluid as possible, allowing a MANET to "plug in" to just about any location within a wire-line network, and also find connectivity, etc., as needed.
標準的なプロトコルであるOSPF（[OSPF]および[OSPFV3]に記載）を拡張する動機は、マネットで動作することです。主な理由は相互運用性のためです - MANETデバイスは、できるだけ多くのケースでワイヤーラインネットワークに接続したときに動作できる必要があります。マネとワイヤーラインのネットワークの間のジャンクションポイントもできるだけ流動的である必要があり、必要に応じて、マネがワイヤーラインネットワーク内のほぼ任意の場所に「プラグイン」し、接続性などを見つけることができます。
While routes could be redistributed between two routing protocols, one designed just for wire-line networks, and the other just for MANETs, this adds complexity and overhead to the MANET/wireline interface, increases the odds of an error being introduced between the two domains, and decreases flexibility.
ルートは2つのルーティングプロトコルの間に再配布できますが、1つはワイヤーラインネットワーク向けに設計され、もう1つはMANETのためだけに設計されていますが、これによりMANET/WIRELINEインターフェイスに複雑さとオーバーヘッドが追加され、2つのドメイン間に導入されるエラーのオッズが増加します。、および柔軟性を低下させます。
The second motivation is that OSPF is a well-understood and widely deployed routing protocol. This provides a strong basis of experience and skills from which to work. A protocol that is known to work can be extended, rather than developing a new protocol that must then be completely troubleshot, tested, and modified over a number of years. Working with a well-known protocol allows development effort to be placed in a narrowly focused area, rather than rebuilding, from scratch, many things that are already known to work.
2番目の動機は、OSPFがよく理解されており、広く展開されているルーティングプロトコルであることです。これは、仕事をするための経験とスキルの強力な基盤を提供します。動作することが知られているプロトコルは、何年もの間、完全にトラブルシューショット、テスト、変更する必要がある新しいプロトコルを開発するのではなく、拡張できます。よく知られているプロトコルを使用することで、開発の努力は、すでに機能することが既に知られている多くのものをゼロから、再構築するのではなく、狭く焦点を絞った領域に配置することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEY].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [key]に記載されているように解釈される。
This document proposes modifications to [OSPFv3] to support mobile ad hoc networks (MANETs). Note that it is possible to use the mechanisms defined in Sections 3.2 and 3.3 independently of one another.
このドキュメントは、モバイルアドホックネットワーク（MANET）をサポートするために[OSPFV3]の変更を提案しています。セクション3.2および3.3で定義されているメカニズムを互いに独立して使用することが可能であることに注意してください。
The challenges with deploying standard [OSPFv3] in a MANET environment fit into two categories. First, traditional link-state routing protocols are designed for a statically configured environment. As a result, most of the configuration is done manually when a new router is placed in the network. Thus, OSPF will not function in an environment where routers interconnect and disconnect in somewhat random topologies and combinations. There are modifications that must be made in order for routers running the same protocol to communicate in a heterogeneous and dynamic environment.
マネ環境で標準[OSPFV3]を展開することに関する課題は、2つのカテゴリに適合します。まず、従来のリンク状態ルーティングプロトコルは、静的に構成された環境向けに設計されています。その結果、ほとんどの構成は、新しいルーターがネットワークに配置されているときに手動で行われます。したがって、OSPFは、ルーターが多少ランダムなトポロジと組み合わせで相互接続および切断する環境では機能しません。同じプロトコルを実行しているルーターが不均一で動的な環境で通信するために行う必要がある変更があります。
Currently there is no defined interface type that describes a wireless network. Wireless links have characteristics of both multi-access and point-to-multipoint links. Treating wireless links as multi-access does not take into account that not all nodes on the same Layer 2 link have bi-directional connectivity. However, any transmission on a link will reach nodes that are within transmission range. In this way, the link is multi-access due to the fact that two simultaneous transmissions may collide. A new interface type needs to be defined in order to accurately describe this behavior.
現在、ワイヤレスネットワークを記述する定義されたインターフェイスタイプはありません。ワイヤレスリンクには、マルチアクセスとポイントツーマルチポイントリンクの両方の特性があります。ワイヤレスリンクをマルチアクセスとして扱うことは、同じレイヤー2リンク上のすべてのノードが双方向の接続性を持っているわけではないことを考慮していません。ただし、リンク上の送信は、送信範囲内のノードに到達します。このようにして、2つの同時トランスミッションが衝突する可能性があるため、リンクはマルチアクセスです。この動作を正確に記述するために、新しいインターフェイスタイプを定義する必要があります。
The second category of challenges involves scalability. A MANET must transmit more state information to maintain reachability. Therefore, OSPF will need scalability enhancements to support MANETs. While some flooding optimizations are present in OSPF, such as designated router (DR) election, many of these were built under the assumption of a true multi-access network. Wireless networks are not true multi-access networks, because it cannot be assumed that there is 2-way connectivity between everyone on the same Layer 2 link. Therefore, optimizations such as DR election will not perform correctly in MANET networks. Without any further optimizations in link-state flooding, current OSPF would not be able to operate in a highly dynamic environment in which links are constantly being formed and broken. The amount of information that would need to be flooded would overload the network.
課題の2番目のカテゴリには、スケーラビリティが含まれます。マネは、到達可能性を維持するために、より多くの状態情報を送信する必要があります。したがって、OSPFは、マネをサポートするためにスケーラビリティの強化を必要とします。指定されたルーター（DR）選挙など、いくつかの洪水の最適化はOSPFに存在しますが、これらの多くは真のマルチアクセスネットワークの仮定の下で構築されました。ワイヤレスネットワークは、同じレイヤー2リンク上のすべての人の間に2方向の接続性があると想定できないため、真のマルチアクセスネットワークではありません。したがって、MANETネットワークでは、選挙博士などの最適化は正しく機能しません。リンク状態の洪水におけるさらなる最適化がなければ、現在のOSPFは、リンクが絶えず形成され壊れている非常に動的な環境で動作することはできません。浸水する必要がある情報の量は、ネットワークを過負荷にするでしょう。
Another scalability issue is the periodic transmission of Hello messages. Currently, even if there are no changes in a router's neighbor list, the Hello messages still list all the neighbors on a particular link. For a MANET router, where saving bandwidth and transmission power is a critical issue, the transmission of potentially large Hello messages is particularly wasteful.
別のスケーラビリティの問題は、Helloメッセージの定期的な送信です。現在、ルーターのネイバーリストに変更がない場合でも、Helloメッセージはまだ特定のリンク上のすべての隣人をリストしています。帯域幅と伝送力を保存することが重要な問題であるMANETルーターの場合、潜在的に大きなハローメッセージの送信は特に無駄です。
Finally, current routing protocols will form a neighbor relationship with any router on a Layer 2 link that is correctly configured. For MANET routers in a wireless network, this may lead to an excessive number of parallel links between two routers if communication is achieved via multiple interfaces. In a statically configured network, this is not a problem, since the physical topology can be built to prevent excessive redundancy. However, in a dynamic network, there must exist additional mechanisms to prevent too many redundant links. (Note that links between two nodes on different radio types, different antennae, different channels, etc., are considered different links and not redundant links.) In scalability tests, it has been demonstrated that the presence of too many redundant links will both increase the size of routing updates and cause extra flooding, resulting in even relatively small networks not converging.
最後に、現在のルーティングプロトコルは、正しく構成されているレイヤー2リンク上の任意のルーターとの隣接関係を形成します。ワイヤレスネットワーク内のMANETルーターの場合、複数のインターフェイスを介して通信が達成された場合、2つのルーター間で過度の数の並列リンクにつながる可能性があります。静的に構成されたネットワークでは、過度の冗長性を防ぐために物理トポロジを構築できるため、これは問題ではありません。ただし、動的ネットワークでは、冗長リンクが多すぎるのを防ぐための追加のメカニズムが存在する必要があります。（異なる無線タイプ、異なるアンテナ、異なるチャネルなどの2つのノード間のリンクは、異なるリンクと見なされ、冗長リンクではないことに注意してください。）スケーラビリティテストでは、冗長リンクが多すぎると両方とも増加することが実証されています。ルーティングの更新のサイズと余分な洪水を引き起こすため、比較的小さなネットワークでさえ収束しません。
Interfaces are defined as the connection between a router and one of its attached networks [OSPF]. Four types of interfaces have been defined and supported in [OSPF] and [OSPFv3]: broadcast, Non-Broadcast Multi-Access (NBMA), point-to-point, and point-to-multipoint.
インターフェイスは、ルーターとその添付ネットワークの1つ[OSPF]の1つの間の接続として定義されます。[OSPF]および[OSPFV3]で4種類のインターフェイスが定義およびサポートされています。
The point-to-multipoint model has been chosen to represent MANET interfaces. (The features designed in this document MAY be included on other interface types as appropriate.) The MANET interface allows the following:
ポイントツーマルチポイントモデルは、MANETインターフェイスを表すために選択されています。（このドキュメントで設計された機能は、必要に応じて他のインターフェイスタイプに含まれている場合があります。）MANETインターフェイスでは、以下を許可します。
o OSPF treats all router-to-router connections over the MANET interface as if they were point-to-point links.
o OSPFは、すべてのルーター間接続をManetインターフェース上のポイントツーポイントリンクであるかのように扱います。
o Link metric can be set on a per-neighbor basis.
o リンクメトリックは、ニーバーごとに設定できます。
o Broadcast and multicast can be accomplished through Layer 2 broadcast or Layer 2 pseudo-broadcast.
o ブロードキャストとマルチキャストは、レイヤー2ブロードキャストまたはレイヤー2の擬似ブロードキャストを介して実現できます。
* The MANET interface supports Layer 2 broadcast if it is able to address a single physical message to all of the attached neighbors. One such example is 802.11.
* MANETインターフェイスは、付着したすべての隣人に単一の物理的なメッセージに対処できる場合、レイヤー2ブロードキャストをサポートします。そのような例の1つは802.11です。
* The MANET interface supports Layer 2 pseudo-broadcast if it is able to pick up a packet from the broadcast queue, replicate the packet, and send a copy over each point-to-point link. One such example is Frame Relay.
* MANETインターフェイスは、ブロードキャストキューからパケットをピックアップし、パケットを再現し、各ポイントツーポイントリンクにコピーを送信できる場合、レイヤー2の擬似ブロードキャストをサポートします。そのような例の1つは、フレームリレーです。
o An API must be provided for Layer 3 to determine the Layer 2 broadcast capability. Based on the return of the API, OSPF classifies the MANET interfaces into the following three types: MANET broadcast, MANET pseudo-broadcast, and MANET non-broadcast.
o レイヤー3の放送機能を決定するには、レイヤー3にAPIを提供する必要があります。APIの返されたことに基づいて、OSPFはMANETインターフェイスを次の3つのタイプに分類します：MANETブロードキャスト、Manet Pseudo Broadcast、およびManet Non-Broadcast。
o Multicast SHOULD be used for OSPF packets. When the MANET interface supports Layer 2 broadcast or pseudo-broadcast, the multicast process is transparent to OSPF. Otherwise, OSPF MUST replicate multicast packets by itself.
o マルチキャストは、OSPFパケットに使用する必要があります。MANETインターフェイスがレイヤー2ブロードキャストまたは擬似ブロードキャストをサポートする場合、マルチキャストプロセスはOSPFに対して透明です。それ以外の場合、OSPFは単独でマルチキャストパケットを複製する必要があります。
A MANET node has at least one MANET interface. MANET nodes can communicate with each other through MANET interfaces. MANET nodes can communicate with non-MANET routers only through normal interfaces, such as Ethernet, ATM, etc.
MANETノードには、少なくとも1つのMANETインターフェイスがあります。MANETノードは、MANETインターフェイスを介して互いに通信できます。MANETノードは、イーサネット、ATMなどの通常のインターフェイスを介してのみ、非マネットルーターと通信できます。
For scalability reasons, it is not required to configure IPv6 global unicast addresses on MANET interfaces. Instead, a management loopback interface with an IPv6 global unicast address MAY be configured on each MANET node.
スケーラビリティの理由から、MANETインターフェイスでIPv6グローバルユニキャストアドレスを構成する必要はありません。代わりに、IPv6グローバルユニキャストアドレスを備えた管理ループバックインターフェイスを各MANETノードで構成できます。
The link state advertisements (LSAs) associated with a MANET interface SHOULD have the DC-bit set in the OSPFv3 Options Field and the DoNotAge bit set in the LS Age field as described in [OSPFv3]. Demand Circuits are an optional feature; hence, the DC-bit setting recommendation level is SHOULD.
MANETインターフェイスに関連付けられたLink State Advertisements（LSA）には、[OSPFV3]に記載されているように、OSPFV3オプションフィールドとLS Ageフィールドに設定されたDCビットが設定されている必要があります。需要回路はオプションの機能です。したがって、DCビット設定の推奨レベルは必要です。
LSA formats are specified in [OSPFv3].
LSA形式は[OSPFV3]で指定されています。
In order to display example LSAs, a network map is included below. Router names are prefixed with the letters RT, network names with the letter N, and router interface names with the letter I.
例のLSAを表示するために、ネットワークマップを以下に示します。ルーター名には、文字RT、文字nのネットワーク名、文字Iのルーターインターフェイス名が付いています。
o Four MANET nodes, RT1, RT2, RT3, and RT4, reside in area 2.
o 4つのMANETノード、RT1、RT2、RT3、およびRT4は、エリア2に存在します。
o RT1 has one MANET interface, I11. Through the interface, RT1 is full-adjacent to RT2, RT3, and RT4.
o RT1には1つのMANETインターフェイス、I11があります。インターフェイスを介して、RT1はRT2、RT3、およびRT4に完全に隣接しています。
o RT2 has two MANET interfaces, I21 and I22, and one Ethernet interface, I23. RT2 is full-adjacent to RT1 and RT4 through the interface I21, and full-adjacent to RT4 through the interface I22. Stub network N1 is attached with RT2 through the interface I23.
o RT2には、I21とI22の2つのMANETインターフェイスと、1つのイーサネットインターフェイスI23があります。RT2は、インターフェイスI21を介してRT1およびRT4にフルアジャセントされ、インターフェイスI22を介してRT4に完全に隣接しています。スタブネットワークN1は、インターフェイスI23を介してRT2に付着しています。
o RT3 has one MANET interface, I31, and is full-adjacent to RT1 through the interface.
o RT3には1つのMANETインターフェイスI31があり、インターフェイスを介してRT1に完全に隣接しています。
o RT4 has two MANET interfaces, I41 and I42. It is full-adjacent to RT2 through the interface I41, and full-adjacent to RT1 and RT2 through the interface I42.
o RT4には、I41とI42の2つのMANETインターフェイスがあります。インターフェイスi41を介してRT2に完全に隣接し、インターフェイスi42を介してRT1およびRT2に完全に調整されます。
o Moreover, each MANET node is configured with a management loopback interface.
o さらに、各MANETノードは、管理ループバックインターフェイスで構成されています。
+---+I11 I21+---+I23 |
|RT1|-+----------+-|RT2|------|N1
+---+ | | +---+ |
| | VI22
| | +
| | |
| | |
| | |
| | |
| | +
| | ^I41
+---+ | +---+
|RT3|-+ +-|RT4|
+---+I31 I42+---+
The assignment of IPv6 global unicast prefixes to network links is shown below. (Note: No IPv6 global unicast addresses are configured on the MANET interfaces).
ネットワークリンクへのIPv6グローバルユニキャストプレフィックスの割り当てを以下に示します。（注：IPv6グローバルユニキャストアドレスはMANETインターフェイスで構成されていません）。
-----------------------------------------------------------
RT1 LOOPBACK 2001:DB8:0001::/64
I11 n/a
RT2 LOOPBACK 2001:DB8:0002::/64
I21 n/a
I22 n/a
I23 2001:DB8:0012::/60
RT3 LOOPBACK 2001:DB8:0003::/64
I31 n/a
RT4 LOOPBACK 2001:DB8:0004::/64
I41 n/a
I42 n/a
The OSPF interface IDs and the link-local addresses for the router interfaces in the network are shown below. EUIxy represents the 64-bit interface identifier of the interface Ixy, in Modified EUI-64 format [IPV6ADD].
ネットワーク内のルーターインターフェイスのOSPFインターフェイスIDとリンクローカルアドレスを以下に示します。EUIXYは、変更されたEUI-64形式[IPv6ADD]で、インターフェイスIXYの64ビットインターフェイス識別子を表します。
Node Interface Interface ID Link-Local address
-----------------------------------------------------------
RT1 LOOPBACK 1 n/a
I11 2 fe80:0002::EUI11
RT2 LOOPBACK 1 n/a
I21 2 fe80:0002::EUI21
I22 3 fe80:0003::EUI22
I23 4 fe80:0004::EUI23
RT3 LOOPBACK 1 n/a
I31 2 fe80:0002::EUI31
RT4 LOOPBACK 1 n/a
I41 2 fe80:0002::EUI41
I42 3 fe80:0003::EUI42
As an example, consider the router-LSAs that node RT2 would originate. Two MANET interfaces, consisting of 3 point-to-point links, are presented.
例として、ノードRT2が発生するルーター-LSAを検討してください。3つのポイントツーポイントリンクで構成される2つのMANETインターフェイスが表示されます。
RT2's router-LSA
RT2のRouter-LSA
LS age = DoNotAge+0 ;newly originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.0.2.2 ;RT2's Router ID
bit E = 0 ;not an AS boundary router
bit B = 0 ;not an area border router
Options = (V6-bit|E-bit|R-bit)
Type = 1 ;p2p link to RT1 over I21
Metric = 10 ;cost to RT1
Interface ID = 2 ;Interface ID of I21
Neighbor Interface ID = 2 ;Interface ID of I11
Neighbor Router ID = 192.0.2.1 ;RT1's Router ID
Type = 1 ;p2p link to RT4 over I21
Metric = 25 ;cost to RT4
Interface ID = 2 ;Interface ID of I21
Neighbor Interface ID = 3 ;Interface ID of I42
Neighbor Router ID = 192.0.2.4 ;RT4's Router ID
Type = 1 ;p2p link to RT4 over I22
Metric = 15 ;cost to RT4
Interface ID = 3 ;Interface ID of I22
Neighbor Interface ID = 2 ;Interface ID of I41
Neighbor Router ID = 192.0.2.4 ;RT4's Router ID
A MANET node originates a separate link-LSA for each attached interface. As an example, consider the link-LSA that RT3 will build for its MANET interface I31.
MANETノードは、添付された各インターフェイスの個別のリンクLSAを発信します。例として、RT3がMANETインターフェイスI31用に構築するLink-LSAを検討してください。
RT3's link-LSA for MANET interface I31
MANETインターフェイスI31用のRT3のLink-LSA
LS age = DoNotAge+0 ;newly originated
LS type = 0x0008 ;link-LSA
Link State ID = 2 ;Interface ID of I31
Advertising Router = 192.0.2.3 ;RT3's Router ID
Rtr Pri = 1 ;default priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0002::EUI31
# prefixes = 0 ;no global unicast address
A MANET node originates an intra-area-prefix-LSA to advertise its own prefixes and those of its attached stub links. As an example, consider the intra-area-prefix-LSA that RT2 will build.
MANETノードは、独自の接頭辞と添付のスタブリンクのプレフィックスを宣伝するために、エリア内 - エリアプレフィックスLSAを産みます。一例として、RT2が構築するエリア内-Prefix-LSAを検討してください。
RT2's intra-area-prefix-LSA for its own prefixes
独自のプレフィックスについては、RT2のエリア内-Prefix-LSA
LS age = DoNotAge+0 ;newly originated LS type = 0x2009 ;intra-area-prefix-LSA Link State ID = 177 ;or something else Advertising Router = 192.0.2.2 ;RT2's Router ID # prefixes = 2 Referenced LS type = 0x2001 ;router-LSA reference Referenced Link State ID = 0 ;always 0 for router-LSA ;reference Referenced Advertising Router = 192.0.2.2 ;RT2's Router ID PrefixLength = 64 ;prefix on RT2's LOOPBACK PrefixOptions = 0 Metric = 0 ;cost of RT2's LOOPBACK Address Prefix = 2001:DB8:0002:: PrefixLength = 60 ;prefix on I23 PrefixOptions = 0 Metric = 10 ;cost of I23 Address Prefix = 2001:DB8:0012::
ls age = donotage 0;新しく起源のLSタイプ= 0x2009; Intra-Area-Prefix-LSA Link状態ID = 177;-LSA参照リンクリンク状態ID = 0;常に0のRouter-LSAの場合は0;参照参照広告router = 192.0.2.2; RT2のルーターIDプレフィックスLength = 64; RT2のループバックプレフィックスのプレフィックス= 0メトリック= 0; RT2のループバックアドレスのコストプレフィックスのコスト= 2001：db8：0002 :: prefixlength = 60; i23のプレフィックス= 0メトリック= 10; i23のコストアドレスプレフィックス= 2001：db8：0012 ::
Note: MANET nodes may originate intra-area-prefix-LSAs for attached transit (broadcast/NBMA) networks. This is normal behavior (defined in [OSPFv3]), which is irrelevant to MANET interfaces. Please consult [OSPFv3] for details.
注：MANETノードは、接続されたトランジット（ブロードキャスト/NBMA）ネットワークのエリア内型LSAを発生する場合があります。これは通常の動作（[OSPFV3]で定義されています）であり、MANETインターフェイスとは無関係です。詳細については、[OSPFV3]を参照してください。
In MANETs, reducing the size of periodically transmitted packets can be very important in decreasing the total amount of overhead associated with routing. Towards this end, removing the list of neighbors from Hello packets, unless that information changes, can reduce routing protocol overhead. While the reduction for each Hello packet is small, over time it will be significant.
マネットでは、定期的に送信されたパケットのサイズを縮小することは、ルーティングに関連するオーバーヘッドの総量を減らす上で非常に重要です。この目的に向かって、その情報が変更されない限り、ハローパケットから隣人のリストを削除すると、ルーティングプロトコルのオーバーヘッドを減らすことができます。各ハローパケットの削減は小さいですが、時間の経過とともに重要になります。
A new option bit is defined in this document to facilitate the operation of incremental Hello packets. A new State Check Sequence TLV (SCS TLV) and Neighbor Drop TLV are also defined, transmitted using LLS [LLS].
このドキュメントでは、新しいオプションビットが定義されており、増分ハローパケットの操作を容易にします。新しい状態チェックシーケンスTLV（SCS TLV）および隣接ドロップTLVも定義され、LLS [LLS]を使用して送信されます。
A new I-bit is defined in the LLS Type 1 Extended Options and Flags field. The bit is defined for Hello packets and indicates that only incremental information is present. See Section 5 for placement of the I-bit.
新しいIビットは、LLSタイプ1拡張オプションとフラグフィールドで定義されています。ビットはハローパケット用に定義されており、増分情報のみが存在することを示します。Iビットの配置については、セクション5を参照してください。
A new TLV is defined that indicates the current state, which is represented by a State Check Sequence (SCS) number of the transmitting router.
新しいTLVは、送信ルーターの状態チェックシーケンス（SCS）数で表される電流状態を示す定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCS Number |R|FS|N | Reserved |
+-----------------------------------------------------------------+
o Type: 6
o タイプ：6
o Length: Set to 4.
o 長さ：4に設定します。
o SCS Number: A circular two-octet unsigned integer indicating the current state of the transmitting device. Note that when the incremental Hello mechanism is invoked (or re-started), an initial SCS value of '1' SHOULD be used for the first incremental Hello packet. This sequence number is referred to as InitialSCS. Note that InitialSCS also implies a full state.
o SCS番号：送信デバイスの電流状態を示す円形の2オクテットの符号なし整数。増分ハローメカニズムが呼び出される（または再起動）場合、最初の増分ハローパケットには「1」の初期SCS値を使用する必要があることに注意してください。このシーケンス番号は、InitialScsと呼ばれます。InitialScsは完全な状態も意味することに注意してください。
o R: Request bit. If set, this is a request for current state. The list of routers that should respond to this request is indicated in the Request From TLV (RF TLV) (defined below). If the RF TLV is not present, it is assumed that the request is meant for all nodes.
o R：リクエストビット。設定されている場合、これは現在の状態のリクエストです。このリクエストに応答するルーターのリストは、TLV（RF TLV）からの要求に示されています（以下に定義）。RF TLVが存在しない場合、リクエストはすべてのノードに対して意図されていると想定されています。
o FS: Full State bit. If set, the Hello packet contains full state as far as the neighbor(s) in the Full State For TLV (FSF TLV) (defined below) are concerned. If the FSF TLV is not present, the Hello packet contains full state for all neighbors.
o FS：完全な状態ビット。設定されている場合、Helloパケットには、TLV（FSF TLV）の完全な状態の隣接（以下に定義）までの完全な状態が含まれています。FSF TLVが存在しない場合、Hello Packetにはすべての隣人の完全な状態が含まれています。
o N: Incomplete bit. If NOT set, the complete state associated with the SCS number is included in the Hello packet. If set, this indicates that the appended TLVs are being sent 'persistently', and that there is more state associated with the SCS number that was sent originally, but is not included in this Hello packet. This bit allows any desired TLVs to be sent 'persistently' for a number of Hellos with the same SCS number without requiring all of the TLVs associated with that SCS number to be transmitted. The first time an SCS number is sent, the entire state associated with that SCS number is transmitted, and the N-bit MUST NOT be set.
o N：不完全なビット。設定されていない場合、SCS番号に関連付けられた完全な状態がHello Packetに含まれています。設定されている場合、これは、追加されたTLVが「永続的に」送信されていること、および元々送信されたSCS数に関連する状態が増えているが、このハローパケットには含まれていないことを示します。このビットにより、目的のTLVは、そのSCS数に関連付けられたすべてのTLVを送信することなく、同じSCS数を持つ多くのHellosに対して「永続的に」送信できます。SCS数が最初に送信されたとき、そのSCS数に関連する状態全体が送信され、N-BITを設定してはなりません。
o Reserved: Set to 0. Reserved for future use.
o 予約済み：0に設定します。将来の使用のために予約されています。
A Hello with the SCS TLV appended and with the R-bit set will be referred to as a Hello request.
SCS TLVが追加され、RビットセットがHelloリクエストと呼ばれます。
A new TLV is defined in this document that indicates neighbor(s) that have been removed from the list of known neighbors.
このドキュメントでは、新しいTLVが定義されており、既知の隣人のリストから削除された隣人を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dropped Neighbor(s) |
+---------------------------------------------------------------+
| ....
+--------------------
o Type: 7 o Length: Set to the number of dropped neighbors included in the TLV multiplied by 4.
o タイプ：7 Oの長さ：TLVに含まれるドロップされた隣人の数に4を掛けた数に設定します。
o Dropped Neighbor(s) - Router ID of the neighbor being dropped.
o ドロップした隣人 - 隣人のルーターIDがドロップされています。
A new TLV is defined in this document that indicates neighbor(s) from which the latest Hello state is being requested.
このドキュメントでは、新しいTLVが定義されており、最新のHello Stateが要求されている隣人を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request From Neighbor(s) |
+---------------------------------------------------------------+
| ....
+--------------------
o Type: 8
o タイプ：8
o Length: Set to the number of neighbors included in the TLV multiplied by 4.
o 長さ：TLVに含まれる隣人の数に4を掛けた数に設定します。
o Request From Neighbor(s) - Router ID of the neighbor(s) from which Hello state is being requested.
o 近隣からのリクエスト - ハローステートが要求されている隣人のルーターID。
A new TLV is defined in this document that indicates neighbor(s) to which the transmitting node is responding with full state.
このドキュメントでは、新しいTLVが定義されており、送信ノードが完全状態で応答している隣接を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Full State For Neighbor(s) |
+---------------------------------------------------------------+
| ....
+--------------------
o Type: 9
o タイプ：9
o Length: Set to the number of neighbors included in the TLV multiplied by 4.
o 長さ：TLVに含まれる隣人の数に4を掛けた数に設定します。
o Full State For Neighbor(s) - Router ID of the neighbor(s) should process this packet.
o 近隣の完全状態 - 隣人のルーターIDはこのパケットを処理する必要があります。
This section describes building neighbor adjacencies and the failure of such adjacencies using the incremental Hello signaling.
このセクションでは、近隣の隣接を構築し、インクリメンタルなハローシグナル伝達を使用したそのような隣接の障害について説明します。
Hello packets are sent periodically in accordance with [OSPF] and [OSPFv3]. An OSPF implementation that supports sending only partial neighbor information in Hello packets SHOULD always set the I-bit in its transmitted Hello packets, except as described elsewhere in this document. Hello packets MAY be suppressed from being transmitted every HelloInterval if other packet transmissions are sent by the router during that time.
こんにちはパケットは[OSPF]および[OSPFV3]に従って定期的に送信されます。Helloパケットに部分的な隣接情報のみを送信することをサポートするOSPF実装は、このドキュメントの他の場所で説明されている場合を除き、送信されたハローパケットにiビットを常に設定する必要があります。Hello Packetは、その間にルーターによって他のパケット送信が送信される場合、すべてのHelloIntervalに送信されることから抑制される場合があります。
On receiving a Hello packet from a new neighbor (in this context, a new neighbor is a neighbor in less than Init state as defined in Section 10.1 [OSPF]), if the Hello has the I-bit set, a router will:
新しい隣人からハローパケットを受信すると（この文脈では、新しい隣人はセクション10.1 [OSPF]で定義されているINIT状態未満の隣人です）、HelloにIビットセットがある場合、ルーターは次のとおりです。
o Place the new neighbor in the neighbor list described in [OSPFv3], Appendix A.3.2.
o [OSPFV3]、付録A.3.2に記載されている近隣リストに新しい隣人を配置します。
o Increment the router's SCS number that it will use in its next Hello (indicated in the SCS TLV).
o 次のhelloで使用するルーターのSCS番号を増やします（SCS TLVに示されています）。
o Remove the neighbor from the neighbor list described in [OSPFv3], Appendix A.3.2, when the neighbor has reached the Exchange state (as described in [OSPF], Section 10.1).
o [OSPFV3]、付録A.3.2に記載されている近隣リストから隣人を削除します。
o Remove the neighbor from the neighbor list described in [OSPFv3], Appendix A.3.2, if the neighbor is not a DR or backup designated router (BDR) on an OSPF broadcast link, and if the neighbor is advertised as connected in the network-LSA advertised by the DR.
o [OSPFV3]、付録A.3.2に記載されている近隣リストから隣人を削除します。隣人がOSPFブロードキャストリンクのDRまたはバックアップ指定ルーター（BDR）ではない場合、ネットワークで接続されていると隣人が宣伝されている場合 - 博士によって宣伝されたLSA。
On discovering an adjacency failure (going to state less than Exchange), a router using I-bit signaling SHOULD:
隣接する障害を発見すると（交換よりも少ない状態になります）、iビットシグナリングを使用したルーターは次のようにする必要があります。
o Remove the adjacent router from local tables, and take the appropriate actions for a failed adjacency described in [OSPF] and [OSPFv3].
o 隣接するルーターをローカルテーブルから削除し、[OSPF]および[OSPFV3]に記載されている隣接の失敗に対して適切なアクションを実行します。
o Add the formerly adjacent router to a Neighbor Drop TLV.
o 以前の隣接したルーターを隣のドロップTLVに追加します。
o Increment the router's SCS number that it will transmit in its next Hello.
o 次のHelloで送信されるルーターのSCS番号を増やします。
o Transmit Hellos with this Neighbor Drop TLV. It may be desirable to send the Neighbor Drop TLV in three consecutive Hellos to increase the probability of reception. In this case, 'persistent' Hello packets would be sent with the same SCS number, the Neighbor Drop TLV, and the N-bit set. Thus, the receiver knows that the Neighbor Drop TLV is being sent persistently, and there is more state associated with the SCS in case it must request missing state presumably transmitted in a previous Hello.
o この隣のドロップTLVでHellosを送信します。隣人のドロップTLVを3つの連続したHellosで送信して、受容の確率を高めることが望ましい場合があります。この場合、「永続的な」ハローパケットは、同じSCS番号、Neighbor Drop TLV、およびNビットセットで送信されます。したがって、受信者は、隣のドロップTLVが永続的に送信されていることを知っており、以前のHelloでおそらく送信された状態が不足している場合に備えて、SCSに関連する状態がより多くあります。
When a device is first attached to a network (whether by being brought within range of another device, powering the device on, enabling the device's radio interface, etc.), it will need to obtain complete neighbor state from each of its neighbors before it can utilize the incremental Hello mechanism. Thus, upon initialization, a device MAY send a multicast Hello request (and omit the Request From TLV). Neighbors will receive the request and respond with a Hello with their complete neighbor state.
デバイスが最初にネットワークに接続されている場合（別のデバイスの範囲内に持ち込まれ、デバイスの電源を入れ、デバイスのラジオインターフェイスを有効にするなど）、それぞれの隣接する前にそれぞれの近隣状態を取得する必要がありますインクリメンタルなハローメカニズムを利用できます。したがって、初期化時に、デバイスはマルチキャストハローリクエストを送信する場合があります（およびTLVからのリクエストを省略します）。隣人はリクエストを受け取り、完全な隣人の状態でこんにちはと応答します。
If a device is in INIT state with a neighbor and receives a Hello from the neighbor without its router ID listed in the neighbor list, the device SHOULD request the current state from the neighbor. Note that this is to avoid a "race" condition, since the received Hello can either mean that the device is NOT SEEN by the neighbor, or that the device is adjacent and not listed in the incremental list. Thus, by receiving a Hello request, the neighbor will respond with its neighbor state for the neighbor.
デバイスが隣人とのinit状態にあり、近隣リストにルーターIDがリストされていない隣人からhelloを受信する場合、デバイスは隣人から現在の状態を要求する必要があります。これは、「レース」の状態を回避するためであることに注意してください。挨拶を受けたハローは、デバイスが隣接するものではないことを意味するか、デバイスが隣接しており、増分リストにリストされていないことを意味する可能性があるためです。したがって、ハローリクエストを受け取ることにより、隣人は隣人のためにその隣人と対応します。
The first Hello packet with a particular SCS number MUST contain the full state associated with that SCS number, i.e., all state changes since the last SCS number. The N-bit MUST NOT be set in the State Check Sequence TLV.
特定のSCS番号を持つ最初のハローパケットには、そのSCS数に関連付けられた完全な状態、つまり最後のSCS数以降のすべての状態の変更を含める必要があります。N-BITは、状態チェックシーケンスTLVに設定してはなりません。
Incremental Hello packets can be sent persistently (sent in k successive Hello packets), with flexibility in the actual amount of information being sent. The three options include:
インクリメンタルハローパケットは、実際に送信される情報の量に柔軟性を備えて、永続的に送信できます（k連続したハローパケットで送信）。3つのオプションには次のものがあります。
o The entire incremental Hello packet is sent persistently. This is accomplished by simply sending the entire state associated with a SCS number for k successive Hellos. Since the SCS number remains the same, the N-bit is not set in these incremental Hello packets.
o インクリメンタルなハローパケット全体が永続的に送信されます。これは、K連続したHellosのSCS数に関連する状態全体を単に送信するだけで達成されます。SCS数は同じままであるため、n-bitはこれらの増分ハローパケットに設定されていません。
o Partial information for a particular SCS number is sent persistently. After the first Hello packet with a particular SCS number is sent, only the TLVs that are desired to be sent persistently are sent in subsequent Hellos with the same SCS number and the N-bit set.
o 特定のSCS番号の部分情報は永続的に送信されます。特定のSCS番号を持つ最初のハローパケットが送信された後、持続的に送信することを望むTLVのみが、同じSCS番号とNビットセットの後続のHellosで送信されます。
o No information is sent persistently. This is simply the default behavior where an incremental Hello packet with a particular SCS number is only sent once.
o 情報は永続的に送信されません。これは、特定のSCS番号を持つ増分ハローパケットが1回しか送信されないデフォルトの動作です。
Each OSPF device supporting incremental Hello signaling, as described in this document, MUST keep the last known SCS number from each neighbor it has received Hellos from as long as the neighbor adjacency structure is maintained.
このドキュメントに記載されているように、インクリメンタルなハローシグナル伝達をサポートする各OSPFデバイスは、隣接する隣接体が隣接する隣接構造が維持されている限り、各近隣から最後の既知のSCS数を保持する必要があります。
If a device receives a Hello from an adjacent neighbor with an SCS number less than the last known SCS number from that neighbor, it MUST first check if the SCS number is a wrap around. "Wrap around" is a condition when the last known SCS number is MAX_SCS (65535) and the new SCS number is 1. If it is not a wrap around, then the device MUST send a Hello request to the neighbor.
デバイスが、その近隣からの最後の既知のSCS数よりも少ないSCS数を持つ隣接する隣人からHelloを受信した場合、最初にSCS数がラップアラウンドであるかどうかを確認する必要があります。「ラップアラウンド」は、最後の既知のSCS数がMAX_SCS（65535）であり、新しいSCS数が1である場合の条件です。ラップアラウンドではない場合、デバイスは近隣にハローリクエストを送信する必要があります。
If it is a wrap around, or if a device receives a Hello from an adjacent neighbor with an SCS number one greater than the last known SCS number from that neighbor, it MUST:
それがラップアラウンドである場合、またはデバイスがその隣人からの最後の既知のSCS番号よりも大きいSCSナンバーワンを持つ隣接する隣人からこんにちはを受け取った場合、それは次のとおりです。
o Examine the neighbor list described in [OSPFv3], Appendix A.3.2. If any neighbors are contained in this list, increment the SCS number contained in the adjacent neighbor's data structure.
o [OSPFV3]、付録A.3.2に記載されている隣接リストを調べます。このリストに近隣が含まれている場合は、隣接する隣人のデータ構造に含まれるSCS数を増やします。
o Examine the Neighbor Drop TLV as described in Section 3.2.6.2. If this list contains a neighbor other than the local router, increment the SCS number contained in the adjacent neighbor's data structure.
o セクション3.2.6.2で説明されているように、隣のドロップTLVを調べます。このリストにローカルルーター以外の近隣が含まれている場合、隣接する隣のデータ構造に含まれるSCS数を増やします。
o Examine the Neighbor Drop TLV as described in Section 3.2.6.2. If the local router identifier is contained in this list, destroy the transmitting adjacent neighbor's data structures.
o セクション3.2.6.2で説明されているように、隣のドロップTLVを調べます。このリストにローカルルーター識別子が含まれている場合は、隣接する隣接するデータ構造を送信します。
o Examine any other TLVs incrementally signaled, as described in documents referring to this RFC. If there are other state changes indicated, increment the SCS number contained in the adjacent neighbor's data structure.
o このRFCを参照するドキュメントで説明されているように、他のTLVを段階的にシグナルに調べます。他の状態の変更が示されている場合は、隣接する隣人のデータ構造に含まれるSCS数を増やします。
o If no state change information is contained in the received Hello, send a request for current state (by setting the 'R'-bit) in the next Hello.
o 受信したHelloに状態変更情報が含まれていない場合は、次のHelloで（r」ビットを設定することで、現在の状態のリクエストを送信します。
If a device receives a Hello from an adjacent neighbor with an SCS number greater than the last known SCS number + 1 from that neighbor, it MUST send a Hello request to the neighbor, since it may be missing some neighbor state.
デバイスが、その隣人からの最後の既知のSCS番号1より大きいSCS番号を持つ隣接する隣人からHelloを受信した場合、隣人の状態が欠落している可能性があるため、隣人にHelloリクエストを送信する必要があります。
If a device receives a Hello with the SCS TLV included and the N-bit set in this TLV, it MUST verify that it has already received the SCS number with the N-bit NOT set from the neighbor. If the device determines that this is the first receipt of the SCS number from this neighbor, then it MUST send a Hello request to the neighbor, since it missed the initial Hello packet with the SCS number and thus is missing state.
デバイスがこのTLVに含まれているSCS TLVとnビットセットでHelloを受信した場合、隣人からセットされていないnビットを使用してSCS番号を既に受信していることを確認する必要があります。これがこの隣人からのSCS番号の最初の領収書であるとデバイスが判断した場合、SCS番号の最初のハローパケットを逃したため、隣接してhelloリクエストを送信する必要があります。
If a device receives a Hello with the SCS TLV included and the R-bit set, it looks for the RF TLV. If its router ID is listed in the RF TLV or the TLV is not found, it includes its full state in the next Hello. This MUST include:
デバイスがSCS TLVを含むHelloを受信し、Rビットセットを受信すると、RF TLVを探します。ルーターIDがRF TLVにリストされている場合、またはTLVが見つからない場合、次のHelloに完全な状態が含まれます。これには以下が含まれます。
o The neighbor ID of the requesting neighbor(s) in the list of neighbors described in [OSPFv3], Appendix A.3.2.
o [OSPFV3]、付録A.3.2に記載されている隣人のリストにある要求する隣人の隣人ID。
o An SCS TLV with the transmitter's current SCS number and the FS-bit set. Note that the transmitter's SCS number is NOT incremented.
o 送信機の現在のSCS番号とFSビットセットを備えたSCS TLV。送信機のSCS数は増加していないことに注意してください。
o Any other TLVs, defined in other documents referencing this RFC, indicating the current state of the local system.
o このRFCを参照する他のドキュメントで定義されている他のTLVは、ローカルシステムの現在の状態を示しています。
o The neighbor ID of all the neighbors who have requested current state, in the FSF TLV.
o FSF TLVで、現在の状態を要求したすべての隣人の隣人ID。
If the full state is being sent to a large number of existing neighbors, an implementation could choose to instead generate a full state for all neighbors and omit the FSF TLV.
完全な状態が多数の既存の隣人に送られている場合、実装は代わりにすべての隣人に完全な状態を生成し、FSF TLVを省略することを選択できます。
When a device receives a Hello with the SCS TLV included and the FS-bit set, the Hello packet contains the neighbor's full state for the device. The packet SHOULD be processed as follows: o If the received SCS number is equal to the last known SCS number, the packet SHOULD be ignored, since the device already has the latest state information.
デバイスがSCS TLVを含むHelloを受信し、FSビットセットを受信すると、Hello Packetにはデバイス用の近隣の完全状態が含まれています。パケットは次のように処理する必要があります。O受信したSCS番号が最後の既知のSCS番号に等しい場合、デバイスには最新の状態情報が既にあるため、パケットは無視する必要があります。
o If the received SCS number is different than the last known SCS number, this Hello has new information and MUST be parsed.
o 受信したSCS数が最後の既知のSCS数とは異なる場合、このHelloには新しい情報があり、解析する必要があります。
o If it is listed in the FSF TLV, or if the FSF TLV is not present, the device MUST save the SCS number, process the Hello as described in Section 3.2.8, and process any other appended TLVs.
o FSF TLVにリストされている場合、またはFSF TLVが存在しない場合、デバイスはSCS番号を保存し、セクション3.2.8で説明されているHelloを処理し、他のAppled TLVを処理する必要があります。
On receiving a Hello packet from a new neighbor without the I-bit set, the local router will continue to place that router's identifier in transmitted Hellos on this link as described in [OSPFv3], Appendix A.3.2.
Iビットセットのない新しい隣人からハローパケットを受信すると、ローカルルーターは、[OSPFV3]、付録A.3.2に記載されているように、このリンクに送信されたHellosにそのルーターの識別子を配置し続けます。
OSPF graceful restart, as described in [OSPFREST] and [OSPFGR], relies on the lack of neighbors in the list of neighbors described in [OSPFv3], Appendix A.3.2, to determine that an adjacent router has restarted, and other signaling to determine that the adjacency should not be torn down. If all Hello packets transmitted by a given router have an empty Hello list, reliance on an empty Hello packet to signal a restart (or to reliably tear down an OSPF adjacency) is no longer possible. Hence, this signaling must be slightly altered. When a router would like to tear down all adjacencies, or signal that it has restarted:
[OSPFREST]と[OSPFGR]で説明されているように、OSPFの優雅な再起動は、[OSPFV3]、付録A.3.2に記載されている隣人のリストに近隣の欠如に依存しています。隣接を取り壊すべきではないと判断します。特定のルーターによって送信されたすべてのハローパケットに空のハローリストがある場合、空のハローパケットに依存して再起動を信号（またはOSPF隣接を確実に取り壊す）はもはや不可能です。したがって、このシグナルはわずかに変更する必要があります。ルーターがすべての隣接を取り壊したい場合、または再起動したことを知らせたい場合：
o On initially restarting, during the first RouterDeadInterval after restart, the router will transmit Hello packets with an empty neighbor list and the I-bit cleared. Any normal restart or other signaling may be included in these initial Hello packets.
o 最初に再起動すると、再起動後の最初のRouterDeadIntervalで、ルーターは空の隣のリストでハローパケットを送信し、iビットがクリアされます。通常の再起動またはその他のシグナリングは、これらの最初のハローパケットに含まれる場合があります。
o As adjacencies are learned, these newly learned adjacent routers are included in the multicast Hellos transmitted on the link.
o 隣接が学習されると、これらの新しく学習した隣接するルーターは、リンクに送信されるマルチキャストHellosに含まれています。
o After one RouterDeadInterval has passed, the incremental Hello mechanism is invoked. An incremental Hello packet with full state is sent with the I-bit set, the SCS TLV included with the FS-bit set, and the InitialSCS value (e.g., SCS of '1'). Subsequent Hello packets will include only incremental state.
o 1つのRouterDeadIntervalが通過した後、増分ハローメカニズムが呼び出されます。完全な状態を備えたインクリメンタルハローパケットは、Iビットセット、FSビットセットに含まれるSCS TLV、およびinitialSCS値（たとえば、 '1'のSCS）で送信されます。後続のハローパケットには、増分状態のみが含まれます。
Routers that are neighboring with a restarting router MUST continue sending their Hello packets with the I-bit set.
再起動ルーターが隣接しているルーターは、Iビットセットでハローパケットを送信し続ける必要があります。
A component that may influence the scalability and convergence characteristics of OSPF ([OSPF], [OSPFv3]) in a MANET environment is how much information needs to be flooded. The ideal solution is that a router will receive a particular routing update only once. However, there must be a trade-off between protocol complexity and ensuring that every speaker in the network receives all of the information. Note that a speaker refers to any node in the network that is running the routing protocol and transmitting routing updates and Hello messages.
MANET環境におけるOSPF（[OSPF]、[OSPFV3]）のスケーラビリティと収束特性に影響を与える可能性のあるコンポーネントは、どれだけの情報を浸水させる必要があるかです。理想的な解決策は、ルーターが特定のルーティングアップデートを一度だけ受け取ることです。ただし、プロトコルの複雑さと、ネットワーク内のすべてのスピーカーがすべての情報を受信することを保証する間にトレードオフが必要です。スピーカーは、ルーティングプロトコルを実行し、ルーティングの更新とハローメッセージを送信しているネットワーク内の任意のノードを参照することに注意してください。
Controlling the amount of information on the link has increased importance in a MANET environment due to the potential transmission costs and resource availability in general.
リンク上の情報の量を制御することは、潜在的な送信コストと一般的なリソースの可用性により、MANET環境で重要性を高めました。
In some environments, a group of speakers that share the same logical segment may not be directly visible to each other; some of the possible causes are the following: low signal strength, long distance separation, environmental disruptions, partial VC (virtual circuit) meshing, etc. In these networks, a logical segment refers to the local flooding domain dynamically determined by transmission radius. In these situations, some speakers (the ones not able to directly reach the sender) may never be able to synchronize their databases. To solve the synchronization issues encountered in these environments, a mechanism is needed through which all the nodes on the same logical segment can receive the routing information, regardless of the state of their adjacency to the source.
一部の環境では、同じ論理セグメントを共有するスピーカーのグループが互いに直接表示されない場合があります。考えられる原因のいくつかは次のとおりです。低信号強度、長距離分離、環境破壊、部分VC（仮想回路）メッシュなど。これらのネットワークでは、論理セグメントは、伝送半径によって動的に決定されるローカルフラッディングドメインを指します。これらの状況では、一部のスピーカー（送信者に直接到達できないスピーカー）は、データベースを同期することができない場合があります。これらの環境で発生する同期の問題を解決するには、ソースへの隣接の状態に関係なく、同じ論理セグメント上のすべてのノードがルーティング情報を受信できるメカニズムが必要です。
The optimized flooding operation relies on the ability of a speaker to advertise all of its locally connected neighbors. In OSPF, this ability is realized through the use of link state advertisements (LSA)s ([OSPF], [OSPFv3]).
最適化された洪水操作は、スピーカーがローカルに接続されたすべての隣人を宣伝する能力に依存しています。OSPFでは、この能力は、Link State Advertisements（LSA）S（[OSPF]、[OSPFV3]）の使用によって実現されます。
A speaker receives router-LSAs from its adjacent neighbors. A speaker's router-LSA conveys the list of the adjacent speakers of the originator ("neighbor list"). The local speaker can compare the neighbor list reported by each speaker to its own neighbor list. If the local neighbor list contains adjacent speakers that the originator cannot reach directly (i.e., those speakers that are not in the originator's neighbor list), then these speakers are locally known as non-overlapping neighbors for the originator.
スピーカーは、隣接する隣人からルーター-LSAを受け取ります。スピーカーのルーター-LSAは、オリジネーターの隣接するスピーカーのリスト（「隣接リスト」）を伝えます。ローカルスピーカーは、各スピーカーから報告された近隣リストを独自の隣人リストと比較できます。ローカルネイバーリストに、オリジネーターが直接到達できない隣接するスピーカー（つまり、オリジネーターの隣人リストにないスピーカー）が含まれている場合、これらのスピーカーは、オリジネーターの重複しない隣人としてローカルに知られています。
The local speaker should relay any routing information to non-overlapping neighbors of the sender based on the algorithm outlined in Section 3.3.8. Because more than one such speaker may exist, the mechanism is called "overlapping relays". The algorithm, however, does select the set of overlapping relays that should transmit first. This set is known as the active set of overlapping relays for a speaker.
ローカルスピーカーは、セクション3.3.8で概説されているアルゴリズムに基づいて、あらゆるルーティング情報を送信者の非重複した隣人に中継する必要があります。複数のスピーカーが存在する可能性があるため、メカニズムは「オーバーラップリレー」と呼ばれます。ただし、アルゴリズムは、最初に送信するようなオーバーラップリレーのセットを選択します。このセットは、スピーカーのオーバーラップリレーのアクティブなセットとして知られています。
The first step in the process is for each speaker to build and propagate their neighbor lists in router-LSA packets. Every speaker is then in a position to determine their 2-hop neighborhood, i.e., those nodes that are neighbors of the speaker's 1-hop neighbors.
プロセスの最初のステップは、各スピーカーがRouter-LSAパケットに近隣リストを構築および伝播することです。すべてのスピーカーは、2ホップの近所、つまりスピーカーの1ホップの隣人の隣人であるノードを決定する立場にあります。
A bidirectional neighbor is considered an overlapping relay for a speaker if it can reach a node in the 2-hop neighborhood of the speaker, i.e., if it has 1-hop neighbors (excluding the speaker itself).
双方向の隣人は、スピーカーの2ホップ近隣のノードに到達できる場合、つまり1ホップの隣人（スピーカー自体を除く）がある場合、スピーカーの重複リレーと見なされます。
The set of Active Overlapping Relays for a speaker is the minimum set of direct neighbors such that every node in the 2-hop neighborhood of the speaker is a neighbor of at least one overlapping relay in the active set.
スピーカーのアクティブオーバーラップリレーのセットは、直接隣接の最小セットであり、スピーカーの2ホップ近傍のすべてのノードがアクティブセットの少なくとも1つのオーバーラップリレーの隣接です。
Each speaker SHOULD select a set of Active Overlapping Relays based on a selection algorithm (one such algorithm is suggested in Section 3.3.4 and is based on the multipoint relay (MPR) selection algorithm described in [OLSR]). The behavior of the overlapping relays MUST follow that specified in Section 3.3.8.
各スピーカーは、選択アルゴリズムに基づいてアクティブオーバーラップリレーのセットを選択する必要があります（そのようなアルゴリズムの1つはセクション3.3.4で提案され、[OLSR]で説明されているマルチポイントリレー（MPR）選択アルゴリズムに基づいています）。重複するリレーの動作は、セクション3.3.8で指定されているものに従う必要があります。
Note that a speaker MUST NOT choose a neighbor to serve as an Active Overlapping Relay if that neighbor set the N-bit in its Active Overlapping Relay TLV as defined in Section 3.3.6, unless the neighbor is the only neighbor to reach a 2-hop neighbor.
スピーカーは、隣人がセクション3.3.6で定義されているように、その隣接が2.3.6で定義されているように、アクティブなオーバーラップリレーTLVにn-bitを設定した場合、アクティブな重複リレーとして機能する隣人を選択してはならないことに注意してください。隣人をホップします。
Election of Active Overlapping Relays is done across interfaces, and thus, it is node-based and not link-based.
アクティブな重複リレーの選挙はインターフェイス全体で行われるため、ノードベースであり、リンクベースではありません。
The following heuristic and terminology for Active Overlapping Relay selection is largely taken from [OLSR]:
アクティブな重複リレー選択のための次のヒューリスティックおよび用語は、[OLSR]から主に取られています。
o FULL: Neighbor state FULL as defined in [OSPF] and [OSPFv3]. Note that all neighbor references in this document are assumed to be FULL neighbors.
o 完全：[OSPF]および[OSPFV3]で定義されている隣接状態。このドキュメントのすべての隣人の参照は、完全な隣人であると想定されていることに注意してください。
o N: N is the set of FULL neighbors of the node.
o n：nは、ノードの完全な近隣のセットです。
o 2-hop FULL neighbors (N2): The list of 2-hop neighbors of the node that are FULL and that can be reached from direct neighbors, excluding any directly connected neighbors.
o 2ホップフルネイバー（N2）：直接接続された隣人を除く、直接接続された隣人から到達できるノードの2ホップ隣人のリスト。
o Active Set: A (sub)set of the neighbors selected, such that through these selected nodes, all 2-hop FULL neighbors are reachable.
o アクティブセット：選択された隣人の（サブ）セット。これらの選択されたノードを介して、すべての2ホップフルネイバーが到達可能になります。
o D(y): The degree of a 1-hop neighbor node y (where y is a member of N) is defined as the number of FULL neighbors of node y, EXCLUDING all the members of N and EXCLUDING the node performing the computation.
o D（Y）：1ホップ隣接ノードY（yはnのメンバー）の程度は、nのすべてのメンバーを除外し、計算を実行するノードを除外し、ノードyの完全な隣接の数として定義されます。
A possible algorithm for discovering overlapping relays is the following:
重複するリレーを発見するための可能なアルゴリズムは、次のとおりです。
1. Start with an active set made of all members of N that have set the A-bit in their Active Overlapping Relay TLV (AOR TLV) as defined in Section 3.3.6.
1. セクション3.3.6で定義されているように、アクティブオーバーラップリレーTLV（AOR TLV）にAビットを設定したNのすべてのメンバーで作られたアクティブセットから始めます。
2. Calculate D(y), where y is a member of N, for all nodes in N.
2. nのすべてのノードについて、yはnのメンバーであるd（y）を計算します。
3. Add to the active set those nodes in N, which are the *only* nodes to provide reachability to a node in N2, i.e., if node b in N2 can be reached only through a symmetric link to node a in N, then add node a to the active set. Remove the nodes from N2 that are now covered by a node in the active set.
3. N2のノードに到達可能性を提供する *のみ *ノードであるnのアクティブセットに追加されます。つまり、N2のノードBにNode Aへの対称リンクを介してNODEのノードAへのみ到達できる場合、ノードを追加できます。Aアクティブセットへ。アクティブセットのノードでカバーされるN2からノードを削除します。
4. While there exist nodes in N2 that are not covered by at least one node in the active set:
4. N2には、アクティブセットの少なくとも1つのノードでカバーされていないノードが存在します。
A. For each node in N, calculate the reachability, i.e., the number of nodes in N2 that are not yet covered by at least one node in the active set and that are reachable through this 1-hop neighbor.
A. nの各ノードについて、到達可能性、つまり、アクティブセットの少なくとも1つのノードでまだカバーされておらず、この1ホップ隣人を介して到達可能なN2のノードの数を計算します。
B. Select as an Active Overlapping Relay the node with the highest Willingness value (Section 3.3.7) among the nodes in N with non-zero reachability. In the case of multiple choices, select the node that provides reachability to the maximum number of nodes in N2. In the case of multiple nodes providing the same amount of reachability, select as active the node whose D(y) is greater. As a final tie breaker, the node with the highest router ID should be chosen. Remove the nodes from N2 that are now covered by a node in the active set.
B. NODEのNODEの中で、NODのノードの中から非ゼロの到達可能性を持つ、最も高い意欲値（セクション3.3.7）を持つノードをアクティブなオーバーラップリレーとして選択します。複数の選択肢の場合、N2の最大数のノードに到達可能性を提供するノードを選択します。同じ量の到達可能性を提供する複数のノードの場合、d（y）が大きいノードをアクティブとして選択します。最終的なタイブレーカーとして、最高のルーターIDを持つノードを選択する必要があります。アクティブセットのノードでカバーされるN2からノードを削除します。
5. As an optimization, process each node, y, in the active set in increasing order of Willingness value. If all nodes in N2 are still covered by at least one node in the active set, excluding node y, and if Willingness of node y is smaller than MAX_WILLINGNESS, then node y should be removed from the active set.
5. 最適化として、各ノードYを、意欲の価値を高めるためにアクティブセットで処理します。N2のすべてのノードが、ノードYを除くアクティブセットの少なくとも1つのノードでまだカバーされている場合、ノードYの意欲がmax_willingnessよりも小さい場合は、ノードyをアクティブセットから削除する必要があります。
A single new option bit, the F-bit, is defined in the LLS Type 1 Extended Options and Flags field. The F-bit indicates that the node supports the optimized flooding mechanism as specified in this document. See Section 5 for placement of the F-bit.
単一の新しいオプションビット、F-BITは、LLSタイプ1拡張オプションとフラグフィールドで定義されています。Fビットは、このドキュメントで指定されているように、ノードが最適化された洪水機構をサポートしていることを示しています。Fビットの配置については、セクション5を参照してください。
A new TLV is defined so that each speaker can convey its set of Active Overlapping Relays in the Hello messages. The TLV is transmitted using LLS [LLS].
新しいTLVが定義されているため、各スピーカーはHelloメッセージにアクティブな重複リレーのセットを伝えることができます。TLVはLLS [LLS]を使用して送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relays Added |A|N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID(s) of Active Overlapping Relay(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 10
o タイプ：10
o Length - variable. Length of TLV in bytes, NOT including Type and Length.
o 長さ - 変数。タイプと長さは含まれないバイト単位のTLVの長さ。
o Relays Added - variable. Number of Active Overlapping Relays that are being added. Note that the number of Active Overlapping Relays that are being dropped is then given by [(Length - 4)/4 - Relays Added].
o リレーを追加 - 変数。追加されているアクティブオーバーラップリレーの数。ドロップされているアクティブオーバーラップリレーの数は、[（長さ-4）/4-リレーが追加された]で与えられることに注意してください。
o A-bit - If this bit is set, the node is specifying that it will always flood routing updates that it receives, regardless of whether it is selected as an Active Overlapping Relay.
o Aビット - このビットが設定されている場合、ノードは、アクティブなオーバーラップリレーとして選択されているかどうかにかかわらず、受信するルーティングの更新を常に洪水にすることを指定しています。
o N-bit - If this bit is set, the node is specifying that it most likely will not flood routing updates. The node SHOULD NOT be chosen to be an Active Overlapping Relay unless it is the *only* neighbor that can reach 2-hop neighbor(s). Note that if the node is selected as an Active Overlapping Relay and the node cannot perform the required duties, network behavior is not compromised, since it results in the same behavior as if the node was not chosen as an Active Overlapping Relay.
o n -bit-このビットが設定されている場合、ノードはルーティングの更新をflood濫させない可能性が高いことを指定しています。ノードは、2ホップの隣人に到達できる *唯一の *隣人でない限り、アクティブなオーバーラップリレーになるように選択する必要はありません。ノードがアクティブなオーバーラップリレーとして選択され、ノードが必要な任務を実行できない場合、ネットワークの動作は損なわれないことに注意してください。ノードがアクティブなオーバーラップリレーとして選択されていない場合と同じ動作になるためです。
o Reserved - Reserved for future use. MUST be set to zero by the sender, and MUST be ignored upon receipt.
o 予約済み - 将来の使用のために予約されています。送信者によってゼロに設定する必要があり、受領時に無視する必要があります。
o Router ID(s) of Active Overlapping Relay(s) - The router ID(s) of neighbor(s) that are either chosen to serve as an Active Overlapping Relay or removed from serving as an Active Overlapping Relay. The Active Overlapping Relays that are being added MUST be listed first, and the number of such relays MUST equal Add Length. The remaining listed relays are being dropped as Active Overlapping Relays, and the number of such relays MUST equal [(Length - 4)/4 - Relays Added].
o アクティブオーバーラップリレーのルーターID（s） - アクティブなオーバーラップリレーとして機能するように選択されるか、アクティブなオーバーラップリレーとして機能するように除去される隣接のルーターID（s）。追加されているアクティブなオーバーラップリレーを最初にリストする必要があり、そのようなリレーの数は追加の長さに等しくなければなりません。残りのリストされたリレーは、アクティブな重複リレーとしてドロップされており、そのようなリレーの数は[（長さ-4）/4-リレーが追加された]等しくなければなりません。
Note that the A-bit and N-bit are independent of any particular selection algorithm to determine the set of Active Overlapping Relays. However, the bits SHOULD be considered as input into the selection algorithm.
AビットとNビットは、アクティブな重複リレーのセットを決定するために、特定の選択アルゴリズムとは無関係であることに注意してください。ただし、BITは選択アルゴリズムへの入力と見なされる必要があります。
If a node is selected as an Active Overlapping Relay and it does not support the Incremental Hello mechanism defined in Section 3.2, then it SHOULD always be included as an Active Overlapping Relay in the TLV. Note that while a node needs to know whether it is an Active Overlapping Relay, it does not necessarily have to know the identities of the other Active Overlapping Relays.
ノードがアクティブなオーバーラップリレーとして選択され、セクション3.2で定義されている増分ハローメカニズムをサポートしない場合、TLVのアクティブなオーバーラップリレーとして常に含める必要があります。ノードはアクティブな重複リレーであるかどうかを知る必要がありますが、必ずしも他のアクティブオーバーラップリレーのアイデンティティを知る必要はありません。
A new TLV is defined so that each speaker can convey its willingness to serve as an Active Overlapping Relay in the Hello message. The TLV is transmitted using the LLS [LLS].
新しいTLVが定義されているため、各スピーカーは、Helloメッセージでアクティブな重複リレーとして機能する意欲を伝えることができます。TLVは、LLS [LLS]を使用して送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Willingness | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 11
o タイプ：11
o Length - 4 bytes. It does not include the Type and Length fields.
o 長さ-4バイト。タイプと長さのフィールドは含まれていません。
o Willingness - 1 byte to indicate the willingness of the node to serve as an Active Overlapping Relay for its neighbors. * 0: MIN_WILLINGNESS * 128: DEFAULT_WILLINGNESS * 255: MAX_WILLINGNESS
o 意欲-1バイトは、近隣のためのアクティブな重複リレーとしてノードの意欲を示すための1バイト。* 0：min_willingness * 128：default_willingness * 255：max_willingness
The TLV is optional and MUST be silently ignored if not understood. If the Willingness TLV is not included in the Hello packet, the Willingness value SHOULD be taken as DEFAULT_WILLINGNESS.
TLVはオプションであり、理解していない場合は静かに無視する必要があります。意欲のTLVがHello Packetに含まれていない場合、意欲の値はdefault_willingnessとみなされるべきです。
The decision whether to relay any received LSAs, and when to relay such information, is made depending on the topology and whether the node is part of the set of Active Overlapping Relays.
受信したLSAを中継するかどうか、いつそのような情報を中継するかは、トポロジーとノードがアクティブなオーバーラップリレーのセットの一部であるかどうかに応じて行われます。
Upon receiving an LSA from a bi-directional neighbor, a node makes flooding decisions based on the following algorithm:
双方向の隣人からLSAを受信すると、ノードは次のアルゴリズムに基づいて洪水の決定を下します。
1. If the node is an Active Overlapping Relay for the adjacent speaker, then the router SHOULD immediately relay any information received from the adjacent speaker.
1. ノードが隣接するスピーカーのアクティブなオーバーラップリレーである場合、ルーターはすぐに隣接するスピーカーから受け取った情報をリレーする必要があります。
2. If the node is a non-Active Overlapping Relay for the adjacent speaker, then the router SHOULD wait a specified amount of time (PushbackInterval plus jitter (see Section 3.3.10)) to decide whether to transmit. [Jitter is used to try to avoid several non-Active Overlapping Relays from propagating redundant information.] Note that a node with the N-bit set in the 'Active Overlapping Relays' extension will not be chosen as an Active Overlapping Relay unless it is the only node to provide reachability to a 2-hop neighbor. However, it MUST perform the duties of a non-Active Overlapping Relay as required. Non-Active Overlapping Relays MUST follow the acknowledgment mechanism outlined in Section 3.3.9.
2. ノードが隣接するスピーカーの非アクティブなオーバーラップリレーである場合、ルーターは指定された時間（プッシュバックインターバルとジッター（セクション3.3.10を参照）を参照）を待って、送信するかどうかを決定する必要があります。[ジッターは、冗長な情報を伝播することからいくつかの非アクティブな重複リレーを回避しようとするために使用されます。]「アクティブオーバーラップリレー」に設定されたNビットのノードは、アクティブなオーバーラップリレーとして選択されないことに注意してください。2ホップの隣人に到達可能性を提供する唯一のノード。ただし、必要に応じて、非アクティブなオーバーラップリレーの業務を実行する必要があります。非アクティブなオーバーラップリレーは、セクション3.3.9で概説されている確認メカニズムに従う必要があります。
A. During this time, if the node determines that flooding the LSA will only result in a redundant transmission, the node MUST suppress its transmission. Otherwise, it MUST transmit upon expiration of PushbackInterval plus jitter.
A.この間、ノードがLSAに浸水すると冗長トランスミッションが発生すると判断した場合、ノードは送信を抑制する必要があります。それ以外の場合は、PushbackInterval Plus Jitterの有効期限が切れると送信する必要があります。
B. If a non-Active Overlapping Relay hears a re-flood from another node that covers its non-overlapping neighbors before its timer to transmit expires, it SHOULD reset its PushbackInterval plus jitter timer. (Note that the implementation should take care to avoid resetting the PushbackInterval timer based on transmissions from Active Overlapping Relays.) During this time, if the node determines that flooding the update will only result in a redundant transmission, the node MUST suppress its transmission. Otherwise, it MUST transmit upon expiration of PushbackInterval plus jitter.
B.非アクティブなオーバーラップリレーが、有効期限が切れる前に、重複していない隣人をカバーする別のノードからリフルードを聞くと、プッシュバックインターバルとジッタータイマーをリセットする必要があります。（実装は、アクティブなオーバーラップリレーからの送信に基づいてプッシュバックインターバルタイマーのリセットを避けるように注意する必要があることに注意してください。）この期間中、ノードが更新の洪水が冗長伝送になるだけであると判断した場合、ノードは送信を抑制する必要があります。それ以外の場合は、PushbackInterval Plus Jitterの有効期限が切れると送信する必要があります。
C. If a non-Active Overlapping Relay hears an old instance of the LSA during this time, it SHOULD ignore the LSA, and it SHOULD NOT send a unicast packet to the neighbor with the most recent LSA as specified in [OSPFv3].
C.この期間中にLSAの古いインスタンスを聞くことができない場合は、[OSPFV3]で指定されているように、最新のLSAを持つLSAにユニキャストパケットを送信するべきではありません。
3. For LSAs that are received unicast because of retransmission by the originator, the node MUST determine whether it has already received the LSA from another speaker. If it already has the current instance of the LSA in its database, it MUST do nothing further in terms of flooding the LSA (since it would have taken appropriate action when it initially received the LSA). However, if it does not have the current instance of the LSA in its database, it MUST take action according to the rules above, just as if it received the multicast LSA. The acknowledgment mechanism outlined in Section 3.3.9 MUST be followed, and any timeout mechanism for unicast LSAs MAY be followed.
3. オリジネーターによる再送信のためにユニキャストを受けたLSAの場合、ノードは別のスピーカーからすでにLSAを受信しているかどうかを判断する必要があります。データベースにLSAの現在のインスタンスが既にある場合、LSAの洪水という点でこれ以上何もしなければなりません（最初にLSAを受け取ったときに適切な措置を講じていたからです）。ただし、データベースにLSAの現在のインスタンスがない場合は、マルチキャストLSAを受け取ったかのように、上記のルールに従ってアクションを実行する必要があります。セクション3.3.9で概説されている承認メカニズムに従う必要があり、ユニキャストLSAのタイムアウトメカニズムに従うことができます。
Note that a node can determine whether further flooding an LSA will only result in a redundant transmission by already having heard link state acknowledgments (ACKs) or floods for the LSA from all of its neighbors.
Nodeは、LSAをさらに浸水させると、すべての近隣からLSAのLink State Aumponedments（ACK）または洪水をすでに聞いたことによって、冗長な伝送にのみ発生するかどうかを判断できることに注意してください。
Due to the dynamic nature of a network, the set of Active Overlapping Relays may not be up to date at the time the relay decision is made or may not be able to perform the flooding duties, e.g., due to poor link quality. The non-Active Overlapping Relays prevent this situation from causing database synchronization issues and, thus, packet loss.
ネットワークの動的な性質により、リンクの品質が低いために、リレーの決定が行われた時点で、リレーの決定が行われた時点では、アクティブな重複リレーのセットが最新ではない可能性があります。非アクティブなオーバーラップリレーは、この状況がデータベースの同期の問題を引き起こすことを防ぎ、したがってパケット損失を防ぎます。
Since the originator of the information, the relay, and the receiver are all in the same dynamically determined local flooding domain, the relay MUST NOT change the routing update information. In general, LSAs SHOULD be sent to a well-known multicast address. In some cases, routing updates MAY be sent using unicast packets.
情報、リレー、および受信機の発信元はすべて同じ動的に決定されたローカル洪水ドメインに含まれているため、リレーはルーティングアップデート情報を変更してはなりません。一般に、LSAはよく知られているマルチキャストアドレスに送信する必要があります。場合によっては、ルーティングの更新はユニキャストパケットを使用して送信される場合があります。
In order to optimize the bandwidth utilization on the link, a speaker MUST follow these recommendations related to ACK transmissions:
リンク上の帯域幅の利用を最適化するには、スピーカーはACK送信に関連するこれらの推奨事項に従う必要があります。
1. All ACKs MUST be sent via multicast.
1. すべてのACKはマルチキャストを介して送信する必要があります。
2. Typically, LSAs are acknowledged by all of the adjacent speakers. In the case of relayed information, the relay MUST only expect either explicit or implicit acknowledgments from neighbors that have not previously acknowledged this LSA.
2. 通常、LSAは隣接するすべてのスピーカーによって認められます。リレー情報の場合、リレーは、このLSAを以前に認めていなかった隣人からの明示的または暗黙的な謝辞のみを期待する必要があります。
3. Because routing updates are sent via multicast, the set of overlapping speakers will usually receive the same update more than once. A speaker SHOULD only acknowledge the first update received on the link.
3. ルーティングの更新はマルチキャストを介して送信されるため、オーバーラップスピーカーのセットは通常、同じ更新を複数回受け取ります。スピーカーは、リンクで受信した最初の更新のみを確認する必要があります。
4. An Active Overlapping Relay SHOULD NOT explicitly acknowledge information that it is relaying. The relayed information will serve as an acknowledgment to the sender. If no information is being relayed, then an explicit ACK MUST be sent.
4. アクティブなオーバーラップリレーは、リレーしていることを明示的に認めるべきではありません。中継された情報は、送信者への承認として機能します。情報が中継されていない場合は、明示的なACKを送信する必要があります。
5. Several ACKs MAY be bundled into a single packet. The wait (AckInterval) before sending one such packet reduces the number of packet transmissions required in acknowledging multiple LSAs.
5. いくつかのACKを単一のパケットにバンドルすることができます。そのようなパケットを1つ送信する前の待機（Ackinterval）は、複数のLSAを認める際に必要なパケット送信の数を減らします。
6. All ACK packets SHOULD reset the RouterDeadInterval at the receiver. If there is no state waiting to be transmitted in a Hello packet at the sender, then the HelloInterval at the sender SHOULD be reset. Note that an ACK serves as a Hello packet with no state change.
6. すべてのACKパケットは、レシーバーでRouterDeadIntervalをリセットする必要があります。送信者のハローパケットに送信されるのを待っている状態がない場合、送信者のhellointervalはリセットする必要があります。ACKは、状態変更のないハローパケットとして機能することに注意してください。
7. Any LSA received via unicast MUST be acknowledged. (Note that acknowledgment is via multicast as specified in rule (1) above.)
7. ユニキャストを介して受け取ったLSAは認められなければなりません。（上記の規則（1）で指定されているように、謝辞はマルチキャスト経由であることに注意してください。）
An ACK received from a non-overlapping neighbor should prevent redundant transmission of the information to it by another overlapping relay.
重複しない隣人から受け取ったACKは、別の重複リレーによる情報の冗長な伝送を防ぐ必要があります。
This section details the timers that were introduced in Sections 3.3.8 and 3.3.9.
このセクションでは、セクション3.3.8および3.3.9で導入されたタイマーの詳細について説明します。
o PushbackInterval: The length of time in seconds that a non-Active Overlapping Relay SHOULD wait before further flooding an LSA if needed. This timer MUST be less than 1/2 of the RxmtInterval ([OSPF], [OSPFv3]) minus propagation delays, i.e., (PushbackInterval + propagation delay) < RxmtInterval/2. The PushbackInterval is set by a non-Active Overlapping Relay upon receipt of an LSA.
o PushbackInterval：必要に応じてLSAをさらに浸水させる前に、非アクティブなオーバーラップリレーが待機する秒での時間の長さ。このタイマーは、RXMTINTERVAL（[OSPF]、[OSOSPFV3]）を差し引いたものの1/2未満でなければなりません。プッシュバックインターバルは、LSAの受領時に非アクティブなオーバーラップリレーによって設定されます。
o AckInterval: After a node determines that it must transmit an ACK and the AckInterval timer is not already set, the node SHOULD set the AckInterval timer. The AckInterval is the length of time in seconds that a node should wait in order to transmit many ACKs in the acknowledgment packet. This wait reduces the number of packet transmissions required in acknowledging multiple LSAs. The AckInterval MUST be less than the PushbackInterval minus propagation delays, i.e., (AckInterval + propagation delay) < PushbackInterval.
o Ackinterval：ノードがACKを送信する必要があり、Ackintervalタイマーがまだ設定されていないと判断した後、ノードはAckintervalタイマーを設定する必要があります。Ackintervalは、nodeが確認パケットで多くのAckを送信するためにノードが待機する必要がある秒単位の時間です。これにより、複数のLSAを認める際に必要なパケット送信の数が減ります。Ackintervalは、プッシュバックインターバルマイナス伝播遅延、つまり（Ackinterval伝播遅延）<PushbackIntervalよりも少ない必要があります。
The mechanism described refers to the operation of relays on a common media segment. In other words, an LSA is only relayed out the same interface through which it was received. However, the concept of information relay may be extended to the flooding of all link state advertisements received on any interface (and forwarded on any other interface). OSPF works on the premise that all of the nodes in a flooding domain will receive all of the routing information. Note that one of the important properties is that the routing information is not altered when relayed.
説明されているメカニズムは、一般的なメディアセグメントでのリレーの動作を指します。言い換えれば、LSAは、受信したのと同じインターフェイスのみを中継します。ただし、情報リレーの概念は、任意のインターフェイスで受け取ったすべてのリンク状態広告の洪水に拡張される場合があります（および他のインターフェイスに転送されます）。OSPFは、フラッディングドメイン内のすべてのノードがすべてのルーティング情報を受信するという前提で機能します。重要な特性の1つは、中継時にルーティング情報が変更されないことです。
If each speaker advertised all of its adjacent neighbors on all interfaces, then the overlap check would result in the determination of which speakers are adjacent to both speakers. As a result, link state information should only be flooded to non-overlapping neighbors (taking all of the interfaces into account).
各スピーカーがすべてのインターフェイスで隣接するすべての隣人を宣伝した場合、オーバーラップチェックは、どのスピーカーが両方のスピーカーに隣接するかを判断します。その結果、リンク状態情報は、重複しない隣人にのみ浸水する必要があります（すべてのインターフェイスを考慮してください）。
The flooding mechanism in OSPF relies on a designated router to guarantee that any new LSA received by one router attached to the broadcast network will be re-flooded properly to all the other routers attached to the broadcast network. Such designated routers must be able to reach all of the other speakers on the same subnet. A designated router SHOULD NOT be elected if overlapping relays are used.
OSPFの洪水メカニズムは、指定されたルーターに依存して、ブロードキャストネットワークに接続された1つのルーターが受け取った新しいLSAが、ブロードキャストネットワークに接続された他のすべてのルーターに適切に再フード化されることを保証します。このような指定されたルーターは、同じサブネット上の他のすべてのスピーカーに到達できる必要があります。重複するリレーを使用している場合、指定されたルーターを選出しないでください。
If such designated routers already exist, then the relays MUST be capable of differentiating them and then making the relaying decisions based on the OSPF's normal operation. As a result, there may be groups of neighbors to which some information should not be relayed. This mode of operation is NOT RECOMMENDED, as it adds to the complexity of the system.
そのような指定されたルーターが既に存在する場合、リレーはそれらを区別し、OSPFの通常の操作に基づいてリレー決定を行うことができなければなりません。その結果、いくつかの情報を中継すべきではない隣人のグループがあるかもしれません。この動作モードは、システムの複雑さを増すため、推奨されません。
The intent of the overlapping relay mechanism is to optimize flooding of routing control information. However, other information (such as data) may also be relayed in some networks using the same mechanism.
重複するリレーメカニズムの意図は、ルーティング制御情報の洪水を最適化することです。ただし、他の情報（データなど）は、同じメカニズムを使用して一部のネットワークで中継することもできます。
On receiving a Hello packet from a new neighbor without the F-bit set, the local router will assume that the new neighbor will flood normally as described in [OSPFv3]. Thus, the local router SHOULD include the neighbor in its overlapping relay set since the neighbor will flood by default. This will allow the local router to more optimally select its entire overlapping relay set.
Fビットセットのない新しい隣人からハローパケットを受信すると、ローカルルーターは[OSPFV3]で説明されているように、新しい隣人が通常浸水すると仮定します。したがって、ローカルルーターには、隣人がデフォルトであふれるため、隣人を重複するリレーセットに含める必要があります。これにより、ローカルルーターが重複するリレーセット全体をより最適に選択できるようになります。
If the F-bit is set and the I-bit as defined in Section 3.2 is not set in the neighbor's Hello, and the neighbor is selected as an overlapping relay by the local router, the local router will continue to include the neighbor's identifier in its active relay set.
Fビットが設定され、セクション3.2で定義されているIビットが隣人のHelloで設定されておらず、隣人がローカルルーターによって重複するリレーとして選択されている場合、ローカルルーターは引き続き隣人の識別子を含めますそのアクティブリレーセット。
Two new option bits are defined in the "LLS Type 1 Extended Options and Flags" Field [LLS] as follows:
次のように、「LLSタイプ1拡張オプションとフラグ」フィールドで2つの新しいオプションビットが定義されています。
o I-bit - defined in Section 3.2.1: The I-bit is only defined for Hello packets and indicates that only incremental information is present.
o Iビット - セクション3.2.1で定義されています：IビットはHelloパケットに対してのみ定義され、増分情報のみが存在することを示します。
o F-bit - defined in Section 3.3.5: The F-bit indicates that the node supports the optimized flooding mechanism as specified in this document.
o Fビット - セクション3.3.5で定義されている：F-BITは、ノードがこのドキュメントで指定されているように最適化された洪水メカニズムをサポートしていることを示しています。
There is significant overhead in OSPF when a router has to establish adjacencies with every peer with whom it can verify 2-way connectivity. OSPF supports the broadcast network type for these scenarios, where you only have to peer with the designated router (DR). However, a full mesh of connectivity is required for proper operation, and this doesn't help in networks with overlapping partial meshes of connectivity. This document proposes a technique to reduce the number of adjacencies based on shortest path tree (SPT) reachability information.
ルーターが2方向の接続を検証できるすべてのピアと隣接を確立する必要がある場合、OSPFには大きなオーバーヘッドがあります。OSPFは、これらのシナリオのブロードキャストネットワークタイプをサポートします。ここでは、指定されたルーター（DR）をピアリングするだけで済みます。ただし、適切な動作には接続の完全なメッシュが必要であり、これは接続の部分的なメッシュが重複するネットワークでは役立ちません。このドキュメントは、最短のパスツリー（SPT）の到達可能性情報に基づいて隣接の数を減らす手法を提案しています。
In OSPF ([OSPF], [OSPFv3]), nodes establish an adjacency by first verifying 2-way connectivity between them and then synchronizing their link state databases. Once the peering relationship is complete and the adjacency is established, the nodes will continue to advertise each other in their LSAs. As a result, the peers are maintained in the link state database and are included in all SPF (Shortest Path First) calculations. During the reliable flooding process, a node must ensure that each peer has indeed received the flooded routing update via an acknowledgment and retransmission mechanism.
OSPF（[OSPF]、[OSPFV3]）では、ノードは最初にそれらの間の2方向の接続性を検証し、次にリンク状態データベースを同期することにより、隣接性を確立します。ピアリング関係が完了し、隣接が確立されると、ノードはLSAでお互いを宣伝し続けます。その結果、ピアはリンク状態データベースに維持され、すべてのSPF（最短パス最初の）計算に含まれています。信頼できる洪水プロセス中、ノードは、各ピアが実際に承認と再送信メカニズムを介して浸水したルーティングアップデートを受け取ったことを確認する必要があります。
Consequently, maintaining an adjacency for a particular peer is a trade-off between the added redundancy in routing paths and network reachability versus the associated overhead (memory consumption, SPF computations, routing overhead, and network convergence).
その結果、特定のピアの隣接性を維持することは、ルーティングパスで追加された冗長性とネットワークの到達可能性と関連するオーバーヘッド（メモリ消費、SPF計算、ルーティングオーバーヘッド、ネットワーク収束）との間のトレードオフです。
Consider the possibility of reducing the number of adjacencies that a node maintains without compromising reachability and redundancy. This will have direct implications on network scalability and is especially attractive in environments where the network topology is dynamic. For example, in a mobile ad hoc network (MANET), where nodes are mobile and the topology is constantly changing, it seems highly desirable to 'intelligently' become adjacent with only selected peers and not establish a peering session with every node that comes within transmission range. Selective peering can be particularly useful in avoiding the peering process for unstable nodes, i.e., nodes that come in and out of transmission range.
到達可能性と冗長性を損なうことなく、ノードが維持する隣接の数を減らす可能性を考慮してください。これは、ネットワークのスケーラビリティに直接的な意味を持ち、ネットワークトポロジが動的である環境で特に魅力的です。たとえば、ノードがモバイルであり、トポロジが絶えず変化しているモバイルアドホックネットワーク（MANET）では、選択されたピアのみで「インテリジェント」に隣接することが非常に望ましいと思われ、内部にあるすべてのノードでピアリングセッションを確立しません。送信範囲。選択的ピアリングは、不安定なノードのピアリングプロセス、つまり伝送範囲外に出入りするノードのピアリングプロセスを回避するのに特に役立ちます。
The formation of a FULL adjacency requires discovery (2-way relationship) and database synchronization. To prevent achieving the FULL state, others have taken the approach of modifying link state protocols to use periodic advertisements (instead of a database exchange). The result is that neighbor discovery is still required, but routing information is learned over time. An example of this approach is:
完全な隣接の形成には、発見（2方向の関係）とデータベースの同期が必要です。完全な状態の達成を防ぐために、他の人々は、（データベース交換の代わりに）定期的な広告を使用するためにリンク状態プロトコルを変更するアプローチを取っています。その結果、近隣の発見がまだ必要ですが、ルーティング情報は時間の経過とともに学習されます。このアプローチの例は次のとおりです。
o OSPFv2 Wireless Interface Type [WINTF]
o OSPFV2ワイヤレスインターフェイスタイプ[WINTF]
* where the use of periodic advertisements "eliminates the formation of full adjacencies on wireless interfaces; all neighbor states beyond 2-Way are not reached,and no database synchronization is performed".
* 定期的な広告の使用が「ワイヤレスインターフェイスでの完全な隣接の形成を「排除」する場合、2ウェイを超えるすべての隣接状態に到達せず、データベースの同期は実行されません」。
What we propose in this specification goes a step further by not requiring the formation and maintenance of neighbor state (2-way, or other) *and* without changing the route distribution mechanisms in the link state protocols. In other words, the mechanism described is completely backward compatible.
この仕様で提案するものは、リンク状態のプロトコル内のルート分布メカニズムを変更せずに、隣人状態（2ウェイ、またはその他）の形成と維持を必要とせずにさらに一歩進んでいます。言い換えれば、説明されているメカニズムは完全に後方互換です。
Two routers are defined as synchronized when they have identical link state databases. To limit the number of neighbors that are formed, an algorithm is needed to select which neighbors with whom to peer.
2つのルーターは、同一のリンク状態データベースがある場合に同期として定義されます。形成される隣人の数を制限するには、どの隣人がピアにいるかを選択するためにアルゴリズムが必要です。
The algorithm MUST provide reachability to every possible destination in the network, just as when normal adjacency formation processes are used. We should always peer with a neighbor if it provides our only path to currently unreachable destinations.
アルゴリズムは、通常の隣接形成プロセスが使用されている場合と同じように、ネットワーク内のすべての可能な宛先に到達可能性を提供する必要があります。現在到達不可能な目的地への唯一の道を提供する場合、私たちは常に隣人と一緒に覗き込む必要があります。
The peering decision is really a local matter to a router. If a router can ensure that reachability to other nodes is available without bringing up a new adjacency, it can choose not to bring up the new adjacency.
ピアリングの決定は、実際にはルーターにとってローカルな問題です。ルーターが、新しい隣接をもたらさずに他のノードへの到達可能性を確実に利用できるようにすることができる場合、新しい隣接を育てないことを選択できます。
We propose an algorithm that uses the existing information about a new neighbor's reachability in the SPT. If the two routers can already reach each other in the SPT, it is not necessary to form an adjacency between them.
SPTにおける新しい隣人の到達可能性に関する既存の情報を使用するアルゴリズムを提案します。2つのルーターがSPTですでに互いに到達できる場合、それらの間に隣接する必要はありません。
The decision to peer or not is made when a Hello is received. When a Hello is received from a new neighbor or a neighbor in a state lower than Exchange:
ピアの決定は、こんにちはを受け取ったときに行われます。Exchangeよりも低い州の新しい隣人または隣人からこんにちはが受け取られたとき：
o A check is made in the link state database to see if the peer is already reachable in the SPT.
o リンク状態データベースにチェックが作成され、ピアが既にSPTで到達可能かどうかを確認します。
* If the peer is either not known in the SPT or is not reachable, we start the Exchange process.
* ピアがSPTで知られていないか、到達できない場合は、交換プロセスを開始します。
* If the peer is reachable, then bringing up adjacency with this neighbor does not provide reachability to any new destinations.
* ピアが到達可能な場合、この隣人と隣接することは、新しい目的地に到達可能性を提供しません。
Let's take an example of a single OSPF area. This check would look for the neighbor's router-LSA. If the LSA is present in the database and is reachable in the SPT, we have a chance to suppress adjacency formation.
単一のOSPFエリアの例を見てみましょう。このチェックは、隣人のルーター-LSAを探します。LSAがデータベースに存在し、SPTに到達可能な場合、隣接能力の形成を抑制する機会があります。
It's worth noting that as the number of links and redundancy in the network is reduced, the likelihood of suboptimal routing increases.
ネットワークのリンクと冗長性の数が減少するにつれて、最適ではないルーティングの可能性が増加することは注目に値します。
The state machine of a basic implementation of this algorithm is provided below. An implementation MAY use some heuristics (Step (3) below), beyond the SPT reachability, to decide whether or not it considers a new adjacency to be of value.
このアルゴリズムの基本的な実装の状態マシンを以下に示します。実装では、SPTの到達可能性を超えて、いくつかのヒューリスティック（以下のステップ（3））を使用して、新しい隣接性が価値があると考えるかどうかを決定することができます。
......................
|Receive a Hello |
(1) |from a new potential|
|neighbor |
'`''''''''''''''''''''
|
|
|
,''''''''''''''''''''''|
|Check to see if there |
(2) |is a router-LSA from |----no--(4)form a
|the new potential | new
|neighbor in the link | neighbor
|state database, which |
|is reachable in SPT |
'`''''''''''''''''''''''
|
|yes
(3) |
,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
| (3b)........................ |
|(3a),______________________ |Determine if the | |
| |Determine if the new | |number of redundant | |
| |link cost is better | |paths to the potential| |
| |than the current path| |neighbor is < the | |
| |cost by a configured | |maximum configured | |
| |amount | |value | |
| '`''''''''''''''''''''' '`'''''''''''''''''''''' |
| \ / |
| .....\.........../.... |
| |User configurable | |
| |selection algorithm | |
| '`'''/'''''''\'''''''' |
| / \ |
'`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
/ \
requirements requirements
met not met
/ \
/ \
(4) form a new neighbor (5) do not become
neighbors
The technique described in Section 3.5.3 minimizes the number of adjacencies in highly meshed environments. This is especially useful when the network is in motion and the average adjacency lifetime is small.
セクション3.5.3で説明されている手法は、高度にメッシュ化された環境の隣接の数を最小限に抑えます。これは、ネットワークが動いており、平均隣接寿命が小さい場合に特に役立ちます。
However, it suffers from an undesirable side effect of limiting the number of transit links available to forward traffic.
ただし、フォワードトラフィックに利用可能なトランジットリンクの数を制限するという望ましくない副作用に苦しんでいます。
An implementation may choose to allow some (or even all) of these 2-way state neighbors to be announced in the router-LSA. Since the state remains 2-way, we don't incur control plane (database sync and flooding) overhead. However, advertising the link in the router-LSA makes the link available to the data plane.
実装は、これらの2方向の州の隣人の一部（またはすべて）がルーター-LSAで発表されることを許可することを選択する場合があります。状態は2方向のままであるため、コントロールプレーン（データベースの同期と洪水）は頭上にありません。ただし、Router-LSAのリンクを宣伝すると、リンクがデータプレーンで利用可能になります。
This can be safely done if the neighbor is reachable in a special SPT constructed by ignoring any other 2-way links in the network. This optional optimization is described below.
これは、ネットワーク内の他の2ウェイリンクを無視することで構築された特別なSPTで隣人が到達できる場合、安全に行うことができます。このオプションの最適化については、以下に説明します。
If the new neighbor is already reachable in the SPT, there is no urgency in doing a full database sync with it. These are the steps we need to perform when a neighbor has reached 2-way state.
新しい隣人がSPTですでに到達可能である場合、完全なデータベース同期を実行することに緊急性はありません。これらは、隣人が2方向の状態に達したときに実行する必要がある手順です。
Note that when we say "SPT" in this section, we mean the special SPT constructed based on rules in Section 3.5.4.2.
このセクションで「SPT」と言うとき、セクション3.5.4.2のルールに基づいて構築された特別なSPTを意味することに注意してください。
o After a 2-WayReceived event, check if the neighbor is reachable in the SPT. If yes, mark the neighbor as FULL with respect to link advertisement.
o 2方向のイベントの後、隣人がSPTで到達できるかどうかを確認します。はいの場合、リンク広告に関して隣人をいっぱいにマークします。
o This means that the router-LSA or network-LSA link corresponding to the neighbor is advertised as if the neighbor is FULL.
o これは、隣人に対応するルーター-LSAまたはネットワークLSAリンクが隣人がいっぱいであるかのように宣伝されていることを意味します。
o The adjacency information is constructed with the U-bit (see below).
o 隣接情報はUビットで構築されます（以下を参照）。
o Database synchronization is postponed:
o データベースの同期が延期されます：
* By a configured amount of time -OR-
* 構成された時間の時間によって - または -
* Until the time it's absolutely "necessary"
* それが絶対に「必要」になるまで
In either case, if a database sync is currently pending, it is started as soon as we detect that the neighbor is no longer reachable in the SPT. The database sync can be done by Out-of-Band Sync [OOB], which maintains the current adjacency and does the sync in the background. A normal resync can alternately be done with the drawback of adjacency flap.
どちらの場合でも、データベースの同期が現在保留中の場合、隣人がSPTで到達できなくなったことを検出するとすぐに開始されます。データベースの同期は、現在の隣接性を維持し、バックグラウンドで同期を行う帯域Out-Band Sync [OOB]によって実行できます。隣接フラップの欠点を使用して、通常の再配合を交互に行うことができます。
In standard OSPF, we first bring up adjacency and then announce a transit link. The approach described above allows the link to be used as a forwarding path very quickly and still allows the database to be synchronized in a timely fashion when the alternate flooding path has recently been broken.
標準のOSPFでは、最初に隣接を取り上げてから、トランジットリンクを発表します。上記のアプローチにより、リンクを転送パスとして非常に迅速に使用できますが、それにより、代替洪水パスが最近壊れたときにデータベースをタイムリーに同期させることができます。
There is a circular dependency issue that also needs to be resolved. Once you start announcing the link, the shortest path will likely be via this very link. So it's non-trivial to detect when the alternate dependent path is gone. We would like to be able to detect that the neighbor is reachable via a path that doesn't traverse an unsynchronized path.
また、解決する必要がある循環依存関係の問題があります。リンクの発表を開始すると、最短のパスはこのまさにリンクを介して行われる可能性があります。したがって、代替依存パスがいつなくなったかを検出することは自明ではありません。私たちは、異議を唱えないパスを横断しないパスを介して隣人が到達可能であることを検出できるようにしたいと思います。
We have generally solved this class of problems by running an SPF and pretending that the link in question doesn't exist. It doesn't require a full SPF, but just enough to see if ANY other path is available to reach the neighbor. The worst case is when the alternate path is really gone, which we find that out by building a full SPT. This needs to be done every time the link state database changes, and for EACH link that has SPT dependence for its viability. This approach has scalability concerns and is not considered further here.
一般に、SPFを実行し、問題のリンクが存在しないふりをすることで、このクラスの問題を解決しました。完全なSPFは必要ありませんが、隣人に到達するために他のパスが利用できるかどうかを確認するのに十分です。最悪の場合は、代替パスが本当になくなったときです。これは、完全なSPTを構築することでそれを見つけます。これは、リンク状態データベースが変更されるたびに行う必要があります。また、その実行可能性のためにSPT依存性を持つリンクごとに行う必要があります。このアプローチにはスケーラビリティの懸念があり、ここではこれ以上考慮されていません。
We can achieve the same results with just ONE additional SPF that is capable of ignoring these Unsynchronized links. The result from this SPT can be used to satisfy the reachability condition for ANY number of Unsynchronized Adjacencies. This basically requires that we can actually tell the difference between a normal FULL adjacency and this new Unsynchronized Adjacency. We can do this in one of two ways:
これらの非物語化されていないリンクを無視できる追加のSPFだけで同じ結果を達成できます。このSPTの結果を使用して、任意の数の非物語化された隣接の到達可能性条件を満たすことができます。これには、基本的に、通常の完全な隣接とこの新しい非色素化された隣接性の違いを実際に伝えることができます。これは2つの方法のいずれかで行うことができます。
(A) Defining LD Options and using a bit in it, as shown below:
（a）以下に示すように、LDオプションを定義し、少し使用しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | LD Options | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Description in a Router-LSA
ルーターLSAのリンク説明
LD Options Link Description options. Used to specify some special capability or state of a link.
LDオプションリンク説明オプション。リンクの特別な機能または状態を指定するために使用されます。
+-+-+-+-+-+-+-+-+
| | | | | | | |U|
+-+-+-+-+-+-+-+-+
LD Options
LDオプション
U-bit The "Unsynchronized" bit. This is set if the adjacency is being announced before databases are fully synchronized.
Uビット「非色素化」ビット。これは、データベースが完全に同期される前に隣接性が発表されている場合に設定されます。
This approach is backward compatible, because the only routers looking at this bit are those that support the mechanisms specified in this document.
このアプローチは、このビットを見るルーターのみが、このドキュメントで指定されたメカニズムをサポートするルーターであるため、後方互換性があります。
(B) Introducing a new link type in router-LSA.
（b）ルーターLSAに新しいリンクタイプを導入します。
This is a much more complex solution, with backward compatibility concerns, due to the fact that unknown link type handling is not defined in the OSPF standard [OSPF]. Hence, this solution isn't considered further.
これは、OSPF標準[OSPF]では不明なリンクタイプの取り扱いが定義されていないという事実により、より複雑なソリューションであり、逆方向の互換性の懸念を備えています。したがって、このソリューションはこれ以上考慮されていません。
Whenever link state changes happen, we need to run ONE additional SPF by ignoring all links with the U-bit set. This SPT is then consulted to see if any of our Unsynchronized Adjacencies need to start database sync. This SPT is also consulted when a new neighbor goes into 2-way state to decide if we should form the adjacency immediately or defer it for later.
リンク状態の変更が発生するたびに、Uビットセットとのすべてのリンクを無視することにより、追加のSPFを1つ実行する必要があります。次に、このSPTに相談して、非シンデイア化された隣接のいずれかがデータベースの同期を開始する必要があるかどうかを確認します。また、このSPTは、新しい隣人が2方向の状態に入ったときに相談して、すぐに隣接を形成するか、後でそれを延期すべきかどうかを決定します。
One of the main goals in trying to delay the database synchronization is to be able to reduce unnecessary OSPF packets traversing these links. Since the unsynchronized Adjacencies remain in 2-way state, OSPF updates will not be flooded over the corresponding interfaces, resulting in additional savings.
データベースの同期を遅らせようとする主な目標の1つは、これらのリンクを横断する不必要なOSPFパケットを減らすことができることです。非シネ型の隣接は双方向の状態であるため、OSPFの更新は対応するインターフェイスに浸水しないため、追加の節約が行われます。
An option is provided to enable or disable flooding over these Unsynchronized Adjacencies. The advantage of allowing flooding is being able to use more links for control plane purposes. We will still have the savings of not having to form the adjacency.
これらの非同期の隣接を介して洪水を有効または無効にするためのオプションが提供されます。洪水を許可することの利点は、制御プレーンの目的でより多くのリンクを使用できることです。隣接を形成する必要がないという節約があります。
The overlapping relay election algorithm uses the 2-hop neighborhood it gleans from our neighbor's router-LSAs. The introduction of Unsynchronized Adjacencies needs to be considered in the relay election algorithm.
重複するリレー選挙アルゴリズムは、隣人のルーターLSAから収集する2ホップ近隣を使用します。リレー選挙アルゴリズムで、非同義の隣接の導入を考慮する必要があります。
If flooding is enabled on unsynchronized Adjacencies, no change is needed in the relay election algorithm. If flooding is disabled, then the relay election algorithm needs to prune neighbors that are connected via an Unsynchronized Adjacency from our 1-hop and 2-hop neighbor lists.
非シンデーロー化された隣接で洪水が有効になっている場合、リレー選挙アルゴリズムに変更は必要ありません。洪水が無効になっている場合、リレー選挙アルゴリズムは、1ホップおよび2ホップの隣人リストからの非色素化された隣接を介して接続されている隣人を剪定する必要があります。
In a MANET, security is both more difficult and important, due to the wireless nature of the medium. Controlling the ability of devices to connect to a MANET at Layer 2 will be relegated to Layer 2 security mechanisms, such as 802.1x, and others. Controlling the ability of attached devices to transmit traffic will require some type of security system (outside the scope of this document) that can authenticate, and provide authorization for, individual members of the routing domain.
マネでは、媒体のワイヤレス性のため、セキュリティはより困難で重要です。レイヤー2でマネに接続するデバイスの能力を制御することは、802.1xなどのレイヤー2セキュリティメカニズムに追いやられます。接続されたデバイスがトラフィックを送信する機能を制御するには、ルーティングドメインの個々のメンバーを認証し、許可を提供できる、何らかのタイプのセキュリティシステム（このドキュメントの範囲外）が必要です。
Additional security considerations are similar to any MANET protocol extension. The following text is from [MDR]:
追加のセキュリティ上の考慮事項は、MANETプロトコル拡張に似ています。次のテキストは[MDR]からのものです。
As with OSPFv3 [OSPFv3], OSPF-OR can use the IPv6 Authentication Header (AH) [AH] and/or the IPv6 Encapsulation Security Payload (ESP) [ESP] to provide authentication, integrity, and/or confidentiality. The use of AH and ESP for OSPFv3 is described in [OSPFv3-SEC].
OSPFV3 [OSPFV3]と同様に、OSPF-ORはIPv6認証ヘッダー（AH）[AH]および/またはIPv6カプセル化セキュリティペイロード（ESP）[ESP]を使用して、認証、整合性、および/または機密性を提供できます。OSOSPFV3のAHおよびESPの使用は、[OSPFV3-sec]に記載されています。
Generic threats to routing protocols are described and categorized in [THREATS]. The mechanisms described in [OSPFv3-SEC] provide protection against many of these threats, but not all of them. In particular, as mentioned in [OSPFv3], these mechanisms do not provide protection against compromised, malfunctioning, or misconfigured routers (also called Byzantine routers); this is true for both OSPFv3 and OSPF-OR.
ルーティングプロトコルに対する一般的な脅威は、[脅威]で説明および分類されます。[Ospfv3-sec]で説明されているメカニズムは、これらの脅威の多くに対する保護を提供しますが、それらのすべてではありません。特に、[OSPFV3]で述べたように、これらのメカニズムは、侵害、誤動作、または誤ったルーター（ビザンチンルーターとも呼ばれます）に対する保護を提供しません。これは、OSPFV3とOSPF-ORの両方に当てはまります。
The extension of OSPFv3 to include MANET routers does not introduce any new security threats. However, the use of a wireless medium and lack of infrastructure, inherent with MANET routers, may render some of the attacks described in [THREATS] easier to mount. Depending on the network context, these increased vulnerabilities may increase the need to provide authentication, integrity, and/or confidentiality, as well as anti-replay service.
MANETルーターを含むOSPFV3の拡張では、新しいセキュリティの脅威は導入されません。ただし、ワイヤレスメディアの使用と、マネルーターに固有のインフラストラクチャの不足により、[脅威]に記載されている攻撃の一部がマウントを容易にする可能性があります。ネットワークのコンテキストに応じて、これらの脆弱性の増加は、認証、整合性、および/または機密性を提供する必要性を高める可能性があります。
For example, sniffing of routing information and traffic analysis are easier tasks with wireless routers than with wired routers, since the attacker only needs to be within the radio range of a router. The use of confidentiality (encryption) provides protection against sniffing but not traffic analysis.
たとえば、攻撃者はルーターの無線範囲内にいるだけである必要があるため、ルーティング情報とトラフィック分析のスニッフィングは、有線ルーターよりもワイヤレスルーターのタスクが簡単です。機密性（暗号化）の使用は、交通分析ではなく、スニッフィングに対する保護を提供します。
Similarly, interference attacks are also easier to mount against MANET routers due to their wireless nature. Such attacks can be mounted even if OSPF packets are protected by authentication and confidentiality, e.g., by transmitting noise or replaying outdated OSPF packets. As discussed below, an anti-replay service (provided by both ESP and AH) can be used to protect against the latter attack.
同様に、干渉攻撃は、ワイヤレスの性質のために、マネルーターに対しても簡単に取り付けられます。このような攻撃は、OSPFパケットが認証と機密性によって保護されている場合でも、たとえば、ノイズの送信や古いOSPFパケットの再生によって保護されていても、取り付けることができます。以下で説明するように、後者の攻撃から保護するために、アンチレプレイサービス（ESPとAHの両方で提供）を使用できます。
The following threat actions are also easier with MANET routers: spoofing (assuming the identity of a legitimate router), falsification (sending false routing information), and overloading (sending or triggering an excessive amount of routing updates). These attacks are only possible if authentication is not used, or the attacker takes control of a router or is able to forge legitimacy (e.g., by discovering the cryptographic key).
MANETルーターでは、次の脅威アクションも簡単です。スプーフィング（正当なルーターのIDを想定）、偽造（誤ったルーティング情報の送信）、過負荷（過剰な量のルーティング更新の送信またはトリガー）。これらの攻撃は、認証が使用されない場合にのみ可能です。または、攻撃者がルーターを制御するか、正当性を築くことができます（例えば、暗号化キーを発見することによって）。
[OSPFv3-SEC] mandates the use of manual keying when current IPsec protocols are used with OSPFv3. Routers are required to use manually configured keys with the same security association (SA) parameters for both inbound and outbound traffic. For MANET routers, this implies that all routers attached to the same MANET must use the same key for multicasting packets. This is required in order to achieve scalability and feasibility, as explained in [OSPFv3-SEC]. Future specifications can explore the use of automated key management protocols that may be suitable for MANETs.
[OSPFV3-SEC]は、現在のIPSECプロトコルがOSPFV3で使用される場合に手動キーイングの使用を義務付けています。ルーターは、インバウンドトラフィックとアウトバウンドトラフィックの両方に同じセキュリティアソシエーション（SA）パラメーターを備えた手動で構成されたキーを使用する必要があります。MANETルーターの場合、これは、同じマネに取り付けられたすべてのルーターがマルチリキャストパケットに同じキーを使用する必要があることを意味します。[OSPFV3-sec]で説明されているように、これはスケーラビリティと実現可能性を実現するために必要です。将来の仕様では、マネに適している可能性のある自動化された主要な管理プロトコルの使用を探ることができます。
As discussed in [OSPFv3-SEC], the use of manual keys can increase vulnerability. For example, manual keys are usually long lived, thus giving an attacker more time to discover the keys. In addition, the use of the same key on all routers attached to the same MANET leaves all routers insecure against impersonation attacks if any one of the routers is compromised.
[OSPFV3-sec]で説明したように、手動キーを使用すると脆弱性が向上する可能性があります。たとえば、マニュアルキーは通常長生きしているため、攻撃者にキーを発見する時間が増えます。さらに、同じマネに取り付けられたすべてのルーターで同じキーを使用すると、ルーターのいずれかが侵害された場合、すべてのルーターがなりすまし攻撃に対して不安定になります。
Although [AH] and [ESP] state that implementations of AH and ESP SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed, it is important to note that such service is allowed if the sequence number counter at the sender is correctly maintained across local reboots until the key is replaced. Therefore, it may be possible for MANET routers to make use of the anti-replay service provided by AH and ESP.
[AH]と[ESP]は、AHとESPの実装は、手動でキーを塗ったSASと組み合わせてアンチレプレイサービスを提供すべきではないと述べていますが、送信者のシーケンス番号カウンターが許可されている場合は、そのようなサービスが許可されていることに注意することが重要です。キーが交換されるまで、ローカルの再起動全体で正しく維持されます。したがって、MANETルーターがAHおよびESPが提供するアンチレプレイサービスを利用できる可能性があります。
When an OSPF routing domain includes both MANETs and fixed networks, the frequency of OSPF updates either due to actual topology changes or malfeasance could result in instability in the fixed networks. In situations where this is a concern, it is recommended that the border routers segregate the MANETs from the fixed networks with either separate OSPF areas or, in cases where legacy routers are very sensitive to OSPF update frequency, separate OSPF instances. With separate OSPF areas, the 5-second MinLSInterval will dampen the frequency of changes originated in the MANETs. Additionally, OSPF ranges can be configured to aggregate prefixes for the areas supporting MANETs. With separate OSPF instances, more conservative local policies can be employed to limit the volume of updates emanating from the MANETs.
OSPFルーティングドメインにMANETと固定ネットワークの両方が含まれる場合、実際のトポロジの変更または不正行為によるOSPF更新の頻度は、固定ネットワークの不安定性をもたらす可能性があります。これが懸念事項である状況では、境界線ルーターが、別々のOSPF領域を持つ固定ネットワークからマネを分離することをお勧めします。別々のOSPF領域を使用すると、5秒のMinlsintervalは、マネに由来する変化の頻度を減衰させます。さらに、OSPF範囲は、マネをサポートする領域の接頭辞を集約するように構成できます。個別のOSPFインスタンスを使用すると、より保守的なローカルポリシーを使用して、マネから発せられる更新の量を制限できます。
IANA has made the assignments as explained below using the policies outlined in [IANA].
IANAは、[IANA]で概説されているポリシーを使用して以下で説明するように、割り当てを行いました。
o I-bit and F-bit from "LLS Type 1 Extended Options and Flags" registry as defined below:
o 以下に定義されている「LLSタイプ1拡張オプションとフラグ」レジストリからのIビットとFビット：
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * | F | I | RS| LR|
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Bits in Extended Options and Flags TLV
拡張オプションとフラグTLVのビット
o New TLV types from the "Link Local Signalling TLV Identifiers (LLS Types)" registry as defined below:
o 「Link Local Signaling TLV識別子（LLSタイプ）」からの新しいTLVタイプ。
TLV Name TLV Type
-------- --------
State Check Sequence TLV 6
Neighbor Drop TLV 7
Request From TLV 8
Full State For TLV 9
Active Overlapping Relay TLV 10
Willingness TLV 11
o A new registry has been defined for LD Options as defined in Section 3.5.4.1. The U-bit is allocated by this document.
o セクション3.5.4.1で定義されているように、LDオプションの新しいレジストリが定義されています。Uビットはこのドキュメントによって割り当てられます。
All future additions to LD Options are subject to OSPF WG review and require IETF Review.
LDオプションへの将来の追加はすべてOSPF WGレビューの対象となり、IETFレビューが必要です。
The following persons are contributing authors to the document:
次の人が著者を文書に貢献しています。
Fred Baker Dave Cook
Cisco Systems Cisco Systems
1121 Via Del Rey 7025-4 Kit Creek Road
Santa Barbara, CA 93117 Research Triangle Park, NC 27709
USA USA
EMail: fred@cisco.com EMail: dacook@cisco.com
Alvaro Retana Yi Yang
Cisco Systems Cisco Systems
7025-4 Kit Creek Road 7025-4 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
EMail: aretana@cisco.com EMail: yiya@cisco.com
Russ White Cisco Systems 7025-4 Kit Creek Road Research Triangle Park, NC 27709 USA EMail: riw@cisco.com
Russ White Cisco Systems 7025-4 Kit Creek Road Research Triangle Park、NC 27709 USAメール：riw@cisco.com
The authors and contributors would like to thank Pratap Pellakuru and Stan Ratliff for their feedback and implementation of the document. Thanks to Richard Ogier and John Avery for doing a final review.
著者と貢献者は、Pratap PellakuruとStan Ratliffに、ドキュメントのフィードバックと実装について感謝したいと思います。最終レビューをしてくれたリチャード・オギエとジョン・エイブリーに感謝します。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFV3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[LLS] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[LLS] Zinin、A.、Roy、A.、Nguyen、L.、Friedman、B。、およびD. Yeung、「OSPF Link-Local Signaling」、RFC 5613、2009年8月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Key] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IPV6ADD] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IPv6Add] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[OSPFGR] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[Ospfgr] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful Ospf Restart」、RFC 3623、2003年11月。
[OSPFREST] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007.
[Ospfrest] Nguyen、L.、Roy、A。、およびA. Zinin、「OSPF Restart Signaling」、RFC 4812、2007年3月。
[OOB] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link State Database (LSDB) Resynchronization", RFC 4811, March 2007.
[OOB] Nguyen、L.、Roy、A。、およびA. Zinin、「OSPF Out-Band Link State Database（LSDB）再同期」、RFC 4811、2007年3月。
[OLSR] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[OLSR] Clausen、T.、ed。、およびP. Jacquet、ed。、「最適化されたリンク状態ルーティングプロトコル（OLSR）」、RFC 3626、2003年10月。
[WINTF] Ahrenholz J., et al., "OSPFv2 Wireless Interface Type", Work in Progress, May 2004.
[Wintf] Ahrenholz J.、et al。、「Ospfv2 Wireless Interface Type」、Work in Progress、2004年5月。
[MDR] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.
[MDR] Ogier、R。およびP. Spagnolo、「コネクテッドドミネートセット（CD）洪水を使用したOSPFのモバイルアドホックネットワーク（MANET）拡張」、RFC 5614、2009年8月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、S。、「セキュリティペイロード（ESP）のIPカプセル化」、RFC 4303、2005年12月。
[OSPFv3-SEC] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3-SEC] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[脅威] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
Authors' Addresses
著者のアドレス
Abhay Roy (Editor) Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com
Abhay Roy（編集者）Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USAメール：akr@cisco.com
Madhavi W. Chandra (Editor) 113 Holmhurst Court Cary, NC 27519
Madhavi W. Chandra（編集者）113 Holmhurst Court Cary、NC 27519
EMail: mw.chandra@gmail.com