Network Working Group R. Chandra
Request for Comments: 3392 Redback Networks
Obsoletes: 2842 J. Scudder
Category: Standards Track Cisco Systems
November 2002
Network Working Group R. Chandra
Request for Comments: 3392 Redback Networks
Obsoletes: 2842 J. Scudder
Category: Standards Track Cisco Systems
November 2002
Capabilities Advertisement with BGP-4
使用BGP-4发布功能广告
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 Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
本文档定义了一个新的可选参数，称为Capabilities，该参数通过在不要求终止BGP对等的情况下提供优雅的功能播发，有助于在边界网关协议（BGP）中引入新功能。
This document obsoletes RFC 2842.
本文件淘汰了RFC 2842。
Currently BGP-4 requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP.
目前，BGP-4要求当BGP扬声器接收到带有一个或多个无法识别的可选参数的打开消息时，扬声器必须终止BGP对等。这使得BGP中新功能的引入变得复杂。
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]中所述进行解释。
When a BGP speaker [BGP-4] that supports capabilities advertisement sends an OPEN message to its BGP peer, the message MAY include an Optional Parameter, called Capabilities. The parameter lists the capabilities supported by the speaker.
当支持功能广告的BGP扬声器[BGP-4]向其BGP对等方发送打开消息时，该消息可能包括一个可选参数，称为“功能”。该参数列出了扬声器支持的功能。
A BGP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer.
BGP演讲者通过检查演讲者从对等方收到的开放消息所携带的capabilities可选参数中存在的能力列表来确定其对等方支持的能力。
A BGP speaker that supports a particular capability may use this capability with its peer after the speaker determines (as described above) that the peer supports this capability.
支持特定功能的BGP扬声器可在其对等方确定（如上所述）该对等方支持该功能后，将该功能用于其对等方。
A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. In this case the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter.
BGP说话者确定其对等方不支持功能播发，如果说话者响应带有“功能”可选参数的打开消息，收到错误子码设置为“不支持的可选参数”的通知消息。在这种情况下，演讲者应尝试与对等方重新建立BGP连接，而无需向对等方发送可选参数。
If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer, and terminate peering (see Section "Extensions to Error Handling" for more details). The Error Subcode in the message is set to Unsupported Capability. The message SHOULD contain the capability (capabilities) that causes the speaker to send the message. The decision to send the message and terminate peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically.
如果支持特定功能的BGP扬声器确定其对等方不支持此功能，则扬声器可能会向对等方发送通知消息，并终止对等（有关更多详细信息，请参阅“错误处理扩展”一节）。消息中的错误子代码设置为不支持的功能。信息应包含使说话人发送信息的功能。发送消息和终止对等的决定是说话人的本地决定。如果终止，这种对等不应自动重新建立。
4. Capabilities Optional Parameter (Parameter Type 2):
4. 功能可选参数（参数类型2）：
This is an Optional Parameter that is used by a BGP speaker to convey to its BGP peer the list of capabilities supported by the speaker.
这是一个可选参数，BGP演讲者使用该参数向其BGP对等方传达演讲者支持的功能列表。
The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
该参数包含一个或多个三元组<Capability Code，Capability Length，Capability Value>，其中每个三元组的编码如下所示：
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
The use and meaning of these fields are as follows:
这些字段的用法和含义如下：
Capability Code:
能力代码：
Capability Code is a one octet field that unambiguously identifies individual capabilities.
能力代码是一个八位字段，明确标识单个能力。
Capability Length:
能力长度：
Capability Length is a one octet field that contains the length of the Capability Value field in octets.
Capability Length是一个八位字节字段，包含以八位字节为单位的Capability Value字段的长度。
Capability Value:
能力价值：
Capability Value is a variable length field that is interpreted according to the value of the Capability Code field.
能力值是根据能力代码字段的值解释的可变长度字段。
BGP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value. Note however, that processing of multiple instances of such capability does not require special handling, as additional instances do not change the meaning of announced capability.
BGP扬声器不应包含多个具有相同功能代码、功能长度和功能值的功能实例。但是，请注意，处理此类功能的多个实例不需要特殊处理，因为其他实例不会改变所宣布功能的含义。
BGP speakers MAY include more than one instance of a capability (as identified by the Capability Code) with non-zero Capability Length field, but with different Capability Value, and either the same or different Capability Length. Processing of these capability instances is specific to the Capability Code and MUST be described in the document introducing the new capability.
BGP扬声器可能包括一个以上的能力实例（由能力代码标识），该能力具有非零能力长度字段，但具有不同的能力值，以及相同或不同的能力长度。这些能力实例的处理特定于能力代码，必须在介绍新能力的文档中进行描述。
This document defines new Error Subcode - Unsupported Capability. The value of this Subcode is 7. The Data field in the NOTIFICATION message SHOULD list the set of capabilities that cause the speaker to send the message. Each such capability is encoded the same way as it would be encoded in the OPEN message.
本文档定义了新的错误子代码-不支持的功能。此子代码的值为7。通知消息中的数据字段应列出导致扬声器发送消息的一组功能。每个这样的功能的编码方式与开放消息中的编码方式相同。
This document defines a Capability Optional Parameter along with an Capability Code field. IANA maintains the registry for Capability Code values. Capability Code value 0 is reserved. Capability Code values 1 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. Capability Code values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. Capability Code values 128 through 255 are for "Private Use" as defined in RFC 2434.
本文档定义了一个功能可选参数以及一个功能代码字段。IANA维护功能代码值的注册表。保留功能代码值0。IANA将使用RFC 2434中定义的“IETF共识”策略分配能力代码值1至63。IANA将使用RFC 2434中定义的“先到先得”策略分配能力代码值64至127。能力代码值128到255用于RFC 2434中定义的“专用”。
This extension to BGP does not change the underlying security issues inherent in the existing BGP [Heffernan].
BGP的这一扩展并没有改变现有BGP[Heffernan]固有的潜在安全问题。
The authors would like to thank members of the IDR Working Group for their review and comments.
作者要感谢IDR工作组成员的审查和评论。
In addition to several minor editorial changes, this document also clarifies how to handle multiple instances of the same capability.
除了几个小的编辑性修改外，本文档还阐明了如何处理相同功能的多个实例。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[Heffernan]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[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月。
Ravi Chandra Redback Networks Inc. 350, Holger Way San Jose, CA 95134
拉维·钱德拉Redback Networks Inc.位于加利福尼亚州圣何塞霍尔格路350号，邮编95134
EMail: rchandra@redback.com
EMail: rchandra@redback.com
John G. Scudder Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
John G.Scudder Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: jgs@cisco.com
EMail: jgs@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。