Network Working Group JP. Vasseur
Request for Comments: 5029 S. Previdi
Category: Standards Track Cisco Systems, Inc
September 2007
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，称为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 ....................................................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]中指定IS-IS协议（ISO 10589）及其扩展以支持IPv4。路由器播发一个或多个链路状态协议数据单元，这些数据单元由称为TLV（类型长度值）的可变长度元组组成。
[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]定义了一组新的TLV，其目的是添加更多关于链路特性的信息，增加IS-IS度量的范围，并优化IS-IS前缀的编码。
This document defines a new sub-TLV named "Link-attributes" carried within the extended IS reachability TLV (type 22) specified in [RFC3784].
本文件定义了[RFC3784]中规定的扩展IS可达性TLV（类型22）中携带的名为“链路属性”的新子TLV。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
链路属性sub-TLV在TLV 22中携带，其格式与is-is的流量工程扩展使用的sub-TLV格式相同（[RFC3784]）：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]).
本地保护可用（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.
不支持链接属性sub-TLV的路由器只会默默地忽略此sub-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分配了代码点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]
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]“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（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.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年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，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年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，“早期IANA标准轨道代码点分配”，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 40902005年5月。
Authors' Addresses
作者地址
JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur Cisco Systems，Inc.美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
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
EMail: sprevidi@cisco.com
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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的IETF-ipr@ietf.org.