[要約] RFC 7770は、OSPFにおけるオプションのルーター機能の広告に関する拡張を提供します。このRFCの目的は、ネットワーク管理者がルーターの機能をより効果的に制御し、ネットワークのパフォーマンスを最適化することです。
Internet Engineering Task Force (IETF) A. Lindem, Ed.
Request for Comments: 7770 N. Shen
Obsoletes: 4970 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Arktan
S. Shaffer
Akamai
February 2016
Extensions to OSPF for Advertising Optional Router Capabilities
オプションのルーター機能をアドバタイズするためのOSPFの拡張
Abstract
概要
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.
OSPFv2またはOSPFv3ルーティングドメイン内のルーターが、隣接するルーターおよびルーティングドメイン内の他のルーターの機能を知るのに役立ちます。このドキュメントでは、オプションのルーター機能をアドバタイズするためのOSPFv2およびOSPFv3への拡張を提案します。この目的のために、ルーター情報（RI）リンク状態アドバタイズ（LSA）が定義されています。 OSPFv2では、RI LSAはOpaque LSAタイプIDで実装されます。 OSPFv3では、RI LSAは一意のLSAタイプの機能コードで実装されます。どちらのプロトコルでも、RI LSAは、定義されたフラッディングスコープ（リンク、エリア、または自律システム（AS））のいずれかでアドバタイズできます。このドキュメントは、RI LSAの複数のインスタンスのアドバタイズのサポートと機能的な機能のTLVを含む改訂された仕様を提供することにより、RFC 4970を廃止します。
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/rfc7770.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7770で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3
2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 4
2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4
2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 5
2.3. OSPF Router Information LSA TLV Format . . . . . . . . . 6
2.4. OSPF Router Informational Capabilities TLV . . . . . . . 6
2.5. Assigned OSPF Router Informational Capability Bits . . . 7
2.6. OSPF Router Functional Capabilities TLV . . . . . . . . . 8
2.7. Flooding Scope of the Router Information LSA . . . . . . 9
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 10
5.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 10
5.3. OSPF RI LSA TLV Type Assignment . . . . . . . . . . . . . 11
5.4. Registry for OSPF Router Informational Capability Bits . 12
5.5. Registry for OSPF Router Functional Capability Bits . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFv3] routing domain to know the capabilities of their neighbors and other routers in the routing domain. This can be useful for both the advertisement and discovery of OSPFv2 and OSPFv3 capabilities. Throughout this document, OSPF will be used when the specification is applicable to both OSPFv2 and OSPFv3. Similarly, OSPFv2 or OSPFv3 will be used when the text is protocol specific.
OSPFv2 [OSPF]またはOSPFv3 [OSPFv3]ルーティングドメイン内のルーターが、隣接するルーターおよびルーティングドメイン内の他のルーターの機能を知るのに役立ちます。これは、OSPFv2およびOSPFv3機能のアドバタイズと検出の両方に役立ちます。このドキュメント全体を通して、仕様がOSPFv2とOSPFv3の両方に適用可能な場合、OSPFが使用されます。同様に、テキストがプロトコル固有である場合、OSPFv2またはOSPFv3が使用されます。
OSPF uses the options field in LSAs and hello packets to advertise optional router capabilities. In the case of OSPFv2, all the bits in this field have been allocated so additional optional capabilities cannot be advertised. This document describes extensions to OSPF to advertise these optional capabilities via Opaque LSAs in OSPFv2 and LSAs with a unique type in OSPFv3. For existing OSPF capabilities, backwards compatibility issues dictate that this advertisement is used primarily for informational purposes. For future OSPF extensions, this advertisement MAY be used as the sole mechanism for advertisement and discovery.
OSPFは、LSAおよびhelloパケットのオプションフィールドを使用して、オプションのルーター機能をアドバタイズします。 OSPFv2の場合、このフィールドのすべてのビットが割り当てられているため、追加のオプション機能をアドバタイズできません。このドキュメントでは、OSPFv2の不透明LSAとOSPFv3の一意のタイプのLSAを介してこれらのオプション機能をアドバタイズするためのOSPFの拡張機能について説明します。既存のOSPF機能の場合、下位互換性の問題により、この提供情報は主に情報提供の目的で使用されます。今後のOSPF拡張では、このアドバタイズはアドバタイズとディスカバリの唯一のメカニズムとして使用される可能性があります。
This document obsoletes RFC 4970 by providing a revised specification including support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.
このドキュメントは、RI LSAの複数インスタンスのアドバタイズメントのサポートと機能的な機能のTLVを含む改訂された仕様を提供することにより、RFC 4970を廃止します。
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-KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC-KEYWORDS]で説明されているように解釈されます。
This document includes the following changes from RFC 4970 [RFC4970]:
このドキュメントには、RFC 4970 [RFC4970]からの次の変更が含まれています。
1. The main change is that an OSPF router will be able to advertise multiple instances of the OSPF Router Information LSA. This change permeates through much of the document.
1. 主な変更は、OSPFルーターがOSPFルーター情報LSAの複数のインスタンスをアドバタイズできるようになることです。この変更は、ドキュメントの多くに浸透しています。
2. Additionally, Section 2.6 includes an additional TLV for functional capabilities. This is in contrast to the existing TLV that is used to advertise capabilities for informational purposes only.
2. さらに、セクション2.6には、機能的な機能のための追加のTLVが含まれています。これは、情報提供のみを目的として機能をアドバタイズするために使用される既存のTLVとは対照的です。
3. The IANA allocation policy has been changed from "Standards Action" to "IETF Review" [IANA-GUIDE] for the following registries:
3. 以下のレジストリについて、IANA割り当てポリシーが「標準アクション」から「IETFレビュー」[IANA-GUIDE]に変更されました。
o OSPFv3 LSA Function Codes o OSPF Router Information (RI) TLVs o OSPF Router Informational Capability Bits o OSPF Router Functional Capability Bits
o OSPFv3 LSA機能コードo OSPFルーター情報（RI）TLV o OSPFルーター情報機能ビットo OSPFルーター機能機能ビット
4. Finally, references have been updated for documents that have become RFCs and RFCs that have been obsoleted since the publication of RFC 4970.
4. 最後に、RFCおよびRFC 4970の発行後に廃止されたRFCになったドキュメントの参照が更新されました。
OSPFv2 routers will advertise a link scoped, area-scoped, or AS-scoped Opaque LSA [OPAQUE]. The OSPFv2 RI LSA has an Opaque type of 4 and the Opaque ID is the RI LSA Instance ID. The first Opaque ID, i.e., 0, SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV. RI LSA instances subsequent to the first can be used for information that doesn't fit in the first instance.
OSPFv2ルーターは、リンクスコープ、エリアスコープ、またはASスコープの不透明LSA [OPAQUE]をアドバタイズします。 OSPFv2 RI LSAの不透明タイプは4で、不透明IDはRI LSAインスタンスIDです。最初の不透明ID、つまり0には、常にルーター情報機能TLV、およびアドバタイズされている場合はルーター機能機能TLVが含まれている必要があります（SHOULD）。最初のインスタンスに続くRI LSAインスタンスは、最初のインスタンスに適合しない情報に使用できます。
OSPFv2 routers will advertise a link-scoped, area-scoped, or AS-scoped Opaque LSA [OPAQUE]. The OSPFv2 Router Information LSA has an Opaque type of 4. The Opaque ID specifies the LSA Instance ID with the first instance always having an Instance ID of 0.
OSPFv2ルーターは、リンクスコープ、エリアスコープ、またはASスコープのOpaque LSA [OPAQUE]をアドバタイズします。 OSPFv2ルーター情報LSAの不透明タイプは4です。不透明IDはLSAインスタンスIDを指定し、最初のインスタンスは常にインスタンスIDが0です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Opaque ID (Instance ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+d-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 1. OSPFv2 Router Information Opaque LSA
図1. OSPFv2ルーター情報の不透明なLSA
The format of the TLVs within the body of an RI LSA is as defined in Section 2.3.
RI LSAの本体内のTLVの形式は、セクション2.3で定義されています。
The OSPFv3 Router Information LSA has a function code of 12 while the S1/S2 bits are dependent on the desired flooding scope for the LSA. The U bit will be set indicating that the OSPFv3 RI LSA should be flooded even if it is not understood. The Link State ID (LSID) value for this LSA is the Instance ID. The first Instance ID, i.e., 0, SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV. OSPFv3 Router Information LSAs subsequent to the first can be used for information that doesn't fit in the first instance. OSPFv3 routers MAY advertise multiple RI LSAs per flooding scope.
OSPFv3ルーター情報LSAの機能コードは12ですが、S1 / S2ビットはLSAに必要なフラッディングスコープに依存しています。 Uビットが設定され、OSPFv3 RI LSAが理解されていなくてもフラッディングする必要があることを示します。このLSAのリンク状態ID（LSID）値はインスタンスIDです。最初のインスタンスID、つまり0には、常にルーター情報機能TLV、およびアドバタイズされている場合はルーター機能機能TLVが含まれている必要があります（SHOULD）。最初のインスタンスに続くOSPFv3ルーター情報LSAは、最初のインスタンスに適合しない情報に使用できます。 OSPFv3ルーターは、フラッディングスコープごとに複数のRI LSAを通知する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|S12| 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (Instance ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 2. OSPFv3 Router Information LSA
図2. OSPFv3ルーター情報LSA
The format of the TLVs within the body of an RI LSA is as defined in Section 2.3
RI LSAの本体内のTLVの形式は、セクション2.3で定義されています。
The format of the TLVs within the body of an RI LSA is the same as the format used by the Traffic Engineering Extensions to OSPF [TE]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is:
RI LSAの本体内のTLVの形式は、OSPFへのトラフィックエンジニアリング拡張[TE]で使用される形式と同じです。 LSAペイロードは、1つ以上のネストされたタイプ/長さ/値（TLV）トリプレットで構成されます。各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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. TLV Format
図3. TLVフォーマット
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 4-octet aligned. For example, a 1-octet value would have the length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. The padding is composed of undefined bits. Unrecognized types are ignored.
長さフィールドは、値の部分の長さをオクテットで定義します（したがって、値の部分がないTLVの長さは0になります）。 TLVは4オクテットアライメントにパディングされます。パディングは長さフィールドに含まれません（したがって、3オクテットの値の長さは3になりますが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも4オクテットで整列されます。たとえば、1オクテットの値では長さフィールドが1に設定され、3オクテットのパディングがTLVの値部分の最後に追加されます。パディングは未定義のビットで構成されています。認識されないタイプは無視されます。
When a new Router Information LSA TLV is defined, the specification MUST explicitly state whether the TLV is applicable to OSPFv2 only, OSPFv3 only, or both OSPFv2 and OSPFv3.
新しいルーター情報LSA TLVが定義されるとき、仕様はTLVがOSPFv2のみ、OSPFv3のみ、またはOSPFv2とOSPFv3の両方に適用可能であるかを明示的に述べなければなりません（MUST）。
An OSPF router advertising an OSPF RI LSA MAY include the Router Informational Capabilities TLV. If included, it MUST be the first TLV in the first instance, i.e., Instance 0, of the OSPF RI LSA. Additionally, the TLV MUST accurately reflect the OSPF router's capabilities in the scope advertised. However, the informational capabilities advertised have no impact on OSPF protocol operation; they are advertised purely for informational purposes.
OSPF RI LSAをアドバタイズするOSPFルーターには、ルーター情報機能TLVが含まれる場合があります。含める場合は、OSPF RI LSAの最初のインスタンス、つまりインスタンス0の最初のTLVにする必要があります。さらに、TLVは、アドバタイズされるスコープ内のOSPFルーターの機能を正確に反映する必要があります。ただし、アドバタイズされる情報機能は、OSPFプロトコルの動作に影響を与えません。情報提供のみを目的として宣伝されています。
The format of the Router Informational Capabilities TLV is as follows:
ルータ情報機能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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Informational Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A 16-bit field set to 1.
タイプ1に設定された16ビットフィールド。
Length A 16-bit field that indicates the length of the value portion in octets and will be a multiple of 4 octets dependent on the number of capabilities advertised. Initially, the length will be 4, denoting 4 octets of informational capability bits.
長さオクテットで値部分の長さを示す16ビットのフィールドであり、アドバタイズされる機能の数に応じて4オクテットの倍数になります。最初は、長さは4で、情報オクテットビットが4オクテットであることを示します。
Value A variable-length sequence of capability bits rounded to a multiple of 4 octets padded with undefined bits. Initially, there are 4 octets of capability bits. Bits are numbered left to right starting with the most significant bit being bit 0.
値未定義のビットが埋め込まれた4オクテットの倍数に丸められた機能ビットの可変長シーケンス。最初は、4オクテットの機能ビットがあります。ビットは左から右に番号が付けられ、最上位ビットはビット0です。
Figure 4. OSPF Router Informational Capabilities TLV
図4. OSPFルーターの情報機能TLV
The Router Informational Capabilities TLV MAY be followed by optional TLVs that further specify a capability.
ルーター情報機能TLVの後に、機能をさらに指定するオプションのTLVが続く場合があります。
The following informational capability bits have been assigned:
次の情報機能ビットが割り当てられています。
Bit Capabilities
ビット機能
0 OSPF graceful restart capable [GRACE]
1 OSPF graceful restart helper [GRACE]
2 OSPF Stub Router support [STUB]
3 OSPF Traffic Engineering support [TE]
4 OSPF point-to-point over LAN [P2PLAN]
5 OSPF Experimental TE [EXP-TE]
6-31 Unassigned (IETF Review)
Figure 5. OSPF Router Informational Capabilities Bits
図5. OSPFルーターの情報機能ビット
References for [GRACE], [STUB], [TE], [P2PLAN], and [EXP-TE] are included herein.
[GRACE]、[STUB]、[TE]、[P2PLAN]、および[EXP-TE]の参照は、ここに含まれています。
This specification also defines the Router Functional Capabilities TLV for advertisement in the OSPF Router Information LSA. An OSPF router advertising an OSPF RI LSA MAY include the Router Functional Capabilities TLV. If included, it MUST be the included in the first instance of the LSA. Additionally, the TLV MUST reflect the advertising OSPF router's actual functional capabilities since the information will be used to dictate OSPF protocol operation in the flooding scope of the containing OSPF RI LSA. If the TLV is not included or the length doesn't include the assigned OSPF functional capability bit, the corresponding OSPF functional capability is implicitly advertised as not being supported by the advertising OSPF router.
この仕様は、OSPFルーター情報LSAでの通知用のルーター機能機能TLVも定義しています。 OSPF RI LSAをアドバタイズするOSPFルーターには、ルーター機能機能TLVが含まれる場合があります。含まれている場合は、LSAの最初のインスタンスに含まれている必要があります。さらに、情報は、含まれているOSPF RI LSAのフラッディングスコープでOSPFプロトコルの動作を指示するために使用されるため、TLVは、アドバタイズするOSPFルーターの実際の機能を反映する必要があります。 TLVが含まれていないか、割り当てられたOSPF機能能力ビットが長さに含まれていない場合、対応するOSPF機能機能は、アドバタイズOSPFルーターによってサポートされていないものとして暗黙的にアドバタイズされます。
The format of the Router Functional Capabilities TLV is as follows:
ルータ機能機能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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Functional Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A 16-bit field set to 2.
タイプ2に設定された16ビットフィールド。
Length A 16-bit field that indicates the length of the value portion in octets and will be a multiple of 4 octets dependent on the number of capabilities advertised. Initially, the length will be 4, denoting 4 octets of informational capability bits.
長さオクテットで値部分の長さを示す16ビットのフィールドであり、アドバタイズされる機能の数に応じて4オクテットの倍数になります。最初は、長さは4で、情報オクテットビットが4オクテットであることを示します。
Value A variable-length sequence of capability bits rounded to a multiple of 4 octets padded with undefined bits. Initially, there are 4 octets of capability bits. Bits are numbered left to right starting with the most significant bit being bit 0.
値未定義のビットが埋め込まれた4オクテットの倍数に丸められた機能ビットの可変長シーケンス。最初は、4オクテットの機能ビットがあります。ビットは左から右に番号が付けられ、最上位ビットはビット0です。
Figure 6. OSPF Router Functional Capabilities TLV
図6. OSPFルーター機能能力TLV
The Router Functional Capabilities TLV MAY be followed by optional TLVs that further specify a capability. In contrast to the Router Informational Capabilities TLV, the OSPF extensions advertised in this TLV MAY be used by other OSPF routers to dictate protocol operation. The specifications for functional capabilities advertised in this TLV MUST describe protocol behavior and address backwards compatibility.
ルーター機能機能TLVの後には、機能をさらに指定するオプションのTLVが続く場合があります。ルーター情報機能TLVとは対照的に、このTLVでアドバタイズされるOSPF拡張機能は、プロトコルの動作を指示するために他のOSPFルーターで使用される場合があります。このTLVでアドバタイズされる機能機能の仕様は、プロトコルの動作を記述し、下位互換性に対処する必要があります。
The flooding scope for a Router Information LSA is determined by the LSA type. For OSPFv2, a type 9 (link-scoped), type 10 (area-scoped), or type 11 (AS-scoped) Opaque LSA may be flooded. For OSPFv3, the S1 and S2 bits in the LSA type determine the flooding scope. If AS-wide flooding scope is chosen, the originating router should also advertise area-scoped LSA(s) into any attached Not-So-Stubby Area (NSSA) area(s). An OSPF router MAY advertise different capabilities when both NSSA area-scoped LSA(s) and an AS-scoped LSA are advertised. This allows functional capabilities to be limited in scope. For example, a router may be an area border router but only support traffic engineering (TE) in a subset of its attached areas.
ルーター情報LSAのフラッディングスコープは、LSAタイプによって決定されます。 OSPFv2の場合、タイプ9（リンクスコープ）、タイプ10（エリアスコープ）、またはタイプ11（ASスコープ）の不透明LSAがフラッディングされる可能性があります。 OSPFv3の場合、LSAタイプのS1およびS2ビットがフラッディングスコープを決定します。 AS全体のフラッディングスコープが選択されている場合、発信元ルーターは、エリアスコープのLSAを、接続されているNot-So-Stubby Area（NSSA）エリアにもアドバタイズする必要があります。 OSPFルーターは、NSSAエリアスコープのLSAとASスコープのLSAの両方がアドバタイズされる場合に、異なる機能をアドバタイズする場合があります。これにより、機能の範囲を制限できます。たとえば、ルーターはエリア境界ルーターであっても、接続されたエリアのサブセットでのみトラフィックエンジニアリング（TE）をサポートします。
The choice of flooding scope is made by the advertising router and is a matter of local policy. The originating router MAY advertise multiple RI LSAs with the same Instance ID as long as the flooding scopes differ. TLV flooding-scope rules will be specified on a per-TLV basis and MUST be specified in the accompanying specifications for future Router Information LSA TLVs.
フラッディングスコープの選択はアドバタイズルータによって行われ、ローカルポリシーの問題です。発信ルーターは、フラッディングスコープが異なる限り、同じインスタンスIDを持つ複数のRI LSAをアドバタイズできます（MAY）。 TLVフラッディングスコープルールは、TLVごとに指定され、将来のルーター情報LSA TLVの付随する仕様で指定する必要があります。
For backwards compatibility, previously advertised Router Information TLVs SHOULD continue to be advertised in the first instance, i.e., 0, of the Router Information LSA. If a Router Information TLV is advertised in multiple Router Information LSA instances and the multiple instance processing is not explicitly specified in the RFC defining that Router Information TLV, the Router Instance TLV in the Router Information LSA with the numerically smallest Instance ID will be used and subsequent instances will be ignored.
下位互換性のために、以前にアドバタイズされたルーター情報TLVは、ルーター情報LSAの最初のインスタンス、つまり0で引き続きアドバタイズされる必要があります（SHOULD）。ルーター情報TLVが複数のルーター情報LSAインスタンスでアドバタイズされ、そのルーター情報TLVを定義するRFCで複数インスタンス処理が明示的に指定されていない場合、インスタンスIDが数値的に最小のルーター情報LSAのルーターインスタンスTLVが使用され、後続のインスタンスは無視されます。
This document describes both a generic mechanism for advertising router capabilities and TLVs for advertising informational and functional capabilities. The capability TLVs are less critical than the topology information currently advertised by the base OSPF protocol. The security considerations for the generic mechanism are dependent on the future application and, as such, should be described as additional capabilities are proposed for advertisement. Security considerations for the base OSPF protocol are covered in [OSPF] and [OSPFv3].
このドキュメントでは、ルーター機能をアドバタイズするための一般的なメカニズムと、情報機能および機能機能をアドバタイズするためのTLVの両方について説明します。機能TLVは、基本のOSPFプロトコルによって現在アドバタイズされているトポロジ情報ほど重要ではありません。一般的なメカニズムのセキュリティに関する考慮事項は、将来のアプリケーションに依存しているため、追加の機能がアドバタイズのために提案されているため、そのように説明する必要があります。基本OSPFプロトコルのセキュリティに関する考慮事項は、[OSPF]および[OSPFv3]で説明されています。
[RFC4970] defined the Router Information Opaque LSA as type 4 in the "Opaque Link-State Advertisements (LSA) Option Types" registry. IANA has updated the reference for that entry to point to this RFC.
[RFC4970]は、「不透明なリンクステートアドバタイズメント（LSA）オプションタイプ」レジストリでルーター情報不透明LSAをタイプ4として定義しました。 IANAは、このRFCを指すようにそのエントリの参照を更新しました。
[RFC4970] created the registry for "OSPFv3 LSA Function Codes". IANA has updated the reference for that registry to point to this RFC. References within that registry to [RFC4970] have been updated to point to this RFC; references to other RFCs are unchanged.
[RFC4970]は、「OSPFv3 LSA機能コード」のレジストリを作成しました。 IANAは、このレジストリをこのRFCを指すように更新しました。そのレジストリ内の[RFC4970]への参照は、このRFCを指すように更新されました。他のRFCへの参照は変更されていません。
The definition and assignment policy has been updated as follows.
定義と割り当てのポリシーが次のように更新されました。
This registry is now comprised of the fields Value, LSA Function Code Name, and Reference. The OSPFv3 LSA function code is defined in Appendix A.4.2.1 of [OSPFv3]. Values 1-11 and 13-15 have already been assigned. The OSPFv3 LSA function code 12 has been assigned to the OSPFv3 Router Information (RI) LSA as defined herein.
このレジストリは、Value、LSA Function Code Name、およびReferenceフィールドで構成されています。 OSPFv3 LSA機能コードは、[OSPFv3]の付録A.4.2.1で定義されています。値1-11および13-15はすでに割り当てられています。 OSPFv3 LSA機能コード12は、ここで定義されているように、OSPFv3ルーター情報（RI）LSAに割り当てられています。
+-----------+-------------------------------------+
| Range | Assignment Policy |
+-----------+-------------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 16-255 | Unassigned (IETF Review) |
| | |
| 256-8175 | Reserved (No assignments) |
| | |
| 8176-8183 | Experimentation (No assignments) |
| | |
| 8184-8190 | Vendor Private Use (No assignments) |
| | |
| 8191 | Reserved (not to be assigned) |
+-----------+-------------------------------------+
Figure 7. OSPFv3 LSA Function Codes
図7. OSPFv3 LSA機能コード
o The assignment policy for OSPFv3 LSA function codes in the range 16-255 has changed and are now assigned subject to IETF Review. New values are assigned through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG documents [IANA-GUIDE].
o 16〜255の範囲のOSPFv3 LSA機能コードの割り当てポリシーが変更され、IETFレビューの対象として割り当てられるようになりました。新しい値は、ADスポンサードまたはIETF WGドキュメント[IANA-GUIDE]としてIESGを介して導入されたRFCを通じて割り当てられます。
o OSPFv3 LSA function codes in the range 8176-8183 are for experimental use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
o 8176〜8183の範囲のOSPFv3 LSA機能コードは実験用です。これらはIANAに登録されず、RFCで言及されてはなりません。
o OSPFv3 LSAs with an LSA Function Code in the Vendor Private Use range 8184-8190 MUST include the Enterprise Code [ENTERPRISE-CODE] as the first 4 octets following the 20 octets of LSA header.
o LSA機能コードがベンダーのプライベート使用範囲8184-8190のOSPFv3 LSAには、エンタープライズコード[ENTERPRISE-CODE]を、LSAヘッダーの20オクテットに続く最初の4オクテットとして含める必要があります。
o If a new LSA Function Code is documented, the documentation MUST include the valid combinations of the U, S2, and S1 bits for the LSA. It SHOULD also describe how the Link State ID is to be assigned.
o 新しいLSA機能コードが文書化されている場合、文書にはLSAのU、S2、およびS1ビットの有効な組み合わせを含める必要があります。また、リンク状態IDの割り当て方法についても説明する必要があります。
[RFC4970] created the registry for "OSPF Router Information (RI) TLVs". IANA has updated the reference for this registry to point to this RFC. References within that registry to [RFC4970] have been updated to point to this RFC; references to other RFCs are unchanged.
[RFC4970]は、「OSPFルーター情報（RI）TLV」のレジストリを作成しました。 IANAは、このレジストリの参照を更新して、このRFCを指すようにしました。そのレジストリ内の[RFC4970]への参照は、このRFCを指すように更新されました。他のRFCへの参照は変更されていません。
The definition and assignment policy has been updated as follows.
定義と割り当てのポリシーが次のように更新されました。
The registry is now comprised of the fields Value, TLV Name, and Reference. Values 3-9 have already been assigned. Value 1 has been assigned to the Router Informational Capabilities TLV and value 2 has been assigned to the Router Functional Capabilities TLV as defined herein.
レジストリは、Value、TLV Name、およびReferenceフィールドで構成されています。値3〜9は既に割り当てられています。ここで定義されているように、値1はルーター情報機能TLVに割り当てられ、値2はルーター機能機能TLVに割り当てられています。
+-------------+-----------------------------------+
| Range | Assignment Policy |
+-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 10-32767 | Unassigned (IETF Review) |
| | |
| 32768-32777 | Experimentation (No assignments) |
| | |
| 32778-65535 | Reserved (Not to be assigned) |
+-------------+-----------------------------------+
Figure 8. OSPF RI TLVs
図8. OSPF RI TLV
o Types in the range 10-32767 are to be assigned subject to IETF Review. New values are assigned through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG documents [IANA-GUIDE].
o 10-32767の範囲のタイプは、IETFレビューの対象として割り当てられます。新しい値は、ADスポンサードまたはIETF WGドキュメント[IANA-GUIDE]としてIESGを介して導入されたRFCを通じて割り当てられます。
o Types in the range 32778-65535 are reserved and are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that cover the range being assigned.
o 32778〜65535の範囲のタイプは予約されており、現時点では割り当てられません。この範囲内で割り当てを行う前に、割り当てられる範囲をカバーするIANAの考慮事項を指定する標準規格トラックRFCが存在する必要があります。
[RFC4970] created the registry for "OSPF Router Informational Capability Bits". IANA has updated the reference for this registry to point to this RFC. The definition and assignment policy has been updated as follows.
[RFC4970]は、「OSPFルーター情報機能ビット」のレジストリを作成しました。 IANAは、このレジストリの参照を更新して、このRFCを指すようにしました。定義と割り当てのポリシーが次のように更新されました。
o This registry is now comprised of the fields Bit Number, Capability Name, and Reference.
o このレジストリは現在、ビット番号、機能名、および参照のフィールドで構成されています。
o The values are defined in Section 2.6. All Router Informational Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE].
o 値はセクション2.6で定義されています。すべてのルーター情報機能TLVの追加は、IETFレビュー[IANA-GUIDE]を通じて割り当てられます。
IANA has created a subregistry for "OSPF Router Functional Capability Bits" within the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. This subregistry is comprised of the fields Bit Number, Capability Name, and Reference. Initially, the subregistry will be empty but will be available for future capabilities. All Router Functional Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE].
IANAは、「Open Shortest Path First v2（OSPFv2）Parameters」レジストリ内に「OSPFルーター機能ビット」のサブレジストリを作成しました。このサブレジストリは、ビット番号、機能名、および参照のフィールドで構成されています。最初は、サブレジストリは空ですが、将来の機能で使用できます。すべてのルーター機能機能TLVの追加は、IETFレビュー[IANA-GUIDE]を通じて割り当てられます。
[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, <http://www.rfc-editor.org/info/rfc5250>.
[OPAQUE] Berger、L.、Bryskin、I.、Zinin、A。、およびR. Coltun、「OSPF Opaque LSAオプション」、RFC 5250、DOI 10.17487 / RFC5250、2008年7月、<http：//www.rfc -editor.org/info/rfc5250>。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[OSPFv3] 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>.
[OSPFv3] 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>。
[RFC-KEYWORDS] 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>.
[RFC-KEYWORDS] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/ info / rfc2119>。
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 2007, <http://www.rfc-editor.org/info/rfc4970>.
[RFC4970] Lindem、A.、Ed。、Shen、N.、Vasseur、JP。、Aggarwal、R.、and S. Shaffer、 "Extensions to OSPF for Advertising Optional Router Capabilities"、RFC 4970、DOI 10.17487 / RFC4970、 2007年7月、<http://www.rfc-editor.org/info/rfc4970>。
[TE] 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>.
[TE] 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>。
[ENTERPRISE-CODE] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, <http://www.rfc-editor.org/info/rfc5612>.
[エンタープライズコード] Eronen、P。およびD. Harrington、「ドキュメント使用のためのエンタープライズ番号」、RFC 5612、DOI 10.17487 / RFC5612、2009年8月、<http://www.rfc-editor.org/info/rfc5612> 。
[EXP-TE] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering", RFC 4973, DOI 10.17487/RFC4973, July 2007, <http://www.rfc-editor.org/info/rfc4973>.
[EXP-TE] Srisuresh、P。およびP. Joseph、「OSPF-xTE：OSPFに対するOSPFのトラフィックエンジニアリングの実験的拡張」、RFC 4973、DOI 10.17487 / RFC4973、2007年7月、<http：//www.rfc-editor。 org / info / rfc4973>。
[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003, <http://www.rfc-editor.org/info/rfc3623>.
[GRACE] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、RFC 3623、DOI 10.17487 / RFC3623、2003年11月、<http://www.rfc-editor.org/ info / rfc3623>。
[IANA-GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[IANA-GUIDE] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http：//www.rfc-editor .org / info / rfc5226>。
[P2PLAN] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, <http://www.rfc-editor.org/info/rfc5309>.
[P2PLAN] Shen、N。、編、およびA. Zinin、編、「リンクステートルーティングプロトコルにおけるLAN経由のポイントツーポイント操作」、RFC 5309、DOI 10.17487 / RFC5309、2008年10月、<http：/ /www.rfc-editor.org/info/rfc5309>。
[STUB] 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>.
[STUB] 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>。
Acknowledgments
謝辞
The idea for this work grew out of a conversation with Andrew Partan and we thank him for his contribution. The authors thank Peter Psenak for his review and helpful comments on early draft versions of the document.
この作品のアイデアは、Andrew Partanとの会話から生まれました。彼の貢献に感謝します。著者は、レビューとドキュメントの初期ドラフトバージョンに関する有益なコメントを提供してくれたPeter Psenakに感謝します。
Special thanks to Tom Petch for providing the updated IANA text in this document.
このドキュメントの更新されたIANAテキストを提供してくれたTom Petchに特に感謝します。
Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian Farrel have been incorporated into later draft versions of this document.
Abhay Roy、Vishwas Manral、Vivek Dubey、およびAdrian Farrelからのコメントは、このドキュメントの後のドラフトバージョンに組み込まれています。
Thanks to Yingzhen Qu for acting as document shepherd.
ドキュメントシェパードを務めてくれたYingzhen Quに感謝します。
Thanks to Chris Bowers, Alia Atlas, Shraddha Hegde, Dan Romascanu, and Victor Kuarsingh for review of this document.
このドキュメントをレビューしてくれたChris Bowers、Alia Atlas、Shraddha Hegde、Dan Romascanu、Victor Kuarsinghに感謝します。
Authors' Addresses
著者のアドレス
Acee Lindem (editor) Cisco Systems 301 Midenhall Way Cary, NC 27513 United States
Acee Lindem（編集者）Cisco Systems 301 Midenhall Way Cary、NC 27513米国
Email: acee@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 United States
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: naiming@cisco.com
Jean-Philippe Vasseur Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 United States
じぇあんーＰひぃっぺ ゔぁっせうｒ しｓこ Ｓｙｓてｍｓ １４１４ まっさちゅせっｔｓ あゔぇぬえ ぼｘぼろうｇｈ、 ま ０１７１９ うにてｄ Ｓたてｓ
Email: jpv@cisco.com
Rahul Aggarwal Arktan
ラフル・アガーワル・アークタン
Email: raggarwa_1@yahoo.com
Scott Shaffer Akamai 8 Cambridge Center Cambridge, MA 02142 United States
Scott Shaffer Akamai 8 Cambridge Center Cambridge、MA 02142 United States
Email: sshaffer@akamai.com