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
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.
この文書では、モバイル広告のアドホックネットワーク（MANET）をサポートするために、OSPFへの拡張機能について説明します。 OSPF-OR（OSPF-重複リレー）と呼ばれる拡張機能は、リンクローカルシグナリング（LLS）ためのメカニズム、OSPF-MANETインタフェースだけ増分状態変化を送信することによって、Helloパケットのサイズを縮小するための簡単な技術、と含みますルーティングアップデートの最適化された洪水のための方法。 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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
モバイルアドホックネットワーク（MANET）は、様々なワーキンググループやエリア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]と[OSPFv3の]に記載されている）標準プロトコル、OSPFを拡張する動機は2つある。主な理由は、相互運用性のためである - MANETデバイスは、できるだけ多くの場合、有線ネットワークに接続するときに動作できるようにする必要があります。 MANETと有線ネットワークとの間の接続点は、また、必要に応じて、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つ、および他の間に再分配することができるが、これはMANET /有線インターフェースの複雑さとオーバーヘッドを追加し、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.
第二の動機は、OSPFは、よく理解され、広く展開されているルーティングプロトコルであることです。これは動作するから経験やスキルの強固な基盤を提供します。作業にはよく知られているプロトコルではなく、その後完全に、troubleshot試験し、そして数年かけて修正しなければならない新しいプロトコルを開発するよりも、拡張することができます。よく知られたプロトコルでの作業、ゼロからではなく、再構築よりも、開発努力が狭く注目領域に配置されるように、既に動作することが知られている多くのことが可能になります。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
MANET環境で標準[OSPFv3の]展開と課題は二つのカテゴリーに収まります。まず、伝統的なリンクステートルーティングプロトコルは、静的に構成された環境のために設計されています。新しいルータをネットワークに配置されたときにその結果、ほとんどの設定は手動で行われます。従って、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.
課題の第二のカテゴリーは、拡張性を必要とします。 MANETは、到達可能性を維持するために、複数の状態情報を送信しなければなりません。そのため、OSPFは、アドホックネットワークにおけるをサポートするために、スケーラビリティの強化が必要になります。いくつかの洪水の最適化は、指定ルータ（DR）選挙など、OSPFに存在しているが、これらの多くは、真のマルチアクセスネットワークの仮定の下で建設されました。同じレイヤ2リンク上のすべての人の間での双方向の接続性があると仮定することができないため、無線ネットワークは、真のマルチアクセスネットワークではありません。したがって、このようなDRの選出などの最適化は、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ルータについては、潜在的に大きなHelloメッセージの送信は、特に無駄です。
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.
インターフェイスは、ルータとその接続ネットワーク[OSPF]の1つとの間の接続として定義されます。インターフェイス4種類が定義され、[OSPF]と[OSPFv3の]でサポートされている：放送、非放送マルチアクセス（NBMA）、ポイントツーポイントおよびポイントツーマルチポイント。
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放送レイヤをサポートしています。その一例は、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擬似ブロードキャストをサポートしています。その一例は、フレームリレーです。
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 APIは、レイヤ2ブロードキャスト機能を決定するために、レイヤ3のために提供されなければなりません。 MANETブロードキャスト、MANET擬似放送、およびMANET非ブロードキャスト：APIのリターンに基づいて、OSPFは、次の3種類にMANETインタフェースを分類します。
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のノードは、少なくとも一つのMANETインタフェースを有しています。 MANETノードは、MANETインタフェースを介して互いに通信することができます。 MANETノードのみなど、イーサネット、ATM、などの通常のインターフェースを介して非MANETルータと通信することができます。
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.
【のOSPFv3]に記載されているようにOSPFv3のオプションフィールドとDoNotAgeに設定DCビットを有するべきであるMANETインタフェースに関連付けられたリンクステートアドバタイズメント（LSA）はLS年齢フィールドにビットセット。デマンド回線はオプション機能です。したがって、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を表示するために、ネットワークマップは以下が含まれます。ルータ名は文字I.との手紙N、およびルータのインタフェース名で手紙RT、ネットワーク名が付いています
o Four MANET nodes, RT1, RT2, RT3, and RT4, reside in area 2.
Oフォー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は、I11を1つのMANETインタフェースを持っています。インタフェースを介して、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は、二つのMANETインタフェース、I21及びI22、および1つのイーサネットインターフェース、I23を有しています。 RT2はフル隣接インターフェースI21を介しRT1およびRT4に、フル隣接RT4にインターフェースI22を介してです。スタブネットワークN1は、インターフェースI23を通じてRT2が取り付けられています。
o RT3 has one MANET interface, I31, and is full-adjacent to RT1 through the interface.
O RT3一の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は、二つのMANETインタフェース、I41及びI42を有しています。これは、インタフェースI41を通してフル隣接RT2にある、フル隣接RT1とRT2のインターフェースI42を介し。
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は[IPV6ADD]変形EUI-64フォーマットで、インターフェース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ポイントツーポイントリンクから成る二つMANETインタフェースは、提示されています。
RT2's router-LSA
RT2のルータ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
LS年齢= DoNotAge + 0;新しく始まっLSタイプ= 0x2001;ルータLSAリンクステートID = 0;最初のフラグメント広告ルータ= 192.0.2.2; RT2のルータIDビットE = 0;ないAS境界ルータビットB = 0;ないエリアボーダルータオプション=（V6ビット| Eビット| Rビット）TYPE = 1; I21メトリック= 10上RT1にP2Pリンク、RT1インタフェースID = 2のコスト; I21ネイバーインタフェースIDのインタフェースID = 2; I11近隣ルータID = 192.0.2.1のインタフェースID、RT1のルータIDタイプ= 1; I21メトリック= 25以上RT4にP2Pリンク、RT4インタフェースID = 2のコスト; I21ネイバーインタフェースID = 3のインタフェースID、インタフェースI42近隣ルータID = 192.0.2.4のID、RT4のルータIDタイプ= 1; I22メトリック= 15上RT4にP2Pリンク、RT4インタフェースID = 3のコスト; I22ネイバーインタフェースID = 2のインタフェースID、I41のインタフェースIDネイバールータID = 192.0.2.4; RT4のルータ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を発信します。例として、リンクLSA RT3は、そのMANETインタフェースI31用にビルドすることを検討してください。
RT3's link-LSA for MANET interface I31
RT3のリンクLSA MANETインタフェースI31について
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
LS年齢= DoNotAge + 0;新しく始まっLSタイプ= 0x0008で、リンクLSAリンクステートID = 2; I31広告ルータ= 192.0.2.3のインターフェイスID; RT3のルータID Rtrとぷり= 1;デフォルトの優先オプション=（V6ビット| E-ビット| R-ビット）リンクローカルインタフェースアドレス= FE80：0002 :: EUI31＃接頭辞= 0;なしグローバルユニキャストアドレス
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が構築することを、エリア内プレフィックス-LSAを考えます。
RT2's intra-area-prefix-LSA for its own prefixes
独自のプレフィックスのRT2のエリア内プレフィックス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時代= DoNotAge + 0;新しく始まっLSタイプ= 0x2009;エリア内プレフィックス-LSAリンクステートID = 177;または何か他の広告ルータ= 192.0.2.2; RT2のルータID番号の接頭辞= 2参考LSタイプ= 0x2001;ルータLSAの参照はリンクステートID = 0を参考に、常に0ルータLSAのために、参照対象広告ルータ= 192.0.2.2; RT2のルータID PrefixLength = 64; RT2のループバックPrefixOptionsの接頭辞= 0メートル= 0; RT2のループバックアドレスのコスト接頭辞= 2001：DB8：0002 :: PrefixLength = 60; I23 PrefixOptionsの接頭辞= 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を発信してもよいです。これは、MANETインタフェースとは無関係である、（[OSPFv3の]で定義された）通常の動作です。詳細については、[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.
アドホックネットワークにおけるにおいて、定期的に送信されるパケットのサイズを小さくするルーティングに関連するオーバーヘッドの総量を減少させる上で非常に重要であり得ます。このために、Helloパケットからネイバーのリストを削除し、その情報が変更されない限り、ルーティングプロトコルのオーバーヘッドを減らすことができます。各Helloパケットのための削減は小さいですが、時間をかけてそれが重要になります。
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].
新しいオプションビットは、増分Helloパケットの操作を容易にするために、このドキュメントで定義されています。新しい状態のチェックシーケンス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の拡張オプションとフラグフィールドで定義されています。ビットは、Helloパケットのために定義されたとだけ増分情報が存在することを示しています。 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値が第1インクリメンタルHelloパケットに使用されるべきであることに注意してください。このシーケンス番号は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.
R O：要求ビット。設定した場合、これは、現在の状態の要求です。この要求に応答すべきルータのリストは、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）の完全な状態で隣人（s）が懸念しているとして、完全な状態が含まれています。 FSF TLVが存在しない場合、Helloパケットは、すべてのネイバーの完全な状態が含まれています。
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パケットに含まれています。セットした場合、これは追加のTLVは「永続的」送信され、最初に送信されましたが、このHelloパケットに含まれていないSCS番号に関連付けられている多くの状態があることをされていることを示しています。このビットは、送信すべきSCS番号に関連付けられているのTLVの全てを必要とすることなく、同じSCS番号で「永続的」ハローズの数のために送信されるように、任意の所望のTLVを可能にします。 SCS番号が送信されて初めて、そのSCS番号に関連付けられた全体の状態が送信され、Nビットがセットされてはいけません。
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ビットがセットされたハローはハローリクエストと呼ぶことにします。
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長さ：ドロップされた隣人の数を設定し、4を乗じたTLVに含まれています。
o Dropped Neighbor(s) - Router ID of the neighbor being dropped.
Oドロップネイバー（S） - 近隣のルータIDは破棄されます。
A new TLV is defined in this document that indicates neighbor(s) from which the latest Hello state is being requested.
新しいTLVは、最新のHello状態が要求されているから、隣人（複数可）を示し、この文書で定義されています。
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の長さ：4を乗じたTLVに含ま隣人の数に設定してください。
o Request From Neighbor(s) - Router ID of the neighbor(s) from which Hello state is being requested.
こんにちは状態が要求されているから、隣人（S）のルータID - 近隣（複数可）からO要求。
A new TLV is defined in this document that indicates neighbor(s) to which the transmitting node is responding with full state.
新しいTLVは、送信ノードが完全な状態で応答された隣接（S）を示し、この文書で定義されています。
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の長さ：4を乗じたTLVに含ま隣人の数に設定してください。
o Full State For Neighbor(s) - Router ID of the neighbor(s) should process this packet.
Oフル状態は、隣人のために（S） - 隣人（S）のルータ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ビットを設定する必要があります。こんにちは、パケットは他のパケットの送信がその時にルータによって送信された場合、すべての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:
新しい隣人からHelloパケットを受信する（セクションで定義されるように、この文脈では、新しい隣人はInitステート未満で隣人がある10.1 [OSPF]）、こんにちは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 TLVに示されている）で使用するルータのSCS番号をインクリメントします。
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（[OSPF]、10.1節に記載したように）隣人が交換状態に達したとき、[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ネイバーがOSPF放送リンク上でDRまたはバックアップ指定ルータ（BDR）でない場合、[OSPFv3の]に記載のネイバーリスト、付録A.3.2からネイバーを削除し、ネットワークに接続されているように隣人がアドバタイズされた場合DRによってアドバタイズ-lsa。
On discovering an adjacency failure (going to state less than Exchange), a router using I-bit signaling SHOULD:
隣接の障害を発見するには、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.
このネイバードロップTLVとO送信ハローズ。受信の確率を高めるために3つの連続したhelloメッセージで近隣ドロップTLVを送信することが望ましい場合があります。この場合は、「永続的な」Helloパケットは、同じSCS番号、近隣ドロップ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.
デバイスが最初に（かどうかなど、デバイスの無線インタフェースを有効にする、上のデバイスに電力を供給する、別の装置の範囲内に持ち込まれることによって）ネットワークに接続されている場合、それは前にその近隣の各々からの完全な隣接状態を取得する必要がありますインクリメンタルこんにちはメカニズムを利用することができます。このように、初期化時に、デバイスは、マルチキャストのHello要求を送信（およびTLVからの要求を省略）してもよい（MAY）。隣人は要求を受信し、その完全な隣人状態でこんにちはで応答します。
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番号の最初のHelloパケットは、SCSの番号、最後SCS番号ので、すなわち、すべての状態の変化に関連する完全な状態を含まなければなりません。 Nビットは、ステート・チェック・シーケンス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:
増分Helloパケットは、送信される情報の実際の量の柔軟性と、（K連続Helloパケットで送信される）永続的に送信することができます。 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全体の増分Helloパケットが持続的に送信されます。これは、単にk個の連続ハローズのためのSCS番号に関連する全体の状態を送信することによって達成されます。 SCS番号は同じままであるので、Nビットは、これらの増分のHelloパケットに設定されていません。
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番号の最初のHelloパケットが送信された後、持続的に送信されることが望まれている唯一のTLVは、同じSCS番号とNビットのセットと後続のハローズで送信されます。
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番号の増分Helloパケットは一度だけ送信されるデフォルトの動作です。
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デバイスは、この文書に記載されているように、それは限りネイバー隣接構造が維持されるからhelloを受信した各ネイバーから最後の既知の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）があり、それは、デバイスが近隣へのHello要求を送らなければなりません、ラップアラウンドされていない場合、新しい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のナンバーワンと隣接するネイバーからのHelloを受信した場合、それがなければならない場合
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.
セクション3.2.6.2で説明したように、O隣人ドロップ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.
セクション3.2.6.2で説明したように、O隣人ドロップ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こんにちは、次こんにちは（「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を受信した場合、それはいくつかの隣人状態を失われる可能性があるため、それが隣人に挨拶要求を送らなければなりません。
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.
デバイスは、SCS TLVでのHelloを受信含まれており、Nビットは、このTLVに設定されている場合、それは隣人から設定しないNビットでSCS数をすでに受信していることを確かめなければなりません。デバイスは、これがこのネイバーからSCS番号の最初の領収書であると判断した場合、それがSCS番号の最初のHelloパケットを逃したので、状態が欠落しているので、それは、隣人への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を持つこんにちは含まれており、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.
【のOSPFv3]に記載のネイバーリストの要求隣人（S）、付録A.3.2のネイバーID O。
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.
送信機の現在のSCS番号とFSビットが設定されたSCS TLV O。トランスミッタの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.
FSF TLVで、現在の状態を要求したすべてのネイバーのネイバーID O。
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パケットは、デバイスのために隣人の完全な状態が含まれています。受信されたSCS番号が最後の既知のSCSの数に等しい場合、デバイスが既に最新の状態情報を有しているので、パケットは、無視されるべき（O）パケットは、以下のように処理されるべきです。
o If the received SCS number is different than the last known SCS number, this Hello has new information and MUST be parsed.
受信SCS番号が最後の既知のSCS番号と異なる場合は、O、これこんにちは、新たな情報を持っており、解析する必要があります。
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が存在しない場合、デバイスは、セクション3.2.8に記載したようにSCS番号、プロセスハローを保存し、他の添付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ビットが設定されていない新しい隣人からHelloパケットを受信すると、ローカルルータは、[OSPFv3の]、付録A.3.2で説明したように、このリンク上で送信されるhelloメッセージにそのルータの識別子を配置していきます。
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に記載ネイバーのリストにおける近隣の欠如に依存して、および他へのシグナリング隣接関係が取り壊されるべきではないことを決定。特定のルータによって送信されたすべてのHelloパケットが空のHelloリストを持っている場合は、再起動を通知する（または確実OSPFの隣接関係を取り壊すために）空のHelloパケットに頼ることはもはや不可能です。従って、このシグナリングがわずかに変更されなければなりません。ときルータは、すべての隣接関係を取り壊すか、それが再起動したことを知らせるしたいと思います。
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ビットでHelloパケットを送信します。任意の通常の再起動または他のシグナル伝達は、これらの最初のHelloパケットに含まれていてもよいです。
o As adjacencies are learned, these newly learned adjacent routers are included in the multicast Hellos transmitted on the link.
隣接関係が学習されているOとして、これらの新たに学習隣接ルータは、リンク上で送信されたマルチキャストhelloメッセージに含まれています。
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.
1 RouterDeadIntervalが経過した後は、O、インクリメンタルこんにちは機構が呼び出されます。満杯状態に増分HelloパケットがIビットセットで送信され、SCS TLVは、FSビットのセット、およびInitialSCS値（「1」の例えば、SCS）に含まれています。後続のHelloパケットは、増分のみの状態が含まれます。
Routers that are neighboring with a restarting router MUST continue sending their Hello packets with the I-bit set.
再起動するルータと隣接しているルータは、Iビットのセットで彼らのHelloパケットの送信を継続しなければなりません。
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の]）のスケーラビリティと収束特性に影響を与え得る要素は、情報をフラッディングする必要がどのくらいです。理想的なソリューションでは、ルータが一度だけ特定のルーティングアップデートを受信することです。しかし、プロトコルの複雑さと、ネットワーク内のすべてのスピーカーはすべての情報を受け取ることを確実にすることの間にはトレードオフが存在する必要があります。スピーカは、ルーティングプロトコルを実行し、ルーティングアップデートとHelloメッセージを送信しているネットワーク内の任意のノードを指すことに留意されたいです。
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では、この機能は、リンクステートアドバタイズメント（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
地元のスピーカーは、セクション3.3.8に概説されたアルゴリズムに基づいて、送信者の非重複隣人へのルーティング情報を中継する必要があります。以上のようにスピーカーが存在する可能性があるため、
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.
メカニズムは、「オーバーラップリレー」と呼ばれています。このアルゴリズムは、しかし、最初に送信しなければならないの重複リレーのセットを選択しません。このセットは、スピーカー用のリレーの重複のアクティブセットとして知られています。
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.
プロセスの最初のステップは、ルータ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.
各スピーカーは、選択アルゴリズムに基づいてアクティブ重複リレーのセットを選択すべきである（そのようなアルゴリズムは、セクション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.
隣人が2-到達するための唯一の隣人である場合を除き、3.3.6項で定義されるように、その隣人がそのアクティブ重複リレーTLVにNビットを設定した場合、スピーカーがアクティブ重複リレーとして機能するように隣人を選択してはならないことに注意してください隣人をホップ。
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 FULL：[OSPF]と[OSPFv3の]で定義されるようにFULL隣人状態。このドキュメントのすべての隣接参照がFULL隣人であると想定されていることに注意してください。
o N: N is the set of FULL neighbors of the node.
O N：NはノードのFULL隣人のセットです。
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ホップ隣人FULL（N2）：FULLであり、それは任意の直接接続されたネイバーを除いて、直接隣人から到達可能なノードの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ホップネイバーFULLが到達可能であるように選択された近隣の（サブ）セット。
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）：（YはNのメンバーである）1ホップ隣接ノードyの程度は、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.
セクション3.3.6で定義されるように、それらの活性重複リレーTLV（TLV AOR）におけるAビットが設定されているNのすべてのメンバーからなるアクティブセットと1.。
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におけるノードBがNでノードAに対称リンクを介してのみ到達できる場合、すなわちN2、ノードへの到達可能性を提供するために、*のみ*ノードであるNでそれらのノードを追加アクティブセットにノードaを追加します。現在アクティブセット内のノードによってカバーされるN2からノードを削除します。
4. While there exist nodes in N2 that are not covered by at least one node in the active set:
前記アクティブセットに少なくとも1つのノードによって覆われていないN2のノードが存在するが：
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つのノードによって覆われていないN2内のノードの数は、この1ホップネイバーを介して到達可能です。
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.選択アクティブ重複リレーなどの非ゼロ到達可能性のあるN個のノードの中で最高のプレイ値（セクション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.
意思額の値の昇順に、アクティブセット内の最適化、プロセスの各ノード、Yとしては、5。 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ビットは、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].
各スピーカーは、HelloメッセージのActive重複リレーのセットを伝えることができるように、新しいTLVが定義されています。 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の長さ - 変数。タイプと長さを含むバイト、NOTで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ビット - このビットが設定されている場合、ノードは、常に、それがアクティブな重複中継として選択されているかどうかにかかわらず、受信したルーティングアップデートをフラッディングすることを指定されています。
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ビット - このビットが設定されている場合、ノードは、それが最も可能性の高いルーティングアップデートをあふれないことを指定しています。それは2ホップの隣人（複数可）に達することができる*だけ*隣人でない限り、ノードは、Active重複リレーするように選択されるべきではありません。ノードがアクティブ重複中継器として選択されなかったかのように同じ動作になるため、ノードがアクティブ重複中継として選択されたノードは、必要な職務を行うことができないならば、ネットワーク動作が損なわれないことに留意されたいです。
o Reserved - Reserved for future use. MUST be set to zero by the sender, and MUST be ignored upon receipt.
O Reserved - 今後の使用のために予約されています。送信者によってゼロに設定しなければならなくて、受信時に無視しなければなりません。
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） - のいずれかでアクティブ重複リレーとして機能するように選択又はアクティブ重複リレーとして機能から除去される隣接（S）のルータID（複数可）。追加されているアクティブな重複リレーは、最初にリストされなければならない、そのようなリレーの数は、長さを追加等しくなければなりません。列挙された残りのリレーがアクティブ重複リレーとして廃棄され、そしてそのようなリレーの数は、[（長さ - 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ビットのアクティブ重複リレーのセットを決定するために、任意の特定の選択アルゴリズムとは無関係であることに留意されたいです。しかし、ビットが選択アルゴリズムへの入力として考慮されるべきです。
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.
ノードがActive重複リレーとして選択され、それは、セクション3.2で定義されたインクリメンタルこんにちはメカニズムをサポートしていない場合、それは常にTLVで活躍重複リレーとして含まれるべきです。ノードがアクティブ重複リレーであるかどうかを知る必要がありながら、それは必ずしも他のActive重複リレーのアイデンティティを知っている必要はないことに注意してください。
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].
各スピーカーは、HelloメッセージでActive重複リレーとして機能する意思を伝えることができるように、新しいTLVが定義されています。 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のプレイ - その隣人のためのActive重複リレーとして機能するノードの意欲を示すために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パケットに含まれていない場合は、意欲値は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を参照してくださいPushbackIntervalプラスジッタ）指定された時間を待たなければなりません。 【ジッタは、冗長な情報を伝播するいくつかの非アクティブ重複リレーを回避しようとするために使用される。]、それがない限り、「アクティブ重複リレー」伸長に設定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プラスジッタの満了時に伝えなければなりません。
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プラスジッタタイマーをリセットする必要があります。 （実装はアクティブ重複リレーからの送信に基づいてPushbackIntervalタイマーをリセットしないように注意する必要があることに注意してください。）この間、ノードが更新をフラッディングするだけ冗長伝送につながると判断した場合、ノードは、その送信を抑制しなければなりません。それ以外の場合は、PushbackIntervalプラスジッタの満了時に伝えなければなりません。
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].
非アクティブ重複リレーは、この期間中にLSAの古いインスタンスを聞く場合C.は、それがLSAを無視すべきである、と[OSPFv3の]で指定されているように、最新の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.
発信者によってため再送ユニキャストを受信したLSA 3.、ノードは、既に他のスピーカから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.
ノードはさらに、LSAをフラッディングするだけ既にその近傍のすべてのLSAのために聞いたリンク状態肯定応答（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の送信に関連するこれらの推奨事項に従う必要があります。
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は、単一のパケットにバンドルされるかもしれません。そのようなパケットを送信する前に待機（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をリセットする必要があります。何の状態が送信者にHelloパケットで送信されるのを待っているが存在しない場合は、送信者のHelloIntervalのをリセットする必要があります。 ACKが無い状態変化にHelloパケットとしての役割を果たすことに注意してください。
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をフラッディングする前に待機する秒単位の時間の長さ。このタイマは、すなわち、（PushbackInterval +伝搬遅延）<RxmtInterval / 2、RxmtInterval（[OSPF]、[OSPFv3の]）マイナス伝播遅延の1/2未満でなければなりません。 PushbackIntervalは、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は、ノードが応答パケットで多くのACKを送信するために待つべき秒単位の時間の長さです。この待機は、複数のLSAを認めるに必要なパケット送信の数を減らすことができます。 AckIntervalはPushbackIntervalマイナス伝搬遅延、すなわち、（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は、洪水のドメイン内のすべてのノードは、ルーティング情報のすべてを受信することを前提に動作します。重要な特性の一つを中継するとき、ルーティング情報が変更されないことであることに留意されたいです。
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ビットが設定されていない新しい隣人からHelloパケットを受信すると、ローカルルータは、[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ビットがセットされ、隣人のHelloに設定されていない、セクション3.2で定義されたI-ビットとして、そして隣人は、ローカルルータによって重複リレーとして選択されている場合は、ローカルルータはで隣人の識別子を含めるしていきますそのアクティブリレーセット。
Two new option bits are defined in the "LLS Type 1 Extended Options and Flags" Field [LLS] as follows:
次のように二つの新しいオプションビットが「LLSタイプ1の拡張オプションとフラグ」フィールド[LLS]で定義されています。
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ビットは、この文書で指定されたノードは、最適化されたフラッディングメカニズムをサポートしていることを示しています。
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は】）、ノードは、最初にそれらの間に双方向の接続性を検証した後、それらのリンクステートデータベースを同期させることによって隣接を確立します。ピアリング関係が完了し、隣接関係が確立されると、ノードはその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:
FULL隣接の形成が発見（2ウェイの関係）とデータベースの同期を必要とします。 FULL状態を達成防ぐために、他のものは、（代わりにデータベース交換の）定期的な広告を使用するリンクステートプロトコルを修正するアプローチをとっています。結果は、近隣探索が依然として必要ですが、ルーティング情報は、時間をかけて学習されていることです。このアプローチの例は次のとおりです。
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ウェイを越えてすべての隣接状態に達していない、およびNOデータベース同期は実行されません」。
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で知られているか、到達不可能であるのいずれかでない場合*、我々は、Exchangeプロセスを開始します。
* 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ウェイのままなので、私たちは、コントロールプレーン（データベースの同期や洪水）のオーバーヘッドが発生しません。しかし、ルータ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.
隣人がSPTに到達可能である場合には、O 2 - WayReceivedのイベントの後、確認してください。もしそうであれば、リンク広告に関してFULLとして隣人をマーク。
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のリンクは隣人がFULLであるかのように宣伝されていることを意味します。
o The adjacency information is constructed with the U-bit (see below).
隣接情報は、Uビットで構成されているO（下記参照）。
o Database synchronization is postponed:
Oデータベースの同期が延期されています。
* By a configured amount of time -OR-
*設定時間によって-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],
データベースの同期は現在保留中であればいずれの場合も、それは、すぐに私たちは隣人がSPTにもはや到達可能であることを検出しないように開始されます。データベースの同期は、帯域外同期[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.
これは、現在の隣接関係を維持し、バックグラウンドで同期を行います。通常の再同期が交互に隣接フラップの欠点を用いて行うことができます。
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からの結果は、非同期隣接関係の任意の数の到達可能性の条件を満足するために使用することができます。これは基本的に私たちが実際に通常のFULL隣接し、この新しい非同期隣接の違いを伝えることができることが必要です。我々は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ビットがセットされたすべてのリンクを無視することによってONE追加のSPFを実行する必要があります。このSPTは、その後私たちの非同期隣接関係のいずれかがデータベースの同期を開始する必要があるかどうかを確認するために参照されます。新しい隣人たちはすぐに隣接関係を形成するか、後でそれを延期すべきかどうかを判断するには、2ウェイの状態になったときに、このSPTも参照されます。
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.
データベースの同期を遅らせるしようとしているの主な目標の一つは、これらのリンクを通過する不要な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からgleans 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.
MANETでは、セキュリティが原因メディアの無線性質のために、両方のより困難かつ重要です。レイヤ2でMANETに接続するデバイスの能力を制御することは2つのセキュリティなどの802.1xなどのメカニズム、などが層に追いやられます。トラフィックを送信するために接続されたデバイスの能力を制御することにより、認証、およびルーティングドメインの個々のメンバーのための承認を提供することができます（このドキュメントの範囲外）セキュリティシステムのいくつかの種類が必要になります。
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]を使用することができます。 OSPFv3のための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の拡張は、新たなセキュリティの脅威を導入していません。しかし、無線媒体とMANETルータに固有のインフラの欠如、の使用は、[脅威]マウントが簡単に説明された攻撃の一部をレンダリングすることがあります。ネットワークの状況に応じて、これらの増加の脆弱性は、認証、整合性、および/または機密性だけでなく、アンチリプレイサービスを提供する必要性を増大させることができます。
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.
同様に、干渉攻撃も、ワイヤレス性質に起因MANETルータに対してマウントするのが容易です。このような攻撃は、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ルータとも容易である：スプーフィング（正当なルータのアイデンティティを想定）、改ざん（偽ルーティング情報を送信すること）、及び（送信またはルーティングアップデートの過剰量をトリガ）過負荷します。認証が使用されていない場合、これらの攻撃は可能であり、または攻撃者は、ルータの制御を取るか（暗号鍵を発見することで、例えば）正当性を偽造することができます。
[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ルータの場合、これは同じ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]で議論するように、手動キーの使用は、脆弱性を増加させることができます。例えば、手動キーは通常長いので、攻撃者に鍵を発見するために多くの時間を与えて、住んでいます。ルータのいずれかが侵害された場合に加えて、同じMANETに接続されているすべてのルータで同じキーを使用すると、なりすまし攻撃に対する安全でないすべてのルータを残します。
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の実装は手動でキー入力されたSAと一緒にアンチリプレイサービスを提供すべきではない[AH]と[ESP]状態が、送信元のシーケンス番号カウンタである場合、そのようなサービスが許可されていることに留意することが重要ですキーが交換されるまで、正しくローカル再起動しても維持。 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ルーティングドメインがアドホックネットワークにおける固定ネットワークの両方を含む場合、実際のトポロジーの変更や不正行為によるOSPF更新の頻度のいずれかが、固定ネットワークに不安定になる可能性があります。これが懸念される状況では、境界ルータがOSPFインスタンスを分離し、レガシールータが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:
「LLSタイプ1の拡張オプションとフラグ」レジストリからO 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:
「リンクローカルシグナリングTLV識別子（LLSタイプ）」レジストリから新しいTLVタイプは以下に定義するように、O：
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.
セクション3.5.4.1で定義されているO新しいレジストリは、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
フレッド・ベイカーデイブ・クックシスコシステムズ、シスコシステムズ1121ヴィアデル・レイ7025から4キットクリーク道路サンタバーバラ、CA 93117リサーチトライアングルパーク、NC 27709 USA USA Eメール：fred@cisco.com Eメール：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
アルバロRetana李ヤンシスコシステムズ、シスコシステムズ7025から4キットクリーク道路7025から4キットクリーク道路リサーチトライアングルパーク、NC 27709リサーチトライアングルパーク、NC 27709 USA USA Eメール：aretana@cisco.com Eメール：yiya@cisco.com
Russ White Cisco Systems 7025-4 Kit Creek Road Research Triangle Park, NC 27709 USA EMail: riw@cisco.com
ラスホワイトシスコシステムズ7025から4キットクリーク道路リサーチトライアングルパーク、NC 27709 USA Eメール：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とスタンRatliffに感謝したいと思います。最終審査を行うためのリチャード・オジェとジョン・エイブリーに感謝します。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]モイ、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.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、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]ジニン、A.、ロイ、A.、グエン、L.、フリードマン、B.、およびD.ヨン、 "OSPFリンクローカルシグナリング"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[OSPFGR] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
【OSPFGR】モイ、J.、Pillay-Esnault、P.、およびA. Lindem、 "優雅なOSPF再起動"、RFC 3623、2003年11月。
[OSPFREST] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007.
[OSPFREST]グエン、L.、ロイ、A.、およびA.ジニン、 "OSPFの再起動シグナリング"、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]グエン、L.、ロイ、A.、およびA.ジニン、 "OSPFアウトオブバンドリンクステートデータベース（LSDB）再同期"、RFC 4811、2007年3月。
[OLSR] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[OLSR]クラウゼン、T.、エド。、およびP.ジャケ、エド。、 "最適化されたリンクステートルーティングプロトコル（OLSR）"、RFC 3626、2003年10月。
[WINTF] Ahrenholz J., et al., "OSPFv2 Wireless Interface Type", Work in Progress, May 2004.
【WINTF] Ahrenholz J.、ら、 "OSPFv2の無線インタフェースタイプ"、進歩、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]オジェ、R.とP. Spagnolo、 "OSPFのモバイルアドホックネットワーク（MANET）拡張子が接続されて使用して支配集合（CDS）フラッディング"、RFC 5614、2009年8月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[OSPFv3-SEC] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFv3の-SEC]グプタ、M.およびN.メラム、 "OSPFv3のための認証/機密性"、RFC 4552、2006年6月。
[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[脅威] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年10月。
Authors' Addresses
著者のアドレス
Abhay Roy (Editor) Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com
アブヘイロイ（編集）シスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134 USA電子メール：akr@cisco.com
Madhavi W. Chandra (Editor) 113 Holmhurst Court Cary, NC 27519
マダビW.チャンドラ（編集）113 Holmhurst裁判所カリー、NC 27519
EMail: mw.chandra@gmail.com
メールアドレス：mw.chandra@gmail.com