PCEP Extensions for Establishing Relationships Between Sets of LSPsGoogle, Inc.1600 Amphitheatre ParkwayMountain ViewCA94043USinaminei@google.comedward.crabbe@gmail.comCisco Systems, Inc.170 West Tasman Dr.San JoseCA95134USmsiva@cisco.comPacket Designhari@packetdesign.comHuawei TechnologiesF3-5-B R&D Center, Huawei Base Bantian, Longgang District
ShenzhenGuangdong518129P.R.Chinazhang.xian@huawei.comNTT Communications CorporationGranpark Tower 3-4-1 Shibaura, Minato-ku
Tokyo108-8118Japanyosuke.tanaka@ntt.comPCE Working Group This document introduces a generic mechanism to create a grouping of LSPs in the
context of a 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 is equally applicable to the active and passive modes of a stateful PCE as well as
a stateless PCE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
describes the Path Computation Element
Protocol PCEP. PCEP enables the communication between a Path Computation
Client (PCC) and a Path Control Element (PCE), or between PCE and PCE,
for the purpose of computation of Multiprotocol Label Switching (MPLS) as well
as Generalzied MPLS (GMPLS) for Traffic
Engineering Label Switched Path (TE LSP) characteristics.
Stateful pce specifies a
set of extensions to PCEP to enable stateful
control of TE LSPs between and across PCEP sessions in compliance with
and focuses on a model where LSPs are configured
on the PCC and control over them is delegated to the PCE. The model of
operation where LSPs are initiated from the PCE is described in
.
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 is equally applicable to the active and passive modes of a stateful PCE and a stateless
PCE.
This document uses the following terms defined in : PCC, PCE, PCEP Peer. The following term is defined in this document: Association Timeout Interval: when a PCEP session is terminated,
a PCC waits for this time period before deleting associations created by the PCEP peer.
Stateful PCE provides the ability to update existing LSPs and to instantiate new ones.
To enable support for PCE-controlled make-before-break and for protection, there is a need
to define associations between LSPs. For example, the association between the original
and the re-optimized path in the make-before break scenario, or between the
working and protection path in end-to-end protection. Another use for LSP grouping is for
applying a common set of configuration parameters or behaviors to a set of LSPs.
For a stateless PCE, it might be useful to associate a path
computation request to an association group, thus enabling it to associate
a common
set of configuration parameters or behaviors with
the request.
Rather than creating separate mechanisms for each use case, this draft defines a generic mechanism that can
be reused as needed.
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 head end
or different head ends. For LSPs originating at the same head end, the association
can be initiated by either the PCC (head end) or by a PCE. Only a stateful
PCE can initiate an association for LSPs originating at different head ends.
For both cases, the association is uniquely identified by the combination of an association
identifier and the address of the node that created the association.
Multiple types of groups can exist, each with their own identifiers 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, of different or of the same type.
In the case of a stateless PCE, associations are created out of band, and
PCEP peers should be aware of the association and its significance
outside of the protocol.
Association groups can be created by both PCC and PCE. When a PCC's
PCEP session with a PCE terminates unexpectedly, the PCC cleans up associations (as per
the processing rules in this document).
Creation of an association group and modifications to its membership
can be initiated by either the PCE or the PCC. Association groups
and their memberships are defined using the ASSOCIATION object for
stateful PCE.
ASSOCIATION Object-Class is to be assigned by IANA (TBD). ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in
: ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in
: Reserved: 16 bits - MUST be set to 0 and ignored upon receipt.
Flags: 16 bits - The following flags are currently defined:
when set, the requesting
PCE peer requires the removal of an LSP from the association group.
Association type: 16 bits - the association type (for example protection).
The association type will be defined
in separate documents.
Association ID: 16 bits - the identifier of the association group. When combined
with Type and Association Source, this value uniquely identifies an association group.
The value 0xffff and 0x0 are reserved. The value 0xffff is used to indicate
all association groups.
Association Source: 4 or 16 bytes - An IPv4 or IPv6 address, which is associated
to the node that originated the association.
Optional TLVs: The optional TLVs follow the PCEP TLV format
of . This document defines two optional TLVs.
The Global Association Source TLV is an optional TLV for use in the Association Object.
Type: To be allocated by IANA Length: Fixed value of 4 bytes Global Association Source: as defined in The Extended Association ID TLV is an optional TLV for use in
the Association Object.
Type: To be allocated by IANA Length: variable Extended Association ID: as defined in The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path
Computation Update (PCUpd), Path Computation Report (PCRpt) and Path
Computation Initiate (PCinit) messages. When carried in PCRpt message, it is used to report the association
group membership information pertaining to a LSP to a stateful PCE.
It can also be used to remove an LSP from one or more association groups
by setting the R flag to 1. Unless, a PCE wants to delete an association
from an LSP, it does not need to carry the ASSOCIATION
object while updating other LSP attributes using the PCUpd message. The PCRpt message is defined in
and updated as below: When an LSP is delegated to a stateful PCE, the stateful PCE can initiate
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 or in a PCInit message. A stateful PCE can also remove a delegated
LSP from one or more association groups by setting the R flag to 1. The PCUpd message is defined in
and updated as below:The PCInitiate message is defined in
and updated as below:
In case of passive stateful or stateless PCE, the ASSOCIATION Object
is OPTIONAL and MAY be carried in the Path Computation Request
(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
might be further informed via PCRpt message in case of passive
stateful PCE later or it might be created out of band in case of
stateless PCE.
The PCReq message is defined in [RFC5440] and updated in
[I-D.ietf-pce-stateful-pce], it is further updated below for
association:
Note that LSP object MAY be present for the passive stateful PCE.
Both a PCC and a PCE can create one or more association groups for an LSP.
But a PCE peer cannot add new members for association group created by
another peer. If a
PCE peer does not recognize the ASSOCIATION object, it MUST return a PCErr
message with Error-Type "Unknown Object" as described in [RFC5440]. If a PCE
peer is unwilling or unable to process the ASSOCIATION object, it MUST return a
PCErr message with the Error-Type "Not supported object" and follow the relevant
procedures described in [RFC5440].
The association timeout interval is as a PCC-local value that can be
operator-configured or computed by the PCC based on local policy and is used in the context
of cleaning up associations on session failure. The association timeout
must be set to a value no larger than the state timeout interval (defined in
) and larger than the delegation
timeout interval (defined in
.
When a PCC's PCEP session wih the PCE terminates unexpectedly, the PCC MUST
wait for the association timeout interval before cleaning up the association.
If this PCEP session can be re-established before the association timeout
interval time expires, no action is taken to clean the association created by
this PCE. During the time window of the redelegation timeout interval and
the association timeout interval, the PCE, after re-establishing the session,
can also ask for redelegation following the procedure
defined in and
.
When the association timeout interval timers expires,
the PCC clears all the associations which are not delegated to any PCEs.
Upon LSP delegation revocation, the PCC MAY clear the association
created by the related PCE, but in order to avoid traffic loss, it can perform this
in a make-before-break fashion, which is the same as what is defined in
Stateful pce for handling
LSP state cleanup.Error handling for situations for multiple PCE scenarios will be included in
future versions of this draft.
The "PCEP Parameters" registry contains a subregistry "PCEP Objects".
This document request IANA to allocate the values from this registry.Object-Class Value Name Reference TBDAssociationThis documentObject-Type 1: IPv4 2: IPv6 This document defines the following new PCEP TLVs:ValueMeaning Reference TBD Global Association SourceThis documentTBD Extended Association IdThis documentThis document requests IANA to create a subregistry of the "PCEP Parameters" for
the bits carried in the Flags field of the ASSOCIATION object.
The subregistry is called "ASSOCIATION Flags Field". The field contains 12 bits numbered from bit 0 as the most significant bit.Bit;Name: Description Reference 15 R: RemovalThis document The security considerations described in
apply to the extensions described in this document. Additional
considerations related to a malicious PCE are introduced, as the PCE may now create additional state
on the PCC through the creation of association groups.
We would like to thank Yuji Kamite and Joshua George for
their contributions to this document. Also Thank Venugopal Reddy and
Cyril Margaria for their useful comments.
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
Email: dhruv.ietf@gmail.com