[要約] RFC 6845は、OSPFハイブリッドブロードキャストおよびポイントツーマルチポイントインターフェースタイプに関する仕様です。このRFCの目的は、OSPFプロトコルを使用してネットワーク上のブロードキャストおよびポイントツーマルチポイントトラフィックを効率的にルーティングするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) N. Sheth
Request for Comments: 6845 Contrail Systems
Updates: 2328, 5340 L. Wang
Category: Standards Track J. Zhang
ISSN: 2070-1721 Juniper Networks
January 2013
OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
OSPFハイブリッドブロードキャストおよびポイントツーマルチポイントインターフェイスタイプ
Abstract
概要
This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.
このドキュメントでは、OSPF操作の目的で、ブロードキャストネットワークとポイントツーマルチポイントネットワークのハイブリッドとしてブロードキャストネットワークをモデル化するメカニズムについて説明します。ネイバー探索と保守、およびLink State Advertisement（LSA）データベースの同期は、ブロードキャストモデルを使用して実行されますが、ネットワークは、接続されているルーターのルーターLSAでポイントツーマルチポイントモデルを使用して表されます。これにより、ブロードキャスト操作のネットワーク効率を維持しながら、ネットワーク上の異なるルーター間の通信コストを正確に表すことができます。このアプローチは比較的単純で、OSPFへの変更は最小限で済みます。
This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340).
このドキュメントでは、OSPFv2（RFC 2328）とOSPFv3（RFC 5340）の両方を更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6845.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6845で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 4
4.2. Neighbor Data Structure . . . . . . . . . . . . . . . . . . 4
4.3. Neighbor Discovery and Maintenance . . . . . . . . . . . . 5
4.4. Database Synchronization . . . . . . . . . . . . . . . . . 5
4.5. Generating Network-LSAs . . . . . . . . . . . . . . . . . . 5
4.6. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . 5
4.6.1. Stub Links in OSPFv2 Router-LSA . . . . . . . . . . . . 6
4.6.2. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . 6
4.7. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . 6
4.8. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 6
5. Compatibility Considerations . . . . . . . . . . . . . . . . . 6
6. Scalability and Deployment Considerations . . . . . . . . . . . 7
7. Management Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
OSPF [RFC2328] operation on broadcast interfaces takes advantage of the broadcast capabilities of the underlying medium for doing neighbor discovery and maintenance. Further, it uses a Designated Router (DR) and Backup Designated Router (BDR) to keep the Link State Advertisement (LSA) databases of the routers on the network synchronized in an efficient manner. However, it has the limitation that a router cannot advertise different costs to each of the neighboring routers on the network in its router-LSA.
ブロードキャストインターフェイスでのOSPF [RFC2328]オペレーションは、ネイバーディスカバリおよびメンテナンスを行うために、基盤となるメディアのブロードキャスト機能を利用します。さらに、指定ルーター（DR）とバックアップ指定ルーター（BDR）を使用して、ネットワーク上のルーターのリンク状態アドバタイズ（LSA）データベースを効率的に同期させます。ただし、ルーターはルーターLSA内のネットワーク上の隣接ルーターのそれぞれに異なるコストを通知できないという制限があります。
Consider a radio network that supports true broadcast, yet the metrics between different pairs of terminals could be different for various reasons (e.g., different signal strength due to placement). When running OSPF over the radio network, for a router to advertise different costs to different neighbors, the interface must be treated as point-to-multipoint (P2MP), even though the network has true broadcast capability.
真のブロードキャストをサポートする無線ネットワークを検討してください。ただし、さまざまな理由（たとえば、配置による信号強度の違い）によって、端末の異なるペア間のメトリックは異なる場合があります。無線ネットワーク上でOSPFを実行している場合、ルーターが異なるネイバーに異なるコストをアドバタイズするには、ネットワークに真のブロードキャスト機能がある場合でも、インターフェイスをポイントツーマルチポイント（P2MP）として扱う必要があります。
Operation on point-to-multipoint interfaces could require explicit configuration of the identity of neighboring routers. It also requires the router to send separate Hellos to each neighbor on the network. Further, it mandates establishment of adjacencies to all configured or discovered neighbors on the network. However, it gives the routers the flexibility to advertise different costs to each of the neighboring routers in their router-LSAs.
ポイントツーマルチポイントインターフェイスでの操作では、隣接ルータのIDを明示的に設定する必要があります。また、ルーターはネットワーク上の各ネイバーに個別のHelloを送信する必要があります。さらに、ネットワーク上のすべての設定済みまたは検出されたネイバーへの隣接関係の確立を義務付けます。ただし、ルーターにルーターLSA内の隣接ルーターのそれぞれに異なるコストを通知する柔軟性を提供します。
This document proposes a new interface type that can be used on networks that have broadcast capability. In this mode, neighbor discovery and maintenance, as well as database synchronization are performed using existing procedures for broadcast mode. The network is modeled as a collection of point-to-point links in the router-LSA, just as it would be in point-to-multipoint mode. This new interface type is referred to as hybrid-broadcast-and-P2MP in the rest of this document.
このドキュメントでは、ブロードキャスト機能を持つネットワークで使用できる新しいインターフェイスタイプを提案します。このモードでは、ネイバー探索とメンテナンス、およびデータベースの同期は、ブロードキャストモードの既存の手順を使用して実行されます。ネットワークは、ポイントツーマルチポイントモードと同様に、ルーターLSA内のポイントツーポイントリンクのコレクションとしてモデル化されます。このドキュメントの残りの部分では、この新しいインターフェイスタイプをハイブリッドブロードキャストとP2MPと呼びます。
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]で説明されているように解釈されます。
There are some networks that are broadcast capable but have a potentially different cost associated with communication between any given pair of nodes. The cost could be based on the underlying topology as well as various link quality metrics such as bandwidth, delay, and jitter, among others.
ブロードキャストに対応しているが、ノードの特定のペア間の通信に関連するコストが異なる可能性のあるネットワークがいくつかあります。コストは、基盤となるトポロジー、および特に帯域幅、遅延、ジッターなどのさまざまなリンク品質メトリックに基づく可能性があります。
It is not accurate to treat such networks as OSPF broadcast networks since that does not allow a router to advertise a different cost to each of the other routers. Using OSPF point-to-multipoint mode would satisfy the requirement to correctly describe the cost to reach each router. However, it would be inefficient in the sense that it would require forming O(N^2) adjacencies when there are N routers on the network.
このようなネットワークをOSPFブロードキャストネットワークとして扱うことは正確ではありません。これは、ルーターが他のルーターのそれぞれに異なるコストを通知することを許可しないためです。 OSPFポイントツーマルチポイントモードを使用すると、各ルーターに到達するためのコストを正しく説明するための要件を満たします。ただし、ネットワーク上にN台のルーターがある場合、O（N ^ 2）隣接関係を形成する必要があるという意味では非効率的です。
It is advantageous to use the hybrid-broadcast-and-P2MP type for such networks. This combines the flexibility of point-to-multipoint type with the advantages and efficiencies of broadcast interface type.
このようなネットワークには、broadcast-and-P2MPタイプを使用すると便利です。これは、ポイントツーマルチポイントタイプの柔軟性と、ブロードキャストインターフェイスタイプの利点と効率を組み合わせたものです。
OSPF routers supporting the capabilities described herein should have support for an additional hybrid-broadcast-and-P2MP type for the Type data item described in Section 9 of [RFC2328].
ここで説明されている機能をサポートするOSPFルーターは、[RFC2328]のセクション9で説明されているタイプデータ項目の追加のハイブリッドブロードキャストとP2MPタイプをサポートする必要があります。
The following sub-sections describe salient aspects of OSPF operation on routers configured with a hybrid-broadcast-and-P2MP interface.
次のサブセクションでは、broadcast-and-P2MPインターフェースを使用して構成されたルーターでのOSPF操作の主な側面について説明します。
The "Router Priority" interface parameter as specified in OSPFv2 [RFC2328] and OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-P2MP interface.
OSPFv2 [RFC2328]およびOSPFv3 [RFC5340]で指定されている「ルーター優先度」インターフェースパラメータは、ハイブリッドブロードキャストとP2MPのインターフェースに適用されます。
The "LinkLSASuppression" interface parameter as specified in OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-P2MP interface. The default value is "disabled". It may be set to "enabled" via configuration.
OSPFv3 [RFC5340]で指定されている「LinkLSASuppression」インターフェイスパラメータは、ハイブリッドブロードキャストとP2MPのインターフェイスに適用されます。デフォルト値は「無効」です。設定により「有効」に設定できます。
An additional field called the Neighbor Output Cost is added to the neighbor data structure. This is the cost of sending a data packet to the neighbor, expressed in the link state metric. The default value of this field is the Interface output cost. It may be set to a different value using mechanisms that are outside the scope of this document, like static per-neighbor configuration, or any dynamic discovery mechanism that is supported by the underlying network.
Neighbor Output Costと呼ばれる追加フィールドがNeighborデータ構造に追加されます。これは、リンク状態メトリックで表された、データパケットをネイバーに送信するコストです。このフィールドのデフォルト値は、インターフェース出力コストです。静的なネイバーごとの構成や、基盤となるネットワークでサポートされている動的な検出メカニズムなど、このドキュメントの範囲外のメカニズムを使用して別の値に設定される場合があります。
Routers send and receive Hellos so as to perform neighbor discovery and maintenance on the interface using the procedures specified for broadcast interfaces in [RFC2328] and [RFC5340].
ルータはHelloを送受信して、[RFC2328]および[RFC5340]のブロードキャストインターフェイスに指定された手順を使用して、インターフェイスでネイバーの検出とメンテナンスを実行します。
Routers elect a DR and BDR for the interface and use them for initial and ongoing database synchronization using the procedures specified for broadcast interfaces in [RFC2328] and [RFC5340].
ルーターはインターフェイスのDRとBDRを選択し、[RFC2328]と[RFC5340]でブロードキャストインターフェイスに指定された手順を使用して、初期および進行中のデータベース同期にそれらを使用します。
Since a hybrid-broadcast-and-P2MP interface is described in router-LSAs using a collection of point-to-point links, the DR MUST NOT generate a network-LSA for the interface.
ハイブリッドブロードキャストとP2MPのインターフェースは、ポイントツーポイントリンクのコレクションを使用してルーターLSAで記述されるため、DRはインターフェースのネットワークLSAを生成してはなりません（MUST NOT）。
Routers describe the interface in their router-LSA as specified for a point-to-multipoint interface in Section 12.4.1.4 of [RFC2328] and Section 4.4.3.2 of [RFC5340], with the following modifications for Type 1 links:
ルーターは、[RFC2328]のセクション12.4.1.4および[RFC5340]のセクション4.4.3.2でポイントツーマルチポイントインターフェースに指定されているように、ルーターLSA内のインターフェースを記述し、タイプ1リンクに次の変更を加えます。
o If a router is not the DR and does not have a full adjacency to the DR, it MUST NOT add any Type 1 links.
o ルーターがDRではなく、DRへの完全な隣接がない場合、ルーターはタイプ1リンクを追加してはなりません（MUST NOT）。
o If a router is not the DR and has a full adjacency to the DR, and both the DR and this router agree on the DR role, it MUST add a Type 1 link corresponding to each neighbor that is in state 2-Way or higher and to which the DR's router-LSA includes a link.
o ルーターがDRではなく、DRに完全に隣接していて、DRとこのルーターの両方がDRの役割に同意している場合、2ウェイ以上の状態にある各ネイバーに対応するタイプ1リンクを追加する必要があります。 DRのルーターLSAへのリンクが含まれます。
o The cost for a Type 1 link corresponding to a neighbor SHOULD be set to the value of the Neighbor Output Cost field as defined in Section 4.2.
o ネイバーに対応するタイプ1リンクのコストは、セクション4.2で定義されているように、ネイバー出力コストフィールドの値に設定する必要があります（SHOULD）。
Routers MUST add a Type 3 link for their own IP address to the router-LSA as described in Section 12.4.1.4 of [RFC2328]. Further, they MUST also add a Type 3 link with the Link ID set to the IP subnet address, Link Data set to the IP subnet mask, and cost equal to the configured output cost of the interface.
[RFC2328]のセクション12.4.1.4で説明されているように、ルーターは独自のIPアドレスのタイプ3リンクをルーターLSAに追加する必要があります。さらに、IPサブネットアドレスに設定されたリンクID、IPサブネットマスクに設定されたリンクデータ、およびインターフェイスの構成済み出力コストに等しいコストを持つタイプ3リンクも追加する必要があります。
Routers MUST add globally scoped IPv6 addresses on the interface to the intra-area-prefix-LSA as described for point-to-multipoint interfaces in Section 4.4.3.9 of [RFC5340]. In addition, they MUST also add all globally scoped IPv6 prefixes on the interface to the LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the configured output cost of the interface.
[RFC5340]のセクション4.4.3.9でポイントツーマルチポイントインターフェースについて説明されているように、ルーターはインターフェースにグローバルスコープのIPv6アドレスをintra-area-prefix-LSAに追加する必要があります。さらに、PrefixLength、PrefixOptions、およびAddress Prefixフィールドを指定することにより、インターフェイス上のすべてのグローバルスコープIPv6プレフィックスをLSAに追加する必要もあります。これらの各プレフィックスのメトリックフィールドは、インターフェースの構成済み出力コストに設定されます。
The DR MUST NOT generate an intra-area-prefix-LSA for the transit network for this interface since it does not generate a network-LSA for the interface. Note that the global prefixes associated with the interface are advertised in the intra-area-prefix-LSA for the router as described above.
DRは、インターフェイスのネットワークLSAを生成しないため、このインターフェイスの中継ネットワークのエリア内プレフィックスLSAを生成してはなりません（MUST NOT）。上記のように、インターフェイスに関連付けられているグローバルプレフィックスは、ルータのintra-area-prefix-LSAでアドバタイズされることに注意してください。
Next-hops to destinations that are directly connected to a router via the interface are calculated as specified for a point-to-multipoint interface in Section 16.1.1 of [RFC2328].
インターフェースを介してルーターに直接接続されている宛先へのネクストホップは、[RFC2328]のセクション16.1.1のポイントツーマルチポイントインターフェースの指定に従って計算されます。
The following modifications to the procedures defined in Section 2.2, item 1, of [RFC3623] are required in order to ensure that the router correctly exits graceful restart.
[RFC3623]のセクション2.2、アイテム1で定義された手順に対する以下の変更は、ルータが正常な再起動を正しく終了することを保証するために必要です。
o If a router is the DR on the interface, the pre-restart network-LSA for the interface MUST NOT be used to determine the previous set of adjacencies.
o ルーターがインターフェースのDRである場合、インターフェースの再起動前のネットワークLSAを使用して、以前の隣接セットを決定してはなりません（MUST NOT）。
o If a router is in state DROther on the interface, an adjacency to a non-DR or non-BDR neighbor is considered as reestablished when the neighbor state reaches 2-Way.
o ルーターがインターフェイスでDROther状態にある場合、非DRまたは非BDRネイバーへの隣接関係は、ネイバー状態が2ウェイに達したときに再確立されたと見なされます。
All routers on the network must support the hybrid-broadcast-and-P2MP interface type for successful operation. Otherwise, the interface should be configured as a standard broadcast interface.
正常に動作させるには、ネットワーク上のすべてのルーターがハイブリッドブロードキャストとP2MPインターフェースタイプをサポートしている必要があります。それ以外の場合は、インターフェイスを標準のブロードキャストインターフェイスとして構成する必要があります。
If some routers on the network treat the interface as broadcast and others as hybrid-broadcast-and-P2MP, neighbors and adjacencies will still get formed as for a broadcast interface. However, due to the differences in how router and network-LSAs are built for these two interface types, there will be no traffic traversing certain pairs of routers. Note that this will not cause any persistent loops or black-holing of traffic.
ネットワーク上のルーターがインターフェイスをブロードキャストとして扱い、他のルーターがハイブリッドブロードキャストとP2MPとして扱う場合でも、ブロードキャストインターフェイスの場合と同様に、ネイバーと隣接関係が形成されます。ただし、ルーターとネットワークLSAがこれら2つのインターフェイスタイプに対して構築される方法が異なるため、特定のルーターのペアを通過するトラフィックはありません。これにより、永続的なループやトラフィックのブラックホールが発生することはありません。
To detect and flag possible mismatched configurations, an implementation of this specification SHOULD log a message if a network-LSA is received for a locally configured hybrid interface.
不一致の可能性がある構成を検出してフラグを付けるために、この仕様の実装は、ローカルに構成されたハイブリッドインターフェイスのネットワークLSAを受信した場合にメッセージをログに記録する必要があります（SHOULD）。
Treating a broadcast interface as hybrid-broadcast-and-P2MP results in O(N^2) links to represent the network instead of O(N), when there are N routers on the network. This will increase memory usage and have a negative impact on route calculation performance on all the routers in the area. Network designers should carefully weigh the benefits of using the new interface type against the disadvantages mentioned here.
ネットワーク上にN台のルーターがある場合、ブロードキャストインターフェイスをHybrid-broadcast-and-P2MPとして扱うと、O（N ^ 2）リンクがO（N）ではなくネットワークを表すようになります。これにより、メモリ使用量が増加し、エリア内のすべてのルーターのルート計算パフォーマンスに悪影響を及ぼします。ネットワーク設計者は、新しいインターフェイスタイプを使用するメリットと、ここで説明するデメリットを慎重に比較検討する必要があります。
The following MIB variable/value should be added to the appropriate OSPFv2 and OSPFv3 MIBs ([RFC4750], [RFC5643]).
次のMIB変数/値は、適切なOSPFv2およびOSPFv3 MIB（[RFC4750]、[RFC5643]）に追加する必要があります。
o For ospfIfType/ospfv3IfType, a new value broadcast-P2MP-hybrid (X) for the hybrid interface type (X to be defined when the revised MIB documents are approved).
o ospfIfType / ospfv3IfTypeの場合、ハイブリッドインターフェイスタイプの新しい値broadcast-P2MP-hybrid（X）（Xは、改訂されたMIBドキュメントが承認されたときに定義される）。
o For ospfNbrEntry/ospfv3NbrEntry, an ospfNbrMetricValue/ ospfv3NbrMetricValue attribute for per-neighbor metrics. In case of non-hybrid interfaces, the value is the same as the interface metric.
o ospfNbrEntry / ospfv3NbrEntryの場合、ネイバーごとのメトリックのospfNbrMetricValue / ospfv3NbrMetricValue属性。非ハイブリッドインターフェイスの場合、値はインターフェイスメトリックと同じです。
This section is not normative.
このセクションは規範的ではありません。
This document raises no new security issues for OSPF. Security considerations for the base OSPF protocol are covered in [RFC2328], [RFC5340], and [RFC6506].
このドキュメントでは、OSPFの新しいセキュリティ問題は発生しません。基本OSPFプロトコルのセキュリティに関する考慮事項は、[RFC2328]、[RFC5340]、および[RFC6506]で説明されています。
The authors would like to thank Acee Lindem and Richard Ogier for their comments and suggestions.
著者は、コメントと提案を提供してくれたAcee LindemとRichard Ogierに感謝します。
[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月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、RFC 3623、2003年11月。
[RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
[RFC4750] Joyal、D.、Galecki、P.、Giacarone、S.、Coltun、R。、およびF. Baker、「OSPFバージョン2管理情報ベース」、RFC 4750、2006年12月。
[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月。
[RFC5643] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", RFC 5643, August 2009.
[RFC5643] Joyal、D。およびV. Manral、「OSPFv3の管理情報ベース」、RFC 5643、2009年8月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 6506、2012年2月。
Authors' Addresses
著者のアドレス
Nischal Sheth Contrail Systems 2350 Mission College Blvd, #1140 Santa Clara, CA 95054 US
Nischal Sheth Contrail Systems 2350 Mission College Blvd、＃1140 Santa Clara、CA 95054 US
EMail: nsheth@contrailsystems.com
Lili Wang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 US
Lili Wang Juniper Networks 10 Technology Park Dr. Westford、MA 01886 US
EMail: liliw@juniper.net
Jeffrey Zhang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 US
Jeffrey Zhang Juniper Networks 10 Technology Park Dr. Westford、MA 01886 US
EMail: zzhang@juniper.net