[要約] RFC 4970は、OSPFにおけるオプションのルーター機能の広告に関する拡張を提供しています。このRFCの目的は、ネットワーク上のルーターが持つ追加の機能を広告するための仕組みを提供することです。
Network Working Group A. Lindem, Ed.
Request for Comments: 4970 Redback Networks
Category: Standards Track N. Shen
JP. Vasseur
Cisco Systems
R. Aggarwal
Juniper Networks
S. Shaffer
BridgePort Networks
July 2007
Extensions to OSPF for Advertising Optional Router Capabilities
オプションのルーター機能を広告するためのOSPFへの拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new 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)).
OSPFV2またはOSPFV3ルーティングドメインのルーターが、ルーティングドメイン内の隣人や他のルーターの機能を知るのに役立ちます。このドキュメントは、オプションのルーター機能を広告するために、OSPFV2およびOSPFV3への拡張を提案しています。この目的のために、新しいルーター情報（RI）リンク状態広告（LSA）が提案されています。OSPFV2では、RI LSAは新しい不透明LSAタイプIDで実装されます。OSPFV3では、RI LSAは新しいLSA型関数コードで実装されます。両方のプロトコルで、RI LSAは、定義された洪水スコープ（リンク、面積、または自律システム（AS））のいずれかで宣伝できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . . 3
2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 3
2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 5
2.3. OSPF Router Informational Capabilities TLV . . . . . . . . 5
2.4. Assigned OSPF Router Informational Capability Bits . . . . 6
2.5. Flooding Scope of the Router Information LSA . . . . . . . 7
3. Router Information LSA Opaque Usage and Applicability . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
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 new optional capabilities cannot be advertised. This document proposes extensions to OSPF to advertise these optional capabilities via opaque LSAs in OSPFv2 and new LSAs in OSPFv3. For existing OSPF capabilities, backward- compatibility issues dictate that this advertisement is used primarily for informational purposes. For future OSPF features, this advertisement MAY be used as the sole mechanism for advertisement and discovery.
OSPFは、LSASおよびHello Packetのオプションフィールドを使用して、オプションのルーター機能を宣伝します。OSPFv2の場合、この分野のすべてのビットが割り当てられているため、新しいオプションの機能を宣伝できません。このドキュメントは、OSPF2の不透明なLSAとOSPFV3の新しいLSAを介してこれらのオプションの機能を宣伝するために、OSPFへの拡張を提案しています。既存のOSPF機能については、後方互換性の問題は、この広告が主に情報目的で使用されることを示しています。将来のOSPF機能のために、この広告は、広告と発見の唯一のメカニズムとして使用される場合があります。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[rfc-keywords]で説明されているように解釈されます。
OSPF routers MAY optionally advertise their optional capabilities in a link-scoped, area-scoped, or AS-scoped LSA. For existing OSPF capabilities, this advertisement will be used primarily for informational purposes. Future OSPF features could use the RI LSA as the sole mechanism for advertisement and discovery. The RI LSA will be originated initially when an OSPF router instance is created and whenever one of the advertised capabilities is configured or changed.
OSPFルーターは、オプションでオプションの機能をリンクスコープ、エリアスープ、またはスコープ付きLSAで宣伝する場合があります。既存のOSPF機能については、この広告は主に情報目的で使用されます。将来のOSPF機能は、広告と発見の唯一のメカニズムとしてRI LSAを使用できます。RI LSAは、OSPFルーターインスタンスが作成されたときに最初に発信され、宣伝された機能の1つが構成または変更されるたびに発信されます。
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 and Opaque ID of 0.
OSPFV2ルーターは、リンクスコープ、エリアスコープ、またはスコープされた不透明LSA [不透明]を宣伝します。OSPFV2ルーター情報LSAには、4の不透明なタイプと0の不透明なIDがあります。
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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv2 Router Information Opaque LSA
OSPFV2ルーター情報不透明LSA
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
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 32-bit aligned. For example, a 1-byte 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. Unrecognized types are ignored.
長さのフィールドは、オクテットの値部分の長さを定義します（したがって、値部分のないTLVの長さは0になります）。TLVは4-OCTETアライメントにパッドで埋められています。パディングは長さフィールドに含まれていません（したがって、3オクテットの値は3の長さですが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも32ビットアライメントされています。たとえば、1バイト値の長さフィールドは1に設定され、3オクテットのパディングがTLVの値部分の最後に追加されます。認識されていないタイプは無視されます。
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 0. This is unambiguous since an OSPFv3 router will only advertise a single RI LSA per flooding scope.
OSPFV3ルーター情報LSAは12の関数コードを持っていますが、S1/S2ビットはLSAの希望の洪水範囲に依存します。uビットは、たとえ理解されていなくても、ospfv3 ri lsaを浸水させるべきであることを示しています。このLSAのリンク状態ID（LSID）値は0です。これは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (Link State ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv3 Router Information LSA
OSPFV3ルーター情報LSA
The format of the TLVs within the body of an RI LSA is as defined in Section 2.1
ri LSAの本体内のTLVの形式は、セクション2.1で定義されています。
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の両方に適用できるかどうかを明示的に述べなければなりません。
The first defined TLV in the body of an RI LSA is the Router Informational Capabilities TLV. A router advertising an RI LSA MAY include the Router Informational Capabilities TLV. If included, it MUST be the first TLV in the 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 the OSPF protocol's operation -- they are advertised purely for informational purposes.
ri LSAの本体で最初に定義されたTLVは、ルーター情報能力TLVです。RILSAを宣伝するルーターには、ルーターの情報機能TLVが含まれる場合があります。含まれている場合、それはLSAの最初の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.
タイプA 16ビットフィールドを1に設定します。
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であることから、左から右への番号が付けられています。
OSPF Router Informational Capabilities TLV
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 are 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 (Standards Action)
OSPF Router Informational Capabilities Bits
OSPFルーター情報機能ビット
The flooding scope for a Router Information LSA is determined by the LSA type. For OSPFv2, type 9 (link-scoped), type 10 (area-scoped), or a 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（スコープ付き）不透明LSAが浸水する可能性があります。OSPFV3の場合、LSAタイプのS1およびS2ビットが洪水範囲を決定します。幅広の洪水スコープが選択されている場合、発信元のルーターは、エリアスコープ付きLSAを、添付されていないエリア（NSSA）エリアに宣伝する必要があります。OSPFルーターは、NSSAエリアの両方のLSAとASScoped 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 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 new Router Information LSA TLVs.
洪水範囲の選択は、広告ルーターによって行われ、ローカルポリシーの問題です。洪水スコープが異なる限り、発生するルーターは複数のRI LSAを宣伝する場合があります。TLVフラッドスコープルールは、TLVごとに指定され、新しいルーター情報LSA TLVの付随する仕様で指定する必要があります。
The purpose of the Router Information (RI) LSA is to advertise information relating to the aggregate OSPF router. Normally, this should be confined to TLVs with a single value or very few values. It is not meant to be a generic container to carry any and all information. The intent is to both limit the size of the RI LSA to the point where an OSPF router will always be able to contain the TLVs in a single LSA and to keep the task of determining what has changed between LSA instances reasonably simple. Hence, discretion and sound engineering judgment will need to be applied when deciding whether newly proposed TLV(s) in support of a new application are advertised in the RI LSA or warrant the creation of an application specific LSA.
ルーター情報（RI）LSAの目的は、集約OSPFルーターに関連する情報を宣伝することです。通常、これは単一の値または非常に少ない値でTLVに限定する必要があります。すべての情報を運ぶための一般的な容器であることを意図したものではありません。意図は、RI LSAのサイズを、OSPFルーターが常に単一のLSAにTLVを封じ込めることができるポイントに制限し、LSAインスタンス間で合理的に単純なものを決定するタスクを維持することです。したがって、新しいアプリケーションをサポートする新たに提案されたTLVがRI LSAで宣伝されるか、アプリケーション固有のLSAの作成を保証するかどうかを決定する際に、裁量と健全なエンジニアリングの判断を適用する必要があります。
This document describes both a generic mechanism for advertising router capabilities and a TLV for advertising informational capability bits. The latter TLV is 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]でカバーされています。
The following IANA assignment was made from an existing registry:
次のIANAの割り当ては、既存のレジストリから行われました。
The OSPFv2 opaque LSA type 4 has been reserved for the OSPFv2 RI opaque LSA.
OSPFV2不透明LSAタイプ4は、OSPFV2 RI Opaque LSAのために予約されています。
The following registries have been defined for the following purposes:
次のレジストリは、次の目的で定義されています。
1. Registry for OSPFv3 LSA Function Codes - This new top-level registry will be comprised of the fields Value, LSA function code name, and Document Reference. The OSPFv3 LSA function code is defined in section A.4.2.1 of [OSPFV3]. The OSPFv3 LSA function code 12 has been reserved for the OSPFv3 Router Information (RI) LSA.
1. OSPFV3 LSA関数コードのレジストリ - この新しいトップレベルレジストリは、フィールド値、LSA関数コード名、およびドキュメントリファレンスで構成されます。OSPFV3 LSA関数コードは、[OSPFV3]のセクションA.4.2.1で定義されています。OSPFV3 LSA関数コード12は、OSPFV3ルーター情報（RI）LSAのために予約されています。
+-----------+-------------------------------------+
| Range | Assignment Policy |
+-----------+-------------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 1-9 | Already assigned |
| | |
| 10-11 | Unassigned (Standards Action) |
| | |
| 12 | OSPFv3 RI LSA (Assigned herein) |
| | |
| 13-255 | Unassigned (Standards Action) |
| | |
| 256-8175 | Reserved (No assignments) |
| | |
| 8176-8183 | Experimentation (No assignments) |
| | |
| 8184-8191 | Vendor Private Use (No assignments) |
+-----------+-------------------------------------+
OSPFv3 LSA Function Codes
OSPFV3 LSA関数コード
* OSPFv3 LSA function codes in the range 256-8175 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.
* 範囲256-8175のOSPFV3 LSA関数コードは、現時点では割り当てられません。この範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定する標準トラックRFCが必要です。
* OSPFv3 LSA function codes in the range 8176-8181 are for experimental use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
* 範囲8176-8181のOSPFV3 LSA関数コードは実験用です。これらはIANAに登録されておらず、RFCSで言及してはなりません。
* OSPFv3 LSAs with an LSA Function Code in the Vendor Private Use range 8184-8191 MUST include the Vendor Enterprise Code as the first 4 octets following the 20 octets of LSA header.
* ベンダープライベート使用範囲にLSA関数コードを備えたOSPFV3 LSAS 8184-8191には、LSAヘッダーの20オクテットに続く最初の4オクテットとしてベンダーエンタープライズコードを含める必要があります。
* 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.
* 新しいLSA関数コードが文書化されている場合、ドキュメントには、LSAのU、S2、およびS1ビットの有効な組み合わせを含める必要があります。また、リンク状態IDがどのように割り当てられるかを説明する必要があります。
2. Registry for OSPF RI TLVs - This top-level registry will be comprised of the fields Value, TLV Name, and Document Reference. The value of 1 for the capabilities TLV is defined herein.
2. OSPF RI TLVSのレジストリ - このトップレベルのレジストリは、フィールド値、TLV名、およびドキュメントリファレンスで構成されます。TLVの機能の値は、本明細書で定義されています。
+-------------+-----------------------------------+
| Range | Assignment Policy |
+-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 1 | Already assigned |
| | |
| 2-32767 | Unassigned (Standards Action) |
| | |
| 32768-32777 | Experimentation (No assignements) |
| | |
| 32778-65535 | Reserved (Not to be assigned) |
+-----------+-------------------------------------+
OSPF RI TLVs
OSPF ri tlvs
* Types in the range 32768-32777 are for experimental use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
* 範囲32768-32777のタイプは、実験用のものです。これらはIANAに登録されておらず、RFCSで言及してはなりません。
* 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 covers the range being assigned.
* 範囲32778-65535のタイプは予約されており、現時点では割り当てられません。この範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定する標準トラックRFCが必要です。
3. Registry for OSPF Router Informational Capability Bits - This sub-registry of the OSPF RI TLV registry will be comprised of the fields Bit Number, Capability Name, and Document Reference. The values are defined in Section 2.4. All Router Informational Capability TLV additions are to be assigned through standards action.
3. OSPFルーターのレジストリ情報能力機能ビット - OSPF ri tlvレジストリのこのサブレジストリは、フィールドビット番号、機能名、およびドキュメント参照で構成されます。値はセクション2.4で定義されています。すべてのルーター情報機能TLVの追加は、標準アクションを通じて割り当てられます。
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[Opaque] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2370、1998年7月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[OSPFV3] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-Keywords] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003.
[Te] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering Extensions to OSPF」、RFC 3630、2003年9月。
[EXP-TE] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering", RFC 4973, July 2007.
[Exp-Te] Srisuresh、P。およびP. Joseph、「OSPF-XTE：トラフィックエンジニアリングのためのOSPFへの実験的拡張」、RFC 4973、2007年7月。
[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[Grace] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、RFC 3623、2003年11月。
[P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN in link-state routing protocols", Work in Progress, April 2006.
[P2Plan] Shen、N。およびA. Zinin、「リンク状態のルーティングプロトコルにおけるLAN上のポイントツーポイント操作」、2006年4月、進行中の作業。
[STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[Stub] Retana、A.、Nguyen、L.、White、R.、Zinin、A。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 3137、2001年6月。
The idea for this work grew out of a conversation with Andrew Partan and we would like to thank him for his contribution. The authors would like to thanks Peter Psenak for his review and helpful comments on early versions of the document.
この作品のアイデアは、アンドリュー・パルタンとの会話から生まれました。彼の貢献に感謝したいと思います。著者は、Peter Psenakのレビューと文書の初期バージョンに関する有益なコメントに感謝したいと思います。
Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian Farrel have been incorporated into later versions.
Abhay Roy、Vishwas Manral、Vivek Dubey、およびAdrian Farrelからのコメントは、後のバージョンに組み込まれています。
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、Marshall RoseのXML2RFCツールを使用して作成されました。
Authors' Addresses
著者のアドレス
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem（編集者）Redback Networks 102 Carric Bend Court Cary、NC 27519 USA
EMail: acee@redback.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
ナイミングシェンシスコシステム225ウェストタスマンドライブサンノゼ、カリフォルニア95134 USA
EMail: naiming@cisco.com
Jean-Philippe Vasseur Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Jean-Philippe Vasseur Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 USA
EMail: rahul@juniper.net
Scott Shaffer BridgePort Networks One Main Street, 7th Floor Cambridge, MA 02142 USA
Scott Shaffer Bridgeport Networks One Main Street、7階のケンブリッジ、マサチューセッツ州02142 USA
EMail: sshaffer@bridgeport-networks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。