RFC4970 日本語訳
4970 Extensions to OSPF for Advertising Optional Router Capabilities.A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. July 2007. (Format: TXT=26416 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループA.Lindem、エドをネットワークでつないでください。コメントのために以下を要求してください。 4970年の20ドル紙幣はカテゴリをネットワークでつなぎます: 規格はN.シンJPを追跡します。 S.シャッファーBridgePortが2007年7月にネットワークでつなぐVasseurシスコシステムズR.Aggarwal杜松ネットワーク
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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に拡大を提案します。 新しいRouter情報(ロードアイランド)リンク州Advertisement(LSA)はこのために提案されます。 OSPFv2では、RI LSAは新しい不透明なLSAタイプIDと共に実行されるでしょう。 OSPFv3では、RI LSAは新しいLSAタイプ機能コードで実行されるでしょう。 両方のプロトコルでは、定義された氾濫範囲(リンク、領域、または自律システム(AS))のいずれにもRI LSAの広告を出すことができます。
Lindem, et al. Standards Track [Page 1] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 要件記法. . . . . . . . . . . . . . . . . . 3 2 OSPFルータ情報(ロードアイランド)LSA. . . . . . . . . . . . . . . 3 2.1。 OSPFv2ルータ情報(ロードアイランド)の不透明なLSA. . . . . . . . 3 2.2。 OSPFv3ルータ情報(ロードアイランド)の不透明なLSA. . . . . . . . 5 2.3。 OSPFのルータの情報の能力TLV. . . . . . . . 5 2.4。 OSPFルータ情報の能力ビット. . . . 6 2.5は割り当てられます。 ルータ情報の範囲をLSA.7 3にあふれさせます。 ルータ情報LSAは用法と適用性. . . . 7 4について不透明にします。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 10付録A.承認. . . . . . . . . . . . . . . . . . . 11
Lindem, et al. Standards Track [Page 2] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[2ページ]。
1. Introduction
1. 序論
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のオプション分野を使用します、そして、こんにちは。任意のルータ能力の広告を出すパケット。 OSPFv2の場合では、任意の能力が広告を出すことができないようにとても新しい状態でこの分野のすべてのビットを割り当てました。 このドキュメントは、OSPFv3にOSPFv2の不透明なLSAsと新しいLSAsを通してこれらの任意の能力の広告を出すためにOSPFに拡大を提案します。 既存のOSPF能力のために、後方の互換性の問題は、この広告が主として情報の目的に使用されると決めます。 将来のOSPFの特徴に関しては、この広告は広告と発見に唯一のメカニズムとして使用されるかもしれません。
1.1. Requirements Notation
1.1. 要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-キーワード]で説明されるように本書では解釈されることであるべきですか?
2. OSPF Router Information (RI) LSA
2. OSPFルータ情報(ロードアイランド)LSA
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ルータはリンクで見られたか、領域で見られたか、ASによって見られたLSAに任意に彼らの任意の能力の広告を出すかもしれません。 既存のOSPF能力において、この広告は主として情報の目的に使用されるでしょう。 将来のOSPFの特徴は広告と発見に唯一のメカニズムとしてRI LSAを使用するかもしれません。 OSPFルータ例が作成されて、広告を出している能力の1つを構成するか、または変えるときはいつも、RI LSAは初めは、溯源されるでしょう。
2.1. OSPFv2 Router Information (RI) Opaque LSA
2.1. OSPFv2ルータ情報(ロードアイランド)の不透明な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 and Opaque ID of 0.
OSPFv2ルータは領域によって見られた状態で見られたリンク、またはASの見られたOpaque-LSA[OPAQUE]の広告を出すでしょう。 OSPFv2 Router情報LSAには、4人のOpaqueタイプと0のOpaque IDがあります。
Lindem, et al. Standards Track [Page 3] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[3ページ]。
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 -+
| ... |
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時代| オプション| 9、10、または11| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 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のボディーの中のTLVsの形式はTraffic Engineering ExtensionsによってOSPF[TE]に使用された形式と同じです。 LSAペイロードは1つ以上の入れ子にされたType/長さ/値(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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Length分野は八重奏における、値の部分の長さを定義します(その結果、値の部分のないTLVには、0の長さがあるでしょう)。 TLVは4八重奏の整列に水増しされます。 詰め物は長さの分野に含まれていません(3八重奏の値には、したがって、3の長さがあるでしょうが、TLVの総サイズは8つの八重奏でしょう)。 また、並べられた状態で、入れ子にされたTLVsは32ビットです。 例えば、1バイトの値で長さの分野を1に設定するでしょう、そして、詰め物の3つの八重奏がTLVの値の一部の端に言い足されるでしょう。 認識されていないタイプは無視されます。
Lindem, et al. Standards Track [Page 4] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[4ページ]。
2.2. OSPFv3 Router Information (RI) Opaque LSA
2.2. OSPFv3ルータ情報(ロードアイランド)の不透明なLSA
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 Router情報LSAには、LSAにおいて、S1/S2ビットは必要な氾濫範囲に依存していますが、12の機能コードがあります。 Uビットはそれが理解されていなくてもOSPFv3RI LSAが水につかるべきであるのを示すように設定されるでしょう。 このLSAのためのLink州ID(LSID)値は0です。 OSPFv3ルータが氾濫範囲あたり1独身の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 -+
| ... |
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時代|1|S12| 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (リンク州のID)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 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のボディーの中のTLVsの形式がセクション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.
TLVがOSPFv2だけ、OSPFv3だけ、または両方に適切であるか否かに関係なく、仕様は、新しいRouter情報LSA TLVがいつ定義されるかを明らかに述べなければなりません。OSPFv2とOSPFv3。
2.3. OSPF Router Informational Capabilities TLV
2.3. OSPFのルータの情報の能力TLV
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はRouter Informational Capabilities TLVです。 RI LSA MAYの広告を出すルータはRouter Informational Capabilities TLVを含んでいます。 含まれているなら、それはLSAで最初のTLVであるに違いありません。 さらに、TLV MUSTは正確にOSPFルータの能力を広告に掲載された範囲に反映します。 しかしながら、広告に掲載された情報の能力はOSPFプロトコルの操作に変化も与えません--情報の目的のために純粋にそれらの広告を出します。
Lindem, et al. Standards Track [Page 5] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[5ページ]。
The format of the Router Informational Capabilities TLV is as follows:
Router Informational Capabilities 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 A 16-bit field set to 1.
A16ビットの分野セットを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.
八重奏における、値の部分の長さを示して、広告に掲載された能力の数に依存する4つの八重奏の倍数になる長さのA16ビットの分野。 初めは、情報の能力ビットの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つの八重奏の倍数に一周した能力ビットの値のA可変長系列は未定義のビットでそっと歩きました。 初めは、能力ビットの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.
Router Informational Capabilities TLVはさらに能力を指定する任意のTLVsによって続かれるかもしれません。
2.4. Assigned OSPF Router Informational Capability Bits
2.4. 割り当てられたOSPFルータ情報の能力ビット
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)
0 LAN[P2PLAN]5OSPF Experimental TE[EXP-TE]6-31Unassignedの上のOSPFの優雅な再開[グレース]1できるOSPFの優雅な再開アシスタント[グレース]2OSPF Stub Routerサポート[STUB]3OSPF Traffic Engineeringサポート[TE]4OSPFポイントツーポイント(規格動作)
OSPF Router Informational Capabilities Bits
OSPFルータ情報の能力ビット
Lindem, et al. Standards Track [Page 6] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[6ページ]。
2.5. Flooding Scope of the Router Information LSA
2.5. ルータ情報LSAの氾濫範囲
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.
Router情報LSAのための氾濫範囲はLSAタイプによって決定されます。 OSPFv2に関しては、9(リンクで見られた)をタイプするか、10(領域で見られた)をタイプしてください。さもないと、タイプの11の(ASによって見られる)の不透明なLSAは水につかっているかもしれません。 OSPFv3に関しては、LSAタイプのS1とS2ビットは氾濫範囲を決定します。 また、ASの広い氾濫範囲が選ばれているなら、由来しているルータはどんな付属とても短く太いNot Area(NSSA)領域にも領域で見られたLSA(s)の広告を出すべきです。 NSSA領域の見られたLSA(s)とASによって見られたLSAの両方が広告に掲載されているとき、OSPFルータは異なった能力の広告を出すかもしれません。 これは範囲で制限されるべき機能的な能力を許容します。 例えば、ルータは、境界ルータですが、付属領域の部分集合の交通工学(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.
氾濫範囲の選択は、広告ルータによって作られて、ローカルの方針の問題です。 氾濫範囲が異なる限り、由来しているルータは複数のロードアイランドLSAsの広告を出すかもしれません。 TLV氾濫範囲規則を1TLVあたり1個のベースで指定されて、新しいRouter情報LSA TLVsのための付随の仕様で指定しなければなりません。
3. Router Information LSA Opaque Usage and Applicability
3. ルータの情報のLSAの不明瞭な用法と適用性
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.
Router情報(ロードアイランド)LSAの目的は集合OSPFルータに関連する情報の広告を出すことです。 通常、これはただ一つの値かほんのわずかな値でTLVsに閉じ込められるはずです。 それは、ありとあらゆる情報を運ぶために一般的な容器であることが意味されません。 意図はともにOSPFルータが独身のLSAにTLVsを含んで、いつも何がLSA例の間で合理的に変化したかを決定するタスクを簡単に保つことができる肝心のRI LSAのサイズを制限することです。 したがって、思慮深さと音の工学的判断は、新しいアプリケーションを支持した新たに提案されたTLV(s)がRI LSAに広告を出すかどうか決めるとき、適用されるのが必要である、またはアプリケーション特有のLSAの創造を保証するでしょう。
4. Security Considerations
4. セキュリティ問題
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]でカバーされています。
Lindem, et al. Standards Track [Page 7] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[7ページ]。
5. IANA Considerations
5. IANA問題
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のロードアイランドの不透明な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 Function Codesのための登録--この新しいトップレベル登録は分野のLSA機能コードのValue、名前、およびDocument Referenceから成るでしょう。 OSPFv3 LSA機能コードは.1セクションA.4.2[OSPFV3]で定義されます。 OSPFv3 LSA機能コード12はOSPFv3 Router情報(ロードアイランド)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) |
+-----------+-------------------------------------+
+-----------+-------------------------------------+ | 範囲| 課題方針| +-----------+-------------------------------------+ | 0 | 予約されます(割り当てられない)。| | | | | 1-9 | 既に割り当てられます。| | | | | 10-11 | 割り当てられません(規格動作)。| | | | | 12 | OSPFv3RI LSA(ここに割り当てられます)| | | | | 13-255 | 割り当てられません(規格動作)。| | | | | 256-8175 | 予約されます(課題がありません)。| | | | | 8176-8183 | 実験(課題がありません)| | | | | 8184-8191 | 業者兵士のUse(課題がありません)| +-----------+-------------------------------------+
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 Considerationsを指定するStandards Track 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は言及してはいけません。
Lindem, et al. Standards Track [Page 8] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[8ページ]。
* 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ヘッダーの20の八重奏に続いて、LSA Function CodeがVendor兵士のUse範囲8184-8191にあるOSPFv3 LSAsは最初の4つの八重奏としてVendorエンタープライズCodeを含まなければなりません。
* 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 Function Codeが記録されるなら、ドキュメンテーションはLSAのためのU、S2、およびS1ビットの有効な組み合わせを含まなければなりません。 それ、また、SHOULDはLink州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のための登録--このトップレベル登録は分野のValue、TLV Name、およびDocument Referenceから成るでしょう。 能力TLVのための1の値はここに定義されます。
+-------------+-----------------------------------+
| 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) |
+-----------+-------------------------------------+
+-------------+-----------------------------------+ | 範囲| 課題方針| +-------------+-----------------------------------+ | 0 | 予約されます(割り当てられない)。| | | | | 1 | 既に割り当てられます。| | | | | 2-32767 | 割り当てられません(規格動作)。| | | | | 32768-32777 | 実験(assignementsがありません)| | | | | 32778-65535 | 予約されます(割り当てられない)。| +-----------+-------------------------------------+
OSPF RI TLVs
OSPFロードアイランド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 Considerationsを指定するStandards Track 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 Router Informational Capability Bitsのための登録--OSPF RI TLV登録のこのサブ登録は分野のBit Number、Capability Name、およびDocument Referenceから成るでしょう。 値はセクション2.4で定義されます。 すべてのRouter Informational Capability TLV追加は規格動作で割り当てられることです。
Lindem, et al. Standards Track [Page 9] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[9ページ]。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[不透明]のColtun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
IPv6", RFC 2740, December 1999.
[OSPFV3] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCのものにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering Extensions to OSPF", RFC 3630,
September 2003.
[Te] 2003年9月のキャッツとD.とKompella、K.とD.Yeung、「OSPFへの交通工学拡大」RFC3630。
6.2. Informative References
6.2. 有益な参照
[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.ジョゼフ、「OSPF-xTE:」 「交通工学のためのOSPFへの実験的な拡大」、RFC4973、2007年7月。
[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
OSPF Restart", RFC 3623, November 2003.
[優雅] MoyとJ.とPillay-Esnault、P.とA.Lindem、「優雅なOSPFは再開する」RFC3623、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] シンとN.とA.ジニン、「LinkState方式プロトコルのLANの上の二地点間操作」、Progress、2006年4月のWork。
[STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement",
RFC 3137, June 2001.
[引き抜きます] レタナとA.とNguyenとL.とホワイトとR.とジニン、A.とD.マクファーソン、「OSPFスタッブルータ通知」、RFC3137、2001年6月。
Lindem, et al. Standards Track [Page 10] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[10ページ]。
Appendix A. Acknowledgments
付録A.承認
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.
この仕事のための考えはアンドリューPartanとの会話から成長しました、そして、彼の貢献について彼に感謝申し上げます。 作者はドキュメントの早めのバージョンにおける彼のレビューと役に立つコメントのための感謝ピーターPsenakがそうしたいです。
Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian Farrel have been incorporated into later versions.
Abhayロイ、Vishwas Manral、Vivek Dubey、およびエードリアン・ファレルからのコメントを後のバージョンに組み入れてあります。
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、マーシャル・ローズのxml2rfcツールを使用することで製作されました。
Lindem, et al. Standards Track [Page 11] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem(エディタ)20ドル紙幣ネットワーク102こづなつなぎ法廷のNC27519ケーリー(米国)
EMail: acee@redback.com
メール: acee@redback.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Driveシンシスコシステムズ225カリフォルニア95134サンノゼ(米国)をNaimingします。
EMail: naiming@cisco.com
メール: naiming@cisco.com
Jean-Philippe Vasseur Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
ジャンフィリップVasseurシスコシステムズ1414マサチューセッツ通りBoxborough、MA01719米国
EMail: jpv@cisco.com
メール: jpv@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Rahul Aggarwal杜松は1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
EMail: rahul@juniper.net
メール: rahul@juniper.net
Scott Shaffer BridgePort Networks One Main Street, 7th Floor Cambridge, MA 02142 USA
スコットシャッファーBridgePortは1つの大通り、第7Floorケンブリッジ、MA02142米国をネットワークでつなぎます。
EMail: sshaffer@bridgeport-networks.com
メール: sshaffer@bridgeport-networks.com
Lindem, et al. Standards Track [Page 12] RFC 4970 OSPF Capability Extensions July 2007
Lindem、他 規格はOSPF能力拡大2007年7月にRFC4970を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Lindem, et al. Standards Track [Page 13]
Lindem、他 標準化過程[13ページ]
一覧
スポンサーリンク
