diff options
Diffstat (limited to 'doc/rfc/rfc8697.txt')
| -rw-r--r-- | doc/rfc/rfc8697.txt | 1414 |
1 files changed, 1414 insertions, 0 deletions
diff --git a/doc/rfc/rfc8697.txt b/doc/rfc/rfc8697.txt new file mode 100644 index 0000000..fde0e5e --- /dev/null +++ b/doc/rfc/rfc8697.txt @@ -0,0 +1,1414 @@ + + + + +Internet Engineering Task Force (IETF) I. Minei +Request for Comments: 8697 Google, Inc. +Category: Standards Track E. Crabbe +ISSN: 2070-1721 Individual Contributor + S. Sivabalan + Cisco Systems, Inc. + H. Ananthakrishnan + Netflix + D. Dhody + Huawei + Y. Tanaka + NTT Communications Corporation + January 2020 + + + Path Computation Element Communication Protocol (PCEP) Extensions for + Establishing Relationships between Sets of Label Switched Paths (LSPs) + +Abstract + + This document introduces a generic mechanism to create a grouping of + Label Switched Paths (LSPs) in the context of a Path Computation + Element (PCE). This grouping can then be used to define associations + between sets of LSPs or between a set of LSPs and a set of attributes + (such as configuration parameters or behaviors), and it is equally + applicable to the stateful PCE (active and passive modes) and the + stateless PCE. + +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 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8697. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://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. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. Terminology + 3. Architectural Overview + 3.1. Motivations + 3.2. Relationship to the SVEC List + 3.3. Operational Overview + 3.4. Operator-Configured Association Range + 4. Discovery of Supported Association Types + 4.1. ASSOC-Type-List TLV + 4.1.1. Procedure + 5. Operator-Configured Association Range TLV + 5.1. Procedure + 6. ASSOCIATION Object + 6.1. Object Definition + 6.1.1. Global Association Source TLV + 6.1.2. Extended Association ID TLV + 6.1.3. Association Source + 6.1.4. Unique Identification for an Association Group + 6.2. Relationship to the RSVP ASSOCIATION Object + 6.3. Object Encoding in PCEP Messages + 6.3.1. Stateful PCEP Messages + 6.3.2. Request Message + 6.3.3. Reply Message + 6.4. Processing Rules + 7. IANA Considerations + 7.1. PCEP Object + 7.2. PCEP TLV + 7.3. Association Flags + 7.4. Association Type + 7.5. PCEP-Error Object + 8. Security Considerations + 9. Manageability Considerations + 9.1. Control of Function and Policy + 9.2. Information and Data Models + 9.3. Liveness Detection and Monitoring + 9.4. Verifying Correct Operation + 9.5. Requirements on Other Protocols + 9.6. Impact on Network Operations + 10. References + 10.1. Normative References + 10.2. Informative References + Appendix A. Example of an Operator-Configured Association Range + Acknowledgments + Contributors + Authors' Addresses + +1. Introduction + + [RFC5440] describes the Path Computation Element (PCE) Communication + Protocol (PCEP). PCEP enables communication between a Path + Computation Client (PCC) and a PCE, or between a PCE and another PCE, + for the purpose of the computation of Multiprotocol Label Switching + (MPLS) as well as Generalized MPLS (GMPLS) Traffic Engineering Label + Switched Path (TE LSP) characteristics. + + [RFC8231] specifies a set of extensions to PCEP to enable stateful + control of TE LSPs within and across PCEP sessions in compliance with + [RFC4657]. It includes mechanisms to effect LSP State + Synchronization between PCCs and PCEs, delegation of control over + LSPs to PCEs, and PCE control of timing and sequence of path + computations within and across PCEP sessions. The operational model + whereby LSPs are initiated from the PCE is described in [RFC8281]. + + [RFC4872] defines the RSVP ASSOCIATION object, which was defined in + the context of GMPLS-controlled LSPs to be used to associate recovery + LSPs with the LSP they are protecting. This object also has broader + applicability as a mechanism to associate RSVP state. [RFC6780] + describes how the ASSOCIATION object can be more generally applied by + defining the Extended ASSOCIATION object. + + This document introduces a generic mechanism to create a grouping of + LSPs. This grouping can then be used to define associations between + sets of LSPs or between a set of LSPs and a set of attributes (such + as configuration parameters or behaviors), and it is equally + applicable to the stateful PCE (active and passive modes) and the + stateless PCE. The associations could be created dynamically and + conveyed to a PCEP peer within PCEP, or they could be configured + manually by an operator on the PCEP peers. Refer to Section 3.3 for + more details. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Terminology + + This document uses the following terms defined in [RFC5440]: + + * PCC + + * PCE + + * PCEP Peer + + * Path Computation Request (PCReq) + + * Path Computation Reply (PCRep) + + * PCEP Error (PCErr) + + This document uses the following terms defined in [RFC8051]: + + * Stateful PCE + + * Active Stateful PCE + + * Passive Stateful PCE + + * Delegation + + This document uses the following terms defined in [RFC8231]: + + * LSP State Report (PCRpt) + + * LSP Update Request (PCUpd) + + * State Timeout Interval + + This document uses the following terms defined in [RFC8281]: + + * PCE-initiated LSP + + * LSP Initiate Request (PCInitiate) + +3. Architectural Overview + +3.1. Motivations + + A stateful PCE provides the ability to update existing LSPs and to + instantiate new ones. There are various situations where several + LSPs need to share common information. For example, to support PCE- + controlled make-before-break, an association between the original + path and the reoptimized path is desired. Similarly, for end-to-end + protection, an association between working and protection LSPs is + required (see [PCE-PROTECTION]). For diverse paths, an association + between a group of LSPs could be used (see [PCE-DIVERSITY]). Another + use for an LSP grouping would be to apply a common set of + configuration parameters or behaviors to a set of LSPs. + + For a stateless PCE, it might be useful to associate a PCReq message + to an association group, thus enabling it to associate a common set + of policies, configuration parameters, or behaviors with the request. + + Some associations could be created dynamically, such as an + association between the working and protection LSPs of a tunnel, + whereas some associations could be created by the operator manually, + such as a policy-based association where the LSP could join an + operator-configured existing association. + + Rather than creating separate mechanisms for each use case, this + document defines a generic mechanism that can be reused as needed. + +3.2. Relationship to the SVEC List + + Note that [RFC5440] defines a mechanism for the synchronization of a + set of PCReq messages by using the SVEC (Synchronization VECtor) + object, which specifies the list of synchronized requests that can be + either dependent or independent. The SVEC object identifies the + relationship between the set of PCReq messages, identified by + "Request-ID-number" in the RP (Request Parameters) object. [RFC6007] + further clarifies the use of the SVEC list for synchronized path + computations when computing dependent requests, and it describes a + number of usage scenarios for SVEC lists within single-domain and + multi-domain environments. + + The motivations behind the association group defined in this document + and the SVEC object are quite different, though some use cases may + overlap. PCEP extensions that define a new Association Type should + clarify the relationship between the SVEC object and the Association + Type, if any. + +3.3. Operational Overview + + LSPs are associated with other LSPs with which they interact by + adding them to a common association group. Association groups as + defined in this document can be applied to LSPs originating at the + same headend or different headends. + + Some associations could be created dynamically by a PCEP speaker, and + the associations (along with the set of LSPs) are conveyed to a PCEP + peer. Whereas some associations are configured by the operator + beforehand on the PCEP peers in question, a PCEP speaker could then + ask an LSP to join the Operator-configured Association. Usage of + dynamic and configured associations is usually dependent on the type + of association. + + For Operator-configured Associations, the association parameters, + such as the Association Identifier (Association ID), Association + Type, and the Association Source IP address, are manually configured + by the operator. In the case of a dynamic association, the + association parameters, such as the Association ID, are allocated + dynamically by the PCEP speaker. The Association Source is set as + the local PCEP speaker address unless local policy dictates + otherwise, in which case the Association Source is set based on the + local policy. + + The dynamically created association can be reported to the PCEP peer + via the PCEP messages as per the stateful extensions. When the + Operator-configured Association is known to the PCEP peer beforehand, + a PCEP peer could ask an LSP to join the Operator-configured + Association via the stateful PCEP messages. + + The associations are properties of the LSP and thus could be stored + in the LSP state database. The dynamic association exists as long as + the LSP state exists. In the case of PCEP session termination, the + LSP state cleanup MUST also take care of associations. + + Multiple types of associations can exist, each with its own + Association ID space. The definition of the different Association + Types and their behaviors is outside the scope of this document. The + establishment and removal of the association relationship can be done + on a per-LSP basis. An LSP may join multiple association groups that + have the same Association Type or different Association Types. + +3.4. Operator-Configured Association Range + + Some Association Types are dynamic, some are operator configured, and + some could be both. For the Association Types that could be both + dynamic and operator configured and use the same Association Source, + it is necessary to distinguish a range of Association IDs that are + marked for Operator-configured Associations, to avoid any Association + ID clashes within the scope of the Association Source. This document + assumes that these two ranges are configured. + + A range of Association IDs for each Association Type (and Association + Source) is kept for the Operator-configured Associations. Dynamic + associations MUST NOT use the Association ID from this range. + + This range, as set at the PCEP speaker (a PCC or PCE, as an + Association Source), needs to be communicated to a PCEP peer in the + Open message. A new TLV is defined in this specification for this + purpose (Section 5). See Appendix A for an example. + + The Association ID range for sources other than the PCEP speaker (for + example, a Network Management System (NMS)) is not communicated in + PCEP, and the procedure for Operator-configured Association Range + settings is outside the scope of this document. + +4. Discovery of Supported Association Types + + This section defines PCEP extensions so as to support the capability + advertisement of the Association Types supported by a PCEP speaker. + + A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. + The PCEP ASSOC-Type-List TLV is carried within an OPEN object. This + way, during the PCEP session-setup phase, a PCEP speaker can + advertise to a PCEP peer the list of supported Association Types. + +4.1. ASSOC-Type-List TLV + + The PCEP ASSOC-Type-List TLV is OPTIONAL. It MAY be carried within + an OPEN object sent by a PCEP speaker in an Open message to a PCEP + peer so as to indicate the list of supported Association Types. + + The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV + format defined in [RFC5440]. That is, the TLV is composed of 2 + octets for the type, 2 octets specifying the TLV length, and a Value + field. The Length field defines the length of the value portion in + octets. The TLV is padded to 4-octet alignment, and padding is not + included in the Length field (e.g., a 3-octet value would have a + length of three, but the total size of the TLV would be 8 octets). + + The PCEP ASSOC-Type-List TLV has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Assoc-Type #1 | Assoc-Type #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Assoc-Type #N | padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: The ASSOC-Type-List TLV Format + + Type: 35 + + Length: N * 2 (where N is the number of Association Types). + + Value: List of 2-byte Association Type code points, identifying the + Association Types supported by the sender of the Open message. + + Assoc-Type (2 bytes): Association Type code point identifier. IANA + manages the "ASSOCIATION Type Field" code point registry (see + Section 7.4). + +4.1.1. Procedure + + An ASSOC-Type-List TLV within an OPEN object in an Open message is + included by a PCEP speaker in order to advertise a set of one or more + supported Association Types. The ASSOC-Type-List TLV MUST NOT appear + more than once in an OPEN object. If it appears more than once, the + PCEP session MUST be rejected with Error-Type 1 and Error-value 1 + (PCEP session establishment failure / Reception of an invalid Open + message). As specified in [RFC5440], a PCEP peer that does not + recognize the ASSOC-Type-List TLV will silently ignore it. + + The Association Type (to be defined in future documents) can specify + if the Association Type advertisement is mandatory for it. Thus, the + ASSOC-Type-List TLV MUST be included if at least one mandatory + Association Type needs to be advertised, and the ASSOC-Type-List TLV + MAY be included otherwise. For an Association Type that specifies + that the advertisement is mandatory, a missing Assoc-Type in the + ASSOC-Type-List TLV (or a missing ASSOC-Type-List TLV) is to be + interpreted as meaning that the Association Type is not supported by + the PCEP speaker. + + The absence of the ASSOC-Type-List TLV in an OPEN object MUST be + interpreted as an absence of information in the list of supported + Association Types (rather than an indication that the Association + Type is not supported). In this case, the PCEP speaker could still + use the ASSOCIATION object: if the peer does not support the + association, it will react as per the procedure described in + Section 6.4. + + If the use of the ASSOC-Type-List TLV is triggered by support for a + mandatory Association Type, then it is RECOMMENDED that the PCEP + implementation include all supported Association Types (including + optional types) to ease the operations of the PCEP peer. + +5. Operator-Configured Association Range TLV + + This section defines a PCEP extension to support the advertisement of + the Operator-configured Association Range used for an Association + Type by the PCEP speaker (as an Association Source). + + A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association + Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried + within an OPEN object. This way, during the PCEP session-setup + phase, a PCEP speaker can advertise to a PCEP peer the Operator- + configured Association Range for an Association Type. + + The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL. It MAY be carried + within an OPEN object sent by a PCEP speaker in an Open message to a + PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the + PCEP TLV format defined in [RFC5440]. That is, the TLV is composed + of 2 bytes for the type, 2 bytes specifying the TLV length, and a + Value field. The Length field defines the length of the value + portion in bytes. + + The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Assoc-Type #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Start-Assoc-ID #1 | Range #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Assoc-Type #N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Start-Assoc-ID #N | Range #N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: The OP-CONF-ASSOC-RANGE TLV Format + + Type: 29 + + Length: N * 8 (where N is the number of Association Types). + + Value: Includes the following fields, repeated for each Association + Type: + + Reserved (2 bytes): MUST be set to 0 on transmission and MUST be + ignored on receipt. + + Assoc-Type (2 bytes): The Association Type (Section 7.4). The + Association Types will be defined in future documents. + + Start-Assoc-ID (2 bytes): The "start association" identifier for + the Operator-configured Association Range for the particular + Association Type. The values 0 and 0xffff MUST NOT be used; on + receipt of these values in the TLV, the session is rejected, + and an error message is sent (see Section 5.1). + + Range (2 bytes): The number of associations marked for the + Operator-configured Associations. Range MUST be greater than + 0, and it MUST be such that (Start-Assoc-ID + Range) does not + cross the largest Association ID value of 0xffff. If this + condition is not satisfied, the session is rejected, and an + error message is sent (see Section 5.1). + +5.1. Procedure + + A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN + object in an Open message sent to a PCEP peer in order to advertise + the Operator-configured Association Range for an Association Type. + The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN + object. If it appears more than once, the PCEP session MUST be + rejected with Error-Type 1 and Error-value 1 (PCEP session + establishment failure / Reception of an invalid Open message). + + As specified in [RFC5440], a PCEP peer that does not recognize the + OP-CONF-ASSOC-RANGE TLV will silently ignore it. + + The Operator-configured Association Range SHOULD be included for each + Association Type that could be both dynamic and operator configured. + For Association Types that are only dynamic or only operator + configured, this TLV MAY be skipped, in which case the full range of + Association IDs is considered dynamic or operator configured, + respectively. Each Association Type (to be defined in future + documents) can specify the default value for its Operator-configured + Association Range. + + The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be + interpreted as an absence of an explicit Operator-configured + Association Range at the PCEP peer. In this case, the default + behavior as per each Association Type applies. If the Association + Source is not a PCEP speaker, the default value for the Operator- + configured Association Range is used for the Association Source. + + If the Assoc-Type is not recognized or supported by the PCEP speaker, + it MUST ignore that respective (Start-Assoc-ID + Range). If the + Assoc-Type is recognized/supported but Start-Assoc-ID or Range is set + incorrectly, the PCEP session MUST be rejected with Error-Type 1 and + Error-value 1 (PCEP session establishment failure / Reception of an + invalid Open message). The incorrect range includes the case when + the (Start-Assoc-ID + Range) crosses the largest Association ID value + of 0xffff. + + A given Assoc-Type MAY appear more than once in the OP-CONF-ASSOC- + RANGE TLV in the case of a non-contiguous Operator-configured + Association Range. The PCEP speaker originating this TLV MUST NOT + send overlapping ranges for an Association Type. If a PCEP peer + receives overlapping ranges for an Association Type, it MUST consider + the Open message malformed and MUST reject the PCEP session with + Error-Type 1 and Error-value 1 (PCEP session establishment failure / + Reception of an invalid Open message). + + There may be cases where an Operator-configured Association was + configured with association parameters (such as an Association ID, + Association Type, and Association Source) at the local PCEP speaker, + and the PCEP session is later established with the Association Source + and a new operator-configured range is learned during session + establishment. At this time, the local PCEP speaker MUST remove any + associations that are not in the new operator-configured range (by + disassociating any LSPs that are part of it (and notifying the PCEP + peer of this change)). If a PCEP speaker receives an association for + an Operator-configured Association and the Association ID is not in + the Operator-configured Association Range for the Association Type + and Association Source, it MUST generate an error (as described in + Section 6.4). + +6. ASSOCIATION Object + +6.1. Object Definition + + Association groups and their memberships are defined using a new + ASSOCIATION object. + + The ASSOCIATION Object-Class value is 40. + + The ASSOCIATION Object-Type value is 1 for IPv4, and its format is + shown in Figure 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Flags |R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Association Type | Association ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Association Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // Optional TLVs // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: The IPv4 ASSOCIATION Object Format + + The ASSOCIATION Object-Type value is 2 for IPv6, and its format is + shown in Figure 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Flags |R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Association Type | Association ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IPv6 Association Source | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // Optional TLVs // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: The IPv6 ASSOCIATION Object Format + + Reserved (2 bytes): MUST be set to 0 and ignored upon receipt. + + Flags (2 bytes): The following flag is currently defined: + + R (Removal - 1 bit): When set, the requesting PCEP peer requires + the removal of an LSP from the association group. When unset, + the PCEP peer indicates that the LSP is added or retained as + part of the association group. This flag is used for the + ASSOCIATION object in the Path Computation Report (PCRpt) and + Path Computation Update (PCUpd) messages. It is ignored in + other PCEP messages. + + The unassigned flags MUST be set to 0 on transmission and MUST be + ignored on receipt. + + Association Type (2 bytes): The Association Type (Section 7.4). The + Association Types will be defined in future documents. + + Association ID (2 bytes): The identifier of the association group. + When combined with other association parameters, such as an + Association Type and Association Source, this value uniquely + identifies an association group. The values 0xffff and 0x0 are + reserved. The value 0xffff is used to indicate all association + groups and could be used with the R flag to indicate removal for + all associations for the LSP within the scope of the Association + Type and Association Source. + + Association Source: Contains a valid IPv4 address (4 bytes) if the + ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if + the ASSOCIATION Object-Type is 2. The address provides scoping + for the Association ID. See Section 6.1.3 for details. + + Optional TLVs: The optional TLVs follow the PCEP TLV format defined + in [RFC5440]. This document defines two optional TLVs. Other + documents can define more TLVs in the future. + +6.1.1. Global Association Source TLV + + The Global Association Source TLV is an optional TLV for use in the + ASSOCIATION object. The meaning and usage of the Global Association + Source TLV are as per Section 4 of [RFC6780]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Global Association Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: The Global Association Source TLV Format + + Type: 30 + + Length: Fixed value of 4 bytes. + + Global Association Source: As defined in Section 4 of [RFC6780]. + +6.1.2. Extended Association ID TLV + + The Extended Association ID TLV is an optional TLV for use in the + ASSOCIATION object. The meaning and usage of the Extended + Association ID TLV are as per Section 4 of [RFC6780]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // Extended Association ID // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: The Extended Association ID TLV Format + + Type: 31 + + Length: Variable. + + Extended Association ID: As defined in Section 4 of [RFC6780]. + +6.1.3. Association Source + + The Association Source field in the ASSOCIATION object is set to a + valid IP address to identify the node that originated the + association. In the case of dynamic associations, the Association + Source is usually set as the local PCEP speaker address unless local + policy dictates otherwise, in which case the Association Source is + set based on the local policy. In the case of PCE redundancy, local + policy could set the source as a virtual IP address that identifies + all instances of the PCE. In the case of Operator-configured + Associations, the Association Source is manually configured, and it + could be set as one of the PCEP speakers, an NMS, or any other valid + IP address that scopes the Association ID for the Association Type. + +6.1.4. Unique Identification for an Association Group + + The combination of the mandatory fields Association Type, Association + ID, and Association Source in the ASSOCIATION object uniquely + identifies the association group. If the optional TLVs (Global + Association Source and Extended Association ID) are included, then + they MUST be included in combination with mandatory fields to + uniquely identify the association group. In this document, all these + fields are collectively called "association parameters". Note that + the ASSOCIATION object MAY include other optional TLVs (not defined + in this document) based on the Association Types. These TLVs provide + "information" related to the Association Type. This document refers + to this information as "association information". + +6.2. Relationship to the RSVP ASSOCIATION Object + + The format of the PCEP ASSOCIATION object defined in this document is + aligned with the RSVP ASSOCIATION object [RFC6780]. Various + Association Types related to RSVP association are defined in + [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define + new Association Types should clarify how the PCEP associations would + work with RSVP associations and vice versa. + +6.3. Object Encoding in PCEP Messages + + Message formats in this document are expressed using Routing BNF + (RBNF) as used in [RFC5440] and defined in [RFC5511]. + +6.3.1. Stateful PCEP Messages + + The ASSOCIATION object MAY be carried in the PCUpd, PCRpt, and Path + Computation Initiate (PCInitiate) messages. + + When carried in a PCRpt message, this object is used to report the + association group membership pertaining to an LSP to a stateful PCE. + The PCRpt message is used for initial State Synchronization + operations (Section 5.6 of [RFC8231]), as well as whenever the state + of the LSP changes. If the LSP belongs to an association group, then + the associations MUST be included during the State Synchronization + operations. + + The PCRpt message can also be used to remove an LSP from one or more + association groups by setting the R flag to 1 in the ASSOCIATION + object. + + When an LSP is first reported to the PCE, the PCRpt message MUST + include all the association groups that it belongs to. Any + subsequent PCRpt message SHOULD include only the associations that + are being modified or removed. + + The PCRpt message is defined in [RFC8231] and updated as shown below: + + <PCRpt Message> ::= <Common Header> + <state-report-list> + + Where: + + <state-report-list> ::= <state-report>[<state-report-list>] + + <state-report> ::= [<SRP>] + <LSP> + [<association-list>] + <path> + + Where: + + <path>::= <intended-path> + [<actual-attribute-list><actual-path>] + <intended-attribute-list> + + <association-list> ::= <ASSOCIATION> [<association-list>] + + When an LSP is delegated to a stateful PCE, the stateful PCE can + create a new association group for this LSP or associate it with one + or more existing association groups. This is done by including the + ASSOCIATION object in a PCUpd message. A stateful PCE can also + remove a delegated LSP from one or more association groups by setting + the R flag to 1 in the ASSOCIATION object. + + The PCUpd message SHOULD include the association groups that are + being modified or removed. There is no need to include associations + that remain unchanged. + + The PCUpd message is defined in [RFC8231] and updated as shown below: + + <PCUpd Message> ::= <Common Header> + <update-request-list> + + Where: + + <update-request-list> ::= <update-request>[<update-request-list>] + + <update-request> ::= <SRP> + <LSP> + [<association-list>] + <path> + + Where: + + <path>::= <intended-path><intended-attribute-list> + + <association-list> ::= <ASSOCIATION> [<association-list>] + + Unless a PCEP speaker wants to delete an association from an LSP or + make changes to the association, it does not need to include the + ASSOCIATION object in future stateful messages. + + A PCE initiating a new LSP can also include the association groups + that this LSP belongs to. This is done by including the ASSOCIATION + object in a PCInitiate message. The PCInitiate message MUST include + all the association groups that it belongs to. The PCInitiate + message is defined in [RFC8281] and updated as shown below: + + <PCInitiate Message> ::= <Common Header> + <PCE-initiated-lsp-list> + + Where: + + <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> + [<PCE-initiated-lsp-list>] + + <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>| + <PCE-initiated-lsp-deletion>) + + <PCE-initiated-lsp-instantiation> ::= <SRP> + <LSP> + [<END-POINTS>] + <ERO> + [<association-list>] + [<attribute-list>] + + Where: + + <association-list> ::= <ASSOCIATION> [<association-list>] + +6.3.2. Request Message + + In the case of a passive (stateful or stateless) PCE, the ASSOCIATION + object is OPTIONAL and MAY be carried in the PCReq message. + + When carried in a PCReq message, the ASSOCIATION object is used to + associate the path computation request to an association group. The + association (and the other LSPs) should be known to the PCE + beforehand. These could be operator configured or dynamically + learned beforehand via stateful PCEP messages. The R flag in the + ASSOCIATION object within a PCReq message MUST be set to 0 while + sending and ignored on receipt. + + The PCReq message is defined in [RFC5440] and updated in [RFC8231]. + It is further updated below for association groups: + + <PCReq Message>::= <Common Header> + [<svec-list>] + <request-list> + + Where: + + <svec-list>::= <SVEC>[<svec-list>] + <request-list>::= <request>[<request-list>] + + <request>::= <RP> + <END-POINTS> + [<LSP>] + [<LSPA>] + [<BANDWIDTH>] + [<metric-list>] + [<association-list>] + [<RRO>[<BANDWIDTH>]] + [<IRO>] + [<LOAD-BALANCING>] + + Where: + + <association-list> ::= <ASSOCIATION> [<association-list>] + + Note that the LSP object MAY be present for the passive stateful PCE + mode. + +6.3.3. Reply Message + + In the case of a passive (stateful or stateless) PCE, the ASSOCIATION + object is OPTIONAL and MAY be carried in the PCRep message with the + NO-PATH object. The ASSOCIATION object in the PCRep message + indicates the association group that caused the PCE to fail to find a + path. + + The PCRep message is defined in [RFC5440] and updated in [RFC8231]. + It is further updated below for association groups: + + <PCRep Message> ::= <Common Header> + <response-list> + + Where: + + <response-list>::=<response>[<response-list>] + + <response>::=<RP> + [<LSP>] + [<NO-PATH>] + [<association-list>] + [<attribute-list>] + [<path-list>] + + Where: + + <association-list> ::= <ASSOCIATION> [<association-list>] + + Note that the LSP object MAY be present for the passive stateful PCE + mode. + +6.4. Processing Rules + + Association groups can be operator configured on the necessary PCEP + speakers, and the PCEP speakers can join the existing association + groups. In addition, a PCC or a PCE can create association groups + dynamically, and the PCEP speaker can also report the associations to + its peer via PCEP messages. The Operator-configured Associations are + created via configurations (where all association parameters are + manually set) and exist until explicitly removed via configurations. + The PCEP speaker can add LSPs to these configured associations and + provide this information via stateful PCEP messages. The dynamic + associations are created dynamically by the PCEP speaker (where all + association parameters are populated dynamically). The association + group is attached to the LSP state, and the association group exists + until there is at least one LSP as part of the association. As + described in Section 6.1.4, the association parameters are the + combination of Association Type, Association ID, and Association + Source, as well as the optional Global Association Source and + Extended Association ID TLVs; this combination uniquely identifies an + association group. The information related to the Association Types + encoded via the TLVs of a particular Association Type (not described + in this document) is the association information (Section 6.1.4). + + If a PCEP speaker does not recognize the ASSOCIATION object in the + stateful message, it will return a PCErr message with Error-Type + "Unknown Object" as described in [RFC5440]. In the case of a PCReq + message, the PCE would react based on the P flag as per [RFC5440]. + If a PCEP speaker understands the ASSOCIATION object but does not + support the Association Type, it MUST return a PCErr message with + Error-Type 26 "Association Error" and Error-value 1 "Association Type + is not supported". If any association parameters are invalid in the + ASSOCIATION object, the PCEP speaker would consider this object + malformed and process it as a malformed message [RFC5440]. On + receiving a PCEP message with an ASSOCIATION object, if a PCEP + speaker finds that too many LSPs belong to the association group, it + MUST return a PCErr message with Error-Type 26 "Association Error" + and Error-value 2 "Too many LSPs in the association group". If a + PCEP speaker cannot handle a new association, it MUST return a PCErr + message with Error-Type 26 "Association Error" and Error-value 3 "Too + many association groups". These numbers MAY be set by the operator + or chosen based on a local policy. + + If a PCE peer is unwilling or unable to process the ASSOCIATION + object in the stateful message, it MUST return a PCErr message with + the Error-Type "Not supported object" and follow the relevant + procedures described in [RFC5440]. In the case of a PCReq message, + the PCE would react based on the P flag as per [RFC5440]. On + receiving a PCEP message with an ASSOCIATION object, if a PCEP + speaker could not add the LSP to the association group for any + reason, it MUST return a PCErr message with Error-Type 26 + "Association Error" and Error-value 7 "Cannot join the association + group". + + If a PCEP speaker receives an ASSOCIATION object for an Operator- + configured Association and the Association ID is not in the Operator- + configured Association Range for the Association Type and Association + Source, it MUST return a PCErr message with Error-Type 26 + "Association Error" and Error-value 8 "Association ID not in range". + + If a PCEP speaker receives an ASSOCIATION object in a PCReq message + and the association is not known (the association is not configured, + was not created dynamically, or was not learned from a PCEP peer), it + MUST return a PCErr message with Error-Type 26 "Association Error" + and Error-value 4 "Association unknown". + + If the association information (related to the association group as a + whole) received from the peer does not match the local operator- + configured information, it MUST return a PCErr message with Error- + Type 26 "Association Error" and Error-value 5 "Operator-configured + association information mismatch". On receiving association + information (related to the association group as a whole) that does + not match the association information previously received about the + same association from a peer, it MUST return a PCErr message with + Error-Type 26 "Association Error" and Error-value 6 "Association + information mismatch". Note that information related to each LSP + within the association as part of the association information TLVs + could be different. + + If a PCEP speaker receives an ASSOCIATION object with the R bit set + for removal and the association group (identified by association + parameters) is not known, it MUST return a PCErr message with Error- + Type 26 "Association Error" and Error-value 4 "Association unknown". + + The dynamic associations are cleared along with the LSP state + information as per [RFC8231]. When a PCEP session is terminated, + after expiry of the State Timeout Interval at the PCC, the LSP state + associated with that PCEP session is reverted to operator-defined + default parameters or behaviors. The same procedure is also followed + for the association groups. On session termination at the PCE, when + the LSP state reported by the PCC is cleared, the association groups + are also cleared. When there are no LSPs in an association group, + the association is considered empty and thus deleted. + + If the LSP is delegated to another PCE on session failure, the + associations (and association information) set by the PCE remain + intact, unless updated by the new PCE that takes over. + + Upon LSP delegation revocation, the PCC MAY clear the association + created by the PCE, but in order to avoid traffic loss, it SHOULD + perform this action in a make-before-break fashion (same as + [RFC8231]). + +7. IANA Considerations + + IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" + registry at <https://www.iana.org/assignments/pcep>. + +7.1. PCEP Object + + The "Path Computation Element Protocol (PCEP) Numbers" registry + contains a subregistry called "PCEP Objects". IANA has allocated the + following code point in the "PCEP Objects" registry. + + +--------------------+-------------+-------------+-----------+ + | Object-Class Value | Name | Object-Type | Reference | + +====================+=============+=============+===========+ + | 40 | ASSOCIATION | 0: Reserved | RFC 8697 | + | | +-------------+-----------+ + | | | 1: IPv4 | RFC 8697 | + | | +-------------+-----------+ + | | | 2: IPv6 | RFC 8697 | + +--------------------+-------------+-------------+-----------+ + + Table 1: PCEP Object + +7.2. PCEP TLV + + IANA has allocated the following code points in the "PCEP TLV Type + Indicators" registry. + + +-------+---------------------------------------+-----------+ + | Value | Meaning | Reference | + +=======+=======================================+===========+ + | 29 | Operator-configured Association Range | RFC 8697 | + +-------+---------------------------------------+-----------+ + | 30 | Global Association Source | RFC 8697 | + +-------+---------------------------------------+-----------+ + | 31 | Extended Association ID | RFC 8697 | + +-------+---------------------------------------+-----------+ + + Table 2: PCEP TLV Type Indicators + + IANA has corrected the capitalization in the meaning for value 31 in + the above registry to "Extended Association ID"; it was previously + listed as "Extended Association Id". + + IANA has made a new assignment in the existing "PCEP TLV Type + Indicators" registry as follows: + + +-------+-----------------+-----------+ + | Value | Meaning | Reference | + +=======+=================+===========+ + | 35 | ASSOC-Type-List | RFC 8697 | + +-------+-----------------+-----------+ + + Table 3: ASSOC-Type-List PCEP TLV + Type Indicator + +7.3. Association Flags + + Per this document, IANA has created a subregistry of the "Path + Computation Element Protocol (PCEP) Numbers" registry for the bits + carried in the Flags field of the ASSOCIATION object. The + subregistry is called "ASSOCIATION Flag Field". New values are + assigned by Standards Action [RFC8126]. Each bit is tracked with the + following qualities: + + * Bit number (counting from bit 0 as the most significant bit) + + * Capability description + + * Defining RFC + + +-----+-------------+-----------+ + | Bit | Description | Reference | + +=====+=============+===========+ + | 15 | R (Removal) | RFC 8697 | + +-----+-------------+-----------+ + + Table 4: New ASSOCIATION Flag + Field + +7.4. Association Type + + Per this document, IANA has created a subregistry of the "Path + Computation Element Protocol (PCEP) Numbers" registry for the + Association Type field of the ASSOCIATION object. The subregistry is + called "ASSOCIATION Type Field". New values are assigned by + Standards Action [RFC8126]. Each value is tracked with the following + qualities: + + * Type + + * Name + + * Reference + + +------+----------+-----------+ + | Type | Name | Reference | + +======+==========+===========+ + | 0 | Reserved | RFC 8697 | + +------+----------+-----------+ + + Table 5: New ASSOCIATION + Type Field + + Values 2-65535 are Unassigned. Future documents should request the + assignment of Association Types from this subregistry. + +7.5. PCEP-Error Object + + IANA has allocated the following code points within the "PCEP-ERROR + Object Error Types and Values" subregistry of the "Path Computation + Element Protocol (PCEP) Numbers" registry as follows: + + +------------+-------------+------------------------+-----------+ + | Error-Type | Meaning | Error-value | Reference | + +============+=============+========================+===========+ + | 26 | Association | 0: Unassigned | RFC 8697 | + | | Error +------------------------+-----------+ + | | | 1: Association Type is | RFC 8697 | + | | | not supported | | + | | +------------------------+-----------+ + | | | 2: Too many LSPs in | RFC 8697 | + | | | the association group | | + | | +------------------------+-----------+ + | | | 3: Too many | RFC 8697 | + | | | association groups | | + | | +------------------------+-----------+ + | | | 4: Association unknown | RFC 8697 | + | | +------------------------+-----------+ + | | | 5: Operator-configured | RFC 8697 | + | | | association | | + | | | information mismatch | | + | | +------------------------+-----------+ + | | | 6: Association | RFC 8697 | + | | | information mismatch | | + | | +------------------------+-----------+ + | | | 7: Cannot join the | RFC 8697 | + | | | association group | | + | | +------------------------+-----------+ + | | | 8: Association ID not | RFC 8697 | + | | | in range | | + +------------+-------------+------------------------+-----------+ + + Table 6: PCEP-ERROR Types and Names + +8. Security Considerations + + The security considerations described in [RFC8231] and [RFC5440] + apply to the extensions described in this document as well. + Additional considerations related to a malicious PCEP speaker are + introduced, as associations could be spoofed and could be used as an + attack vector. An attacker could attempt to create too many + associations in an attempt to load the PCEP peer. The PCEP peer + responds with a PCErr message as described in Section 6.4. An + attacker could impact LSP operations by creating bogus associations. + Further, association groups could provide an adversary with the + opportunity to eavesdrop on the relationship between the LSPs. Thus, + securing the PCEP session using Transport Layer Security (TLS) + [RFC8253], as per the recommendations and best current practices in + [RFC7525], is RECOMMENDED. + + Much of the information carried in the ASSOCIATION object as per this + document is not extra sensitive. It often reflects information that + can also be derived from the LSP database, but the association + provides a much easier grouping of related LSPs and messages. + Implementations and operators can, and should, use indirect values in + the ASSOCIATION object as a way to hide any sensitive business + relationships. + +9. Manageability Considerations + + All manageability requirements and considerations listed in [RFC5440] + and [RFC8231] apply to PCEP protocol extensions defined in this + document. In addition, requirements and considerations listed in + this section apply. + +9.1. Control of Function and Policy + + A PCE or PCC implementation MUST allow Operator-configured + Associations and SHOULD allow the setting of the Operator-configured + Association Range (Section 3.4) as described in this document. + +9.2. Information and Data Models + + The PCEP YANG module is defined in [PCEP-YANG]. In the future, this + YANG module should be extended or augmented to provide the following + additional information related to association groups. + + An implementation SHOULD allow the operator to view the associations + configured or created dynamically. Future implementations SHOULD + allow the viewing of associations reported by each peer and the + current set of LSPs in the association. + + It might also be useful to find out how many associations for each + Association Type currently exist and to know how many free + Association IDs are available for a particular Association Type and + source. + +9.3. Liveness Detection and Monitoring + + Mechanisms defined in this document do not imply any new liveness + detection and monitoring requirements in addition to those already + listed in [RFC5440]. + +9.4. Verifying Correct Operation + + Mechanisms defined in this document do not imply any new operation + verification requirements in addition to those already listed in + [RFC5440] and [RFC8231]. + +9.5. Requirements on Other Protocols + + Mechanisms defined in this document do not imply any new requirements + on other protocols. + +9.6. Impact on Network Operations + + Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP + extensions defined in this document. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <https://www.rfc-editor.org/info/rfc5440>. + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, DOI 10.17487/RFC5511, April + 2009, <https://www.rfc-editor.org/info/rfc5511>. + + [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP + ASSOCIATION Object Extensions", RFC 6780, + DOI 10.17487/RFC6780, October 2012, + <https://www.rfc-editor.org/info/rfc6780>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <https://www.rfc-editor.org/info/rfc7525>. + + [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a + Stateful Path Computation Element (PCE)", RFC 8051, + DOI 10.17487/RFC8051, January 2017, + <https://www.rfc-editor.org/info/rfc8051>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for Stateful PCE", RFC 8231, + DOI 10.17487/RFC8231, September 2017, + <https://www.rfc-editor.org/info/rfc8231>. + + [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for PCE-Initiated LSP Setup in a Stateful PCE + Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, + <https://www.rfc-editor.org/info/rfc8281>. + +10.2. Informative References + + [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol Generic + Requirements", RFC 4657, DOI 10.17487/RFC4657, September + 2006, <https://www.rfc-editor.org/info/rfc4657>. + + [RFC4872] Lang, J.P., 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, DOI 10.17487/RFC4872, May 2007, + <https://www.rfc-editor.org/info/rfc4872>. + + [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, + "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, + May 2007, <https://www.rfc-editor.org/info/rfc4873>. + + [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization + VECtor (SVEC) List for Synchronized Dependent Path + Computations", RFC 6007, DOI 10.17487/RFC6007, September + 2010, <https://www.rfc-editor.org/info/rfc6007>. + + [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE + Extensions for Associated Bidirectional Label Switched + Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, + <https://www.rfc-editor.org/info/rfc7551>. + + [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, + "PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP)", + RFC 8253, DOI 10.17487/RFC8253, October 2017, + <https://www.rfc-editor.org/info/rfc8253>. + + [PCEP-YANG] + Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, + "A YANG Data Model for Path Computation Element + Communications Protocol (PCEP)", Work in Progress, + Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October + 2019, + <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>. + + [PCE-PROTECTION] + Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., + and M. Negi, "PCEP Extensions for Associating Working and + Protection LSPs with Stateful PCE", Work in Progress, + Internet-Draft, draft-ietf-pce-stateful-path-protection- + 11, 25 September 2019, <https://tools.ietf.org/html/draft- + ietf-pce-stateful-path-protection-11>. + + [PCE-DIVERSITY] + Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, + "Path Computation Element Communication Protocol (PCEP) + Extension for LSP Diversity Constraint Signaling", Work in + Progress, Internet-Draft, draft-ietf-pce-association- + diversity-14, 26 January 2020, + <https://tools.ietf.org/html/draft-ietf-pce-association- + diversity-14>. + +Appendix A. Example of an Operator-Configured Association Range + + Consider an Association Type T1 (which allows both dynamic and + Operator-configured Associations with a default range of <0x1000, + 0xffff>). Consider that, because of the needs of the network, the + PCE needs to create more dynamic associations and would like to + change the Association Range to <0xbffe, 0xffff> instead. During + PCEP session establishment, the PCE would advertise the new range. + The PCC could skip advertising, as the default values are used. If a + PCC is creating a dynamic association (with the PCC as the + Association Source), it needs to pick a free Association ID for type + T1 in the range <0x1, 0x0fff>, whereas if a PCE is creating a dynamic + association (with the PCE as the Association Source), it needs to + pick a free Association ID from the range <0x1, 0xbffd>. Similarly, + if an Operator-configured Association is manually configured with the + PCC as the Association Source, it should be from the range <0x1000, + 0xffff>, whereas if the PCE is the Association Source, it should be + from the range <0xbffe, 0xffff>. If the Association Source is not a + PCEP peer (for example, an NMS), then the default range of <0x1000, + 0xffff> is considered. + +Acknowledgments + + We would like to thank Yuji Kamite and Joshua George for their + contributions to this document. Thanks also to Venugopal Reddy, + Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for + their useful comments. + + We would like to thank Julien Meuric for shepherding this document + and providing comments with text suggestions. + + Thanks to Stig Venaas for the RTGDIR review comments. + + Thanks to Alvaro Retana, Mirja Kühlewind, Martin Vigoureux, Barry + Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG + comments. + +Contributors + + Stephane Litkowski + Orange + + Email: stephane.litkowski@orange.com + + + Xian Zhang + Huawei Technologies + F3-1-B RnD Center, Huawei Base + Bantian, Longgang District + Shenzhen, 518129 + China + + Email: zhang.xian@huawei.com + + + Mustapha Aissaoui + Nokia + + Email: mustapha.aissaoui@nokia.com + + +Authors' Addresses + + Ina Minei + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + + Email: inaminei@google.com + + + Edward Crabbe + Individual Contributor + + Email: edward.crabbe@gmail.com + + + Siva Sivabalan + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + United States of America + + Email: msiva@cisco.com + + + Hariharan Ananthakrishnan + Netflix + + Email: hari@netflix.com + + + Dhruv Dhody + Huawei + Divyashree Techno Park, Whitefield + Bangalore 560066 + KA + India + + Email: dhruv.ietf@gmail.com + + + Yosuke Tanaka + NTT Communications Corporation + Granpark Tower 3-4-1 Shibaura, Minato-ku, Tokyo + 108-8118 + Japan + + Email: yosuke.tanaka@ntt.com |