[要約] RFC 5029は、IS-ISリンク属性のサブ-TLV（Type-Length-Value）の定義に関するものであり、IS-ISプロトコルにおけるリンク属性の拡張を提供します。このRFCの目的は、IS-ISネットワークでリンク属性をより詳細に表現するための標準化を行うことです。
Network Working Group JP. Vasseur
Request for Comments: 5029 S. Previdi
Category: Standards Track Cisco Systems, Inc
September 2007
Definition of an IS-IS Link Attribute Sub-TLV
IS-ISリンク属性サブTLVの定義
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics.
このドキュメントでは、TLV 22内で運ばれ、いくつかのリンク特性をflood濫させるために使用される「link-attributes」と呼ばれるサブTLVを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Link-Attributes Sub-TLV Format ..................................2
3. Interoperability with Routers Not Supporting This Capability ....3
4. IANA Considerations .............................................3
5. Security Considerations .........................................3
6. Acknowledgements ................................................3
7. References ......................................................4
7.1. Normative References .......................................4
7.2. Informative References .....................................4
[IS-IS] specifies the IS-IS protocol (ISO 10589) with extensions to support IPv4 in [RFC1195]. A router advertises one or several Link State Protocol data units that are composed of variable length tuples called TLVs (Type-Length-Value).
[IS-IS]は、[RFC1195]でIPv4をサポートする拡張機能を備えたIS-ISプロトコル（ISO 10589）を指定します。ルーターは、TLVと呼ばれる可変長さのタプルで構成される1つまたは複数のリンク状態プロトコルデータユニットを宣伝します（タイプ長値）。
[RFC3784] defines a set of new TLVs whose aims are to add more information about links characteristics, increase the range of IS-IS metrics, and optimize the encoding of IS-IS prefixes.
[RFC3784]は、リンクの特性に関する情報を追加し、ISメトリックの範囲を増やし、IS-ISプレフィックスのエンコードを最適化することを目的とする新しいTLVのセットを定義します。
This document defines a new sub-TLV named "Link-attributes" carried within the extended IS reachability TLV (type 22) specified in [RFC3784].
このドキュメントでは、拡張された拡張性IS IS Reachability TLV（タイプ22）という名前の「link-aTtributes」という名前の新しいサブTLVが[RFC3784]で指定されています。
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 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The link-attribute sub-TLV is carried within the TLV 22 and has a format identical to the sub-TLV format used by the Traffic Engineering Extensions for IS-IS ([RFC3784]): 1 octet of sub-type, 1 octet of length of the value field of the sub-TLV followed by the value field -- in this case, a 16 bit flags field.
Link-Attribute sub-TLVはTLV 22内に運ばれ、IS-ISのトラフィックエンジニアリング拡張機能で使用されるサブTLV形式と同一の形式を備えています（[RFC3784]）：サブタイプの1オクテット、1オクテットの1オクテットSub-TLVの値フィールドの長さとその後の値フィールド（この場合、16ビットフラグフィールド）が続きます。
The Link-attribute sub-type is 19 and the link-attribute has a length of 2 octets.
Link-Attributeのサブタイプは19で、Link-Attributeの長さは2オクターです。
This sub-TLV is OPTIONAL and MUST appear at most once for a single IS neighbor. If a received Link State Packet (LSP) contains more than one Link-Attribute Sub-TLV, an implementation SHOULD decide to consider only the first encountered instance.
このSub-TLVはオプションであり、1つのIS Neightで最大1回表示する必要があります。受信したリンク状態パケット（LSP）に複数のLink-Attribute sub-TLVが含まれている場合、実装は最初の遭遇したインスタンスのみを考慮することを決定する必要があります。
The following bits are defined:
次のビットが定義されています。
Local Protection Available (0x01). When set, this indicates that the link is protected by means of some local protection mechanism (e.g., [RFC4090]).
利用可能なローカル保護（0x01）。設定すると、これはリンクがいくつかの局所保護メカニズムによって保護されていることを示します（例：[RFC4090]）。
Link excluded from local protection path (0x02). When set, this link SHOULD not be included in any computation of a repair path by any other router in the routing area. The triggers for setting up this bit are out of the scope of this document.
ローカル保護パス（0x02）から除外されたリンク。設定した場合、このリンクは、ルーティング領域の他のルーターによる修理パスの計算に含めるべきではありません。このビットをセットアップするためのトリガーは、このドキュメントの範囲外です。
A router not supporting the link-attribute sub-TLV will just silently ignore this sub-TLV.
Link-Attribute sub-TLVをサポートしていないルーターは、このサブTLVを静かに無視します。
IANA has assigned codepoint 19 for the link-attribute sub-TLV defined in this document and carried within TLV 22.
IANAは、このドキュメントで定義され、TLV 22内に携帯されているリンクアトリブサブTLVにCodePoint 19を割り当てました。
IANA has created a registry for bit values inside the link-attributes sub-TLV. The initial contents of this registry are as follows
IANAは、link-attributes sub-tlv内のビット値のレジストリを作成しました。このレジストリの最初の内容は次のとおりです
Value Name Reference
----- ---- ---------
0x1 Local Protection Available [RFC5029]
0x2 Link Excluded from Local Protection [RFC5029]
Further values are to be allocated by the Standards Action process defined in [RFC2434], with Early Allocation (defined in [RFC4020]) permitted.
[RFC2434]で定義されている標準アクションプロセスによって、許可された早期割り当て（[RFC4020]で定義）によって、さらなる値が割り当てられます。
Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, the ease/difficulty of which has not been altered. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information. Note that an integrity mechanism, such as one defined in [RFC3567], should be applied if there is high risk resulting from the modification of capability information.
このドキュメントの手順によって提起された新しいセキュリティの問題は、LSPがスヌーピングおよび変更される機会に依存します。その容易さ/難易度は変更されていません。LSPにはルーター機能に関する追加情報が含まれているため、この新しい情報も攻撃者が利用できるようになります。このメカニズムに基づく仕様は、情報の開示と変更に関するセキュリティ上の考慮事項を説明する必要があります。[RFC3567]で定義されているものなどの整合性メカニズムは、機能情報の変更に起因するリスクが高い場合は適用する必要があることに注意してください。
The authors would like to thank Mike Shand, Les Ginsberg, and Bill Fenner for their useful comments.
著者は、マイク・シャンド、レス・ギンズバーグ、ビル・フェナーに有用なコメントをしてくれたことに感謝します。
[IS-IS] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589.
[IS-IS] "Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための中間システムへの中間システム内領域内領域内領域内部ルーティング交換プロトコル」、ISO 10589。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020] Kompella、K。およびA. Zinin、「標準の初期の配分追跡コードポイント」、BCP 100、RFC 4020、2005年2月。
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC3567] Li、T。およびR. Atkinson、「中間システムから中間システム（IS-IS）暗号認証」、RFC 3567、2003年7月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
Authors' Addresses
著者のアドレス
JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur Cisco Systems、Inc 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Roma 00142 Italy
Stefano Previdi Cisco Systems、Inc、Del Serafico 200 Roma 00142 Italy
EMail: sprevidi@cisco.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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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への情報をお問い合わせください。