RFC 8408

Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages

📅 published July 2018, from ietf

RFC 8408: Conveying Path Setup Type in PCEP Messages 💖

Okay bestie, this one is a Standards Track doc from the IETF, approved by the IESG 🔥. It came out in July 2018, and the ISSN is 2070-1721. The authors are S. Sivabalan from Cisco Systems, J. Tantsura from Nuage Networks, I. Minei from Google, R. Varga from Pantheon Technologies SRO, and J. Hardwick from Metaswitch Networks. Ten out of ten squad 👑. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract

A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network, and those paths come with all kinds of constraints 🦋. Right now TE paths are Label Switched Paths (LSPs) that get set up with the RSVP-TE signaling protocol. But other TE path setup methods are possible inside the PCE architecture, so this document proposes an extension to the PCE Communication Protocol (PCEP). The extension lets you use different path setup methods over one PCEP session 💅.

Status of This Memo

This is an Internet Standards Track document 🌸.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🎀.

Info about the current status of this doc, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8408 ✨.

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) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this doc 🧚. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Path Setup Type Capability TLV  . . . . . . . . . . . . . . .   4
4.  Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . .   6
5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   7
6.  Manageability Considerations  . . . . . . . . . . . . . . . .   8
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
  8.1.  Additions to PCEP TLV Type Indicators Registry  . . . . .   9
  8.2.  New PCEP Path Setup Types Registry  . . . . . . . . . . .   9
  8.3.  Additions to PCEP-ERROR Object Error Types and Values
        Registry  . . . . . . . . . . . . . . . . . . . . . . . .  10
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

[RFC5440] describes the PCE Communication Protocol (PCEP) for talking between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between a PCE and another PCE 💖. A PCC asks a PCE for a path that's subject to various constraints and optimization criteria. The PCE answers with a hop-by-hop path in an Explicit Route Object (ERO), and the PCC uses that ERO to set the path up in the network 🦋.

[RFC8231] adds PCEP extensions that let a PCC delegate its LSPs to a PCE. The PCE can then update the state of the LSPs it's been handed 👑. In particular, the PCE can change an LSP's path by sending a new ERO, and the PCC uses it to reroute the LSP make-before-break style 🔥. [RFC8281] gives a PCE a way to dynamically instantiate an LSP on a PCC by sending the ERO along with the LSP's characteristics. The PCC then creates the LSP from the ERO and the other attributes the PCE sent 🌸.

So far, PCEP and its extensions have assumed TE paths are label switched and get set up via RSVP-TE. But other LSP setup methods are possible in the PCE architecture (see [RFC4655] and [RFC4657]) 🧚. This document generalizes PCEP so other LSP setup methods can be used. It defines two new TLVs and the base procedures to make that work:

  • The PATH-SETUP-TYPE-CAPABILITY TLV lets a PCEP speaker announce which LSP setup methods it supports when the PCEP session gets established 🎀.
  • The PATH-SETUP-TYPE TLV lets a PCEP speaker say which setup method should be used for a given LSP. When multiple path setup types are deployed in a network, one PCEP session might have to support more than one path setup type at the same time 💅. A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate the intended path setup type in the appropriate PCEP messages. The exception is RSVP-TE, which is assumed to be the path setup type if no other setup type is indicated. This way both the PCC and the PCE can take the steps they need 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) gets introduced for setting up a path, the document that specifies that new type will define its path setup type code and, optionally, a sub-TLV for it 🌈.

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 📖

Here's the terminology this doc uses:

  • ERO: Explicit Route Object
  • PCC: Path Computation Client
  • PCE: Path Computation Element
  • PCEP: PCE Communication Protocol
  • PST: Path Setup Type
  • TLV: Type, Length, and Value

3. Path Setup Type Capability TLV 🦋

A PCEP speaker tells its peer which PSTs it supports during the PCEP initialization phase, using the process below. When the PCEP session is created, the speaker sends an Open message with an OPEN object that contains the PATH-SETUP-TYPE-CAPABILITY TLV. Here's what the TLV looks like 👀.

    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 (34)           |             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 34. Its Reserved field MUST be set to zero by the sender, and MUST be ignored by the receiver 🫶. Here are the other fields:

  • Length: The total length in bytes of the rest of the TLV, which means everything except the Type and Length fields 📏.
  • Num of PSTs: The number of PSTs in the list that follows, not counting padding 🔢.
  • List of PSTs: A list of the PSTs the PCEP speaker supports. Each PST is one byte long. Duplicate entries in this list MUST be ignored. The PCEP speaker MUST pad the list with zeros so its length is a multiple of four bytes. This document defines one PST value: PST = 0: Path is set up using the RSVP-TE signaling protocol 💜.
  • Optional sub-TLVs: A list of sub-TLVs tied to the supported PSTs. Each PST has zero or one sub-TLVs attached, and each sub-TLV goes with exactly one PST. Each sub-TLV MUST obey the TLV formatting rules defined in [RFC5440]. So each sub-TLV is padded to four-byte alignment, and its Length field doesn't count the padding bytes 🌸. This document doesn't define any sub-TLVs. An example sub-TLV can be found in [PCEP-EXTENSIONS] 🧚.

A PCEP speaker MUST check that this TLV is formatted correctly, like so:

  • If there are no sub-TLVs, the TLV Length field MUST be equal to four bytes plus the size of the PST list, not counting any padding bytes 🍓.
  • If there are sub-TLVs, the TLV Length field MUST be equal to four bytes plus the size of the PST list (rounded up to the nearest multiple of four) plus the size of the appended sub-TLVs, not counting any padding bytes in the final sub-TLV 💅.
  • The Num of PSTs field MUST be greater than zero 🔥.

If a PCEP speaker gets a PATH-SETUP-TYPE-CAPABILITY TLV that breaks 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 also include the malformed OPEN object in the PCErr message 🎀.

If a PCEP speaker gets an OPEN object with more than one PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST ignore all but the first instance of this TLV 👑.

If the OPEN object doesn't have a PATH-SETUP-TYPE-CAPABILITY TLV at all, that's the same as a PATH-SETUP-TYPE-CAPABILITY TLV holding a single PST value of 0 (Path is set up using the RSVP-TE signaling protocol) and no sub-TLVs 🦋. A PCEP speaker MAY leave out the PATH-SETUP-TYPE-CAPABILITY TLV if RSVP-TE is the only PST it supports. But 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 doesn't recognize the PATH-SETUP-TYPE-CAPABILITY TLV, it will ignore the TLV in accordance with [RFC5440] 🙈.

To be continued, bestie! 🧚✨

4. Path Setup Type TLV ✨

Okay so, when one PCEP session is setting up TE paths with different methods, the PCE and the PCC both need to know which path setup method is in play 🧚. Otherwise the PCE can't write paths in the right format, and the PCC can't take the control-plane and forwarding-plane actions that match 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

The PATH-SETUP-TYPE TLV is an optional TLV tied to the Request Parameters (RP) [RFC5440] and Stateful PCE Request Parameters (SRP) [RFC8231] objects 🎀. Its format is in Figure 2, and its TLV type is 28. Its Reserved field MUST be set to zero 🫶. The one-byte PST field holds the PST, as defined for the PATH-SETUP-TYPE-CAPABILITY TLV ✨.

No PATH-SETUP-TYPE TLV at all means the same thing as a PATH-SETUP-TYPE TLV with a PST value of 0 (the path is set up using RSVP-TE signaling) 💜. A PCEP speaker MAY omit the TLV if the PST is RSVP-TE. If the RP or SRP object has more than one PATH-SETUP-TYPE TLV, only the first one MUST be processed, and the rest MUST be ignored 🙈.

If a PCEP speaker doesn't recognize the PATH-SETUP-TYPE TLV, it will ignore the TLV in accordance with [RFC5440] and use RSVP-TE to set up the path 🦋.

5. Operation 👑

During the PCEP initialization phase, if a PCEP speaker gets a PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the peer supports only the PSTs listed in that TLV 👀. If the 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 then close the PCEP session 😭.

If the peer sent no PATH-SETUP-TYPE-CAPABILITY TLV, 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 how it infers that is 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 can express the path in a format that suits 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 doesn't 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 then close the PCEP session 💀. If the PSTs for the PCReq and PCRep messages don't 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 then 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 doesn't support the PST tied to 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 then 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 was triggered by a PCUpd or PCInitiate message, the PST the PCC puts in the PCRpt message MUST match the PST the stateful PCE intended in that PCUpd or PCInitiate message 🎯. If it doesn't match, 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 then close the PCEP session 🚨.

6. Manageability Considerations 🛠️

This document generalizes PCEP so the network can use path setup methods other than RSVP-TE (but it doesn't define any new path setup types besides RSVP-TE) 🌸. A network might end up using several path setup methods at once, and not every device will necessarily support the same set 🤷‍♀️. Managing a network that mixes multiple path setup methods can therefore bring some config and observability challenges, bestie 😩.

Each document that defines a new path setup type in the "PCEP Path Setup Types" registry (Section 8.2) must include a Manageability Considerations section. That section must explain how operators can manage PCEP with the new path setup type. It must address the following questions, which generally apply when you're working with multiple path setup types in PCEP 📋.

  • What are the criteria for when devices will use the new path setup type in PCEP, and how can the operator control this?
  • How can the network be migrated to the new path setup type, and are there any backwards-compatibility issues that operators need to be aware of?
  • Are paths set up using the new path setup type intended to coexist with other paths over the long term, and if so, how is this situation managed with PCEP?
  • How can operators verify the correct operation of PCEP in the network with respect to the new path setup type? Which fault conditions must be reported to the operators?
  • Are there any existing management interfaces (such as YANG models) that must be extended to model the operation of PCEP in the network with respect to the new path setup type?

For more guidance on writing Manageability Considerations sections in Standards Track documents, see [RFC5706] 📚.

7. Security Considerations 🚨

The security considerations in [RFC5440] and [RFC8281] apply to this specification 🔐. No additional security measure is required 🙌.

⚠️ Now the drama: if the security mechanisms of [RFC5440] and [RFC8281] are not used, this protocol could be attacked in a brand-new way. An attacker doing a TCP man-in-the-middle attack could inject error messages into the PCEP session when a particular PST is (or isn't) used 😱. That could potentially force a specific PST to be used, which might let the attacker go after a weakness in that PST 💀.

8. IANA Considerations 🦋

8.1. Additions to PCEP TLV Type Indicators Registry

IANA has allocated the following code points in the "PCEP TLV Type Indicators" registry 🎀.

  Value    Description                   Reference
  -----    --------------------------    ---------
  28       PATH-SETUP-TYPE               RFC 8408
  34       PATH-SETUP-TYPE-CAPABILITY    RFC 8408

8.2. New PCEP Path Setup Types Registry

IANA has created a brand-new sub-registry, "PCEP Path Setup Types", inside the "Path Computation Element Protocol (PCEP) Numbers" registry 🌈. The allocation policy for this new registry is IETF Review [RFC8126] ✨. The registry starts with this one value:

  Value    Description                   Reference
  -----    --------------------------    ---------
  0        Path is set up using the      RFC 8408
           RSVP-TE signaling protocol

8.3. Additions to PCEP-ERROR Object Error Types and Values Registry

IANA has allocated the following code points in the "PCEP-ERROR Object Error Types and Values" registry 💅.

 Error-Type  Meaning                                        Reference
 ----------  -------------------------------------------    ---------
    10       Reception of an invalid object                 RFC 5440

              Error-value = 11: Malformed object            RFC 8408

    21       Invalid traffic engineering path setup type    RFC 8408

              Error-value = 0: Unassigned                   RFC 8408
              Error-value = 1: Unsupported path setup type  RFC 8408
              Error-value = 2: Mismatched path setup type   RFC 8408

9. References 📖

9.1. Normative References

9.2. Informative References

Acknowledgements 🫶

Huge thank you to Marek Zavodsky for the super valuable comments 💖

Contributors 🌸

These babes also contributed to this doc:

  • Jan Medved
  • Edward Crabbe

Authors' Addresses 🎀

Siva Sivabalan, Cisco Systems, Inc. 💅

Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario  K2K 3E8
Canada

Email: msiva@cisco.com

Jeff Tantsura, Nuage Networks 🦋

Jeff Tantsura
Nuage Networks
755 Ravendale Drive
Mountain View, CA  94043
United States of America

Email: jefftant.ietf@gmail.com

Ina Minei, Google, Inc. ✨

Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA  94043
United States of America

Email: inaminei@google.com

Robert Varga, Pantheon Technologies SRO 👑

Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava, 821 05
Slovakia

Email: nite@hq.sk

Jon Hardwick, Metaswitch Networks 🧚

Jon Hardwick
Metaswitch Networks
100 Church Street
Enfield, Middlesex
United Kingdom

Email: jonathan.hardwick@metaswitch.com
📦 where this page comes from