Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6780 LabN
Updates: 2205, 3209, 3473, 4872 F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco
October 2012
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6780 LabN
Updates: 2205, 3209, 3473, 4872 F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco
October 2012
RSVP ASSOCIATION Object Extensions
RSVP关联对象扩展
Abstract
摘要
The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872.
RSVP关联对象是在GMPLS控制的标签交换路径（LSP）上下文中定义的。在此上下文中，该对象用于将恢复LSP与其保护的LSP关联起来。该对象作为关联RSVP状态的机制也具有更广泛的适用性。本文档定义了如何更普遍地应用关联对象。本文档还定义了扩展关联对象，这些对象尤其可以在MPLS传输配置文件（MPLS-TP）的上下文中使用。本文档更新了RFC 2205、RFC 3209和RFC 3473。它还概括了RFC4872中定义的关联ID字段的定义。
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/rfc6780.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6780.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Generalized Association ID Field Definition .....................4
3. Non-GMPLS and Non-Recovery Usage ................................4
3.1. Upstream Initiated Association .............................5
3.1.1. Path Message Format .................................5
3.1.2. Path Message Processing .............................6
3.2. Downstream Initiated Association ...........................7
3.2.1. Resv Message Format .................................8
3.2.2. Resv Message Processing .............................8
3.3. Association Types ..........................................9
3.3.1. Resource Sharing Association Type ...................9
3.3.2. Unknown Association Types ..........................10
4. IPv4 and IPv6 Extended ASSOCIATION Objects .....................10
4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format ..........11
4.2. Processing ................................................13
5. Compatibility ..................................................14
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. IPv4 and IPv6 Extended ASSOCIATION Objects ................15
7.2. Resource Sharing Association Type .........................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................16
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Generalized Association ID Field Definition .....................4
3. Non-GMPLS and Non-Recovery Usage ................................4
3.1. Upstream Initiated Association .............................5
3.1.1. Path Message Format .................................5
3.1.2. Path Message Processing .............................6
3.2. Downstream Initiated Association ...........................7
3.2.1. Resv Message Format .................................8
3.2.2. Resv Message Processing .............................8
3.3. Association Types ..........................................9
3.3.1. Resource Sharing Association Type ...................9
3.3.2. Unknown Association Types ..........................10
4. IPv4 and IPv6 Extended ASSOCIATION Objects .....................10
4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format ..........11
4.2. Processing ................................................13
5. Compatibility ..................................................14
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. IPv4 and IPv6 Extended ASSOCIATION Objects ................15
7.2. Resource Sharing Association Type .........................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................16
End-to-end and segment recovery are defined for GMPLS-controlled Label Switched Paths (LSPs) in [RFC4872] and [RFC4873], respectively. Both definitions use the ASSOCIATION object to associate recovery LSPs with the LSP they are protecting. Additional narrative on how such associations are to be identified is provided in [RFC6689].
[RFC4872]和[RFC4873]中分别为GMPLS控制的标签交换路径（LSP）定义了端到端和段恢复。这两个定义都使用关联对象将恢复LSP与其保护的LSP关联起来。[RFC6689]中提供了关于如何识别此类关联的其他说明。
This document expands the possible usage of the ASSOCIATION object to non-GMPLS and non-recovery contexts. The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. This document also reviews how associations should be made in the case in which the object is carried in a Path message; additionally, it defines usage with Resv messages. This section also discusses usage of the ASSOCIATION object outside the context of GMPLS LSPs.
本文档将关联对象的可能用法扩展到非GMPLS和非恢复上下文。扩展的用法同样适用于GMPLS LSP[RFC3473]、MPLS LSP[RFC3209]和非LSP RSVP会话[RFC2205][RFC2207][RFC3175][RFC4860]。本文档还回顾了在Path消息中携带对象的情况下应如何进行关联；此外，它还定义了Resv消息的用法。本节还讨论了GMPLS LSP上下文之外的关联对象的用法。
Some examples of non-LSP association being used to enable resource sharing are:
用于启用资源共享的非LSP关联的一些示例包括：
o Voice Call-Waiting:
o 语音呼叫等待：
A bidirectional voice call between two endpoints, A and B, is signaled using two separate unidirectional RSVP reservations for the flows A->B and B->A. If endpoint A wishes to put the A-B call on hold and join a separate A-C call, it is desirable that network resources on common links be shared between the A-B and A-C calls. The B->A and C->A subflows of the call can share resources using existing RSVP sharing mechanisms, but only if they use the same destination IP addresses and ports. Since by definition, the RSVP reservations for the subflows A->B and A->C of the call must have different IP addresses in the SESSION objects, this document defines a new mechanism to associate the subflows and allow them to share resources.
两个端点A和B之间的双向语音呼叫使用流A->B和B->A的两个单独的单向RSVP预留发送信号。如果端点A希望暂停A-B呼叫并加入单独的A-C呼叫，则A-B和A-C呼叫之间共享公共链路上的网络资源是可取的。调用的B->A和C->A子流可以使用现有的RSVP共享机制共享资源，但前提是它们使用相同的目标IP地址和端口。根据定义，呼叫子流A->B和A->C的RSVP保留在会话对象中必须具有不同的IP地址，因此本文档定义了一种新的机制来关联子流并允许它们共享资源。
o Voice Shared Line:
o 语音共享线路：
A voice shared line is a single number that rings multiple endpoints (which may be geographically diverse), such as phone lines to a manager's desk and to their assistant. A Voice over IP (VoIP) system that models these calls as multiple point-to-point unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since RSVP unicast reservations to different endpoints cannot share bandwidth. So, a new mechanism is defined in this document to allow separate unicast reservations to be associated and to share resources.
语音共享线路是一个单一的号码，用于连接多个端点（可能在地理位置上不同），例如连接经理办公桌和助理的电话线。IP语音（VoIP）系统将这些呼叫建模为多个点对点单播预环预留，这将导致共享链路上的带宽明显过多，因为对不同端点的RSVP单播预留不能共享带宽。因此，本文定义了一种新的机制，允许关联单独的单播预订并共享资源。
o Symmetric NAT:
o 对称NAT：
RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this case, these flows cannot share resources using RSVP, since the SESSION objects for these two flows outside the NAT have different destination ports. This document defines a new mechanism to associate these flows and allow them to share resources.
RSVP允许在寻址到同一目的地D的多个流之间共享资源，即使来自不同的发送方S1和S2。但是，如果D位于以对称模式[RFC5389]运行的NAT后面，则流S1->D和S2->D的目标端口可能在NAT之外不同。在这种情况下，这些流不能使用RSVP共享资源，因为NAT外部这两个流的会话对象具有不同的目标端口。本文档定义了一种新机制来关联这些流并允许它们共享资源。
In order to support the wider usage of the ASSOCIATION object, this document generalizes the definition of the Association ID field defined in RFC 4872. This generalization has no impact on existing implementations. When using the procedures defined below, association is identified based on exact ASSOCIATION object matching. Some of the other matching mechanisms defined in RFC 4872, e.g., matching based on Session IDs, are not generalized. This document allows for, but does not specify, association type-specific processing.
为了支持关联对象的更广泛使用，本文概括了RFC4872中定义的关联ID字段的定义。这种泛化对现有实现没有影响。当使用下面定义的过程时，关联是基于精确的关联对象匹配来识别的。RFC 4872中定义的一些其他匹配机制（例如，基于会话ID的匹配）不是通用的。此文档允许但不指定特定于关联类型的处理。
This document also defines the Extended ASSOCIATION objects that can be used in the context of MPLS-TP. The scope of the Extended ASSOCIATION objects is not limited to MPLS-TP.
本文档还定义了可在MPLS-TP上下文中使用的扩展关联对象。扩展关联对象的范围不限于MPLS-TP。
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]中所述进行解释。
The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION objects defined in [RFC4872]. The [RFC4872] definition of the field reads:
关联ID字段包含在[RFC4872]中定义的IPv4和IPv6关联对象中。该字段的[RFC4872]定义如下：
A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association.
由LSP头端指定的值。当与关联类型和关联源组合时，此值唯一标识关联。
This document allows for the origination of ASSOCIATION objects by nodes other than "the LSP head-end". As such, the definition of the Association ID field needs to be generalized to accommodate such usage. This document defines the Association ID field of the IPv4 and IPv6 ASSOCIATION objects as:
本文档允许由“LSP头端”以外的节点发起关联对象。因此，需要对关联ID字段的定义进行泛化，以适应这种用法。本文档将IPv4和IPv6关联对象的关联ID字段定义为：
A value assigned by the node that originated the association. When combined with the other fields carried in the object, this value uniquely identifies an association.
由发起关联的节点指定的值。当与对象中携带的其他字段组合时，此值唯一标识关联。
This change in definition does not impact the procedures or mechanisms defined in [RFC4872] or [RFC4873], nor does it impact the existing implementations of [RFC4872] or [RFC4873].
此定义变更不影响[RFC4872]或[RFC4873]中定义的程序或机制，也不影响[RFC4872]或[RFC4873]的现有实现。
While the ASSOCIATION object [RFC4872] is defined in the context of GMPLS recovery, the object can have wider application. [RFC4872] defines the object to be used to "associate LSPs with each other", and then defines an Association Type field to identify the type of association being identified. It also specifies that the Association Type field is to be considered when determining association, i.e., there may be type-specific association rules. As defined by [RFC4872] and reviewed in [RFC6689], this is the case for recovery type ASSOCIATION objects. [RFC6689], notably the text related to resource sharing types, can also be used as the foundation for a generic method for associating LSPs when there is no type-specific association defined.
虽然关联对象[RFC4872]是在GMPLS恢复上下文中定义的，但该对象可以有更广泛的应用。[RFC4872]定义用于“将LSP相互关联”的对象，然后定义关联类型字段以标识要标识的关联类型。它还指定在确定关联时要考虑关联类型字段，即可能存在特定于类型的关联规则。正如[RFC4872]所定义并在[RFC6689]中所述，恢复类型关联对象就是这种情况。[RCF669]，特别是与资源共享类型相关的文本，也可以用作在没有特定类型关联定义的情况下关联LSP的通用方法的基础。
The remainder of this section defines the general rules to be followed when processing ASSOCIATION objects. Object usage in both Path and Resv messages is discussed. The usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. As described below, association is always done based on matching either Path state to Path state, or Resv state to Resv state, but not Path state to Resv State. This section applies to the ASSOCIATION objects defined in [RFC4872].
本节的其余部分定义了处理关联对象时要遵循的一般规则。讨论了Path和Resv消息中的对象用法。该用法同样适用于GMPLS LSP[RFC3473]、MPLS LSP[RFC3209]和非LSP RSVP会话[RFC2205][RFC2207][RFC3175][RFC4860]。如下所述，关联始终基于路径状态与路径状态的匹配，或Resv状态与Resv状态的匹配，而不是路径状态与Resv状态的匹配。本节适用于[RFC4872]中定义的关联对象。
Upstream-initiated association is represented in ASSOCIATION objects carried in Path messages and can be used to associate RSVP Path state across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS tunnel is represented by an RSVP SESSION object, and multiple LSPs may be represented within a single tunnel.) Cross-LSP association based on Path state is defined in [RFC4872]. This section extends that definition by specifying generic association rules and usage for non-LSP uses. This section does not modify processing required to support [RFC4872] and [RFC4873], which is reviewed in Section 3 of [RFC6689]. The use of an ASSOCIATION object in a single session is not precluded.
上游发起的关联在路径消息中携带的关联对象中表示，可用于跨MPLS隧道/RSVP会话关联RSVP路径状态。（注意，根据[RFC3209]，MPLS隧道由RSVP会话对象表示，多个LSP可以在单个隧道中表示。）[RFC4872]中定义了基于路径状态的交叉LSP关联。本节通过为非LSP使用指定通用关联规则和用法来扩展该定义。本节不修改支持[RFC4872]和[RFC4873]所需的处理，这在[RFC6689]的第3节中进行了审查。不排除在单个会话中使用关联对象。
This section provides the Backus-Naur Form (BNF), see [RFC5511], for Path messages containing ASSOCIATION objects. BNF is provided for both MPLS and for non-LSP session usage. Unmodified RSVP message formats and some optional objects are not listed.
本节提供了包含关联对象的路径消息的Backus Naur表单（BNF），请参见[RFC5511]。为MPLS和非LSP会话使用提供了BNF。未列出未修改的RSVP消息格式和一些可选对象。
The formats for MPLS and GMPLS sessions are unmodified from [RFC4872] and can be represented based on the BNF in [RFC3209] as:
MPLS和GMPLS会话的格式未经[RFC4872]修改，可以基于[RFC3209]中的BNF表示为：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format for non-LSP sessions as based on the BNF in [RFC2205] is:
基于[RFC2205]中BNF的非LSP会话格式为：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
In general, relative ordering of ASSOCIATION objects with respect to each other, as well as with respect to other objects, is not significant. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes.
通常，关联对象相对于彼此以及相对于其他对象的相对顺序并不重要。传输节点应保留相同类型关联对象的相对顺序。
This section is based on, and extends, the processing rules described in [RFC4872] and [RFC4873], which is reviewed in [RFC6689]. This section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session state. Note, as previously stated, this section does not modify processing required to support [RFC4872] and [RFC4873].
本节基于并扩展了[RFC4872]和[RFC4873]中描述的处理规则，这些规则在[RFC6689]中进行了审查。本节同样适用于GMPLS LSP、MPLS LSP和非LSP会话状态。注意，如前所述，本节不修改支持[RFC4872]和[RFC4873]所需的处理。
A node sending a Path message chooses when an ASSOCIATION object is to be included in the outgoing Path message. To indicate association between multiple sessions, an appropriate ASSOCIATION object MUST be included in the outgoing Path messages corresponding to each of the associated sessions. In the absence of Association-Type-specific rules for identifying association, the included ASSOCIATION object
发送路径消息的节点选择何时将关联对象包括在传出路径消息中。要指示多个会话之间的关联，必须在与每个关联会话对应的传出路径消息中包含适当的关联对象。在没有用于标识关联的关联类型特定规则的情况下，包含的关联对象
MUST be identical. When there is an Association-Type-specific definition of association rules, the definition SHOULD allow for association based on identical ASSOCIATION objects. This document does not define any Association-Type-specific rules. (See Section 3 of [RFC6689] for a review of Association-Type-specific rules derived from [RFC4872].)
必须是相同的。当存在关联规则的关联类型特定定义时，该定义应允许基于相同关联对象的关联。本文档未定义任何特定于关联类型的规则。（参见[RFC6689]第3节，了解从[RFC4872]派生的特定于关联类型的规则。）
When creating an ASSOCIATION object, the originator MUST format the object as defined in Section 16.1 of [RFC4872]. The originator MUST set the Association Type field based on the type of association being identified. The Association ID field MUST be set to a value that uniquely identifies the specific association within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node originating the association.
创建关联对象时，发起人必须按照[RFC4872]第16.1节中的定义格式化对象。发起人必须根据要识别的关联类型设置关联类型字段。“关联ID”字段必须设置为在关联源字段的上下文中唯一标识特定关联的值。关联源字段必须设置为分配给发起关联的节点的唯一地址。
A downstream node can identify an upstream-initiated association by performing the following checks. When a node receives a Path message, it MUST check each ASSOCIATION object received in the Path message to determine if the object contains an Association Type field value supported by the node. For each ASSOCIATION object containing a supported association type, the node MUST then check to see if the object matches an ASSOCIATION object received in any other Path message. To perform this matching, a node MUST examine the Path state of all other sessions and compare the fields contained in the newly received ASSOCIATION object with the fields contained in the Path state's ASSOCIATION objects. An association is deemed to exist when the same values are carried in all fields of the ASSOCIATION objects being compared. Type-specific processing of ASSOCIATION objects is outside the scope of this document.
下游节点可以通过执行以下检查来识别上游发起的关联。当节点接收到路径消息时，它必须检查路径消息中接收到的每个关联对象，以确定该对象是否包含该节点支持的关联类型字段值。对于包含支持的关联类型的每个关联对象，节点必须检查该对象是否与在任何其他路径消息中接收的关联对象匹配。要执行此匹配，节点必须检查所有其他会话的路径状态，并将新接收的关联对象中包含的字段与路径状态的关联对象中包含的字段进行比较。当在所比较的关联对象的所有字段中携带相同的值时，关联被视为存在。关联对象的特定类型处理不在本文档的范围内。
Note that as more than one association may exist, the described matching MUST continue after a match is identified and MUST be performed against all local Path state. It is also possible for there to be no match identified.
注意，由于可能存在多个关联，所描述的匹配必须在识别匹配后继续，并且必须针对所有本地路径状态执行。也可能没有识别出匹配项。
Unless there are type-specific processing rules, downstream nodes MUST forward all ASSOCIATION objects received in a Path message in any corresponding outgoing Path messages without modification. This processing MUST be followed for unknown Association Type field values.
除非存在特定于类型的处理规则，否则下游节点必须在任何相应的传出路径消息中转发路径消息中接收到的所有关联对象，而无需修改。对于未知关联类型字段值，必须执行此处理。
Downstream-initiated association is represented in ASSOCIATION objects carried in Resv messages and can be used to associate RSVP Resv state across MPLS Tunnels/RSVP sessions. Cross-LSP association, based on Path state, is defined in [RFC4872]. This section defines
下游发起的关联在Resv消息中携带的关联对象中表示，可用于跨MPLS隧道/RSVP会话关联RSVP Resv状态。基于路径状态的交叉LSP关联在[RFC4872]中定义。本节定义了
cross-session association based on Resv state. This section places no additional requirements on implementations supporting [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a single session is not precluded.
基于Resv状态的跨会话关联。本节对支持[RFC4872]和[RFC4873]的实现没有附加要求。注意，不排除在单个会话中使用关联对象。
This section provides the Backus-Naur Form (BNF), see [RFC5511], for Resv messages containing ASSOCIATION objects. BNF is provided for both MPLS and for non-LSP session usage. Unmodified RSVP message formats and some optional objects are not listed.
本节提供了包含关联对象的Resv消息的Backus Naur表单（BNF），请参见[RFC5511]。为MPLS和非LSP会话使用提供了BNF。未列出未修改的RSVP消息格式和一些可选对象。
The formats for MPLS, GMPLS, and non-LSP sessions are identical and are represented based on the BNF in [RFC2205] and [RFC3209]:
MPLS、GMPLS和非LSP会话的格式相同，并基于[RFC2205]和[RFC3209]中的BNF表示：
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
Relative ordering of ASSOCIATION objects with respect to each other, as well as with respect to other objects, is not currently significant. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes.
关联对象相对于彼此以及相对于其他对象的相对顺序目前并不重要。传输节点应保留相同类型关联对象的相对顺序。
This section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session state.
本节同样适用于GMPLS LSP、MPLS LSP和非LSP会话状态。
A node sending a Resv message chooses when an ASSOCIATION object is to be included in the outgoing Resv message. A node that wishes to allow upstream nodes to associate Resv state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Resv messages corresponding to the RSVP sessions to be associated. In the absence of Association-Type-specific rules for identifying association, the included ASSOCIATION objects MUST be identical. When there is an Association-Type-specific definition of association rules, the definition SHOULD allow for association based on identical ASSOCIATION objects. This document does not define any Association-Type-specific rules.
发送Resv消息的节点选择何时将关联对象包括在传出的Resv消息中。希望允许上游节点跨RSVP会话关联Resv状态的节点必须在与要关联的RSVP会话相对应的传出Resv消息中包含关联对象。如果没有用于标识关联的关联类型特定规则，则包含的关联对象必须相同。当存在关联规则的关联类型特定定义时，该定义应允许基于相同关联对象的关联。本文档未定义任何特定于关联类型的规则。
When creating an ASSOCIATION object, the originator MUST format the object as defined in Section 16.1 of [RFC4872]. The originator MUST set the Association Type field based on the type of association being
创建关联对象时，发起人必须按照[RFC4872]第16.1节中的定义格式化对象。发起人必须根据所创建的关联类型设置关联类型字段
identified. The Association ID field MUST be set to a value that uniquely identifies the specific association within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node originating the association.
确定。“关联ID”字段必须设置为在关联源字段的上下文中唯一标识特定关联的值。关联源字段必须设置为分配给发起关联的节点的唯一地址。
An upstream node can identify a downstream-initiated association by performing the following checks. When a node receives a Resv message, it MUST check each ASSOCIATION object received in the Resv message to determine if the object contains an Association Type field value supported by the node. For each ASSOCIATION object containing a supported association type, the node MUST then check to see if the object matches an ASSOCIATION object received in any other Resv message. To perform this matching, a node MUST examine the Resv state of all other sessions and compare the fields contained in the newly received ASSOCIATION object with the fields contained in the Resv state's ASSOCIATION objects. An association is deemed to exist when the same values are carried in all fields of the ASSOCIATION objects being compared. Type-specific processing of ASSOCIATION objects is outside the scope of this document.
上游节点可以通过执行以下检查来识别下游发起的关联。当节点接收到Resv消息时，它必须检查在Resv消息中接收到的每个关联对象，以确定该对象是否包含该节点支持的关联类型字段值。对于包含支持的关联类型的每个关联对象，节点必须检查该对象是否与任何其他Resv消息中接收到的关联对象匹配。要执行此匹配，节点必须检查所有其他会话的Resv状态，并将新接收的关联对象中包含的字段与Resv状态的关联对象中包含的字段进行比较。当在所比较的关联对象的所有字段中携带相同的值时，关联被视为存在。关联对象的特定类型处理不在本文档的范围内。
Note that as more than one association may exist, the described matching MUST continue after a match is identified and MUST be performed against all local Resv state. It is also possible for there to be no match identified.
注意，由于可能存在多个关联，所述匹配必须在识别匹配后继续，并且必须针对所有本地Resv状态执行。也可能没有识别出匹配项。
Unless there are type-specific processing rules, upstream nodes MUST forward all ASSOCIATION objects received in a Resv message in any corresponding outgoing Resv messages without modification. This processing MUST be followed for unknown Association Type field values.
除非存在特定于类型的处理规则，否则上游节点必须在任何相应的传出Resv消息中转发在Resv消息中接收到的所有关联对象，而无需修改。对于未知关联类型字段值，必须执行此处理。
Two association types are currently defined: recovery and resource sharing. Recovery type association is only applicable within the context of recovery [RFC4872] [RFC4873]. Resource sharing is applicable to any context and its general use is defined in this section.
目前定义了两种关联类型：恢复和资源共享。恢复类型关联仅适用于恢复上下文[RFC4872][RFC4873]。资源共享适用于任何上下文，本节定义了资源共享的一般用途。
The Resource Sharing Association Type was defined in [RFC4873] and was defined within the context of GMPLS and upstream-initiated association. This section presents a definition of the resource sharing association that allows for its use with any RSVP session type and in both Path and Resv messages. This definition is consistent with the definition of the resource sharing association
资源共享关联类型在[RFC4873]中定义，并在GMPLS和上游发起关联的上下文中定义。本节介绍了资源共享关联的定义，该定义允许将其用于任何RSVP会话类型以及Path和Resv消息中。此定义与资源共享关联的定义一致
type in [RFC4873] and no changes are required by this section in order to support [RFC4873]. The Resource Sharing Association Type MUST be supported by any implementation compliant with this document.
输入[RFC4873]，本节无需更改即可支持[RFC4873]。符合此文档的任何实现都必须支持资源共享关联类型。
The Resource Sharing Association Type is used to enable resource sharing across RSVP sessions. Per [RFC4873], resource sharing uses the Association Type field value of 2. ASSOCIATION objects with an Association Type with the value Resource Sharing MAY be carried in Path and Resv messages. Association for the Resource Sharing type MUST follow the procedures defined in Section 3.1.2 for upstream-initiated (Path message) association and Section 3.2.1 for downstream-initiated (Resv message) association. There are no type-specific association rules, processing rules, or ordering requirements. Note that, as is always the case with association as enabled by this document, no associations are made across Path and Resv state.
资源共享关联类型用于跨RSVP会话启用资源共享。根据[RFC4873]，资源共享使用关联类型字段值2。Path和Resv消息中可能包含具有值资源共享的关联类型的关联对象。资源共享类型的关联必须遵循第3.1.2节针对上游启动（路径消息）关联和第3.2.1节针对下游启动（Resv消息）关联定义的程序。没有特定于类型的关联规则、处理规则或排序要求。请注意，与本文档启用的关联情况一样，不会跨路径和Resv状态进行关联。
Once an association is identified, resources MUST be considered as shared across the identified sessions by the admission-control function. Since the implementation specifics of the admission-control function is outside the scope of RSVP, we observe that how resource sharing is actually reflected may vary according to specific implementations (e.g., depending on the specific admission-control and resource-management algorithm, or on how local policy is taken into account).
一旦识别出关联，准入控制功能必须将资源视为在已识别的会话中共享。由于接纳控制功能的实现细节不在RSVP的范围内，我们观察到资源共享的实际反映方式可能会因具体实现而有所不同（例如，取决于具体的接纳控制和资源管理算法，或者取决于如何考虑本地策略）。
As required by Sections 3.1.2 and 3.2.2 above, a node that receives an ASSOCIATION object containing an unknown ASSOCIATION type forwards all received ASSOCIATION objects as defined above. The node MAY also identify associations per the defined processing, e.g., to make this information available via a management interface.
根据上述第3.1.2节和第3.2.2节的要求，接收包含未知关联类型的关联对象的节点转发所有接收到的关联对象，如上所述。节点还可以根据定义的处理识别关联，例如，通过管理接口使该信息可用。
[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION object. As defined, these objects each contain an Association Source field and a 16-bit Association ID field. As previously described, the contents of the object uniquely identify an association. Because the Association ID field is a 16-bit field, an association source can allocate up to 65536 different associations and no more. There are scenarios where this number is insufficient (for example, where the association identification is best known and identified by a fairly centralized entity, and therefore may be involved in a large number of associations).
[RFC4872]定义IPv4关联对象和IPv6关联对象。根据定义，这些对象各自包含一个关联源字段和一个16位关联ID字段。如前所述，对象的内容唯一地标识关联。因为关联ID字段是一个16位字段，所以关联源最多可以分配65536个不同的关联，而不能分配更多。有些情况下，该数量不足（例如，关联标识最为人所知，由相当集中的实体标识，因此可能涉及大量关联）。
An additional case that cannot be supported using the existing ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370], MPLS-TP LSPs can be identified based on an operator-unique global identifier. As defined in [RFC6370], "global identifier", or Global_ID, is based on [RFC5003] and includes the operator's Autonomous System Number (ASN).
MPLS-TP LSP提供了使用现有关联对象无法支持的另一种情况。根据[RFC6370]，MPLS-TP LSP可以基于操作员唯一的全局标识符进行标识。根据[RFC6370]中的定义，“全局标识符”或全局ID基于[RFC5003]，包括操作员的自主系统编号（ASN）。
This section defines new ASSOCIATION objects to support extended identification in order to address the previously described limitations. Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION object are defined below. Both new objects include the fields necessary to enable identification of a larger number of associations as well as MPLS-TP-required identification.
本节定义了支持扩展标识的新关联对象，以解决前面描述的限制。具体而言，IPv4扩展关联对象和IPv6扩展关联对象定义如下。这两个新对象都包括识别大量关联以及MPLS TP所需识别所需的字段。
The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION object SHOULD be supported by an implementation compliant with this document. The processing rules for the IPv4 and IPv6 Extended ASSOCIATION object are described below and are based on the rules for the IPv4 and IPv6 ASSOCIATION objects as previously described.
IPv4扩展关联对象和IPv6扩展关联对象应由符合本文档的实现支持。IPv4和IPv6扩展关联对象的处理规则如下所述，并基于前面所述的IPv4和IPv6关联对象的规则。
The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 3) has the format:
IPv4扩展关联对象（11bbbbbb形式的类Num，值=199，C-Type=3）的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 4) has the format:
IPv6扩展关联对象（11bbbbbb格式的类Num，值=199，C-Type=4）的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Association Type: 16 bits
关联类型：16位
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
与IPv4和IPv6关联对象相同，请参阅[RFC4872]。
Association ID: 16 bits
关联ID:16位
Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2.
与IPv4和IPv6关联对象相同，请参见第2节。
Association Source: 4 or 16 bytes
关联源：4或16字节
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
与IPv4和IPv6关联对象相同，请参阅[RFC4872]。
Global Association Source: 4 bytes
全局关联源：4字节
This field contains a value that is a unique global identifier or the special value zero (0). When non-zero and not overridden by local policy, the Global_ID as defined in [RFC6370] SHALL be used. The special value zero indicates that no global identifier is present. Use of the special value zero SHOULD be limited to entities contained within a single operator.
此字段包含唯一全局标识符或特殊值零（0）的值。当非零且未被本地政策覆盖时，应使用[RFC6370]中定义的全局ID。特殊值零表示不存在全局标识符。特殊值零的使用应限于单个运算符中包含的实体。
If the Global Association Source field value is derived from a 2-octet ASN, then the two high-order octets of this 4-octet field MUST be set to zero.
如果全局关联源字段值是从2-八位字节ASN派生的，则此4-八位字节字段的两个高阶八位字节必须设置为零。
Extended Association ID: variable, 4-byte aligned
扩展关联ID：变量，4字节对齐
This field contains data that is additional information to support unique identification. The length and contents of this field is scoped by the Association Source. The length of this field is derived from the object Length field and as such MUST have a length of zero or be 4-byte aligned. A length of zero indicates that this field is omitted.
此字段包含作为支持唯一标识的附加信息的数据。此字段的长度和内容由关联源确定范围。此字段的长度源自对象长度字段，因此长度必须为零或4字节对齐。长度为零表示省略此字段。
The processing of an IPv4 or IPv6 Extended ASSOCIATION object MUST be identical to the processing of an IPv4 or IPv6 ASSOCIATION object as previously described, except as extended by this section. This section applies to ASSOCIATION objects included in both Path and Resv messages.
IPv4或IPv6扩展关联对象的处理必须与前面描述的IPv4或IPv6关联对象的处理相同，本节扩展的除外。本节适用于Path和Resv消息中包含的关联对象。
The following are the modified procedures for Extended ASSOCIATION object processing:
以下是扩展关联对象处理的修改过程：
o When creating an Extended ASSOCIATION object, the originator MUST format the object as defined in this document.
o 创建扩展关联对象时，发起人必须按照本文档中的定义设置对象的格式。
o The originator MUST set the Association Type, Association ID, and Association Source fields as described in Section 4.
o 发起人必须按照第4节所述设置关联类型、关联ID和关联源字段。
o When ASN-based global identification of the Association Source is desired, the originator MUST set the Global Association Source field. When ASN-based global identification is not desired, the originator MUST set the Global Association Source field to zero (0).
o 当需要基于ASN的关联源全局标识时，发起人必须设置全局关联源字段。当不需要基于ASN的全局标识时，发起人必须将全局关联源字段设置为零（0）。
o The Extended ASSOCIATION object originator MAY include the Extended Association ID field. The field is included based on local policy. The field MUST be included when the Association ID field is insufficient to uniquely identify association within the scope of the source of the association. When included, this field MUST be set to a value that, when taken together with the other fields in the object, uniquely identifies the association being identified.
o 扩展关联对象发起人可以包括扩展关联ID字段。该字段是根据本地策略包含的。当关联ID字段不足以唯一标识关联源范围内的关联时，必须包含该字段。包含时，此字段必须设置为一个值，该值与对象中的其他字段一起使用时，唯一标识要标识的关联。
o The object Length field is set based on the length of the Extended Association ID field. When the Extended Association ID field is omitted, the object Length field MUST be set to 16 or 28 for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the Extended Association ID field is present, the object Length field MUST be set to indicate the additional bytes carried in the Extended Association ID field, including pad bytes.
o 对象长度字段是基于扩展关联ID字段的长度设置的。如果省略扩展关联ID字段，则IPv4和IPv6关联对象的对象长度字段必须分别设置为16或28。当存在扩展关联ID字段时，必须设置对象长度字段以指示扩展关联ID字段中包含的其他字节，包括pad字节。
Note: Per [RFC2205], the object Length field is set to the total object length in bytes, is always a multiple of 4, and is at least 4.
注意：根据[RFC2205]，对象长度字段设置为以字节为单位的对象总长度，始终为4的倍数，并且至少为4。
The procedures related to association identification are not modified by this section. It is important to note that Section 4 defines the identification of associations based on ASSOCIATION object matching and that such matching, in the absence of type-specific comparison rules, is based on the comparison of all fields in an ASSOCIATION object. This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects.
本节不修改与关联识别相关的程序。需要注意的是，第4节定义了基于关联对象匹配的关联标识，并且在没有特定类型比较规则的情况下，这种匹配基于关联对象中所有字段的比较。这同样适用于关联对象和扩展关联对象。
Per [RFC4872], the ASSOCIATION object uses an object class number of the form 11bbbbbb to ensure compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification. This is also the action taken for unknown association types as discussed above in Section 3.1.2, 3.2.2, and 3.3.2.
根据[RFC4872]，关联对象使用11BBBB形式的对象类编号，以确保与非支持节点的兼容性。根据[RFC2205]，这样的节点将忽略对象，但在不修改的情况下转发它。这也是上文第3.1.2节、第3.2.2节和第3.3.2节中讨论的针对未知关联类型采取的措施。
Per [RFC4872], transit nodes that support the ASSOCIATION object but not the Extended Association C-Types will "transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message". Per [RFC2205], an egress node that supports the ASSOCIATION object but not the Extended Association C-Types, may generate an "Unknown object C-Type" error. This error will propagate to the ingress node for standard error processing.
根据[RFC4872]，支持关联对象但不支持扩展关联C-TYPE的传输节点将“在不修改的情况下，在相应的传出路径消息中传输任何接收到的关联对象”。根据[RFC2205]，支持关联对象但不支持扩展关联C类型的出口节点可能会生成“未知对象C类型”错误。此错误将传播到入口节点进行标准错误处理。
Operators wishing to use a function supported by a particular association type should ensure that the type is supported on any node that is expected to act on the association.
希望使用特定关联类型支持的函数的操作员应确保该类型在预期作用于该关联的任何节点上都受支持。
A portion of this document reviews procedures defined in [RFC4872] and [RFC4873] and does not define new procedures. As such, no new security considerations are introduced in this portion of the document.
本文件的一部分审查了[RFC4872]和[RFC4873]中定义的程序，但未定义新程序。因此，本文件的这一部分没有引入新的安全注意事项。
Section 3 defines broader usage of the ASSOCIATION object, but does not fundamentally expand on the association function that was previously defined in [RFC4872] and [RFC4873]. Section 4 increases the number of bits that are carried in an ASSOCIATION object (by 32), and similarly does not expand on the association function that was previously defined. This broader definition does allow for additional information to be conveyed, but this information is not fundamentally different from the information that is already carried
第3节定义了关联对象的更广泛用途，但没有从根本上扩展之前在[RFC4872]和[RFC4873]中定义的关联函数。第4节增加关联对象中携带的比特数（增加32个），并且类似地不扩展先前定义的关联函数。这一更广泛的定义确实允许传达更多的信息，但这一信息与已经携带的信息没有根本区别
in RSVP. Therefore, there are no new risks or security considerations introduced by this document.
在RSVP中。因此，本文件没有引入新的风险或安全注意事项。
For a general discussion on MPLS- and GMPLS-related security issues, including RSVP's chain of trust security model, see the MPLS/GMPLS security framework [RFC5920].
有关MPLS和GMPLS相关安全问题的一般性讨论，包括RSVP的信任链安全模型，请参阅MPLS/GMPLS安全框架[RFC5920]。
IANA has assigned new values for namespaces defined in this document and they are summarized in this section.
IANA为本文档中定义的名称空间分配了新的值，本节对这些值进行了总结。
Per this document, IANA has assigned two new C-Types (which are defined in Section 3.1) for the existing ASSOCIATION object in the "Class Names, Class Numbers, and Class Types" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at http://www.iana.org/assignments/rsvp-parameters:
根据本文件，IANA为“资源保留协议（RSVP）参数”注册表中的“类名、类号和类类型”部分中的现有关联对象分配了两个新的C类型（定义见第3.1节）http://www.iana.org/assignments/rsvp-parameters:
199 ASSOCIATION [RFC4872]
199协会[RFC4872]
Class Types or C-Types
类类型还是C类型
3 Type 3 IPv4 Extended Association [RFC6780] 4 Type 4 IPv6 Extended Association [RFC6780]
3类型3 IPv4扩展关联[RFC6780]4类型4 IPv6扩展关联[RFC6780]
This document also broadens the potential usage of the Resource Sharing Association Type defined in [RFC4873]. As such, IANA has updated the reference of the Resource Sharing Association Type included in the associated registry. Per this document, IANA has also corrected the duplicate usage of '(R)' in this registry. In particular, the "Association Type" registry found at http://www.iana.org/assignments/gmpls-sig-parameters/ has been updated as follows:
本文档还扩展了[RFC4873]中定义的资源共享关联类型的潜在用途。因此，IANA更新了相关注册表中包含的资源共享关联类型的引用。根据本文件，IANA还更正了此注册表中重复使用的“（R）”。特别是，可在以下位置找到“关联类型”注册表：http://www.iana.org/assignments/gmpls-sig-parameters/ 已更新如下：
OLD: 2 Resource Sharing (R) [RFC4873]
旧版本：2资源共享（R）[RFC4873]
NEW: 2 Resource Sharing (S) [RFC4873][RFC6780]
新：2个资源共享[RFC4873][RFC6780]
There are no other IANA considerations introduced by this document.
本文件没有介绍其他IANA注意事项。
Valuable comments and input were received from Dimitri Papadimitriou, Fei Zhang, and Adrian Farrel. We thank Subha Dhesikan for her contribution to the early work on sharing of resources across RSVP reservations.
迪米特里·帕帕迪米特里欧、张飞和阿德里安·法雷尔提出了宝贵的意见和建议。我们感谢Subha Dhesikan对RSVP保留区资源共享早期工作的贡献。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[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月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[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月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]Le Faucheur，F.，Davie，B.，Bose，P.，Christou，C.，和M.Davenport，“通用聚合资源预留协议（RSVP）预留”，RFC 48602007年5月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003]Metz，C.，Martini，L.，Balus，F.，和J.Sugimoto，“聚合的附件个人标识符（AII）类型”，RFC 5003，2007年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, July 2012.
[RFC6689]Berger，L.“RSVP关联对象的使用”，RFC 6689，2012年7月。
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
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France EMail: flefauch@cisco.com
Francois Le Faucheur Cisco Systems Greenside，400 Avenue de Roumanille Sophia Antipolis 06410 France电子邮件：flefauch@cisco.com
Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 United States EMail: ashokn@cisco.com
Ashok Narayanan Cisco Systems美国马萨诸塞州Boxborough市比弗布鲁克路300号邮编01719电子邮件：ashokn@cisco.com