[要約] RFC 7137は、単一ホップブロードキャストネットワークでのOSPF-MANETインターフェースの使用に関するものです。このRFCの目的は、OSPF-MANETインターフェースの機能と利点を説明し、単一ホップブロードキャストネットワークでの使用方法を提案することです。
Internet Engineering Task Force (IETF) A. Retana
Request for Comments: 7137 S. Ratliff
Updates: 5820 Cisco Systems, Inc.
Category: Experimental February 2014
ISSN: 2070-1721
Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks
シングルホップブロードキャストネットワークでのOSPF-MANETインターフェイスの使用
Abstract
概要
This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.
このドキュメントでは、シングルホップブロードキャストネットワークでのOSPF-MANETインターフェイスの使用について説明します。このようなネットワークの存在を動的に判断するメカニズムと、その性質による特定の運用上の考慮事項が含まれています。
This document updates RFC 5820.
このドキュメントはRFC 5820を更新します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7137.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7137で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Single-Hop Network Operation . . . . . . . . . . . . . . . . 4
3.1. Use of Router Priority . . . . . . . . . . . . . . . . . 4
3.2. Unsynchronized Adjacencies . . . . . . . . . . . . . . . 5
4. Single-Hop Network Detection . . . . . . . . . . . . . . . . 6
4.1. Transition from Multi-Hop to Single-Hop Mode . . . . . . 6
4.2. Transition from Single-Hop to Multi-Hop Mode . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
The OSPF-MANET interface [RFC5820] uses the point-to-multipoint adjacency model over a broadcast media to allow the following:
OSPF-MANETインターフェイス[RFC5820]は、ブロードキャストメディア上でポイントツーマルチポイント隣接モデルを使用して、次のことを可能にします。
o All router-to-router connections are treated as if they were point-to-point links.
o すべてのルーター間接続は、ポイントツーポイントリンクであるかのように扱われます。
o The link metric can be set on a per-neighbor basis.
o リンクメトリックは、ネイバーごとに設定できます。
o Broadcast and multicast can be accomplished through the Layer 2 broadcast capabilities of the media.
o ブロードキャストとマルチキャストは、メディアのレイヤー2ブロードキャスト機能を介して実行できます。
It is clear that the characteristics of the MANET interface can also be beneficial in other types of network deployments -- specifically, in single-hop broadcast capable networks that may have a different cost associated with any pair of nodes.
MANETインターフェースの特性は、他のタイプのネットワーク配置、特にノードのペアに関連付けられたコストが異なるシングルホップブロードキャスト対応ネットワークでも有益である可能性があることは明らかです。
This document updates [RFC5820] by describing the use of the MANET interface in single-hop broadcast networks; this consists of its simplified operation by not requiring the use of overlapping relays as well as introducing a new heuristic for smart peering using the Router Priority.
このドキュメントは、シングルホップブロードキャストネットワークでのMANETインターフェイスの使用について説明することにより、[RFC5820]を更新しています。これは、重複するリレーの使用を必要とせず、ルータープライオリティを使用したスマートピアリングの新しいヒューリスティックを導入することで、操作が単純化されています。
The OSPF extensions for MANETs assume the ad hoc formation of a network over bandwidth-constrained wireless links, where packets may traverse several intermediate nodes before reaching their destination (multi-hop paths on the interface). By contrast, a single-hop broadcast network (as considered in this document) is one that is structured in such a way that all the nodes in it are directly connected to each other. An Ethernet interface is a good example of the connectivity model.
MANETのOSPF拡張は、帯域幅に制約のあるワイヤレスリンクを介したネットワークのアドホックな形成を想定しています。この場合、パケットは宛先（インターフェイスのマルチホップパス）に到達する前に複数の中間ノードを通過する可能性があります。対照的に、（このドキュメントで検討されている）シングルホップブロードキャストネットワークは、ネットワーク内のすべてのノードが互いに直接接続されるように構成されたネットワークです。イーサネットインターフェイスは、接続モデルの良い例です。
Furthermore, the single-hop networks considered may have different link metrics associated to the connectivity between a specific pair of neighbors. The OSPF broadcast model [RFC2328] can't accurately describe these differences. A point-to-multipoint description is more appropriate given that each node can reach every other node directly.
さらに、検討されているシングルホップネットワークには、特定のネイバーペア間の接続に関連付けられたリンクメトリックが異なる場合があります。 OSPFブロードキャストモデル[RFC2328]では、これらの違いを正確に説明できません。各ノードが他のすべてのノードに直接到達できることを考えると、ポイントツーマルチポイント記述がより適切です。
In summary, the single-hop broadcast interfaces considered in this document have the following characteristics:
要約すると、このドキュメントで検討されているシングルホップブロードキャストインターフェイスには、次の特性があります。
o direct connectivity between all the nodes
o すべてのノード間の直接接続
o different link metrics that may exist per-neighbor
o ネイバーごとに存在する可能性のあるさまざまなリンクメトリック
o broadcast/multicast capabilities
o ブロードキャスト/マルチキャスト機能
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The operation of the MANET interface doesn't change when implemented on a single-hop broadcast interface. However, the operation of some of the proposed enhancements can be simplified. Explicitly, the Overlapping Relay Discovery Process SHOULD NOT be executed, and the A-bit SHOULD NOT be set by any of the nodes, so that the result is an empty set of Active Overlapping Relays.
MANETインターフェイスの動作は、シングルホップブロードキャストインターフェイスに実装されても変わりません。ただし、提案された拡張機能の一部の操作は簡略化できます。明示的に、オーバーラップリレーディスカバリプロセスは実行されるべきではなく（SHOULD NOT）、Aビットはどのノードによっても設定されるべきではない（SHOULD NOT）ので、結果はアクティブオーバーラップリレーの空のセットになります。
This document describes the use of already defined mechanisms and requires no additional on-the-wire changes.
このドキュメントでは、すでに定義されているメカニズムの使用について説明し、追加の送信中の変更を必要としません。
Smart peering [RFC5820] can be used to reduce the burden of requiring a full mesh of adjacencies. In short, a new adjacency is not required if reachability to the node is already available through the existing shortest path tree (SPT). In general, the reachability is verified on a first-come-first-served basis; i.e., in a typical network, the neighbors with which a FULL adjacency is set up depend on the order of discovery.
スマートピアリング[RFC5820]を使用すると、隣接のフルメッシュを必要とする負担を軽減できます。つまり、既存の最短パスツリー（SPT）を通じてノードへの到達可能性がすでに利用可能な場合、新しい隣接関係は必要ありません。一般に、到達可能性は先着順で検証されます。つまり、一般的なネットワークでは、FULL隣接関係が設定されているネイバーは、検出の順序に依存します。
The state machine for smart peering allows for the definition of heuristics, beyond the SPT reachability, to decide whether or not it considers a new adjacency to be of value. This section describes one such heuristic to be used in Step (3) of the state machine, in place of the original one in Section 3.5.3.2 of [RFC5820].
スマートピアリングのステートマシンでは、SPT到達可能性を超えたヒューリスティックの定義により、新しい隣接が価値があると見なすかどうかを決定できます。このセクションでは、[RFC5820]のセクション3.5.3.2の元のヒューリスティックの代わりに、ステートマシンのステップ（3）で使用されるそのようなヒューリスティックの1つについて説明します。
The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3 [RFC5340]) is used in the election of the (Backup) Designated Router, and can be configured only in broadcast and Non-Broadcast Multi-Access (NBMA) interfaces. The MANET interface is a broadcast interface using the point-to-multipoint adjacency model; this means that no (Backup) Designated Router is elected. For its use with the MANET interface, the Router Priority is defined as:
（OSPFv2 [RFC2328]およびOSPFv3 [RFC5340]で定義されている）ルータプライオリティは、（バックアップ）指定ルータの選択に使用され、ブロードキャストおよび非ブロードキャストマルチアクセス（NBMA）インターフェイスでのみ設定できます。 MANETインターフェイスは、ポイントツーマルチポイント隣接モデルを使用したブロードキャストインターフェイスです。これは、（バックアップ）指定ルーターが選択されないことを意味します。 MANETインターフェースで使用する場合、ルーター優先順位は次のように定義されます。
Router Priority An 8-bit unsigned integer. Used to determine the precedence of which router(s) to establish a FULL adjacency with during the Smart Peering selection process. When more than one router attached to a network is present, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence.
ルーター優先順位8ビットの符号なし整数。スマートピアリング選択プロセス中に完全な隣接関係を確立するルーターの優先順位を決定するために使用されます。ネットワークに接続されているルーターが複数存在する場合は、ルーターの優先順位が最も高いルーターが優先されます。それでも同数の場合は、最も高いルーターIDを持つルーターが優先されます。
The heuristic for the state machine for smart peering is described as:
スマートピアリングのステートマシンのヒューリスティックは次のように説明されます。
(3) |
,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
| ............................ |
| |Determine if the number of| |
| |existing adjacencies is < | |
| |the maximum configured | |
| |value | |
| '`'''''''\'''''''''''''''/'' |
| \ / |
| ................\.........../.............. |
| |Determine if the neighbor has the highest| |
| |(Router Priority, Router ID) combination | |
| ''''''''''''`'''/'''''''\'''''''''''''''''' |
| / \ |
'`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
Smart Peering Algorithm
スマートピアリングアルゴリズム
In order to avoid churn in the selection and establishment of the adjacencies, every router SHOULD wait until the ModeChange timer (Section 4) expires before running the state machine for smart peering. Note that this wait should cause the selection process to consider all the nodes on the link, instead of being triggered based on receiving a Hello message from a potential neighbor. The nodes selected using this process are referred to simply as "smart peers".
隣接関係の選択と確立におけるチャーンを回避するために、すべてのルーターは、ModeChangeタイマー（セクション4）が期限切れになるまで待機してから、スマートピアリングのステートマシンを実行する必要があります。この待機により、選択プロセスは、潜在的なネイバーからのHelloメッセージの受信に基づいてトリガーされるのではなく、リンク上のすべてのノードを考慮する必要があります。このプロセスを使用して選択されたノードは、単に「スマートピア」と呼ばれます。
It is RECOMMENDED that the maximum number of adjacencies be set to 2.
隣接関係の最大数を2に設定することをお勧めします。
An unsynchronized adjacency [RFC5820] is one for which the database synchronization is postponed, but that is announced as FULL because SPT reachability can be proven. A single-hop broadcast network has a connectivity model in which all the nodes are directly connected to each other. This connectivity results in a simplified reachability check through the SPT: the adjacency to a specific peer MUST be advertised as FULL by at least one smart peer.
非同期の隣接[RFC5820]は、データベースの同期が延期されるものですが、SPTの到達可能性を証明できるため、FULLとしてアナウンスされます。シングルホップブロードキャストネットワークには、すべてのノードが互いに直接接続されている接続モデルがあります。この接続により、SPTを介した到達可能性チェックが簡素化されます。特定のピアへの隣接は、少なくとも1つのスマートピアによってFULLとしてアドバタイズされる必要があります。
The single-hop nature of the interface allows then the advertisement of the reachable adjacencies as FULL without additional signaling. Flooding SHOULD be enabled for all the unsynchronized adjacencies to take advantage of the broadcast nature of the media. As a result, all the nodes in the interface will be able to use all the LSAs received.
インターフェイスのシングルホップの性質により、追加のシグナリングなしで到達可能な隣接関係をフルとしてアドバタイズできます。メディアのブロードキャストの性質を利用するには、すべての非同期の隣接でフラッディングを有効にする必要があります（SHOULD）。その結果、インターフェイス内のすべてのノードは、受信したすべてのLSAを使用できます。
A single-hop network is one in which all the nodes are directly connected. Detection of such an interface can be easily done at every node by comparing the speaker's 1-hop neighbors with its 2-hop neighborhood. If for every 1-hop neighbor, the set of 2-hop neighbors contains the whole set of the remaining 1-hop neighbors, then the interface is a single-hop network; this condition is called the Single-Hop Condition.
シングルホップネットワークは、すべてのノードが直接接続されているネットワークです。このようなインターフェイスの検出は、話者の1ホップの近傍と2ホップの近傍を比較することにより、すべてのノードで簡単に行うことができます。すべての1ホップネイバーについて、2ホップネイバーのセットに残りの1ホップネイバーのセット全体が含まれている場合、インターフェイスはシングルホップネットワークです。この状態はシングルホップ状態と呼ばれます。
A new field is introduced in the MANET interface data structure. The name of the field is SingleHop, and it is a flag indicating whether the interface is operating in single-hop mode (as described in Section 3). The SingleHop flag is set when the node meets the Single-Hop Condition on the interface. If the Single-Hop Condition is no longer met, then the SingleHop flag MUST be cleared.
MANETインターフェイスデータ構造に新しいフィールドが導入されました。フィールドの名前はSingleHopであり、インターフェイスがシングルホップモードで動作しているかどうかを示すフラグです（セクション3で説明）。シングルホップフラグは、ノードがインターフェイスのシングルホップ条件を満たしたときに設定されます。シングルホップ条件が満たされなくなった場合は、シングルホップフラグをクリアする必要があります。
A new timer is introduced to guide the transition of the interface from/to multi-hop mode (which is the default mode described in [RFC5820]) to/from single-hop mode:
新しいタイマーが導入されて、マルチホップモード（[RFC5820]で説明されているデフォルトモード）との間のインターフェイスの遷移をシングルホップモードとの間でガイドします。
o ModeChange: Every time a node changes the state of the SingleHop flag for the interface, the corresponding ModeChange timer MUST be set. The ModeChange timer represents the length of time in seconds that an interface SHOULD wait before changing between multi-hop and single-hop modes. It is RECOMMENDED that this timer be set to Wait Time [RFC2328].
o ModeChange：ノードがインターフェースのSingleHopフラグの状態を変更するたびに、対応するModeChangeタイマーを設定する必要があります。 ModeChangeタイマーは、マルチホップモードとシングルホップモードを切り替える前にインターフェイスが待機する時間の長さを秒単位で表します。このタイマーを待機時間[RFC2328]に設定することをお勧めします。
The following sections describe the steps to be taken to transition between interface modes.
次のセクションでは、インターフェイスモード間の移行に必要な手順について説明します。
Detection of the Single-Hop Condition triggers the transition into single-hop mode by setting both the SingleHop flag and the ModeChange timer.
シングルホップ状態が検出されると、シングルホップフラグとModeChangeタイマーの両方が設定され、シングルホップモードへの移行がトリガーされます。
Once the ModeChange timer expires, the heuristic defined in Section 3.1 MAY be executed to optimize the set of adjacencies on the interface. Note that an adjacency MUST NOT transition from FULL to 2-Way unless the simplified reachability check (Section 3.2) can be verified.
ModeChangeタイマーが期限切れになると、セクション3.1で定義されたヒューリスティックを実行して、インターフェース上の隣接関係のセットを最適化できます。簡略化された到達可能性チェック（セクション3.2）を確認できない限り、隣接関係はFULLから2-Wayに遷移してはならないことに注意してください。
Not meeting the Single-Hop Condition triggers the transition into multi-hop mode by clearing the SingleHop flag and setting the ModeChange timer. The A-bit MUST be set if the Single-Hop condition is no longer met because of one of the following cases:
シングルホップ条件を満たさない場合は、シングルホップフラグをクリアしてModeChangeタイマーを設定することにより、マルチホップモードへの移行をトリガーします。次のいずれかの場合にシングルホップ条件が満たされない場合は、Aビットを設定する必要があります。
o an increase in the set of 1-hop neighbors, without the corresponding increase of the 2-hop neighborhood
o 1ホップネイバーのセットの増加、2ホップネイバーの対応する増加なし
o a decrease of the 2-hop neighborhood while maintaining all the previous 1-hop neighbors
o 以前のすべての1ホップネイバーを維持しながら、2ホップネイバーの減少
Once the ModeChange timer expires, the multi-hop operation described in [RFC5820] takes over.
ModeChangeタイマーが切れると、[RFC5820]で説明されているマルチホップ操作が引き継ぎます。
Note that the cases listed above may result in the interface either gaining or losing a node before the ModeChange timer expires. In both cases, the heuristic defined in Section 3.1 MAY be executed to optimize the set of adjacencies on the interface.
上記のケースでは、ModeChangeタイマーが期限切れになる前にインターフェースがノードを取得または失う可能性があることに注意してください。どちらの場合も、セクション3.1で定義されたヒューリスティックを実行して、インターフェイス上の隣接関係のセットを最適化できます。
In the case that a node joins the interface, the Designated Router and Backup Designated Router fields in the Hello packet [RFC2328] MAY be used to inform the new node of the identity (Router ID) of the current smart peers (and avoid the optimization).
ノードがインターフェースに参加する場合、Helloパケット[RFC2328]のDesignated RouterフィールドとBackup Designated Routerフィールドを使用して、現在のスマートピアのID（ルーターID）を新しいノードに通知できます（最適化を回避できます）。 ）。
No new security concerns beyond the ones expressed in [RFC5820] are introduced in this document.
このドキュメントでは、[RFC5820]で表現されているものを超える新しいセキュリティの問題は紹介されていません。
The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia Atlas, Juan Antonio Cordero, Richard Ogier, and Christer Holmberg for their comments.
著者は、アントン・スミルノフ、ジェフリー・チャン、アリア・アトラス、フアン・アントニオ・コルデロ、リチャード・オジエ、およびクリスター・ホルムバーグのコメントに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC5820] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile Ad Hoc Networking", RFC 5820, March 2010.
[RFC5820]ロイA.およびM.チャンドラ、「モバイルアドホックネットワーキングをサポートするためのOSPFの拡張」、RFC 5820、2010年3月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
Authors' Addresses
著者のアドレス
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Alvaro Retana Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709 USA
EMail: aretana@cisco.com
Stan Ratliff Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Stan Ratliff Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709 USA
EMail: sratliff@cisco.com