[要約] RFC 7038は、単一ホップブロードキャストネットワークでのOSPF-MDRの使用に関するガイドラインです。このRFCの目的は、OSPF-MDRの適切な使用方法を提供し、ネットワークのパフォーマンスと信頼性を向上させることです。
Internet Engineering Task Force (IETF) R. Ogier
Request for Comments: 7038 SRI International
Updates: 5614 October 2013
Category: Experimental
ISSN: 2070-1721
Use of OSPF-MDR in Single-Hop Broadcast Networks
シングルホップブロードキャストネットワークでのOSPF-MDRの使用
Abstract
概要
RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.
RFC 5614（OSPF-MDR）は、タイプMANETの新しいOSPFインターフェースでの操作を指定することにより、OSPFを拡張してモバイルアドホックネットワーク（MANET）をサポートします。このドキュメントでは、シングルホップブロードキャストネットワークでのOSPF-MDR（MANET指定ルーター）の使用について説明します。これは、各ルーターが他のルーターの（1ホップ）ネイバーであるMANETの特殊なケースです。 OSPFブロードキャストインターフェイスとは異なり、そのようなインターフェイスは、各ネイバーに関連付けられた異なるコストを持つことができます。このドキュメントには、シングルホップブロードキャストネットワークで使用できる構成の推奨事項と簡略化されたメカニズムが含まれています。
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/rfc7038.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7038で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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に記載されているように保証なしで提供されます。
OSPF-MDR [RFC5614] specifies an extension of OSPF [RFC2328, RFC5340] to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. OSPF-MDR generalizes the Designated Router (DR) to a connected dominating set (CDS) consisting of a typically small subset of routers called MANET Designated Routers (MDRs). Similarly, the Backup Designated Router (BDR) is generalized to a subset of routers called Backup MDRs (BMDRs). MDRs achieve scalability in MANETs similar to the way DRs achieve scalability in broadcast networks:
OSPF-MDR [RFC5614]は、タイプMANETの新しいOSPFインターフェイスでの動作を指定することにより、モバイルアドホックネットワーク（MANET）をサポートするためのOSPF [RFC2328、RFC5340]の拡張を指定します。 OSPF-MDRは、代表ルーター（DR）を、MANET指定ルーター（MDR）と呼ばれるルーターの通常小さなサブセットで構成される接続された支配セット（CDS）に一般化します。同様に、バックアップ指定ルーター（BDR）は、バックアップMDR（BMDR）と呼ばれるルーターのサブセットに一般化されています。 MDRは、DRがブロードキャストネットワークでスケーラビリティを実現するのと同様に、MANETでスケーラビリティを実現します。
o MDRs have primary responsibility for flooding the Link State Advertisements (LSAs). Backup MDRs provide backup flooding when MDRs temporarily fail.
o MDRは、リンクステートアドバタイズメント（LSA）をフラッディングする主な責任があります。バックアップMDRは、MDRが一時的に失敗したときにバックアップフラッディングを提供します。
o MDRs allow the number of adjacencies to be dramatically reduced by requiring adjacencies to be formed only between MDR/BMDR routers and their neighbors.
o MDRを使用すると、隣接関係をMDR / BMDRルーターとその隣接ルーター間でのみ形成する必要があるため、隣接関係の数を大幅に減らすことができます。
In addition, OSPF-MDR has the following features:
さらに、OSPF-MDRには次の機能があります。
o MDRs and BMDRs are elected based on information obtained from modified Hello packets received from neighbors.
o MDRとBMDRは、ネイバーから受信した変更されたHelloパケットから取得した情報に基づいて選択されます。
o If adjacency reduction is used (the default), adjacencies are formed between MDRs so as to form a connected subgraph. An option (AdjConnectivity = 2) allows for additional adjacencies to be formed between MDRs/BMDRs to produce a biconnected subgraph.
o 隣接削減が使用される場合（デフォルト）、接続されたサブグラフを形成するために、MDR間で隣接が形成されます。オプション（AdjConnectivity = 2）により、MDR / BMDR間に追加の隣接関係を形成して、バイコネクトされたサブグラフを作成できます。
o Each non-MDR router becomes adjacent with an MDR called its Parent, and optionally (if AdjConnectivity = 2) becomes adjacent with another MDR or BMDR called its Backup Parent.
o 各非MDRルーターは、その親と呼ばれるMDRと隣接し、オプションで（AdjConnectivity = 2の場合）、そのバックアップ親と呼ばれる別のMDRまたはBMDRと隣接します。
o Each router advertises connections to its neighbor routers as point-to-point links in its router-LSA. Network-LSAs are not used.
o 各ルーターは、ルーターLSA内のポイントツーポイントリンクとして隣接ルーターへの接続をアドバタイズします。ネットワークLSAは使用されません。
o In addition to full-topology LSAs, partial-topology LSAs may be used to reduce the size of router-LSAs. Such LSAs are formatted as standard LSAs, but advertise links to only a subset of neighbors.
o 完全トポロジーLSAに加えて、部分トポロジーLSAを使用してルーターLSAのサイズを削減できます。そのようなLSAは標準LSAとしてフォーマットされますが、ネイバーのサブセットのみにリンクをアドバタイズします。
o Optionally, differential Hellos can be used, which reduce overhead by reporting only changes in neighbor states.
o 必要に応じて、差分Helloを使用できます。これにより、ネイバーの状態の変化のみを報告することでオーバーヘッドを削減できます。
This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. An understanding of [RFC5614] is assumed. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. An example use case is when the underlying radio system performs layer-2 routing but has a different number of (layer-2) hops to (layer-3) neighbors.
このドキュメントでは、シングルホップブロードキャストネットワークでのOSPF-MDRの使用について説明します。これは、各ルーターが他のルーターの（1ホップ）ネイバーであるMANETの特殊なケースです。 [RFC5614]を理解していることを前提としています。 OSPFブロードキャストインターフェイスとは異なり、そのようなインターフェイスは、各ネイバーに関連付けられた異なるコストを持つことができます。使用例の1つは、基盤となる無線システムがレイヤ2ルーティングを実行するが、（レイヤ3）ネイバーへの（レイヤ2）ホップの数が異なる場合です。
The rationale for using this interface type for single-hop broadcast networks, instead of a broadcast interface type, is to represent the underlying network in a point-to-multipoint manner, allowing each router to advertise different costs to different neighbors in its router-LSA. In this sense, this document shows how the OSPF-MDR interface type can be configured (and simplified if desired) to achieve the same goals as the OSPF Hybrid Broadcast and Point-to-Multipoint interface type [RFC6845].
ブロードキャストインターフェイスタイプの代わりに、シングルホップブロードキャストネットワークにこのインターフェイスタイプを使用する根拠は、ポイントツーマルチポイントの方法で基礎となるネットワークを表すことであり、これにより、各ルーターはルーター内の異なるネイバーに異なるコストを通知できます。 LSA。この意味で、このドキュメントでは、OSPFハイブリッドブロードキャストおよびポイントツーマルチポイントインターフェイスタイプ[RFC6845]と同じ目標を達成するために、OSPF-MDRインターフェイスタイプを構成（および必要に応じて簡略化）する方法を示します。
Section 2 describes the operation of OSPF-MDR in a single-hop broadcast network with recommended parameter settings. Section 3 describes an alternative procedure that may be used to decide which neighbors on a single-hop broadcast network to advertise in the router-LSA. Section 4 describes a simplified version of the MDR selection algorithm for single-hop networks.
セクション2では、推奨されるパラメータ設定を使用したシングルホップブロードキャストネットワークでのOSPF-MDRの動作について説明します。セクション3では、ルーターLSAでアドバタイズするシングルホップブロードキャストネットワーク上のネイバーを決定するために使用できる代替手順について説明します。セクション4では、シングルホップネットワーク用のMDR選択アルゴリズムの簡易バージョンについて説明します。
The alternative procedure of Section 3 and the simplified algorithm of Section 4 are optional and MUST NOT be used if it is possible for two routers in the network to be more than one hop from each other.
セクション3の代替手順とセクション4の簡略化されたアルゴリズムはオプションであり、ネットワーク内の2つのルーターが互いに2ホップ以上になる可能性がある場合は使用してはなりません。
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]で説明されているように解釈されます。
When OSPF-MDR is used in a single-hop broadcast network, the following parameter settings and options (defined in [RFC5614]) should be used:
OSPF-MDRがシングルホップブロードキャストネットワークで使用される場合、次のパラメーター設定とオプション（[RFC5614]で定義）を使用する必要があります。
o AdjConnectivity SHOULD be equal to 2 (biconnected); this provides the smoothest transition when one router replaces another as MDR, since the set of adjacencies forms a biconnected network that remains connected during the transition.
o AdjConnectivityは2（双方向接続）に等しい必要があります。隣接関係のセットは、遷移中に接続されたままになる双方向接続ネットワークを形成するため、これにより、あるルーターがMDRとして別のルーターを置き換えるときに最もスムーズな遷移が提供されます。
o AdjConnectivity MAY be equal to 1 (uniconnected), resulting in a slightly less smooth transition, since adjacencies must be formed between the new MDR and all of its neighbors.
o 新しいMDRとそのすべてのネイバーとの間で隣接関係を形成する必要があるため、AdjConnectivityは1（単一接続）に等しい場合があり、遷移がわずかにスムーズではなくなります。
o AdjConnectivity SHOULD NOT be equal to 0 (full topology), since this requires adjacencies to be formed between all pairs of routers, adding unnecessary message overhead.
o AdjConnectivityは0（完全なトポロジ）に等しくないでください。これは、ルーターのすべてのペア間で隣接関係を形成する必要があり、不要なメッセージオーバーヘッドが追加されるためです。
o An adjacency SHOULD be eliminated if neither the router nor the neighbor is an MDR or BMDR (see Section 7.3 of [RFC5614]).
o ルーターもネイバーもMDRまたはBMDRでない場合は、隣接を削除する必要があります（[RFC5614]のセクション7.3を参照）。
o LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are required. (The value 5 is defined in Section 3 of this document.)
o 完全なトポロジーのLSAが必要な場合、LSAFullnessは4または5に等しくなければなりません。 （値5は、このドキュメントのセクション3で定義されています。）
o LSAFullness MAY be equal to 1 (min-cost LSAs) if full-topology LSAs are not required. This option reduces the number of advertised links while still providing shortest paths.
o 完全なトポロジーのLSAが必要でない場合、LSAFullnessは1（最小コストのLSA）と等しくてもかまいません。このオプションは、最短パスを提供しながら、アドバタイズされるリンクの数を減らします。
If AdjConnectivity equals 1 or 2 and full-topology LSAs are used, OSPF-MDR running on a single-hop broadcast network has the following properties:
AdjConnectivityが1または2で、フルトポロジLSAが使用されている場合、シングルホップブロードキャストネットワークで実行されているOSPF-MDRには次のプロパティがあります。
o A single MDR is selected, which becomes adjacent with every other router, as in an OSPF broadcast network.
o OSPFブロードキャストネットワークの場合と同様に、他のすべてのルータと隣接する単一のMDRが選択されます。
o Two BMDRs are selected. This occurs because the MDR selection algorithm ensures that the MDR/BMDR backbone is biconnected. If AdjConnectivity = 2, every non-MDR/BMDR router becomes adjacent with one of the BMDRs in addition to the MDR.
o 2つのBMDRが選択されています。これは、MDR選択アルゴリズムにより、MDR / BMDRバックボーンが確実に二重接続されるためです。 AdjConnectivity = 2の場合、すべての非MDR / BMDRルーターが、MDRに加えてBMDRの1つと隣接します。
o When all adjacencies are fully adjacent, the router-LSA for each router includes point-to-point (type 1) links to all bidirectional neighbors (in state 2-Way or greater).
o すべての隣接関係が完全に隣接している場合、各ルーターのルーターLSAには、すべての双方向ネイバー（状態2ウェイ以上）へのポイントツーポイント（タイプ1）リンクが含まれます。
A router running OSPF-MDR with LSAFullness = 4 includes in its router-LSA point-to-point (type 1) links for all fully adjacent neighbors, and for all bidirectional neighbors that are routable. A neighbor is routable if the SPF calculation has produced a route to the neighbor and a flexible quality condition is satisfied.
LSAFullness = 4でOSPF-MDRを実行しているルーターは、完全に隣接するすべてのネイバー、およびルーティング可能なすべての双方向ネイバーのルーターLSAポイントツーポイント（タイプ1）リンクを含みます。 SPF計算がネイバーへのルートを生成し、柔軟な品質条件が満たされている場合、ネイバーはルーティング可能です。
This section describes an alternative procedure that MAY be used instead of the procedure described in Section 6 of [RFC5614], to decide which neighbors on a single-hop broadcast network to advertise in the router-LSA. The alternative procedure will correspond to LSAFullness = 5, and is interoperable with the other choices for LSAFullness. This procedure avoids the need to check whether a neighbor is routable, and thus avoids having to update the set of routable neighbors.
このセクションでは、[RFC5614]のセクション6で説明されている手順の代わりに使用できる代替手順について説明し、シングルホップブロードキャストネットワークのどのネイバーをルーターLSAでアドバタイズするかを決定します。代替手順はLSAFullness = 5に対応し、LSAFullnessの他の選択肢と相互運用できます。この手順により、ネイバーがルーティング可能かどうかを確認する必要がなくなり、ルーティング可能なネイバーのセットを更新する必要がなくなります。
If LSAFullness = 5, then the Selected Advertised Neighbor Set (SANS) is the same as specified for LSAFullness = 4, and the following steps are performed instead of the first paragraph of Section 9.4 in [RFC5614].
LSAFullness = 5の場合、選択したアドバタイズされたネイバーセット（SANS）はLSAFullness = 4で指定したものと同じであり、[RFC5614]のセクション9.4の最初の段落の代わりに次の手順が実行されます。
(1) The MDR includes in its router-LSA a point-to-point (type 1) link for each fully adjacent neighbor. (Note that the MDR becomes adjacent with all of its neighbors.)
（1）MDRのルーターLSAには、完全に隣接する各ネイバーのポイントツーポイント（タイプ1）リンクが含まれています。 （MDRはすべてのネイバーと隣接することに注意してください。）
(2) Each non-MDR router includes in its router-LSA a point-to-point link for each fully adjacent neighbor, and, if the router is fully adjacent with the MDR, for each bidirectional neighbor j such that the MDR's router-LSA includes a link to j.
（2）各非MDRルーターのルーターLSAには、完全に隣接するネイバーごとにポイントツーポイントリンクが含まれ、ルーターがMDRと完全に隣接している場合は、双方向のネイバーjごとにMDRのルーターがLSAにはjへのリンクが含まれています。
To provide rationale for the above procedure, let i and j be two non-MDR routers. Since the SPF calculation (Section 16.1 of [RFC2328]) allows router i to use router j as a next hop only if router j advertises a link back to router i, routers i and j must both advertise a link to each other in their router-LSAs before either can use the other as a next hop. Therefore, the above procedure for non-MDR routers (Step 2) implies there must exist a path of fully adjacent links between i and j (via the MDR) in both directions before this can happen. The above procedure for non-MDR routers is similar to one described in Section 4.6 of [RFC6845] for non-DR routers.
上記の手順の根拠を提供するために、iとjを2つの非MDRルーターとします。 SPFの計算（[RFC2328]のセクション16.1）により、ルーターjがルーターiにリンクをアドバタイズする場合にのみ、ルーターjがルーターjをネクストホップとして使用できるため、ルーターiとjの両方がルーターで相互にリンクをアドバタイズする必要があります-LSAは、前のいずれかが他方を次のホップとして使用できます。したがって、非MDRルーターの上記の手順（ステップ2）は、これが発生する前に、両方向に（MDRを介して）iとjの間に完全に隣接するリンクのパスが存在する必要があることを意味します。上記の非MDRルーターの手順は、非DRルーターの[RFC6845]のセクション4.6に記載されている手順と同様です。
The MDR selection algorithm of [RFC5614] simplifies as follows in single-hop networks. The resulting algorithm is similar to the DR election algorithm of OSPF, but is slightly different (e.g., two Backup MDRs are selected). The following simplified algorithm is interoperable with the full MDR selection algorithm.
[RFC5614]のMDR選択アルゴリズムは、シングルホップネットワークで次のように単純化されます。結果のアルゴリズムは、OSPFのDR選定アルゴリズムに似ていますが、少し異なります（たとえば、2つのバックアップMDRが選択されています）。次の簡略化されたアルゴリズムは、完全なMDR選択アルゴリズムと相互運用できます。
Note that lexicographic order is used when comparing tuples of the form (RtrPri, MDR Level, RID). Also note that each router will form adjacencies with its Parents and dependent neighbors. In the following, the term "neighbor" refers to a bidirectional neighbor (in state 2-Way or greater).
フォームのタプル（RtrPri、MDRレベル、RID）を比較する場合は、辞書式順序が使用されることに注意してください。また、各ルーターはその親および依存するネイバーと隣接関係を形成することにも注意してください。以下では、「ネイバー」という用語は、双方向のネイバー（2ウェイ以上の状態）を指します。
Phase 1: Creating the neighbor connectivity matrix is not required.
フェーズ1：ネイバー接続マトリックスを作成する必要はありません。
Phase 2: MDR Selection
フェーズ2：MDRの選択
(2.1) The set of Dependent Neighbors is initialized to be empty.
（2.1）Dependent Neighborのセットは空に初期化されます。
(2.2) If the router has a larger value of (RtrPri, MDR Level, RID) than all of its (bidirectional) neighbors, the router selects itself as an MDR; selects its BMDR neighbors as Dependent Neighbors if AdjConnectivity = 2; then proceeds to Phase 4.
（2.2）ルーターの（RtrPri、MDRレベル、RID）の値がすべての（双方向）ネイバーよりも大きい場合、ルーターは自身をMDRとして選択します。 AdjConnectivity = 2の場合、BMDRネイバーを依存ネイバーとして選択します。その後、フェーズ4に進みます。
(2.3) Otherwise, if the router's MDR Level is currently MDR, then it is changed to BMDR before executing Phase 3.
（2.3）それ以外の場合、ルーターのMDRレベルが現在MDRであれば、フェーズ3を実行する前にBMDRに変更されます。
Phase 3: Backup MDR Selection
フェーズ3：バックアップMDRの選択
(3.1) Let Rmax be the neighbor with the largest value of (RtrPri, MDR Level, RID).
（3.1）Rmaxを（RtrPri、MDRレベル、RID）の最大値を持つネイバーとします。
(3.2) Determine whether or not there exist two neighbors, other than Rmax, with a larger value of (RtrPri, MDR Level, RID) than the router itself.
（3.2）Rmax以外に、ルーター自体よりも（RtrPri、MDRレベル、RID）の値が大きい2つのネイバーが存在するかどうかを確認します。
(3.3) If there exist two such neighbors, then the router sets its MDR Level to MDR Other.
（3.3）そのようなネイバーが2つ存在する場合、ルーターはMDRレベルをMDRその他に設定します。
(3.4) Else, the router sets its MDR Level to BMDR, and if AdjConnectivity = 2, adds Rmax and its MDR/BMDR neighbors as Dependent Neighbors.
（3.4）それ以外の場合、ルーターはMDRレベルをBMDRに設定し、AdjConnectivity = 2の場合、RmaxとそのMDR / BMDRネイバーを依存ネイバーとして追加します。
(3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing from MDR Other to BMDR, then execute Step 2.2 again before proceeding to Phase 4. (This is necessary because running Step 2.2 again can cause the MDR Level to change to MDR.)
（3.5）ステップ3.1から3.4でMDRレベルがMDRその他からBMDRに変更された場合、フェーズ2.2を再度実行してからフェーズ4に進みます（ステップ2.2を再度実行すると、MDRレベルがMDRに変更される可能性があるため、これが必要です。 ）
Phase 4: Parent Selection
フェーズ4：親の選択
Each router selects a Parent and (if AdjConnectivity = 2) a Backup Parent for the single-hop broadcast network. The Parent for a non-MDR router will be the MDR. The Backup Parent for an MDR Other, if it exists, will be a BMDR. Each non-MDR router becomes adjacent with its Parent and its Backup Parent, if it exists. The Parent selection algorithm is already simple, so a simplified version is not given here.
各ルーターは、シングルホップブロードキャストネットワークの親と（AdjConnectivity = 2の場合）バックアップ親を選択します。非MDRルーターの親はMDRになります。 MDRのバックアップの親（存在する場合）は、BMDRになります。非MDRルーターはそれぞれ、親とバックアップ親（存在する場合）と隣接します。親の選択アルゴリズムはすでに単純であるため、簡略化されたバージョンはここでは示しません。
The Parent and Backup Parent are analogous to the Designated Router and Backup Designated Router interface data items in OSPF. As in OSPF, these are advertised in the DR and Backup DR fields of each Hello sent on the interface.
親とバックアップの親は、OSPFの代表ルーターとバックアップ代表ルーターのインターフェースデータ項目に類似しています。 OSPFと同様に、これらはインターフェイスで送信される各HelloのDRおよびBackup DRフィールドでアドバタイズされます。
This document describes the use of OSPF-MDR in a single-hop broadcast network, and raises no security issues in addition to those already covered in [RFC5614].
このドキュメントでは、シングルホップブロードキャストネットワークでのOSPF-MDRの使用について説明し、[RFC5614]ですでにカバーされている問題に加えて、セキュリティ上の問題は発生しません。
[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月。
[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月。
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.
[RFC5614] Ogier、R。およびP. Spagnolo、「モバイル接続アドホックネットワーク（MANET）OSPFのOSPFの拡張を使用して接続された支配セット（CDS）フラッディング」、RFC 5614、2009年8月。
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, January 2013.
[RFC6845] Sheth、N.、Wang、L。、およびJ. Zhang、「OSPFハイブリッドブロードキャストおよびポイントツーマルチポイントインターフェイスタイプ」、RFC 6845、2013年1月。
Author's Address
著者のアドレス
Richard G. Ogier EMail: ogier@earthlink.net
リチャードG.オジェEメール：ogier@earthlink.net