PCE Working Group                                           S. Sivabalan
Internet-Draft                                                 J. Medved                                       Cisco Systems, Inc.
Intended status: Standards Track                     Cisco Systems, Inc.                             J. Tantsura
Expires: December 25, 2015 October 27, 2017                                     Individual
                                                                I. Minei
                                                            Google, Inc.
                                                               E. Crabbe
                                                  Individual Contributor
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                             J. Tantsura
                                                             J. Hardwick
                                                     Metaswitch Networks
                                                           June 23, 2015
                                                          April 25, 2017

               Conveying path setup type in PCEP messages


   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",
   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 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 December 25, 2015. October 27, 2017.

Copyright Notice

   Copyright (c) 2015 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
   (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 TLV . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .   5
     6.2.  New Path Setup Type Registry  . . . . . . . . . . . . . .   6
     6.3.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

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

   So far, the PCEP protocol and its extensions implicitly assume that
   the TE paths are label switched, and are established via the RSVP-TE
   protocol.  However, other methods of LSP setup are not precluded.
   When a new path setup method (other than RSVP-TE) is introduced for
   setting up a path, a new capability TLV pertaining to the new path
   setup method MAY be advertised when the PCEP session is established.
   Such capability TLV MUST be defined in the specification of the new
   path setup type.  When multiple path setup methods are deployed in a
   network, a given PCEP session may have to simultaneously support more
   than one path setup types.  In this case, the intended path setup
   method 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 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

   PCEP:  Path Computation Element Protocol.

   TLV:  Type, Length, and Value.

3.  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 and take
   forwarding plane actions appropriate to the path setup type.

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

                       Figure 1: 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]) objects.  Its
   format is shown in the above figure.  The type of the TLV is to be
   defined by IANA.  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).

   The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-
   SETUP-TYPE TLV with an PST value of 0.  It is recommended to omit the
   TLV in the default case.  If the RP or SRP object contains more than
   one PATH-SETUP-TYPE TLVs, 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.  Operation

   When requesting a path from a PCE using a PCReq message ([RFC5440]),
   a PCC MAY include the PATH-SETUP-TYPE TLV in the RP object.  If the
   PCE is capable of expressing the path in a format appropriate to the
   setup method used, 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 PCRep message, PATH-SETUP-TYPE
   TLV may be included in the RP object of the PCRep message.
   Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE
   does not support the intended path setup type it MUST send PCErr with
   Error-Type = TBD (Traffic engineering path setup error) (recommended
   value is 21) and Error-Value = 1 (Unsupported path setup type) and
   close the PCEP session.  If the path setup types corresponding to the
   PCReq and PCRep messages do not match, the PCC MUST send a PCErr with
   Error-Type = 21 (Traffic engineering path setup error) and Error-
   Value = 2 (Mismatched path setup type) and close the PCEP session.

   In the case of 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 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 or
   not, if a PCRpt message is triggered due 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 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 PATH-SETUP-TYPE
   TLV in PCInitiate message if the message does not have any other
   means of indicating path setup type.  If a PCC does not support the
   path setup type associated with the PCInitiate message, the PCC MUST
   send PCErr with Error-Type = 21 (Traffic engineering path setup
   error) 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, the PATH-SETUP-TYPE TLV MAY be included in PCRpt messages
   triggered by PCInitiate message.  Regardless of whether PATH-SETUP-
   TYPE TLV is used or not, if a PCRpt message is triggered by a
   PCInitiate message, the path setup types corresponding to the PCRpt
   and the PCInitiate messages should match.  Otherwise, the PCE MUST
   send PCErr message with Error-Type = 21 (Traffic engineering path
   setup error) and Error-Value = 2 (Mismatched path setup type).

5.  Security Considerations

   No additional security measure is required.

6.  IANA Considerations

6.1.  PCEP TLV Type Indicators

   IANA is requested to allocate a new code point in the PCEP TLV Type
   Indicators registry, as follows:

        Value                     Description        Reference

        TBD (recommended 28)      PATH-SETUP-TYPE    This document

6.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".  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 is   This document
                        setup using RSVP signaling

6.3.  PCEP-Error Object

   IANA is requested to allocate code-points in the PCEP-ERROR Object
   Error Types and Values registry for a new error-type and the
   following new error-values:

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

   The following people contributed to this document:

      - Jan Medved
      - Edward Crabbe

8.  Acknowledgements

   We like to thank Marek Zavodsky for valuable comments.


9.  Normative References

              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-04 draft-ietf-pce-pce-initiated-lsp-09 (work in
              progress), April 2015. March 2017.

              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-18 (work in progress), April 2015. 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. 1997,

   [RFC5440]  Vasseur, JP. JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March
              2009. 2009,

Authors' Addresses

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

   Email: msiva@cisco.com

   Jan Medved
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134

   Jeff Tantsura

   Email: jmedved@cisco.com jefftant.ietf@gmail.com

   Ina Minei
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043

   Email: inaminei@google.com

   Edward Crabbe
   Individual Contributor

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

   Email: robert.varga@pantheon.sk
   Jeff Tantsura
   300 Holger Way
   San Jose, CA  95134

   Email: jeff.tantsura@ericsson.com
   Jon Hardwick
   Metaswitch Networks
   100 Church Street
   Enfield, Middlesex

   Email: jon.hardwick@metaswitch.com