| PCE Working Group | S. Sivabalan |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | J. Tantsura |
| Expires: September 28, 2018 | Individual |
| I. Minei | |
| Google, Inc. | |
| R. Varga | |
| Pantheon Technologies SRO | |
| J. Hardwick | |
| Metaswitch Networks | |
| March 27, 2018 |
Conveying path setup type in PCEP messages
draft-ietf-pce-lsp-setup-type-09
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network that are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE communication protocol (PCEP) to allow support for different path setup methods over a given PCEP session.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2018.
Copyright (c) 2018 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.
[RFC5440] describes the Path Computation Element communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between a PCE and a PCE. A PCC requests a path subject to various constraints and optimization criteria from a PCE. The PCE responds to the PCC with a hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the ERO to set up the path in the network.
[RFC8231] specifies extensions to PCEP that allow a PCC to delegate its LSPs to a PCE. The PCE can then update the state of LSPs delegated to it. In particular, the PCE may modify the path of an LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP in a make-before-break fashion. [RFC8281] specifies a mechanism allowing a PCE to dynamically instantiate an LSP on a PCC by sending the ERO and the characteristics of the LSP. The PCC creates the LSP using the ERO and other attributes sent by the PCE.
So far, PCEP and its extensions have assumed that the TE paths are label switched and are established via the RSVP-TE protocol. However, other methods of LSP setup are possible in the PCE architecture (see [RFC4655] and [RFC4657]). This document generalizes PCEP to allow other LSP setup methods to be used. It defines two new TLVs and specifies the base procedures to facilitate this, as follows.
This document defines a path setup type code for RSVP-TE. When a new path setup type (other than RSVP-TE) is introduced for setting up a path, a path setup type code and, optionally, a sub-TLV pertaining to the new path setup type will be defined by the document that specifies the new path setup type.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The following terminologies are used in this document:
A PCEP speaker indicates which PSTs it supports during the PCEP initialization phase, as follows. When the PCEP session is created, it sends an Open message with an OPEN object containing the PATH-SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows.
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 (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
The TLV type is TBD1 (to be assigned by IANA). Its reserved field MUST be set to zero. The other fields in the TLV are as follows.
A PCEP speaker MUST check that this TLV is correctly formatted, as follows. The TLV Length field MUST be equal to the size of the appended sub-TLVs plus the size of the PST list (rounded up to the nearest multiple of four) plus four bytes. The Number of PSTs field MUST be greater than zero. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV which violates these rules, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 (Reception of an invalid object) and Error-Value = 11 (Malformed object) and MUST close the PCEP session. The PCEP speaker MAY include the malformed OPEN object in the PCErr message as well.
If a PCEP speaker receives an OPEN object with more than one PATH-SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first instance of this TLV.
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST it supports is RSVP-TE. If a PCEP speaker supports other PSTs besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE-CAPABILITY TLV in its OPEN object.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST ignore the TLV in accordance with ([RFC5440]).
When a PCEP session is used to set up TE paths using different methods, the corresponding PCE and PCC must be aware of the path setup method used. That means, a PCE must be able to specify paths in the correct format and a PCC must be able to take control plane and forwarding plane actions appropriate to the PST.
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 (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-SETUP-TYPE TLV
PATH-SETUP-TYPE TLV is an optional TLV associated with the RP ([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in the above figure. The TLV type is 28. Its reserved field MUST be set to zero. The one byte value contains the PST as defined for the PATH-SETUP-TYPE-CAPABILITY TLV.
The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit the TLV if the PST is RSVP-TE. If the RP or SRP object contains more than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed and the rest MUST be ignored.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST ignore the TLV in accordance with ([RFC5440]).
During the PCEP initialization phase, if a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST consider that the peer suports only the PSTs listed in the TLV. If the PCEP speaker and its peer have no PSTs in common, then the PCEP speaker MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-Value = 2 (Mismatched path setup type) and close the PCEP session.
If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP speaker MUST infer that the peer supports path setup using at least RSVP-TE. The PCEP speaker MAY also infer that the peer supports other path setup types, but the means of inference are outside the scope of this document.
When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST include the PATH-SETUP-TYPE TLV in the RP object, unless the intended PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the PCE is capable of expressing the path in a format appropriate to the intended PST, it MUST use the appropriate ERO format in the PCRep message.
When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the PCE does not support the intended PST, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-Value = 1 (Unsupported path setup type) and close the PCEP session. If the PSTs corresponding to the PCReq and PCRep messages do not match, the PCC MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-Value = 2 (Mismatched path setup type) and close the PCEP session.
When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the PCC does not support the PST associated with the PCUpd or PCInitiate message, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-Value = 1 (Unsupported path setup type) and close the PCEP session.
When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. The PCC MUST include the SRP object in the PCRpt message if the PST is not RSVP-TE, even when the SRP-ID-number is the reserved value of 0x00000000. If the PCRpt message is triggered by a PCUpd or PCInitiate message, then the PST that the PCC indicates in the PCRpt MUST match the PST that the stateful PCE intended in the PCUpd or PCInitiate. If it does not, then the PCE MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-Value = 2 (Mismatched path setup type) and close the PCEP session.
This document generalises PCEP to allow path setup methods other than RSVP-TE to be used by the network. It is possible that, in a given network, multiple path setup methods will be used. It is also possible that not all devices will support the same set of path setup methods. Managing networks that combine multiple path setup methods may therefore raise some challenges from a configuration and observability point of view.
Each document that introduces a new path setup type to PCEP must include a manageability section. The manageability section must explain how operators can manage PCEP with the new path setup type. It must address the following questions, which are generally applicable when working with multiple path setup types in PCEP.
See [RFC6123] for further guidance on how to write manageability sections in PCEP standards-track documents.
The security considerations described in [RFC5440] and [RFC8281] are applicable to this specification. No additional security measure is required.
IANA is requested to confirm the early allocation of the following code point in the PCEP TLV Type Indicators registry.
| Value | Description | Reference |
|---|---|---|
| 28 | PATH-SETUP-TYPE | This document |
IANA is requested to allocate a new code point for the following TLV in the PCEP TLV Type Indicators registry.
| Value | Description | Reference |
|---|---|---|
| TBD1 | PATH-SETUP-TYPE-CAPABILITY | This document |
Note to IANA: The above TLV type was not part of the early code point allocation that was done for this draft. It was added to the draft after the early code point allocation had taken place. Please assign a code point from the indicated registry and replace each instance of "TBD1" in this document with the allocated code point.
IANA is requested to create a new sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". The allocation policy for this new registry should be by IETF Review. The new registry should contain the following value:
| Value | Description | Reference |
|---|---|---|
| 0 | Path is setup using the RSVP-TE signaling protocol. | This document |
IANA is requested to confirm the early allocation of the following code-points in the PCEP-ERROR Object Error Types and Values registry.
Note to IANA: the early allocation for Error-Type=10, Error-value=11 was originally done by draft-ietf-pce-segment-routing. However, we have since moved its definition into this document. Therefore, please update the reference for this Error-value in the indicated registry to point to RFC.ietf-pce-lsp-setup-type.
The following people contributed to this document:
We like to thank Marek Zavodsky for valuable comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009. |
| [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. |
| [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. |
| [RFC4655] | Farrel, A., Vasseur, J. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006. |
| [RFC4657] | Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006. |
| [RFC6123] | Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, DOI 10.17487/RFC6123, February 2011. |