PCE Working Group                                           S. Sivabalan
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                             J. Tantsura
Expires: May 3, 24, 2018                                         Individual
                                                                I. Minei
                                                            Google, Inc.
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                             J. Hardwick
                                                     Metaswitch Networks
                                                        October 30,
                                                       November 20, 2017

               Conveying path setup type in PCEP messages
                    draft-ietf-pce-lsp-setup-type-05
                    draft-ietf-pce-lsp-setup-type-06

Abstract

   A Path Computation Element can compute traffic engineering paths (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.

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].

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/. http://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 May 3, 24, 2018.

Copyright Notice

   Copyright (c) 2017 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)
   (http://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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Path Setup Type Capability TLV  . . . . . . . . . . . . . . .   4
   4.  Path Setup Type TLV . . . . . .   3
   4. . . . . . . . . . . . . . . .   5
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.1.   7
     7.1.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .   5
     6.2.   7
     7.2.  New Path Setup Type Registry  . . . . . . . . . . . . . .   6
     6.3.   8
     7.3.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .   6
   7.   8
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . .   6 . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7   9

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol (PCEP) for
   communication between a Path Computation Client (PCC) and a Path
   Control
   Computation Element (PCE) (PCE), or between one a pair of PCEs. 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.

   [I-D.ietf-pce-stateful-pce]

   [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.  [I-D.ietf-pce-pce-initiated-lsp]
   specifies a mechanism allowing a PCE to dynamically instantiate an
   LSP on a PCC by sending the ERO and characteristics of the LSP.  The
   PCC signals creates the LSP using the ERO and other attributes sent by the
   PCE.

   So far, the PCEP protocol and its extensions implicitly assume have assumed that the TE paths are
   label switched, switched and are established via the RSVP-TE protocol.
   However, other methods of LSP setup are not precluded. possible in the PCE
   architecture (see [RFC4655] and [RFC4657]).  This document introduces
   a TLV called "PATH-SETUP-TYPE-CAPABILITY" which allows a PCEP speaker
   to announce the path setup types it supports when the PCEP session is
   established.  When a new path setup method type (other than RSVP-TE) is
   introduced for setting up a path, a new capability TLV path setup type code and,
   optionally, a sub-TLV pertaining to the new path setup method MAY be advertised when the PCEP session is established.
   Such capability TLV MUST type will be
   defined in by the specification of document that specifies the new path setup type.

   When multiple path setup methods types are deployed in a network, a given
   PCEP session may have to simultaneously support more than one path
   setup types. type.  In this case, the intended path setup
   method type needs to be
   either explicitly indicated or implied in the appropriate PCEP
   messages (when necessary) so that both the PCC and the PCE can take
   the necessary steps to set up the path.  This document introduces a
   generic TLV called "PATH-SETUP-TYPE TLV" and specifies the base
   procedures to facilitate such this operational model.

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 Element.

   PCEP:  Path Computation Element Protocol.

   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 a the 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 created,
   it sends an Open message with an OPEN object containing the correct PATH-
   SETUP-TYPE-CAPABILITY TLV.  The format and a PCC must be able take control and take
   forwarding plane actions appropriate to the path setup type. 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            |  PST length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: PATH-SETUP-TYPE TLV
      |                                                               |
      //                 List of PSTs (variable)                     //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //               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.

   PST length:  The length of the list of supported PSTs, in octets,
      excluding padding.

   List of PSTs:  A list of the PSTs that the PCEP speaker supports.
      Each PST is a single octet 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 octets in length.

   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
      include the padding bytes.  This document does not define any sub-
      TLVs.

   This document defines the following PST value:

   o  PST = 0: Path is setup using the RSVP-TE signaling protocol.

   The overall TLV length MUST be equal to the size of the appended sub-
   TLVs plus the PST length (rounded up to the nearest multiple of four)
   plus four bytes for the reserved field and PST length field.  The PST
   length 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.  It is
   RECOMMENDED that a PCEP speaker omits 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]).  If a
   PCEP speaker recognizes the TLV but does not support the TLV, it MUST
   send a PCErr message with Error-Type = 2 (Capability not supported)
   and MUST close the PCEP session.

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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved            |      PST      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: PATH-SETUP-TYPE TLV

   PATH-SETUP-TYPE TLV is an optional TLV associated with the RP
   ([RFC5440]) and the SRP ([I-D.ietf-pce-stateful-pce]) ([RFC8231]) objects.  Its format is shown in
   the above figure.  The type of the TLV type is to 28.  Its reserved field MUST be
   defined by IANA.
   set to zero.  The one octet value contains the Path Setup Type
   (PST).  This document specifies the following PST value:

   o  PST = 0: Path is setup via RSVP-TE signaling protocol(default). as defined for the
   PATH-SETUP-TYPE-CAPABILITY TLV.

   The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-
   SETUP-TYPE a PATH-SETUP-
   TYPE TLV with an a PST value of 0. 0 (RSVP-TE).  It is recommended to omit RECOMMENDED that a
   PCEP speaker omits the TLV in if the default case. PST is RSVP-TE.  If the RP or SRP
   object contains more than one PATH-SETUP-TYPE TLVs, 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]).  If a PCEP speaker
   recognizes the TLV but does not support the TLV, it MUST send PCErr
   with Error-Type = 2 (Capability not supported).

4.

5.  Operation

   When requesting

   During the PCEP Initialization phase, if a path PCEP speaker receives a
   PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST infer 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 PCE 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 ([RFC5440]), to a PCC MAY PCE ([RFC5440]), it MUST
   include the PATH-SETUP-TYPE TLV in the RP object. 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
   setup method used, intended PST, it MUST use the appropriate ERO format in the
   PCRep message.  If the path setup type cannot be inferred from the
   ERO or any other object or TLV in the

   When a PCE sends a PCRep message, message to a PCC ([RFC5440]), it MUST
   include the PATH-SETUP-TYPE TLV may be included in the RP object of object, unless the PCRep message.
   Regardless of whether PATH-SETUP-TYPE TLV PST is used or not, if
   RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.  If the
   PCE does not support the intended path setup type the intended PST, it MUST send a PCErr message
   with Error-Type = TBD (Traffic 21 (Invalid traffic engineering path setup error) (recommended
   value is 21) type)
   and Error-Value = 1 (Unsupported path setup type) and close the PCEP
   session.  If the path setup types PSTs corresponding to the PCReq and PCRep messages
   do not match, the PCC MUST send a PCErr message with Error-Type = 21 (Traffic
   (Invalid traffic engineering path setup error) type) and Error-
   Value Error-Value = 2
   (Mismatched path setup type) and close the PCEP session.

   In the case of

   When a stateful PCE, if the path setup type cannot be
   unambiguously inferred from ERO or any other object or TLV, PATH-
   SETUP-TYPE TLV MAY be used in PCRpt and PCE sends a PCUpd messages.  If PATH-
   SETUP-TYPE TLV is used in PCRpt message, the SRP object MUST be
   present even in cases when the SRP-ID-number is the reserved value of
   0x00000000.  Regardless of whether PATH-SETUP-TYPE TLV is used message ([RFC8231]) or
   not, if a PCRpt PCInitiate
   message is triggered due ([I-D.ietf-pce-pce-initiated-lsp]) to a PCUpd message (in this
   case SRP-ID-number is not equal to 0x00000000), the path setup types
   corresponding to the PCRpt and PCUpd messages should match.
   Otherwise, the PCE PCC, it MUST send PCErr with Error-Type = 21 (Traffic
   engineering path setup error) and Error-Value = 2 (Mismatched path
   setup type) and close the connection.

   In the case of PCE initiated LSPs, a PCE MAY include
   the PATH-SETUP-TYPE TLV in PCInitiate message if the message does not have any other
   means of indicating path setup type. SRP object, unless the intended PST is
   RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.  If a the
   PCC does not support the
   path setup type PST associated with the PCUpd or PCInitiate
   message, the PCC it MUST send a PCErr message with Error-Type = 21 (Traffic (Invalid
   traffic engineering path setup
   error) type) and Error-Value = 1 (Unsupported
   path setup type) and close the PCEP session.  Similarly, as mentioned above, if the path setup
   type cannot be unambiguously inferred from ERO or any other object or
   TLV,

   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 be included omit the PATH-SETUP-TYPE TLV.
   The PCC MUST include the SRP object in the PCRpt messages
   triggered by PCInitiate message.  Regardless of whether PATH-SETUP-
   TYPE TLV is used or not, message if a 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 path setup types corresponding to PST that the PCC indicates in the PCRpt
   and
   MUST match the PCInitiate messages should match.  Otherwise, 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 (Traffic (Invalid traffic engineering path setup error) type)
   and Error-Value = 2 (Mismatched path setup type).

5. type) and close the PCEP
   session.

6.  Security Considerations

   The security considerations described in [RFC5440] and
   [I-D.ietf-pce-pce-initiated-lsp] are applicable to this
   specification.  No additional security measure is required.

6.

7.  IANA Considerations

6.1.

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, as follows: registry.

       Value               Description                Reference

        TBD (recommended 28)      PATH-SETUP-TYPE

       TBD1                PATH-SETUP-TYPE-CAPABILITY This document

6.2.

   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.

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 "PATH-
   SETUP-TYPE TLV PST Field". "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               Traffic engineering path               Path is   This document setup using RSVP the RSVP- This document
                        TE signaling
                        protocol

6.3. protocol.

7.3.  PCEP-Error Object

   IANA is requested to allocate confirm the early allocation of the following
   code-points in the PCEP-ERROR Object Error Types and Values registry for a new error-type and the
   following new error-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

7.

   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

8.

9.  Acknowledgements

   We like to thank Marek Zavodsky for valuable comments.

9.

10.  References

10.1.  Normative References

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-09 draft-ietf-pce-pce-initiated-lsp-11 (work in
              progress), March October 2017.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-18 (work in progress), December 2016.

   [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>. <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>. <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>.

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
   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: robert.varga@pantheon.sk nite@hq.sk

   Jon Hardwick
   Metaswitch Networks
   100 Church Street
   Enfield, Middlesex
   UK

   Email: jon.hardwick@metaswitch.com jonathan.hardwick@metaswitch.com