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:
::=
Where:
::= []
::= []
[]
Where:
::=
[]
::= []
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:
::=
Where:
::= []
::=
[]
Where:
::=
::= []
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:
::=
Where:
::=
[]
::= (|
)
::=
[]
[]
[]
Where:
::= []
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:
::=
[]
Where:
::= []
::= []
::=