PCE Working Group S. Sivabalan
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track J. Tantsura
Expires: July 19, 2018 Individual
I. Minei
Google, Inc.
R. Varga
Pantheon Technologies SRO
J. Hardwick
Metaswitch Networks
January 15, 2018
Conveying path setup type in PCEP messages
draft-ietf-pce-lsp-setup-type-08
Abstract
A Path Computation Element 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 PCEP to allow support for different path
setup methods over a given PCEP session.
Status of This Memo
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 July 19, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sivabalan, et al. Expires July 19, 2018 [Page 1]
Internet-Draft PCE path setup type January 2018
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7
7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8
7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[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.
Sivabalan, et al. Expires July 19, 2018 [Page 2]
Internet-Draft PCE path setup type January 2018
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.
o The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to
announce which LSP setup methods it supports when the PCEP session
is established.
o The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify
which setup method should be used for a given LSP. When multiple
path setup types are deployed in a network, a given PCEP session
may have to simultaneously support more than one path setup type.
A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate
the intended path setup type in the appropriate PCEP messages,
unless the path setup type is RSVP-TE (which is assumed to be the
path setup type if no other setup type is indicated). This is so
that both the PCC and the PCE can take the necessary steps to set
up the path.
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.
1.1. Requirements Language
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].
2. Terminology
The following terminologies are used in this document:
ERO: Explicit Route Object.
LSR: Label Switching Router.
PCC: Path Computation Client.
PCE: Path Computation Element.
PCEP: Path Computation Element Protocol.
Sivabalan, et al. Expires July 19, 2018 [Page 3]
Internet-Draft PCE path setup type January 2018
PST: Path Setup Type.
TLV: Type, Length, and Value.
3. Path Setup Type Capability TLV
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.
Length: The total length of the remainder of the TLV, that is,
excluding the Type and Length fields.
Number of PSTs: The number of PSTs in the following list, excluding
padding.
List of PSTs: A list of the PSTs that the PCEP speaker supports.
Each PST is a single byte in length. Duplicate entries in this
list MUST be ignored. The PCEP speaker MUST pad the list with
zeros so that it is a muliple of four bytes in length. This
document defines the following PST value:
* PST = 0: Path is setup using the RSVP-TE signaling protocol.
Optional sub-TLVs: A list of sub-TLVs associated with the supported
PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined
in ([RFC5440]). That is, each sub-TLV MUST be padded to a four
byte alignment, and the length field of each sub-TLV MUST NOT
Sivabalan, et al. Expires July 19, 2018 [Page 4]
Internet-Draft PCE path setup type January 2018
include the padding bytes. This document does not define any sub-
TLVs.
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]).
4. Path Setup Type TLV
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 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
Sivabalan, et al. Expires July 19, 2018 [Page 5]
Internet-Draft PCE path setup type January 2018
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]).
5. Operation
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.
Sivabalan, et al. Expires July 19, 2018 [Page 6]
Internet-Draft PCE path setup type January 2018
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.
6. Security Considerations
The security considerations described in [RFC5440] and [RFC8281] are
applicable to this specification. No additional security measure is
required.
7. IANA Considerations
7.1. PCEP TLV Type Indicators
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
Sivabalan, et al. Expires July 19, 2018 [Page 7]
Internet-Draft PCE path setup type January 2018
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.
7.2. New Path Setup Type Registry
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 Consensus. The new registry should contain the
following value:
Value Description Reference
0 Path is setup using the RSVP- This document
TE signaling protocol.
7.3. PCEP-Error Object
IANA is requested to confirm the early allocation of the following
code-points in the PCEP-ERROR Object Error Types and Values registry.
Error-Type Meaning
10 Reception of an invalid object
Error-value=11: Malformed object
Error-Type Meaning
21 Invalid traffic engineering path setup type
Error-value=0: Unassigned
Error-value=1: Unsupported path setup type
Error-value=2: Mismatched path setup type
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.
8. Contributors
The following people contributed to this document:
- Jan Medved
- Edward Crabbe
Sivabalan, et al. Expires July 19, 2018 [Page 8]
Internet-Draft PCE path setup type January 2018
9. Acknowledgements
We like to thank Marek Zavodsky for valuable comments.
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>.
[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
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed. and J. 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>.
Authors' Addresses
Sivabalan, et al. Expires July 19, 2018 [Page 9]
Internet-Draft PCE path setup type January 2018
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com
Jeff Tantsura
Individual
Email: jefftant.ietf@gmail.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
Email: inaminei@google.com
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava, 821 05
Slovakia
Email: nite@hq.sk
Jon Hardwick
Metaswitch Networks
100 Church Street
Enfield, Middlesex
UK
Email: jonathan.hardwick@metaswitch.com
Sivabalan, et al. Expires July 19, 2018 [Page 10]