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
        

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はTLV 22内に運ば「リンク属性」と呼ばれ、いくつかのリンク特性をあふれさせるために使用される定義されています。

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
        
1. Introduction
1. はじめに

[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の(なType-Length-値)と呼ばれる可変長タプルで構成された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-ISプレフィックスの符号化を最適化することである新規のTLVのセットを定義します。

This document defines a new sub-TLV named "Link-attributes" carried within the extended IS reachability TLV (type 22) specified in [RFC3784].

この文書は、拡張内で運ば「リンク属性」という名前の新しいサブTLVを定義して、[RFC3784]で指定された到達可能性TLV(タイプ22)です。

1.1 Terminology
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 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

2. Link-Attributes Sub-TLV Format
2.サブTLVフォーマットリンクは、属性

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.

リンク属性サブTLVは、TLV 22内に運ばれ、IS-IS([RFC3784])のためのトラフィックエンジニアリングの拡張機能によって使用されるサブTLVのフォーマットと同一のフォーマットを有する:サブタイプの1オクテット、の1つのオクテット値フィールドに続くサブTLVの値フィールドの長さ - この場合、16ビット・フラグ・フィールド。

The Link-attribute sub-type is 19 and the link-attribute has a length of 2 octets.

リンク属性のサブタイプが19で、リンク属性が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.

このサブTLVはオプションで、高々一度単一ISの隣人のために現れなければなりません。受信したリンクステートパケット(LSP)が、複数のリンク属性サブ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]).

利用可能なローカル保護(0×01)。設定した場合、このリンクは、いくつかのローカル保護機構によって保護されることを示す(例えば、[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.

リンクローカル保護パス(0×02)から除外する。設定されている場合、このリンクは、ルーティング領域内の他のルータによって修復経路の計算に含まれるべきではありません。このビットを設定するためのトリガーは、この文書の範囲外です。

3. Interoperability with Routers Not Supporting This Capability
ルータがこの機能をサポートしていない3.相互運用性

A router not supporting the link-attribute sub-TLV will just silently ignore this sub-TLV.

リンク属性サブTLVをサポートしていないルータは、ただ黙ってこのサブTLVを無視します。

4. IANA Considerations
4. IANAの考慮事項

IANA has assigned codepoint 19 for the link-attribute sub-TLV defined in this document and carried within TLV 22.

IANAは、この文書で定義され、TLV 22の中で運ばリンク属性サブTLVのためのコードポイント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は、リンク属性サブ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.

さらに、値は([RFC4020]で定義された)初期割り当てと、[RFC2434]で定義された標準化行動プロセスによって割り当てることが許可されます。

5. Security Considerations
5.セキュリティについての考慮事項

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]で定義されたものなどが適用されるべきであることに留意されたいです。

6. Acknowledgements
6.謝辞

The authors would like to thank Mike Shand, Les Ginsberg, and Bill Fenner for their useful comments.

作者は彼らの役に立つコメントをマイクシャンド、レ・ギンズバーグ、およびビルフェナーに感謝したいと思います。

7. References
7.参考
7.1. Normative References
7.1. 引用規格

[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]「中間システム中間にシステムのドメイン内ルーティング交換プロトコル接続モード・ネットワーク・サービス(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.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング(TE)のための中間システム(IS-IS)への拡張"、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.ジニン、 "標準化過程のコードポイントの初期のIANA配分"、BCP 100、RFC 4020、2005年2月。

7.2. Informative References
7.2. 参考文献

[RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.

[RFC3567]のLi、T.及びR.アトキンソン、 "中間システム(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]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。

Authors' Addresses

著者のアドレス

JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA

JP Vasseurシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA

EMail: jpv@cisco.com

メールアドレス:jpv@cisco.com

Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Roma 00142 Italy

スティーブンは、シスコシステムズ、株式会社ヴィアデルセラフィック200 00142ローマイタリア予感しました

EMail: sprevidi@cisco.com

メールアドレス:sprevidi@cisco.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2007).

著作権(C)IETFトラスト(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。