[要約] RFC 8042は、OSPF（Open Shortest Path First）プロトコルの二部構成メトリックに関する仕様です。このRFCの目的は、OSPFのメトリック計算方法を改善し、ネットワークの経路選択を最適化することです。
Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 8042 L. Wang
Updates: 2328 Juniper Networks, Inc.
Category: Standards Track A. Lindem
ISSN: 2070-1721 Cisco Systems
December 2016
OSPF Two-Part Metric
OSPF 2パートメトリック
Abstract
概要
This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.
このドキュメントでは、オプションのOSPFプロトコル拡張を指定して、マルチアクセスネットワークのルーターメトリックを2つの部分に分けています。ルーターからネットワークへのメトリックと、ネットワークからルーターへのメトリックです。そのようなネットワークの場合、OSPFルート計算のルーター間メトリックは、2つの部分の合計です。このドキュメントはRFC 2328を更新します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8042.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8042で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3
3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4
3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4
3.3. Advertising Network-to-Router Traffic Engineering (TE)
Metric . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5
3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
With Open Shortest Path First (OSPF) [RFC2328] [RFC5340]), a Network-LSA (Link State Advertisement) is advertised to list all routers on a broadcast network. Additionally, each router on the broadcast network includes a link in its Router-LSA to describe its connection to the network. The link in the Router-LSA includes a metric but the listed routers in the Network-LSA do not include a metric. This is based on the assumption that from a particular router, all others on the same network can be reached with the same metric.
Open Shortest Path First（OSPF）[RFC2328] [RFC5340]）を使用すると、Network-LSA（リンク状態アドバタイズメント）がアドバタイズされ、ブロードキャストネットワーク上のすべてのルーターが一覧表示されます。さらに、ブロードキャストネットワークの各ルーターには、ルーターLSAにリンクが含まれており、ネットワークへの接続を記述しています。ルーターLSAのリンクにはメトリックが含まれていますが、ネットワークLSAにリストされているルーターにはメトリックが含まれていません。これは、特定のルーターから、同じネットワーク上の他のすべてのルーターに同じメトリックで到達できるという想定に基づいています。
With some broadcast networks, different routers can be reached with different metrics. [RFC6845] extends the OSPF protocol with a hybrid interface type for that kind of broadcast network, where no Network-LSA is advertised and Router-LSAs simply include point-to-point links to all routers on the same network with individual metrics. Broadcast capability is still used to optimize database synchronization and adjacency maintenance.
一部のブロードキャストネットワークでは、異なるルーターに異なるメトリックで到達できます。 [RFC6845]は、その種類のブロードキャストネットワーク用のハイブリッドインターフェイスタイプでOSPFプロトコルを拡張します。Network-LSAはアドバタイズされず、ルーターLSAは、個々のメトリックを持つ同じネットワーク上のすべてのルーターへのポイントツーポイントリンクを含むだけです。ブロードキャスト機能は、データベースの同期と隣接のメンテナンスを最適化するために引き続き使用されます。
This works well for broadcast networks where the metric between different pairs of routers are really independent, for example, Virtual Private LAN Service (VPLS) networks.
これは、仮想プライベートLANサービス（VPLS）ネットワークなど、ルーターの異なるペア間のメトリックが実際には独立しているブロードキャストネットワークに適しています。
With certain types of broadcast networks, further optimization can be made to reduce the size of Router-LSAs and the number of updates.
特定の種類のブロードキャストネットワークでは、ルーターLSAのサイズと更新の数を減らすために、さらに最適化を行うことができます。
Consider a satellite radio network with fixed and mobile ground terminals. All communication goes through the satellite. When the mobile terminals move about, their communication capability may change. When OSPF runs over the radio network, [RFC6845] hybrid interface can be used, but with the following drawbacks.
固定および移動地上端末を備えた衛星無線ネットワークを考えてみます。すべての通信は衛星を経由します。携帯端末が動き回ると、通信能力が変化する場合があります。 OSPFが無線ネットワーク上で実行される場合、[RFC6845]ハイブリッドインターフェイスを使用できますが、次の欠点があります。
Consider that one terminal/router moves into an area where its communication capability degrades significantly. Through the radio control protocol, all other routers determine that the metric to this particular router changed and they all need to update their Router-LSAs accordingly. In addition, the router in question determines that its metric to reach all others also changed and it needs to update its Router-LSA. Consider that there could be many terminals and many of them can be moving fast and frequently. The number and frequency of updates of those large Router-LSAs could inhibit network scaling.
1つの端末/ルーターが、通信能力が著しく低下するエリアに移動するとします。他のすべてのルーターは、無線制御プロトコルを介して、この特定のルーターへのメトリックが変更されたと判断し、それに応じてすべてのルーターLSAを更新する必要があります。さらに、問題のルーターは、他のすべてに到達するためのメトリックも変更され、ルーターLSAを更新する必要があると判断します。多くの端末が存在する可能性があり、それらの多くは高速かつ頻繁に移動している可能性があることを考慮してください。これらの大きなルーターLSAの更新の数と頻度は、ネットワークのスケーリングを阻害する可能性があります。
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]で説明されているように解釈されます。
Notice that in the above scenario, when one terminal's communication capability changes, its metric to all other terminals and the metric to it from all other terminals will all change in a similar fashion. Given this, the above problem can be easily addressed by breaking the metric into two parts: the metric to the satellite and the metric from the satellite. The metric from terminal R1 to R2 would be the sum of the metric from R1 to the satellite and the metric from the satellite to R2.
上記のシナリオでは、1つの端末の通信機能が変更されると、他のすべての端末へのメトリックと他のすべての端末からのメトリックが同様に変化することに注意してください。これを踏まえると、上記の問題は、メトリックを2つの部分に分割することで簡単に対処できます。衛星へのメトリックと衛星からのメトリックです。端末R1からR2へのメトリックは、R1から衛星へのメトリックと衛星からR2へのメトリックの合計になります。
Instead of using the hybrid interface type described in [RFC6845], the network is treated as a regular broadcast network. A router on the network no longer lists individual metrics to each neighbor in its Router-LSA. Instead, each router advertises the metric from the network to itself in addition to the normal metric for the network. With the normal Router-to-Network and additional Network-to-Router metrics advertised for each router, individual Router-to-Router metrics can be calculated.
[RFC6845]で説明されているハイブリッドインターフェイスタイプを使用する代わりに、ネットワークは通常のブロードキャストネットワークとして扱われます。ネットワーク上のルーターは、ルーターLSA内の各ネイバーに個別のメトリックをリストしなくなりました。代わりに、各ルーターは、ネットワークの通常のメトリックに加えて、ネットワークからそれ自体にメトリックをアドバタイズします。通常のルーターからネットワークへのメトリックと、ルーターごとにアドバタイズされた追加のネットワークからルーターへのメトリックにより、個々のルーターからルーターへのメトリックを計算できます。
With the proposed enhancement, the size of the Router-LSA will be significantly reduced. In addition, when a router's communication capability changes, only that router needs to update its Router-LSA.
提案された拡張機能により、ルーターLSAのサイズは大幅に削減されます。さらに、ルーターの通信機能が変更された場合、そのルーターのみがルーターLSAを更新する必要があります。
Note that while the example uses the satellite as the relay point at the radio level (layer 2), the satellite does not participate in packet forwarding at layer 3. In fact, the satellite does not need to run any layer-3 protocol. Therefore, for generality, the metric is abstracted as to/from the "network" rather than specifically to/ from the "satellite".
この例では、衛星を無線レベル（レイヤー2）の中継点として使用していますが、衛星はレイヤー3でのパケット転送には参加していません。実際、衛星はレイヤー3プロトコルを実行する必要はありません。したがって、一般性のために、メトリックは具体的に「衛星」へ/からではなく、「ネットワーク」へ/から抽象化されます。
The following specifications are added to or modified from the base OSPF protocol. If an area contains one or more two-part metric networks, then all routers in the area MUST support the extensions specified herein. This is ensured by procedures described in Section 3.7.
以下の仕様は、基本OSPFプロトコルに追加または変更されています。エリアに1つ以上の2パートメトリックネットワークが含まれている場合、エリア内のすべてのルーターは、ここで指定された拡張機能をサポートする必要があります。これは、セクション3.7で説明されている手順によって保証されます。
The "Router interface parameters" have the following additions:
「ルーターインターフェースパラメータ」には、次の追加項目があります。
o Two-part metric: TRUE if the interface connects to a multi-access network that uses a two-part metric. All routers connected to the same network SHOULD have the same configuration for their corresponding interfaces.
o 2部構成メトリック：インターフェースが2部構成メトリックを使用するマルチアクセスネットワークに接続する場合はTRUE。同じネットワークに接続されているすべてのルーターは、対応するインターフェースに対して同じ設定をする必要があります。
o Interface input cost: Link-state metric from the two-part-metric network to this router. Defaults to "Interface output cost" but is not valid for normal networks using a single metric. May be configured or dynamically adjusted to a value different from the "Interface output cost".
o インターフェイス入力コスト：2つの部分からなるメトリックネットワークからこのルーターへのリンク状態メトリック。デフォルトは「インターフェース出力コスト」ですが、単一のメトリックを使用する通常のネットワークでは無効です。 「インターフェース出力コスト」とは異なる値に構成または動的に調整できます。
For OSPFv2, the Network-to-Router metric is encoded in an OSPF Extended Link TLV Sub-TLV [RFC7684], defined in this document as the Network-to-Router Metric Sub-TLV. The type of the sub-TLV is 4. The length of the sub-TLV is 4 (for the value part only). The value part of the sub-TLV is defined as follows:
OSPFv2の場合、ネットワークからルータへのメトリックは、このドキュメントでネットワークからルータへのメトリックサブTLVとして定義されているOSPF拡張リンクTLVサブTLV [RFC7684]でエンコードされます。サブTLVのタイプは4です。サブTLVの長さは4です（値の部分のみ）。サブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple such sub-TLVs can exist in a single OSPF Extended Link TLV, one for each topology [RFC4915]. Each sub-TLV will have a unique Multi-Topology Identifier (MT-ID) and will adhere to the advertisement rules defined in Section 3.4 of [RFC4915]. The OSPF Extended Link TLV identifies the transit link to the network and is part of an OSPFv2 Extended-Link Opaque LSA. The sub-TLV MUST ONLY appear in Extended-Link TLVs for Link Type 2 (link to transit network) and MUST be ignored if received for other link types.
このような複数のサブTLVは、トポロジごとに1つ、1つのOSPF拡張リンクTLVに存在できます[RFC4915]。各サブTLVには一意のマルチトポロジ識別子（MT-ID）があり、[RFC4915]のセクション3.4で定義されたアドバタイズルールに従います。 OSPF拡張リンクTLVは、ネットワークへのトランジットリンクを識別し、OSPFv2拡張リンク不透明LSAの一部です。サブTLVは、リンクタイプ2（トランジットネットワークへのリンク）の拡張リンクTLVにのみ出現する必要があり、他のリンクタイプで受信された場合は無視する必要があります。
A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, similar to the Traffic Engineering Metric Sub-TLV defined in Section 2.5.5 of [RFC3630]. The only difference is the TLV type, which is 35. The sub-TLV MUST only appear in Type 2 Link TLVs (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs (OSPFv3) [RFC5329], and MUST appear at most once in such a Link TLV.
[RFC3630]のセクション2.5.5で定義されているトラフィックエンジニアリングメトリックサブ-TLVと同様に、トラフィックエンジニアリングネットワークからルーターへのメトリックサブ-TLVが定義されています。唯一の違いは、TLVタイプ（35）です。サブTLVは、トラフィックエンジニアLSA（OSPF2）またはイントラエリアTE-LSA（OSPFv3）のタイプ2リンクTLV（マルチアクセス）にのみ表示される必要があります[RFC5329]。 、およびそのようなリンクTLVに最大1回出現する必要があります。
Network-to-Router metric advertisement in OSPFv3 Extended Router-LSA [OSPFV3-EXTENDED-LSA] will be described in a separate document.
OSPFv3拡張ルーターLSA [OSPFV3-EXTENDED-LSA]でのネットワークからルーターへのメトリックアドバタイズについては、別のドキュメントで説明します。
When an OSPF router with interfaces to multi-access networks using two-part metrics is advertising itself as a stub router [RFC6987], only the Router-to-Network metric in the stub router's OSPF Router-LSA links for those networks is set to the MaxLinkMetric. This is fully backward compatible and will result in the same behavior as described in [RFC6987].
2部構成のメトリックを使用してマルチアクセスネットワークへのインターフェースを持つOSPFルーターがスタブルーター[RFC6987]としてそれ自体をアドバタイズしている場合、これらのネットワークに対するスタブルーターのOSPFルーターLSAリンクのルーターからネットワークへのメトリックのみが次のように設定されます。 MaxLinkMetric。これは完全に下位互換性があり、[RFC6987]で説明されているのと同じ動作になります。
The first stage of the shortest-path tree calculation is described in Section 16.1 of [RFC2328]. With a two-part metric, when a vertex V corresponding to a Network-LSA has just been added to the Shortest Path Tree (SPT) and an adjacent vertex W (joined by a link in V's corresponding Network-LSA) is being added to the candidate list, the cost from V to W (W's network-to-router cost) is determined as follows:
最短経路ツリー計算の最初の段階は、[RFC2328]のセクション16.1で説明されています。 2つの部分からなるメトリックでは、Network-LSAに対応する頂点Vが最短パスツリー（SPT）に追加され、隣接する頂点W（Vの対応するNetwork-LSAのリンクによって結合される）が候補リスト、VからWへのコスト（Wのネットワークからルーターへのコスト）は、次のように決定されます。
o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque LSA with an Extended Link TLV for the link from W to V, and the Extended Link TLV has a Network-to-Router Metric Sub-TLV for the corresponding topology, then the cost from V to W is the metric in the sub-TLV. Otherwise, the cost is 0.
o OSPFv2の場合、頂点Wに対応する拡張リンク不透明LSAがあり、WからVへのリンクに拡張リンクTLVがあり、拡張リンクTLVに対応するトポロジのネットワークからルーターへのメトリックサブTLVがある場合、 VからWへのコストは、サブTLVのメトリックです。それ以外の場合、コストは0です。
o OSPFv3 [RFC5340] Shortest Path First (SPF) changes will be described in a separate document.
o OSPFv3 [RFC5340] Shortest Path First（SPF）の変更については、別のドキュメントで説明します。
Due to the change of procedures in the SPF calculation, all routers in an area that includes one or more two-part metric networks must support the changes specified in this document. To ensure that, if an area is provisioned to support two-part metric networks, all routers supporting this capability must advertise a Router Information (RI) LSA with a Router Functional Capabilities TLV [RFC7770] that includes the following Router Functional Capability Bit:
SPF計算での手順の変更により、1つ以上の2パートメトリックネットワークを含むエリア内のすべてのルーターは、このドキュメントで指定された変更をサポートする必要があります。エリアが2パートメトリックネットワークをサポートするようにプロビジョニングされている場合、この機能をサポートするすべてのルーターは、次のルーター機能機能ビットを含むルーター機能機能TLV [RFC7770]でルーター情報（RI）LSAを通知する必要があります。
Bit Capabilities
ビット機能
6 Two-Part Metric support
6 2パートメトリックサポート
Upon detecting the presence of a reachable Router-LSA without a companion RI LSA that has the bit set, all routers MUST recalculate routes without considering any network-to-router costs.
ビットが設定されているコンパニオンRI LSAなしで到達可能なルーターLSAの存在を検出すると、すべてのルーターは、ネットワークからルーターへのコストを考慮せずにルートを再計算する必要があります。
IANA has made the following assignments per this document:
IANAは、このドキュメントに従って次の割り当てを行いました。
o Two-Part Metric support (6) was added to the "OSPF Router Informational Capability Bits" registry.
o 2部分メトリックサポート（6）が「OSPFルーター情報機能ビット」レジストリに追加されました。
o Network-to-Router Metric Sub-TLV (4) has been added to the "OSPFv2 Extended Link TLV Sub-TLVs" registry.
o Network-to-Router Metric Sub-TLV（4）が「OSPFv2 Extended Link TLV Sub-TLVs」レジストリに追加されました。
o Network-to-Router TE Metric Sub-TLV (35) has been added to the "Types for sub-TLVs of TE Link TLV (Value 2)" registry.
o Network-to-Router TE Metric Sub-TLV（35）が「TE Link TLV（値2）のサブTLVのタイプ」レジストリに追加されました。
This document does not introduce new security risks. Existing security considerations in OSPFv2 and OSPFv3 apply.
このドキュメントでは、新しいセキュリティリスクを紹介していません。 OSPFv2およびOSPFv3の既存のセキュリティに関する考慮事項が適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<http：//www.rfc -editor.org/info/rfc3630>。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC4915] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、DOI 10.17487 / RFC4915、 2007年6月、<http://www.rfc-editor.org/info/rfc4915>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <http://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A.、and A. Lindem、Ed。、 "Traffic Engineering Extensions to OSPF Version 3"、RFC 5329、DOI 10.17487 / RFC5329、September 2008、<http： //www.rfc-editor.org/info/rfc5329>。
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <http://www.rfc-editor.org/info/rfc7684>.
[RFC7684] Psenak、P.、Gredler、H.、Shakir、R.、Henderickx、W.、Tantsura、J。、およびA. Lindem、「OSPFv2 Prefix / Link Attribute Advertisement」、RFC 7684、DOI 10.17487 / RFC7684、 2015年11月、<http://www.rfc-editor.org/info/rfc7684>。
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <http://www.rfc-editor.org/info/rfc7770>.
[RFC7770] Lindem、A.、Ed。、Shen、N.、Vasseur、JP。、Aggarwal、R.、and S. Shaffer、 "Extensions to OSPF for Advertising Optional Router Capabilities"、RFC 7770、DOI 10.17487 / RFC7770、 2016年2月、<http://www.rfc-editor.org/info/rfc7770>。
[OSPFV3-EXTENDED-LSA] Lindem, A., Mirtorabi, S., and A. Roy, "OSPFv3 LSA Extendibility", Work in Progress, draft-ietf-ospf-ospfv3- lsa-extend-13.txt, October 2016.
[OSPFV3-EXTENDED-LSA] Lindem、A.、Mirtorabi、S。、およびA. Roy、「OSPFv3 LSA Extendibility」、Work in Progress、draft-ietf-ospf-ospfv3- lsa-extend-13.txt、2016年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<http：//www.rfc-editor .org / info / rfc5340>。
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, <http://www.rfc-editor.org/info/rfc6845>.
[RFC6845] Sheth、N.、Wang、L。、およびJ. Zhang、「OSPFハイブリッドブロードキャストおよびポイントツーマルチポイントインターフェイスタイプ」、RFC 6845、DOI 10.17487 / RFC6845、2013年1月、<http：// www。 rfc-editor.org/info/rfc6845>。
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.
[RFC6987] Retana、A.、Nguyen、L.、Zinin、A.、White、R。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 6987、DOI 10.17487 / RFC6987、2013年9月、<http：/ /www.rfc-editor.org/info/rfc6987>。
Acknowledgements
謝辞
The authors would like to thank Abhay Roy, Hannes Gredler, Peter Psenak, and Eric Wu for their comments and suggestions.
著者は、コメントと提案を提供してくれたAbhay Roy、Hannes Gredler、Peter Psenak、およびEric Wuに感謝します。
Contributors
貢献者
David Dubois General Dynamics C4S 400 John Quincy Adams Road Taunton, MA 02780 United States of America Email: dave.dubois@gd-ms.com
David Dubois General Dynamics C4S 400 John Quincy Adams Road Taunton、MA 02780 United States of Email Email：dave.dubois@gd-ms.com
Vibhor Julka Individual Contributor
Vibhor Julka個人貢献者
Email: vjulka1@yahoo.com
Tom McMillan L3 Communications, Linkabit 9890 Towne Centre Drive San Diego, CA 92121 United States of America Email: tom.mcmillan@l-3com.com
Tom McMillan L3 Communications、Linkabit 9890 Towne Center Drive San Diego、CA 92121 United States of Email Email：tom.mcmillan@l-3com.com
Authors' Addresses
著者のアドレス
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Zhaohui Zhang Juniper Networks、Inc. 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: zzhang@juniper.net
Lili Wang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Lili Wang Juniper Networks、Inc. 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: liliw@juniper.net
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem Cisco Systems 301 Midenhall Way Cary、NC 27513アメリカ合衆国
Email: acee@cisco.com