Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6510 LabN
Updates: 4875, 5420 G. Swallow
Category: Standards Track Cisco
ISSN: 2070-1721 February 2012
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6510 LabN
Updates: 4875, 5420 G. Swallow
Category: Standards Track Cisco
ISSN: 2070-1721 February 2012
Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects
标签交换路径（LSP）属性对象的资源保留协议（RSVP）消息格式
Abstract
摘要
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420.
使用资源预留协议流量工程（RSVP-TE）扩展建立的多协议标签交换（MPLS）标签交换路径（LSP）可以用一组特定于LSP的属性发出信号。这些属性可以在Path和Resv消息中携带。本文件规定了如何使用Routing Backus Naur表单在RSVP Path和Resv消息中携带LSP属性，并澄清了相关的Resv消息格式。本文件更新了RFC 4875和RFC 5420。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6510.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6510.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Path Messages ...................................................3
2.1. Path Message Format ........................................3
3. Resv Messages ...................................................4
3.1. Resv Message Format -- Per LSP Operational Status ..........5
3.2. Resv Message Format -- Per S2L Operational Status ..........6
3.2.1. Compatibility .......................................6
4. Security Considerations .........................................6
5. Acknowledgments .................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Path Messages ...................................................3
2.1. Path Message Format ........................................3
3. Resv Messages ...................................................4
3.1. Resv Message Format -- Per LSP Operational Status ..........5
3.2. Resv Message Format -- Per S2L Operational Status ..........6
3.2.1. Compatibility .......................................6
4. Security Considerations .........................................6
5. Acknowledgments .................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Signaling in support of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs.
[RFC3209]和[RFC3473]中定义了支持多协议标签交换（MPLS）和通用MPLS（GMPLS）点到点标签交换路径（LSP）的信令。[RFC4875]定义了对点对多点（P2MP）流量工程（TE）LSP的信令支持。
Two LSP Attributes objects are defined in [RFC5420]. These objects may be used to provide additional information related to how an LSP should be set up when carried in a Path message and, when carried in a Resv message, how an LSP has been established. The definition of the objects includes a narrative description of related message formats (see Section 9 of [RFC5420]). This definition does not provide the related Routing Backus-Naur Form (BNF) [RFC5511] that is typically used to define how messages are to be constructed using RSVP objects. The current message format description has led to the open question of how the LSP Attributes objects are to be processed in Resv messages of P2MP LSPs (which are defined in [RFC4875]).
[RFC5420]中定义了两个LSP属性对象。这些对象可用于提供与在路径消息中携带时应如何设置LSP以及在Resv消息中携带时如何建立LSP相关的附加信息。对象的定义包括相关消息格式的叙述性描述（见[RFC5420]第9节）。此定义不提供相关的路由Backus Naur Form（BNF）[RFC5511]，通常用于定义如何使用RSVP对象构造消息。当前的消息格式描述导致了一个公开问题，即如何在P2MP LSP的Resv消息中处理LSP属性对象（在[RFC4875]中定义）。
This document provides the BNF for Path and Resv messages carrying the LSP Attributes object. The definition clarifies how the objects are to be carried for all LSP types. Both Path and Resv message BNF is provided for completeness.
本文档提供了承载LSP属性对象的Path和Resv消息的BNF。该定义阐明了如何为所有LSP类型携带对象。为了完整起见，提供了Path和Resv消息BNF。
This document presents the related RSVP message formats as modified by [RFC5420]. This document modifies formats defined in [RFC3209], [RFC3473], and [RFC4875]. See [RFC5511] for the syntax used by RSVP. Unmodified formats are not listed. An example of a case where the modified formats are applicable is described in [RFC6511].
本文件介绍了[RFC5420]修改的相关RSVP消息格式。本文件修改了[RFC3209]、[RFC3473]和[RFC4875]中定义的格式。RSVP使用的语法请参见[RFC5511]。未修改的格式未列出。[RFC6511]中描述了修改后的格式适用的示例。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section updates [RFC4875]. Path message formatting is unmodified from the narrative description provided in Section 9 of [RFC5420]:
本节更新了[RFC4875]。路径消息格式未根据[RFC5420]第9节中提供的叙述性描述进行修改：
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object
MAY be carried in a Path message....
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object
MAY be carried in a Path message....
The order of objects in RSVP-TE messages is recommended, but implementations must be capable of receiving the objects in any meaningful order.
建议使用RSVP-TE消息中对象的顺序，但实现必须能够以任何有意义的顺序接收对象。
On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed immediately after the SESSION_ATTRIBUTE object if it is present, or otherwise immediately after the LABEL_REQUEST object.
在路径消息上，建议将LSP_ATTRIBUTES对象和LSP_REQUIRED_ATTRIBUTES对象立即放置在会话_属性对象（如果存在）之后，或者立即放置在LABEL_请求对象之后。
If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED to be placed first.
如果LSP_ATTRIBUTES对象和LSP_REQUIRED_ATTRIBUTES对象都存在，则建议首先放置LSP_REQUIRED_ATTRIBUTES对象。
LSRs MUST be prepared to receive these objects in any order in any position within a Path message. Subsequent instances of these objects within a Path message SHOULD be ignored and MUST be forwarded unchanged.
LSR必须准备好在路径消息中的任何位置以任何顺序接收这些对象。路径消息中这些对象的后续实例应被忽略，并且必须原封不动地转发。
This section presents the Path message format as modified by [RFC5420]. Unmodified formats are not listed.
本节介绍由[RFC5420]修改的路径消息格式。未修改的格式未列出。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <LSP_REQUIRED_ATTRIBUTES> ... ]
[ <LSP_ATTRIBUTES> ... ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <LSP_REQUIRED_ATTRIBUTES> ... ]
[ <LSP_ATTRIBUTES> ... ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
Note that PathErr and PathTear messages are not impacted by the introduction of the LSP Attributes objects.
请注意，引入LSP属性对象不会影响PathErr和PathTear消息。
This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420] contains the following text regarding Resv messages:
本节更新了[RFC4875]和[RFC5420]。[RFC5420]第9节包含以下关于Resv消息的文本：
The LSP_ATTRIBUTES object MAY be carried in a Resv message.
LSP_属性对象可以在Resv消息中携带。
The order of objects in RSVP-TE messages is recommended, but implementations must be capable of receiving the objects in any meaningful order.
建议使用RSVP-TE消息中对象的顺序，但实现必须能够以任何有意义的顺序接收对象。
...
...
On a Resv message, the LSP_ATTRIBUTES object is placed in the flow descriptor and is associated with the FILTER_SPEC object that precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be placed immediately after the LABEL object.
在Resv消息上，LSP_ATTRIBUTES对象被放置在流描述符中，并与它前面的FILTER_SPEC对象相关联。建议将LSP_属性对象放置在标签对象之后。
LSRs MUST be prepared to receive this object in any order in any position within a Resv message, subject to the previous note. Only one instance of the LSP_ATTRIBUTES object is meaningful within the context of a FILTER_SPEC object. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged.
LSR必须准备好在Resv消息中的任何位置以任何顺序接收此对象，但需遵守前面的说明。在FILTER_SPEC对象的上下文中，只有一个LSP_ATTRIBUTES对象的实例有意义。该对象的后续实例应被忽略，并且必须原封不动地转发。
This means that LSP attributes may be present per sender (LSP) and allows for the LSP Attributes object to be modified using make-before-break (see [RFC3209]). This definition is sufficient for point-to-point ([RFC3209] and [RFC3473]) LSPs and the special case where all point-to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the same operational status (as used in [RFC5420]). However, this definition does not allow for different
这意味着每个发送方（LSP）都可能存在LSP属性，并允许使用先通后断修改LSP属性对象（请参见[RFC3209]）。此定义对于点对点（[RFC3209]和[RFC3473]）LSP以及所有点对多点源到叶（S2L）子LSP（[RFC4875]）报告相同操作状态（如[RFC5420]中所用）的特殊情况而言已足够。但是，该定义不允许不同的定义
egress Label Switching Routers (LSRs) to report different operational statuses. In order to allow such reporting, this document adds the following definition:
出口标签交换路由器（LSR）报告不同的操作状态。为了允许此类报告，本文件添加了以下定义：
An LSR that wishes to report the operational status of a (point-to-multipoint) S2L sub-LSP may include the LSP Attributes object in a Resv message or update the object that is already carried in a Resv message. LSP Attributes objects representing S2L sub-LSP status MUST follow a S2L_SUB_LSP object. Only the first instance of the LSP Attributes object is meaningful within the context of a S2L_SUB_LSP object. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged.
希望报告（点对多点）S2L子LSP的操作状态的LSR可以在Resv消息中包括LSP Attributes对象，或者更新Resv消息中已经携带的对象。表示S2L子LSP状态的LSP属性对象必须跟随S2L_子LSP对象。在S2L_SUB_LSP对象的上下文中，只有LSP Attributes对象的第一个实例有意义。该对象的后续实例应被忽略，并且必须原封不动地转发。
When an LSP Attributes object is present before the first S2L_SUB_LSP object, the LSP Attributes object represents the operational status of all S2L sub-LSPs identified in the message. Subsequent instances of the object (e.g., in the filter spec or the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be forwarded unchanged. When a branch node is combining Resv state from multiple receivers into a single Resv message and an LSP Attributes object is present before the first S2L_SUB_LSP object in a received Resv message, the received LSP Attributes object SHOULD be moved to follow the first received S2L_SUB_LSP object and then SHOULD be duplicated for, and placed after, each subsequent S2L_SUB_LSP object.
当LSP Attributes对象出现在第一个S2L_SUB_LSP对象之前时，LSP Attributes对象表示消息中标识的所有S2L SUB LSP的运行状态。对象的后续实例（例如，在过滤器规范或S2L子LSP流描述符中）应被忽略，并且必须原封不动地转发。当分支节点将来自多个接收器的Resv状态组合到单个Resv消息中，并且LSP Attributes对象出现在接收到的Resv消息中的第一个S2L_SUB_LSP对象之前时，应将接收到的LSP Attributes对象移动到第一个接收到的S2L_SUB_LSP对象之后，然后对其进行复制并放置在其之后，每个后续S2L_子_LSP对象。
This section presents the Resv message format for LSPs as modified by [RFC5420] and can be used to report operational status per LSP. Unmodified formats are not listed. The following is based on [RFC4875].
本节介绍了经[RFC5420]修改的LSP的Resv消息格式，可用于报告每个LSP的运行状态。未修改的格式未列出。以下内容基于[RFC4875]。
<FF flow descriptor list> ::= <FF flow descriptor>
[ <FF flow descriptor list> ]
<FF flow descriptor list> ::= <FF flow descriptor>
[ <FF flow descriptor list> ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <LSP_ATTRIBUTES> ... ]
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <LSP_ATTRIBUTES> ... ]
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
[ <SE filter spec list> ]
<SE filter spec list> ::= <SE filter spec>
[ <SE filter spec list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL>
[ <LSP_ATTRIBUTES> ... ]
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL>
[ <LSP_ATTRIBUTES> ... ]
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
This section presents the Resv message format for LSPs as modified by this document and [RFC5420], and can be used to report operational status per S2L sub-LSP. Unmodified formats are not listed. The following is based on [RFC4875].
本节介绍了经本文件和[RFC5420]修改的LSP的Resv消息格式，可用于根据S2L子LSP报告运行状态。未修改的格式未列出。以下内容基于[RFC4875]。
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <LSP_ATTRIBUTES> ... ]
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <LSP_ATTRIBUTES> ... ]
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
A node that supports [RFC4875] and [RFC5420], but not this document, will interpret the first LSP Attributes object present in a received message, which is formatted as described in this document, as representing LSP operational status rather than S2L sub-LSP status. It is unclear if this is a significant issue as the LSP Attributes object is currently considered to be an unsuitable mechanism for reporting operational status of P2MP LSPs, for example, see Section 2.1 of [RFC6511]. The intent of this document is to correct this limitation; it is expected that networks that wish to make use of such operational reporting will deploy this extension.
支持[RFC4875]和[RFC5420]但不支持本文档的节点将解释接收到的消息中存在的第一个LSP Attributes对象，其格式如本文档所述，表示LSP操作状态，而不是S2L子LSP状态。目前还不清楚这是否是一个重大问题，因为LSP属性对象目前被认为是报告P2MP LSP运行状态的不合适机制，例如，参见[RFC6511]第2.1节。本文件旨在纠正该限制；希望利用这种业务报告的网络预计将部署这种扩展。
This document clarifies usage of objects defined in [RFC5420]. No new information is conveyed; therefore, no additional security considerations are included here. For a general discussion on MPLS-and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920].
本文件澄清了[RFC5420]中定义的对象的用法。没有传达新的信息；因此，此处不包括其他安全注意事项。有关MPLS和GMPLS相关安全问题的一般性讨论，请参阅MPLS/GMPLS安全框架[RFC5920]。
The authors would like to acknowledge the contributions of Adrian Farrel.
作者要感谢Adrian Farrel的贡献。
[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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）建立MPLS LSP的属性编码”，RFC 5420，2009年2月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，2009年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012.
[RFC6511]Ali，Z.，Swallow，G.和R.Aggarwal，“RSVP-TE标签交换路径的非倒数第二跳弹出行为和带外映射”，RFC 65112012年2月。
Authors' Addresses
作者地址
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电话：+1-301-468-9228电子邮件：lberger@labn.net
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.电子邮件：swallow@cisco.com