Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6689 LabN
Category: Informational July 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6689 LabN
Category: Informational July 2012
ISSN: 2070-1721
Usage of the RSVP ASSOCIATION Object
RSVP关联对象的用法
Abstract
摘要
The Resource Reservation Protocol (RSVP) ASSOCIATION object is 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 document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature.
资源预留协议（RSVP）关联对象是在GMPLS控制的标签交换路径（LSP）上下文中定义的。在此上下文中，该对象用于将恢复LSP与其保护的LSP关联起来。本文件回顾了如何在GMPLS恢复的背景下提供关联。本文件未定义任何新的程序或机制，其性质严格为信息性文件。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6689.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6689.
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
2. Background ......................................................2
2.1. LSP Association ............................................3
2.2. End-to-End Recovery LSP Association ........................4
2.3. Segment Recovery LSP Association ...........................7
2.4. Resource Sharing LSP Association ...........................8
3. Association of GMPLS Recovery LSPs ..............................8
4. Security Considerations ........................................10
5. Acknowledgments ................................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
1. Introduction ....................................................2
2. Background ......................................................2
2.1. LSP Association ............................................3
2.2. End-to-End Recovery LSP Association ........................4
2.3. Segment Recovery LSP Association ...........................7
2.4. Resource Sharing LSP Association ...........................8
3. Association of GMPLS Recovery LSPs ..............................8
4. Security Considerations ........................................10
5. Acknowledgments ................................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
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. This document provides additional narrative on how such associations are to be identified. This document does not define any new procedures or mechanisms and is strictly informative in nature.
[RFC4872]和[RFC4873]中分别为GMPLS控制的标签交换路径（LSP）定义了端到端和段恢复。这两个定义都使用关联对象将恢复LSP与其保护的LSP关联起来。本文件提供了关于如何识别此类关联的补充说明。本文件未定义任何新的程序或机制，且严格为信息性文件。
It may not be immediately obvious to the informed reader why this document is necessary; however, questions were repeatedly raised in the Common Control and Measurement Plane (CCAMP) working group on the proper interpretation of the ASSOCIATION object in the context of end-to-end and segment recovery, and the working group agreed that this document should be produced in order to close the matter. This document formalizes the explanation provided in an e-mail to the working group authored by Adrian Farrel, see [AF-EMAIL]. This document in no way modifies the normative definitions of end-to-end and segment recovery, see [RFC4872] or [RFC4873].
对于知情的读者来说，本文件的必要性可能并不明显；然而，在共同控制和测量平面（CCAMP）工作组中，就如何在端到端和分段恢复的背景下正确解释关联对象，反复提出了问题，工作组一致认为，为了解决这一问题，应编制本文件。本文件正式说明了阿德里安·法雷尔（Adrian Farrel）向工作组发送的电子邮件中提供的解释，见[AF-EMAIL]。本文件绝不修改端到端和段恢复的规范性定义，请参见[RFC4872]或[RFC4873]。
This section reviews the definition of LSP association in the contexts of end-to-end and segment recovery as defined in [RFC4872] and [RFC4873]. This section merely reiterates what has been defined; if differences exist between this text and [RFC4872] or [RFC4873], the earlier RFCs provide the authoritative text.
本节回顾了[RFC4872]和[RFC4873]中定义的端到端和段恢复上下文中LSP关联的定义。本节仅重申已定义的内容；如果本文本与[RFC4872]或[RFC4873]之间存在差异，则早期RFC提供权威文本。
[RFC4872] introduces the concept and mechanisms to support the association of one LSP to another LSP across different RSVP - Traffic Engineering (RSVP-TE) sessions. Such association is enabled via the introduction of the ASSOCIATION object. The ASSOCIATION object is defined in Section 16 of [RFC4872]. It is explicitly defined as having both general application and specific use within the context of recovery. End-to-end recovery usage is defined in [RFC4872] and is covered in Section 2.2 of this document. Segment recovery usage is defined in [RFC4873] and is covered in Section 2.3 of this document. Resource sharing type LSP association is also defined in [RFC4873]. While strictly speaking, such association is beyond the scope of this document, it is covered in Section 2.4 of this document for completeness. The remainder of this section covers generic usage of the ASSOCIATION object.
[RFC4872]介绍了支持跨不同RSVP-流量工程（RSVP-TE）会话将一个LSP与另一个LSP关联的概念和机制。这种关联是通过引入关联对象来启用的。[RFC4872]第16节定义了关联对象。它被明确定义为在恢复上下文中具有一般应用程序和特定用途。[RFC4872]中定义了端到端恢复用法，本文档第2.2节介绍了端到端恢复用法。[RFC4873]中定义了段恢复用途，本文件第2.3节对此进行了介绍。[RFC4873]中还定义了资源共享类型LSP关联。严格来说，这种关联不在本文件的范围内，为了完整性，本文件第2.4节对其进行了介绍。本节的其余部分介绍关联对象的一般用法。
In general, LSP association using the ASSOCIATION object can take place based on the values carried in the ASSOCIATION object. This means that association between LSPs can take place independently of and across different sessions. This is a significant enhancement from the association of LSPs that is possible in base MPLS [RFC3209] and GMPLS [RFC3473].
通常，使用关联对象的LSP关联可以基于关联对象中携带的值进行。这意味着LSP之间的关联可以独立于不同会话并跨不同会话进行。这是LSP关联的显著增强，LSP关联在基本MPLS[RFC3209]和GMPLS[RFC3473]中是可能的。
When using the ASSOCIATION object, LSP association is always initiated by an upstream node that inserts appropriate ASSOCIATION objects in the Path message of LSPs that are to be associated. Downstream nodes then correlate LSPs based on received ASSOCIATION objects. Multiple types of LSP association are supported by the ASSOCIATION object, and downstream correlation is made based on the type.
使用关联对象时，LSP关联始终由上游节点启动，该节点在要关联的LSP的路径消息中插入适当的关联对象。然后，下游节点根据接收到的关联对象关联LSP。关联对象支持多种类型的LSP关联，并基于该类型进行下游关联。
[RFC4872] defines Class Types (C-Types) 1 and 2 of the ASSOCIATION object. Both objects have essentially the same semantics, only differing in the type of address carried (IPv4 and IPv6). The defined objects carry multiple fields. The fields, taken together, enable the identification of which LSPs are in association with one another. The [RFC4872]-defined fields are:
[RFC4872]定义关联对象的类类型（C类型）1和2。这两个对象本质上具有相同的语义，只是所携带的地址类型不同（IPv4和IPv6）。定义的对象包含多个字段。这些字段合在一起可以识别哪些LSP彼此关联。[RFC4872]定义的字段为：
o Association Type: This field identifies the usage, or application, of the ASSOCIATION object. The currently defined values are "Recovery" [RFC4872] and "Resource Sharing" [RFC4873]. This field also scopes the interpretation of the object. In other words, the type field is included when matching LSPs (i.e., the type fields must match), and the way associations are identified may be type dependent.
o 关联类型：此字段标识关联对象的用法或应用程序。当前定义的值是“恢复”[RFC4872]和“资源共享”[RFC4873]。此字段还限定对象的解释范围。换句话说，类型字段在匹配LSP时包括在内（即，类型字段必须匹配），并且识别关联的方式可能依赖于类型。
o Association Source: This field is used to provide global scope (within the address space) to the identified association. There are no specific rules in the general case for which an address should be used by a node creating an ASSOCIATION object beyond that the address is "associated to the node that originated the association", see [RFC4872].
o 关联源：此字段用于为标识的关联提供全局范围（在地址空间内）。在创建关联对象的节点应使用地址的一般情况下，没有特定规则，该地址“关联到发起关联的节点”，请参见[RFC4872]。
o Association ID: This field provides an "identifier" that further scopes an association. Again, this field is combined with the other ASSOCIATION object fields to support identification of associated LSPs. The generic definition does not provide any specific rules on how matching is to be done, so such rules are governed by the Association Type. Note that the definition permits the association of an arbitrary number of LSPs.
o 关联ID：此字段提供一个“标识符”，用于进一步确定关联的范围。同样，此字段与其他关联对象字段组合，以支持关联LSP的标识。泛型定义没有提供关于如何进行匹配的任何特定规则，因此此类规则由关联类型管理。请注意，该定义允许关联任意数量的LSP。
As defined, the ASSOCIATION object may only be carried in a Path message, so LSP association takes place based on the Path state. The definition permits one or more objects to be present. The support for multiple objects enables an LSP to be associated with other LSPs in more than one way at a time. For example, an LSP may carry one ASSOCIATION object to associate the LSP with another LSP for end-to-end recovery, and at the same time carry a second ASSOCIATION object to associate the LSP with another LSP for segment recovery, and at the same time carry a third ASSOCIATION object to associate the LSP with yet another LSP for resource sharing.
根据定义，关联对象只能在路径消息中携带，因此LSP关联基于路径状态发生。该定义允许存在一个或多个对象。对多个对象的支持使LSP能够一次以多种方式与其他LSP关联。例如，LSP可以携带一个关联对象以将LSP与另一个LSP关联以进行端到端恢复，同时携带第二个关联对象以将LSP与另一个LSP关联以进行段恢复，同时携带第三个关联对象以将LSP与另一个LSP关联以进行资源共享。
The association of LSPs in support of end-to-end LSP recovery is defined in Section 16.2 of [RFC4872]. There are also several additional related conformance statements (i.e., use of [RFC2119] defined key words) in Sections 7.3, 8.3, 9.3, and 11.1 of [RFC4872]. When analyzing the definition, as with any Standards Track RFC, it is critical to note and differentiate which statements are made using [RFC2119] defined key words, which relate to conformance, and which statements are made without such key words, and are thereby only informative in nature.
[RFC4872]第16.2节定义了支持端到端LSP恢复的LSP关联。[RFC4872]第7.3节、第8.3节、第9.3节和第11.1节中还有几个附加的相关一致性声明（即使用[RFC2119]定义的关键字）。在分析定义时，与任何标准跟踪RFC一样，重要的是要注意并区分哪些声明使用[RFC2119]定义的关键字，哪些与合规性相关，哪些声明不使用此类关键字，因此仅具有信息性。
As defined in Section 16.2, end-to-end recovery-related LSP association may take place in two distinct forms:
如第16.2节所定义，端到端恢复相关LSP关联可能以两种不同的形式发生：
a. Between multiple (one or more) working LSPs and a single shared (associated) recovery LSP. This form essentially matches the shared 1:N (N >= 1) recovery type described in the other sections of [RFC4872].
a. 在多个（一个或多个）工作LSP和单个共享（关联）恢复LSP之间。此表单基本上与[RFC4872]其他部分中描述的共享1:N（N>=1）恢复类型匹配。
b. Between a single working LSP and multiple (one or more) recovery LSPs. This form essentially matches all other recovery types described in [RFC4872].
b. 在单个工作LSP和多个（一个或多个）恢复LSP之间。此表单基本上与[RFC4872]中描述的所有其他恢复类型匹配。
Both forms share the same Association Type (Recovery) and the same Association Source (the working LSP's tunnel sender address). They also share the same definition of the Association ID, which is (quoting [RFC4872]):
两个表单共享相同的关联类型（恢复）和相同的关联源（工作LSP的隧道发送方地址）。它们还共享相同的关联ID定义，即（引用[RFC4872]）：
The Association ID MUST be set to the LSP ID of the LSP being protected by this LSP or the LSP protecting this LSP. If unknown, this value is set to its own signaled LSP_ID value (default). Also, the value of the Association ID MAY change during the lifetime of the LSP.
关联ID必须设置为受此LSP保护的LSP或保护此LSP的LSP的LSP ID。如果未知，此值将设置为其自己的信号LSP_ID值（默认值）。此外，关联ID的值可以在LSP的生存期期间改变。
The interpretation of the above is fairly straightforward. The Association ID carries one of three values: - The LSP ID of the LSP being protected. - The LSP ID of the protection LSP. - In the case where the matching LSP is not yet known (i.e., initiated), the LSP ID value of the LSP itself.
对上述内容的解释相当直截了当。关联ID包含三个值之一：-受保护LSP的LSP ID。-保护LSP的LSP ID。-在匹配LSP尚未知（即，已启动）的情况下，LSP本身的LSP ID值。
The text also explicitly allows for changing the Association ID during the lifetime of an LSP. However, this is only an option, and is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). It should be noted that [RFC4872] does not describe when such a change should be initiated or the procedures for executing such a change. Clearly, care needs to be taken when changing the Association ID to ensure that the old association is not lost during the transition to a new association.
该文本还明确允许在LSP的生存期内更改关联ID。然而，这只是一种选择，既不是必需的（即“必须”），也不是建议的（即“应该”）。应注意的是，[RFC4872]并未说明何时应启动此类变更或执行此类变更的程序。显然，在更改关联ID时需要小心，以确保在转换到新关联的过程中不会丢失旧关联。
The text does not preclude, and it is therefore assumed, that one or more ASSOCIATION objects may also be added to an LSP that was originated without any ASSOCIATION objects. Again, this is a case that is not explicitly discussed in [RFC4872].
文本不排除，因此假设，一个或多个关联对象也可以添加到没有任何关联对象的LSP。同样，这种情况在[RFC4872]中没有明确讨论。
From the above, this means that the following combinations may occur:
从上述情况来看，这意味着可能发生以下组合：
Case 1. When the ASSOCIATION object of the LSP being protected is initialized before the ASSOCIATION objects of any recovery LSPs are initialized, the Association ID in the LSP being protected and any recovery LSPs will carry the same value, and this value will be the LSP ID value of the LSP being protected.
案例1。在初始化任何恢复LSP的关联对象之前初始化被保护LSP的关联对象时，被保护LSP和任何恢复LSP中的关联ID将携带相同的值，该值将是被保护LSP的LSP ID值。
Case 2. When the ASSOCIATION object of a recovery LSP is initialized before the ASSOCIATION object of any protected LSP is initialized, the Association ID in the recovery LSP and any LSPs being protected by that LSP will carry the same value, and this value will be the LSP ID value of the recovery LSP.
案例2。在初始化任何受保护LSP的关联对象之前初始化恢复LSP的关联对象时，恢复LSP中的关联ID和受该LSP保护的任何LSP将携带相同的值，该值将是恢复LSP的LSP ID值。
Case 3. When the ASSOCIATION objects of both the LSP being protected and the recovery LSP are concurrently initialized, the value of the Association ID carried in the LSP being protected is the LSP ID value of the recovery LSP, and the value of the Association ID carried in the recovery LSP is the LSP ID value of the LSP being protected. As this case can only be applied to LSPs with matching tunnel sender addresses, the scope of this case is limited to end-to-end recovery. Note that this is implicit in [RFC4872], as its scope is limited to end-to-end recovery.
案例3。当同时初始化被保护LSP和恢复LSP的关联对象时，被保护LSP中携带的关联ID的值是恢复LSP的LSP ID值，恢复LSP中携带的关联ID的值是被保护LSP的LSP ID值。由于此情况只能应用于具有匹配的隧道发送方地址的LSP，因此此情况的范围仅限于端到端恢复。请注意，这在[RFC4872]中是隐含的，因为其范围仅限于端到端恢复。
In practical terms, Case 2 will only occur when using the shared 1:N (N >= 1) end-to-end recovery type, and Case 1 will occur with all other end-to-end recovery types. Case 3 is allowed, and it is subject to interpretation as to how often it will occur. Some believe that this will be the common case and, furthermore, that working and recovery LSPs will often first be initiated without any ASSOCIATION objects, and then Case 3 objects will be added once the LSPs are established. Others believe that Case 3 will rarely, if ever occur. Such perspectives have little impact on interoperability, as an [RFC4872]-compliant implementation needs to properly handle (identify associations for) all three cases.
实际上，情况2仅在使用共享的1:N（N>=1）端到端恢复类型时出现，而情况1将与所有其他端到端恢复类型一起出现。第三种情况是允许的，但其发生频率有待解释。有些人认为这是常见的情况，而且，工作和恢复LSP通常首先在没有任何关联对象的情况下启动，然后在LSP建立后添加案例3对象。另一些人则认为，情况3即使发生，也很少发生。这种观点对互操作性影响不大，因为[RFC4872]兼容的实现需要正确处理（识别）所有这三种情况的关联。
It is important to note that Section 16.2 of [RFC4872] provides no further requirements on how or when the Association ID value is to be selected. The other sections of the document do provide further narrative and three additional requirements. In general, the narrative highlights Case 3 identified above but does not preclude the other cases. The three additional requirements are, by [RFC4872] section number:
需要注意的是，[RFC4872]的第16.2节没有提供关于如何或何时选择关联ID值的进一步要求。本文件的其他章节确实提供了进一步的说明和三项额外要求。一般来说，叙述突出了上述案例3，但不排除其他案例。根据[RFC4872]章节号，三项附加要求为：
o Section 7.3 -- "The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1."
o 第7.3节--“关联ID必须默认设置为与N=1对应的受保护LSP的LSP ID。”
When considering this statement together with the three cases enumerated above, it can be seen that this statement clarifies which LSP ID value should be used when a single shared protection LSP is established simultaneously with Case 3, or after Case 2, and with more than one LSP to be protected.
当将该声明与上述三种情况一起考虑时，可以看出，该声明澄清了当与情况3同时建立单个共享保护LSP时，或在情况2之后，以及在多个LSP被保护时，应使用哪个LSP ID值。
o Section 8.3 -- "Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP."
o 第8.3节--“通过在新保护对象中将S位和P位设置为1，以及在关联对象中，将关联ID设置为关联的主要工作LSP_ID，发出二次保护LSP的信号，在发出二次LSP的信号之前必须知道该ID。”
This requirement clarifies that when using the "Rerouting without Extra-Traffic" type of recovery, it is required to follow either Case 1 or 3, but not 2, as enumerated above.
此要求阐明了当使用“无额外流量的重新路由”类型的恢复时，需要遵循上述情况1或3，而不是2。
o Section 9.3 -- "Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP."
o 第9.3节--“通过在新保护对象中将S位和P位设置为1，以及在关联对象中，将关联ID设置为关联的主要工作LSP_ID，发出二次保护LSP的信号，在发出二次LSP的信号之前必须知道该ID。”
This requirement clarifies that when using the "Shared-Mesh Restoration" type of recovery, it is required to follow either Case 1 or 3, but not 2, as enumerated above.
该要求澄清了当使用“共享网格恢复”类型的恢复时，需要遵循上述情况1或3，而不是2。
o Section 11.1 -- "In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP."
o 第11.1节--“在这两种情况下，关联对象的关联ID必须设置为信号LSP的LSP ID值。”
This requirement clarifies that when using the "LSP Rerouting" type of recovery, it is required to follow either Case 1 or 3, but not 2, as enumerated above.
此要求阐明了当使用“LSP重新路由”类型的恢复时，需要遵循上述情况1或3，而不是2。
GMPLS segment recovery is defined in [RFC4873]. Segment recovery reuses the LSP association mechanisms, including the Association Type field value, defined in [RFC4872]. The primary text to this effect in [RFC4873] is:
[RFC4873]中定义了GMPLS段恢复。段恢复重用LSP关联机制，包括[RFC4872]中定义的关联类型字段值。[RFC4873]中的主要内容如下：
3.2.1. Recovery Type Processing
3.2.1. 恢复型处理
Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP.
恢复类型处理程序与[RFC4872]中定义的程序相同，但处理和识别与段恢复LSP有关。请注意，这意味着LSP上可能存在多个恢复类型的关联对象。
This statement means that Case 2, as enumerated above, is to be followed; furthermore, the Association Source is set to the tunnel sender address of the segment recovery LSPs. The explicit exclusion of Case 3 is not listed, as its non-applicability is considered
本声明意味着应遵循上文列举的情况2；此外，关联源被设置为段恢复lsp的隧道发送方地址。由于考虑到案例3的不适用性，因此未列出案例3的明确排除
obvious to the informed reader. (Perhaps having this exclusion explicitly identified would have obviated the need for this document.)
对见多识广的读者来说是显而易见的。（如果明确确定了这一例外情况，可能就不需要本文件了。）
Section 3.2.2 of [RFC4873] defines an additional type of LSP association that is used for "Resource Sharing". Resource sharing enables the sharing of resources across LSPs with different SESSION objects. Without this object, only sharing across LSPs with a shared SESSION object is possible, see [RFC3209].
[RFC4873]第3.2.2节定义了用于“资源共享”的另一种LSP关联类型。资源共享支持使用不同会话对象跨LSP共享资源。如果没有此对象，则只能使用共享会话对象在LSP之间共享，请参阅[RFC3209]。
Resource sharing is indicated using a new Association Type value. As the Association Type field value is not the same as what is used in recovery type LSP association, the semantics used for the association of LSPs using an ASSOCIATION object containing the new type differs from recovery type LSP association.
使用新的关联类型值指示资源共享。由于关联类型字段值与恢复类型LSP关联中使用的值不同，因此使用包含新类型的关联对象进行LSP关联所使用的语义与恢复类型LSP关联不同。
Section 3.2.2 of [RFC4873] states the following rules for the construction of an ASSOCIATION object in support of resource sharing type LSP association:
[RFC4873]的第3.2.2节规定了构建关联对象以支持资源共享类型LSP关联的以下规则：
o The Association Type value is set to "Resource Sharing".
o 关联类型值设置为“资源共享”。
o Association Source is set to the originating node's router address.
o 关联源设置为发起节点的路由器地址。
o The Association ID is set to a value that uniquely identifies the set of LSPs to be associated.
o 关联ID设置为唯一标识要关联的LSP集的值。
The setting of the Association ID value to the working LSP's LSP ID value is mentioned, but using the "MAY" key word. Per [RFC2119], this translates to the use of the LSP ID value as being completely optional and that the choice of Association ID is truly up to the originating node.
提到了将关联ID值设置为工作LSP的LSP ID值，但使用了“MAY”关键字。根据[RFC2119]，这转化为LSP ID值的使用是完全可选的，并且关联ID的选择真正取决于发起节点。
Additionally, the identical ASSOCIATION object is used for all LSPs that should be associated using Resource Sharing. This differs from recovery type LSP association where it is possible for the LSPs to carry different Association ID fields and still be associated (see Case 3 in Section 2.2).
此外，相同的关联对象用于所有应使用资源共享进行关联的LSP。这与恢复类型LSP关联不同，在恢复类型LSP关联中，LSP可能携带不同的关联ID字段，并且仍然关联（参见第2.2节中的案例3）。
The previous section reviews the construction of an ASSOCIATION object, including the selection of the value used in the Association ID field, as defined in [RFC4872] and [RFC4873]. This section reviews how a downstream receiver identifies that one LSP is
上一节回顾了关联对象的构造，包括选择[RFC4872]和[RFC4873]中定义的关联ID字段中使用的值。本节回顾下游接收器如何识别一个LSP
associated within another LSP based on ASSOCIATION objects. Note that this section in no way modifies the normative definitions of end-to-end and segment recovery, see [RFC4872] or [RFC4873].
基于关联对象在另一个LSP中关联。请注意，本节绝不会修改端到端和段恢复的标准定义，请参见[RFC4872]或[RFC4873]。
As the ASSOCIATION object is only carried in Path messages, such identification only takes place based on Path state. In order to support the identification of the recovery type association between LSPs, a downstream receiver needs to be able to handle all three cases identified in Section 2.2. Cases 1 and 2 are simple, as the associated LSPs will carry the identical ASSOCIATION object. This is also always true for resource sharing type LSP association, see Section 2.4. Case 3 is more complicated, as it is possible for the LSPs to carry different Association ID fields and still be associated. The receiver also needs to allow for changes in the set of ASSOCIATION objects included in an LSP.
由于关联对象仅在路径消息中携带，因此这种识别仅基于路径状态进行。为了支持识别LSP之间的恢复类型关联，下游接收器需要能够处理第2.2节中确定的所有三种情况。情况1和2很简单，因为关联的LSP将携带相同的关联对象。对于资源共享类型的LSP关联，也总是如此，请参见第2.4节。情况3更复杂，因为LSP可能携带不同的关联ID字段，并且仍然关联。接收器还需要允许在LSP中包括的关联对象集合中进行更改。
Based on the [RFC4872] and [RFC4873] definitions related to the ASSOCIATION object, the following behavior can be followed to ensure that a receiver always properly identifies the association between LSPs:
根据与关联对象相关的[RFC4872]和[RFC4873]定义，可以遵循以下行为，以确保接收器始终正确识别LSP之间的关联：
o Covering Cases 1 and 2 and resource sharing type LSP association:
o 涵盖案例1和案例2以及资源共享类型LSP关联：
For ASSOCIATION objects with the Association Type field values of "Recovery" (1) and "Resource Sharing" (2), the association between LSPs is identified by comparing all fields of each of the ASSOCIATION objects carried in the Path messages associated with each LSP. An association is deemed to exist when the same values are carried in all fields of an ASSOCIATION object carried in each LSP's Path message. As more than one association may exist (e.g., in support of different association types or end-to-end and segment recovery), all carried ASSOCIATION objects need to be examined.
对于关联类型字段值为“恢复”（1）和“资源共享”（2）的关联对象，通过比较与每个LSP关联的路径消息中携带的每个关联对象的所有字段来识别LSP之间的关联。当在每个LSP路径消息中携带的关联对象的所有字段中携带相同的值时，关联被视为存在。由于可能存在多个关联（例如，支持不同的关联类型或端到端和段恢复），因此需要检查所有携带的关联对象。
o Covering Case 3:
o 涵盖个案3：
Any ASSOCIATION object with the Association Type field value of "Recovery" (1) that does not yield an association in the prior comparison needs to be checked to see if a Case 3 association is indicated. As this case only applies to end-to-end recovery, the first step is to locate any other LSPs with the identical SESSION object fields and the identical tunnel sender address fields as the LSP carrying the ASSOCIATION object. If such LSPs exist, a case 3 association is identified by comparing the value of the Association ID field with the LSP ID field of the other LSP. If the values are identical, then an end-to-end recovery association exists. As this behavior only applies to
需要检查关联类型字段值为“Recovery”（1）且在先前比较中未产生关联的任何关联对象，以查看是否指示了案例3关联。由于这种情况仅适用于端到端恢复，因此第一步是查找具有与承载关联对象的LSP相同的会话对象字段和相同的隧道发送方地址字段的任何其他LSP。如果存在这样的LSP，则通过将关联ID字段的值与另一LSP的LSP ID字段进行比较来识别情况3关联。如果值相同，则存在端到端恢复关联。因为这种行为只适用于
end-to-end recovery, this check need only be performed at the egress.
端到端恢复，此检查只需在出口处执行。
No additional behavior is needed in order to support changes in the set of ASSOCIATION objects included in an LSP, as long as the change represents either a new association or a change in identifiers made as described in Section 2.2.
不需要额外的行为来支持LSP中包含的关联对象集的更改，只要该更改表示新的关联或第2.2节中描述的标识符更改。
This document reviews procedures defined in [RFC4872] and [RFC4873] and does not define any new procedures. As such, no new security considerations are introduced in this document.
本文件审查了[RFC4872]和[RFC4873]中定义的程序，未定义任何新程序。因此，本文档中没有引入新的安全注意事项。
This document formalizes the explanation provided in an e-mail to the working group authored by Adrian Farrel, see [AF-EMAIL]. This document was written in response to questions raised in the CCAMP working group by Nic Neate <nhn@dataconnection.com>. Valuable comments and input were also received from Dimitri Papadimitriou, Francois Le Faucheur, and Ashok Narayanan.
本文件正式说明了阿德里安·法雷尔（Adrian Farrel）向工作组发送的电子邮件中提供的解释，见[AF-EMAIL]。本文件是针对Nic Neate在CCAMP工作组提出的问题编写的<nhn@dataconnection.com>. Dimitri Papadimitriou、Francois Le Faucheur和Ashok Narayanan也提出了宝贵的意见和建议。
[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月。
[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. Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。Lang，J.，Rekhter，Y.，和Papadimitriou，D.，“RSVP-TE
[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月。
[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月。
[AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of the Association ID", CCAMP working group mailing list, http://www.ietf.org/mail-archive/web/ccamp/ current/msg00644.html, November 18, 2008.
[AF-EMAIL]Farrel，A.“回复：澄清您对协会ID的误解”，CCAMP工作组邮件列表，http://www.ietf.org/mail-archive/web/ccamp/ 当前/msg00644.html，2008年11月18日。
Author's Address
作者地址
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