Internet DRAFT - draft-sivabalan-pce-segment-routing

draft-sivabalan-pce-segment-routing







Network Working Group                                       S. Sivabalan
Internet-Draft                                                 J. Medved
Intended status: Standards Track                             C. Filsfils
Expires: January 4, 2015                             Cisco Systems, Inc.
                                                               E. Crabbe
                                                            Google, Inc.
                                                               R. Raszuk
                                                                  NTT I3
                                                                V. Lopez
                                                          Telefonica I+D
                                                             J. Tantsura
                                                                Ericsson
                                                           July 03, 2014


                  PCEP Extensions for Segment Routing
               draft-sivabalan-pce-segment-routing-03.txt

Abstract

   Segment Routing (SR) enables any head-end node to select any path
   without relying on a hop-by-hop signaling technique (e.g., LDP or
   RSVP-TE).  It depends only on "segments" that are advertised by Link-
   State Interior Gateway Protocols (IGPs).  A Segment Routed Path can
   be derived from a variety of mechanisms, including an IGP Shortest
   Path Tree (SPT), explicit configuration, or a Path Computation
   Element (PCE).  This document specifies extensions to the Path
   Computation Element Protocol (PCEP) that allow a stateful PCE to
   compute and initiate Traffic Engineering (TE) paths, as well as a PCC
   to request a path subject to certain constraint(s) and optimization
   criteria in SR networks.

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 http://datatracker.ietf.org/drafts/current/.




Sivabalan, et al.        Expires January 4, 2015                [Page 1]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   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 January 4, 2015.

Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of PCEP Operation in SR Networks . . . . . . . . . .   5
   4.  SR-Specific PCEP Message Extensions . . . . . . . . . . . . .   6
   5.  Object Formats  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  The OPEN Object . . . . . . . . . . . . . . . . . . . . .   7
       5.1.1.  The SR PCE Capability TLV . . . . . . . . . . . . . .   7
     5.2.  The RP/SRP Object . . . . . . . . . . . . . . . . . . . .   8
     5.3.  ERO Object  . . . . . . . . . . . . . . . . . . . . . . .   8
       5.3.1.  SR-ERO Subobject  . . . . . . . . . . . . . . . . . .   9
       5.3.2.  NAI Associated with SID . . . . . . . . . . . . . . .  10
       5.3.3.  ERO Processing  . . . . . . . . . . . . . . . . . . .  12
     5.4.  RRO Object  . . . . . . . . . . . . . . . . . . . . . . .  13
       5.4.1.  RRO Processing  . . . . . . . . . . . . . . . . . . .  13
   6.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  14
   7.  Management Considerations . . . . . . . . . . . . . . . . . .  14
     7.1.  Policy  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  The PCEP Data Model . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  PCEP Objects  . . . . . . . . . . . . . . . . . . . . . .  14
     9.2.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  14
     9.3.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .  15
     9.4.  New Path Setup Type . . . . . . . . . . . . . . . . . . .  15



Sivabalan, et al.        Expires January 4, 2015                [Page 2]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   SR technology leverages the source routing and tunneling paradigms.
   A source node can choose a path without relying on hop-by-hop
   signaling protocols such as LDP or RSVP-TE.  Each path is specified
   as a set of "segments" advertised by link-state routing protocols
   (IS-IS or OSPF).  [I-D.filsfils-rtgwg-segment-routing] provides an
   introduction to SR architecture.  The corresponding IS-IS and OSPF
   extensions are specified in
   [I-D.ietf-isis-segment-routing-extensions] and
   [I-D.ietf-ospf-segment-routing-extensions], respectively.  SR
   architecture defines a "segment" as a piece of information advertised
   by a link-state routing protocols, e.g. an IGP prefix or an IGP
   adjacency.  Several types of segments are defined.  A Node segment
   represents an ECMP-aware shortest-path computed by IGP to a specific
   node, and is always global within SR/IGP domain.  An Adjacency
   Segment represents unidirectional adjacency.  An Adjacency Segment is
   local to the node which advertises it.  Both Node segments and
   Adjacency segments can be used for SR Traffic Engineering (SR-TE).

   The SR architecture can be applied to the MPLS forwarding plane
   without any change, in which case an SR path corresponds to an MPLS
   Label Switching Path (LSP).  This document is relevant to only MPLS
   forwarding plane, and assumes that a 32-bit Segment Identifier (SID)
   represents an absolute value of MPLS label entry.  In this document,
   "Node-SID" and "Adjacency-SID" denote Node Segment Identifier and
   Adjacency Segment Identifier respectively.

   A Segment Routed path (SR path) can be derived from an IGP Shortest
   Path Tree (SPT).  SR-TE paths may not follow IGP SPT.  Such paths may
   be chosen by a suitable network planning tool and provisioned on the
   source node of the SR-TE path.

   [RFC5440] describes Path Computation Element Protocol (PCEP) for
   communication between a Path Computation Client (PCC) and a Path
   Computation Element (PCE) or between one a pair of PCEs.  A PCE or a
   PCC operating as a PCE (in hierarchical PCE environment) computes
   paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on
   various constraints and optimization criteria.
   [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a
   stateful PCE to compute and recommend network paths in compliance



Sivabalan, et al.        Expires January 4, 2015                [Page 3]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs.
   Stateful PCEP extensions provide synchronization of LSP state between
   a PCC and a PCE or between a pair of PCEs, delegation of LSP control,
   reporting of LSP state from a PCC to a PCE, controlling the setup and
   path routing of an LSP from a PCE to a PCC.  Stateful PCEP extensions
   are intended for an operational model in which LSPs are configured on
   the PCC, and control over them is delegated to the PCE.

   A mechanism to dynamically initiate LSPs on a PCC based on the
   requests from a stateful PCE or a controller using stateful PCE is
   specified in [I-D.ietf-pce-pce-initiated-lsp].  Such mechanism is
   useful in Software Driven Networks (SDN) applications, such as demand
   engineering, or bandwidth calendaring.

   It is possible to use a stateful PCE for computing one or more SR-TE
   paths taking into account various constraints and objective
   functions.  Once a path is chosen, the stateful PCE can initiate an
   SR-TE path on a PCC using PCEP extensions specified in
   [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP
   extensions described in this document.  Additionally, using
   procedures described in this document, a PCC can request an SR path
   from either stateful or a stateless PCE.  This specification relies
   on the PATH-SETUP-TYPE TLV and procedures specified in
   [I-D.sivabalan-pce-lsp-setup-type].

2.  Terminology

   The following terminologies are used in this document:

   ERO:  Explicit Route Object

   IGP:  Interior Gateway Protocol

   IS-IS:  Intermediate System to Intermediate System

   LSR:  Label Switching Router

   MSD:  Maximum SID Depth

   NAI:  Node or Adjacency Identifier

   OSPF:  Open Shortest Path First

   PCC:  Path Computation Client

   PCE:  Path Computation Element

   PCEP:  Path Computation Element Protocol



Sivabalan, et al.        Expires January 4, 2015                [Page 4]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   RRO:  Record Route Object

   SID:  Segment Identifier

   SR:  Segment Routing

   SR-TE:  Segment Routed Traffic Engineering

   TED:  Traffic Engineering Database

3.  Overview of PCEP Operation in SR Networks

   In SR networks, an ingress node of an SR path appends all outgoing
   packets with an SR header consisting of a list of SIDs (or MPLS
   labels in the context of this document).  The header has all
   necessary information to guide the packets from the ingress node to
   the egress node of the path, and hence there is no need for any
   signaling protocol.

   In a PCEP session, LSP information is carried in the Explicit Route
   Object (ERO), which consists of a sequence of subobjects.  Various
   types of ERO subobjects have been specified in [RFC3209], [RFC3473],
   and [RFC3477].  In SR networks, an ingress node of an SR path appends
   all outgoing packets with an SR header consisting of a list of SIDs
   (or MPLS labels in the context of this document).  SR-TE LSPs
   computed by a PCE can be represented in one of the following forms:

   o  An ordered set of IP address(es) representing network nodes/links:
      In this case, the PCC needs to convert the IP address(es) into the
      corresponding MPLS labels by consulting its Traffic Engineering
      Database (TED).

   o  An ordered set of SID(s).

   o  An ordered set of both MPLS label(s) and IP address(es): In this
      case, the PCC needs to convert the IP address(es) into the
      corresponding SID(s) by consulting its TED.

   This document defines a new ERO subobject denoted by "SR-ERO
   subobject" capable of carrying a SID as well as the identity of the
   node/adjacency represented by the SID.  SR-capable PCEP speakers
   should be able to generate and/or process such ERO subobject.  An ERO
   containing SR-ERO subobjects can be included in the PCEP Path
   Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP
   Initiate Request message (PCInitiate) defined in
   [I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update
   Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
   defined in [I-D.ietf-pce-stateful-pce].



Sivabalan, et al.        Expires January 4, 2015                [Page 5]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   When a PCEP session between a PCC and a PCE is established, both PCEP
   speakers exchange information to indicate their ability to support
   SR-specific functionality.  Furthermore, an LSP initially established
   via RSVP-TE signaling can be updated with SR-TE path.  This
   capability is useful when a network is migrated from RSVP-TE to SR-TE
   technology.  Similarly, an LSP initially created with SR-TE path can
   updated to signal the LSP using RSVP-TE if necessary.

   A PCC MAY include an RRO object containing the recorded LSP in PCReq
   and PCRpt messages as specified in [RFC5440] and
   [I-D.ietf-pce-stateful-pce] respectively.  This document defines a
   new RRO subobject for SR networks.  Methods used by a PCC to record
   SR-TE LSP are outside the scope of this document.

   In summary, this document:

   o  Defines a new PCEP capability, new ERO subobject, new RRO
      subobject, a new TLV, and new PCEP error codes.

   o  Specifies how two PCEP speakers can establish a PCEP session that
      can carry information about SR-TE paths.

   o  Specifies processing rules of ERO subobject.

   o  Defines a new path setup type carried in the PATH-SETUP-TYPE TLV
      for SR-TE LSP.

   The extensions specified in this document are applicable to the
   stateless PCE model defined in [RFC5440], as well as for the active
   stateful and passive stateful PCE models defined in
   [I-D.ietf-pce-stateful-pce].

4.  SR-Specific PCEP Message Extensions

   As defined in [RFC5440], a PCEP message consists of a common header
   followed by a variable length body made up of mandatory and/or
   optional objects.  This document does not require any changes in the
   format of PCReq and PCRep messages specified in [RFC5440], PCInitiate
   message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and
   PCUpd messages specified in [I-D.ietf-pce-stateful-pce].  However,
   PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE
   TLV in the RP or SRP object to clearly identify that SR-TE LSP is
   intended.  In other words, a PCEP speaker MUST not infer whether or
   not a PCEP message pertains to SR-TE LSP from any other object or
   TLV.






Sivabalan, et al.        Expires January 4, 2015                [Page 6]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


5.  Object Formats

5.1.  The OPEN Object

   This document defines a new optional TLV for use in the OPEN Object.

5.1.1.  The SR PCE Capability TLV

   The SR-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN
   Object to exchange SR capability of PCEP speakers.  The format of the
   SR-PCE-CAPABILITY TLV is shown in the following figure:

       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=TBD           |            Length=4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |     Flags     |      MSD      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 1: SR-PCE-CAPABILITY TLV format

   The code point for the TLV type is to be defined by IANA.  The TLV
   length is 4 octets.

   The 32-bit value is formatted as follows.  The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs that a PCC is
   capable of imposing on a packet.  The "Flags" (1 octet) and
   "Reserved" (2 octets) fields are currently unused, and MUST be set to
   zero on transmission and ignored on reception.

5.1.1.1.  Exchanging SR Capability

   By including the SR-PCE-CAPABILITY TLV in the OPEN message destined
   to a PCE, a PCC indicates that it is capable of supporting the head-
   end functions for SR-TE LSP.  By including the TLV in the OPEN
   message destined to a PCC, a PCE indicates that it is capable of
   computing SR-TE paths.

   The number of SIDs that can be imposed on a packet depends on PCC's
   data plane's capability.  The default value of MSD is 0 meaning that
   a PCC does not impose any limitation on the number of SIDs included
   in any SR-TE path coming from PCE.  Once an SR-capable PCEP session
   is established with a non-default MSD value, the corresponding PCE
   cannot send SR-TE paths with SIDs exceeding that MSD value.  If a PCC
   needs to modify the MSD value, the PCEP session MUST be closed and
   re-established with the new MSD value.  If a PCEP session is



Sivabalan, et al.        Expires January 4, 2015                [Page 7]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   established with a non-default MSD value, and the PCC receives an SR-
   TE path containing more SIDs than specified in the MSD value, the PCC
   MUST send a PCErr message with Error-Type 10 (Reception of an invalid
   object) and Error-value 3 (Unsupported number of Segment ERO).

   The SR Capability TLV is meaningful only in the OPEN message sent
   from a PCC to a PCE.  As such, a PCE does not need to set MSD value
   in outbound message to a PCC.  Similarly, a PCC ignores any MSD value
   received from a PCE.  If a PCE receives multiple SR-PCE-CAPABILITY
   TLVs in an OPEN message, it processes only the first TLV is
   processed.

5.2.  The RP/SRP Object

   In order to setup an SR-TE LSP using SR, RP or SRP object MUST PATH-
   SETUP-TYPE TLV specified in [I-D.sivabalan-pce-lsp-setup-type].  This
   document defines a new Path Setup Type (PST) for SR as follows:

   o  PST = 1: Path is setup using Segment Routing Traffic Engineering
      technique.

5.3.  ERO Object

   An SR-TE path consists of one or more SID(s) where each SID MAY be
   associated with the identifier that represents the node or adjacency
   corresponding to the SID.  This identifier is referred to as the
   'Node or Adjacency Identifier' (NAI).  As described later, a NAI can
   be represented in various formats (e.g., IPv4 address, IPv6 address,
   etc).  Furthermore, a NAI is used only for troubleshooting purposes,
   and MUST NOT be used to replace or modify any fields in a data packet
   header.

   The ERO object specified in [RFC5440] is used to carry SR-TE path
   information.  In order to carry SID and/or NAI, this document defines
   a new ERO subobject referred to as "SR-ERO subobject" whose format is
   specified in the following section.  An ERO object carrying an SR-TE
   path consists of one or more ERO subobject(s), and MUST carry only
   SR-ERO subobject.  Note that an SR-ERO subobject does not need to
   have both SID and NAI.  However, at least one of them MUST be
   present.

   When building the MPLS label stack from ERO, a PCC MUST assume that
   SR-ERO subobjects are organized as a last-in-first-out stack.  The
   first subobject relative to the beginning of ERO contains the
   information about the topmost label.  The last subobject contains
   information about the bottommost label.





Sivabalan, et al.        Expires January 4, 2015                [Page 8]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


5.3.1.  SR-ERO Subobject

   An SR-ERO subobject consists of a 32-bit header followed by the SID
   and the NAI associated with the SID.  The SID is a 32-bit number.
   The size of the NAI depends on its respective type, as described in
   the following sections.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |  ST   |     Flags     |F|S|C|M|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              SID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        NAI (variable)                       //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: SR-ERO Subobject format

   The fields in the SR-ERO Subobject are as follows:

   The 'L' Flag  indicates whether the subobject represents a loose-hop
      in the LSP [RFC3209].  If this flag is unset, a PCC MUST not
      overwrite the SID value present in the SR-ERO subobject.
      Otherwise, a PCC MAY expand or replace one or more SID value(s) in
      the received SR-ERO based on its local policy.


   Type  is the type of the SR-ERO subobject.  This document defines the
      SR-ERO subobject type, and requests a new codepoint from IANA.



   Length  contains the total length of the subobject in octets,
      including the L, Type and Length fields.  Length MUST be at least
      8, and MUST be a multiple of 4.  As mentioned earlier, an SR-ERO
      subobject MUST have at least SID or NAI.  The length should take
      into consideration SID or NAI only if they are not null.  The
      flags described below used to indicate whether SID or NAI field is
      null.


   SID Type (ST)  indicates the type of information associated with the
      SID contained in the object body.  The SID-Type values are
      described later in this document.






Sivabalan, et al.        Expires January 4, 2015                [Page 9]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   Flags  is used to carry any additional information pertaining to SID.
      Currently, the following flag bits are defined:



      *  M: When this bit is set, the SID value represents an MPLS label
         stack entry as specified in [RFC5462] where only the label
         value is specified by the PCE.  Other fields (TC, S, and TTL)
         fields MUST be considered invalid, and PCC MUST set these
         fields according to its local policy and MPLS forwarding rules.



      *  C: When this bit as well as the M bit are set, then the SID
         value represents an MPLS label stack entry as specified in
         [RFC5462], where all the entry's fields (Label, TC, S, and TTL)
         are specified by the PCE.  However, a PCC MAY choose to
         override TC, S, and TTL values according its local policy and
         MPLS forwarding rules.


      *  S: When this bit is set, the SID value in the subobject body is
         null.  In this case, the PCC is responsible for choosing the
         SID value, e.g., by looking up its TED using the NAI which, in
         this case, MUST be present in the subobject.


      *  F: When this bit is set, the NAI value in the subobject body is
         null.


      Editorial Note: we need to decide how to treat an SR-ERO subobject
      in which both NAI and SID are null.

   SID  is the Segment Identifier.


   NAI  contains the NAI associated with the SID.  Depending on the
      value of ST, the NAI can have different format as described in the
      following section.

5.3.2.  NAI Associated with SID

   This document defines the following NAIs:

   'IPv4 Node ID'  is specified as an IPv4 address.  In this case, ST
      value is 1, and the Length is 8 or 12 depending on either SID or
      NAI or both are included in the subobject.



Sivabalan, et al.        Expires January 4, 2015               [Page 10]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   'IPv6 Node ID'  is specified as an IPv6 address.  In this case, ST
      and Length are 2, and Length is 8, 20, or 24 depending on either
      SID or NAI or both are included in the subobject.


   'IPv4 Adjacency'  is specified as a pair of IPv4 addresses.  In this
      case, ST value is 3.  The Length is 8, 12, or 16 depending on
      either SID or NAI or both are included in the subobject, and the
      format of the NAI is shown in the following figure:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Local IPv4 address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Remote IPv4 address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: NAI for IPv4 Adjacency



   'IPv6 Adjacency'  is specified as a pair of IPv6 addresses.  In this
      case, ST valie is 4.  The Length is 8, 36 or 40 depending on
      whether SID or NAI or both included in the subobject,and the
      format of the NAI is shown in the following figure:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Local IPv6 address (16 bytes)                 //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Remote IPv6 address (16 bytes)                //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: NAI for IPv6 adjacenc y



   'Unnumbered Adjacency with IPv4 NodeIDs'  is specified as a pair of
      Node ID / Interface ID tuples.  In this case, ST value is 5.  The
      Length is 8, 20, or 24 depending on whether SID or NAI or both
      included in the subobject, and the format of the NAI is shown in
      the following figure:







Sivabalan, et al.        Expires January 4, 2015               [Page 11]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Local Node-ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Local Interface ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Remote Node-ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Remote Interface ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs

   Editorial Note: We are yet to decide if another SID subobject is
   required for unnumbered adjacency with 128 bit node ID.

5.3.3.  ERO Processing

   A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
   PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
   message and MUST send a PCE error message with Error-Type=3 ("Unknown
   Object") and Error-Value=2 ("Unrecognized object Type") or Error-
   Type=4 ("Not supported object") and Error-Value=2 ("Not supported
   object Type"), defined in [RFC5440].

   When the SID represents an MPLS label (i.e. the M bit is set), its
   value (20 most significant bits) MUST be larger than 15, unless it is
   special purpose label, such as an Entropy Label Indicator (ELI) or an
   Entropy Label (EL).  If a PCEP speaker receives a label ERO subobject
   with an invalid value, it MUST send the PCE error message with Error-
   Type = 10 ("Reception of an invalid object") and Error Value = TBD
   ("Bad label value").  If both M and C bits of an ERO subobject are
   set, and if a PCEP speaker finds erroneous setting in one or more of
   TC, S, and TTL fields, it MUST send a PCE error with Error-Type = 10
   ("Reception of an invalid object") and Error-Value = TBD ("Bad label
   format").

   If a PCC receives a stack of SR-ERO subobjects, and the number of
   stack exceeds the maximum number of SIDs that the PCC can impose on
   the packet, it MAY send a PCE error with Error-Type = 10 ("Reception
   of an invalid object") and Error-Value = TBD ("Unsupported number of
   Segment ERO subobjects").

   When a PCEP speaker detects that all subobjects of ERO are not
   identical, and if it cannot handle such ERO, it MUST send PCE error
   with Error-Type = 10 ("Reception of an invalid object") and Error-
   Value = TBD ("Non-identical ERO subobjects").



Sivabalan, et al.        Expires January 4, 2015               [Page 12]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   If a PCEP speaker receives an SR-ERO subobject in which both SID and
   NAI are absent, it MUST consider the entire ERO object invalid and
   send a PCE error with Error-Type = 10 ("Reception of an invalid
   object") and Error-Value = TBD ("Both SID and NAI are absent in ERO
   subobject").

5.4.  RRO Object

   A PCC can record SR-TE LSP and report the LSP to a PCE via RRO.  An
   RRO object contains one or more subobjects called "SR-RRO subobjects"
   whose format is shown below:

      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    |  ST   |     Flags         |F|S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              SID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        NAI (variable)                       //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: SR-RRO Subobject format

   The format of SR-RRO subobject is the same as that of SR-ERO
   subobject without L, C, and M flags.  The F and S flags are used with
   the same meaning.

   A PCC MUST assume that SR-RRO subobjects are organized such that the
   first subobject relative to the beginning of RRO contains the
   information about the topmost label, and the last subobject contains
   information about the bottommost label of the SR-TE LSP.

5.4.1.  RRO Processing

   Processing rules of SR-RRO subobject are identical to those of SR-ERO
   subobject.

   If a PCEP speaker receives an SR-RRO subobject in which both SID and
   NAI are absent, it MUST consider the entire RRO object invalid and
   send a PCE error with Error-Type = 10 ("Reception of an invalid
   object") and Error-Value = TBD ("Both SID and NAI are absent in RRO
   subobject").








Sivabalan, et al.        Expires January 4, 2015               [Page 13]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


6.  Backward Compatibility

   A PCEP speaker that does not support the SR PCEP capability cannot
   recognize the SR-ERO or SR-RRO subobjects.  As such, it MUST send a
   PCEP error with Error-Type = 4 (Not supported object) and Error-Value
   = 2 (Not supported object Type) as per [RFC5440].

7.  Management Considerations

7.1.  Policy

   PCEP implementation:

   o  Can enable SR PCEP capability either by default or via explicit
      configuration.

   o  May generate PCEP error due to unsupported number of SR-ERO or SR-
      RRO subobjects either by default or via explicit configuration.

7.2.  The PCEP Data Model

   A PCEP MIB module is defined in [I-D.ietf-pce-pcep-mib] needs be
   extended to cover additional functionality provided by [RFC5440] and
   [I-D.ietf-pce-pce-initiated-lsp].  Such extension will cover the new
   functionality specified in this document.

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

9.  IANA Considerations

9.1.  PCEP Objects

   IANA is requested to allocate a new ERO subobject and a new RRO
   subobject types (recommended values = 5 and 6 respectively).

9.2.  PCEP-Error Object

   This document defines new Error-Type and Error-Value for the
   following new conditions:


    Error-Type  Meaning
       10       Reception of an invalid object.




Sivabalan, et al.        Expires January 4, 2015               [Page 14]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


                 Error-value=2:  Bad label value.
                 Error-value=3:  Unsupported number of Segment ERO
                                 subobjects.
                 Error-value=4:  Bad label format.
                 Error-value=5:  Non-identical ERO subobjects.
                 Error-value=6:  Both SID and NAI are absent in ERO
                                 subobject.
                 Error-value=7:  Both SID and NAI are absent in RRO
                                 subobject.

9.3.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs:

       Value    Meaning                              Reference
      --------  ------------------------------------ -----------------
         26     SR-PCE-CAPABILITY                    This document

9.4.  New Path Setup Type

   This document defines a new setup type for the PATH-SETUP-TYPE TLV as
   follows:

                Value    Description           Reference

                  1      Traffic engineering   This document
                         path is setup using
                         Segment Routing
                         technique.

10.  Contributors

   The following people contributed to this document:

      - Lakshmi Sharma (Cisco Systems)

11.  Acknowledgements

   We like to thank Ina Minei, George Swallow, and Marek Zavodsky for
   the valuable comments.

12.  References

12.1.  Normative References







Sivabalan, et al.        Expires January 4, 2015               [Page 15]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   [I-D.filsfils-rtgwg-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture", draft-filsfils-rtgwg-
              segment-routing-01 (work in progress), October 2013.

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
              Litkowski, S., and J. Tantsura, "IS-IS Extensions for
              Segment Routing", draft-ietf-isis-segment-routing-
              extensions-00 (work in progress), April 2014.

   [I-D.ietf-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions-00 (work in progress), June 2014.

   [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-01 (work in
              progress), June 2014.

   [I-D.ietf-pce-pcep-mib]
              Koushik, K., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "PCE communication protocol (PCEP) Management
              Information Base", draft-ietf-pce-pcep-mib-04 (work in
              progress), February 2013.

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

   [I-D.sivabalan-pce-lsp-setup-type]
              Sivabalan, S., Medved, J., Minei, I., Varga, R., and E.
              Crabbe, "LSP setup method in PCEP messages", draft-
              sivabalan-pce-lsp-setup-type-00 (work in progress),
              October 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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



Sivabalan, et al.        Expires January 4, 2015               [Page 16]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, February 2009.

12.2.  Informative References

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol - Traffic Engineering
              (RSVP-TE)", RFC 3477, January 2003.

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

Authors' Addresses

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

   Email: msiva@cisco.com


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

   Email: jmedved@cisco.com











Sivabalan, et al.        Expires January 4, 2015               [Page 17]

Internet-Draft     PCEP Extensions for Segment Routing         July 2014


   Clarence Filsfils
   Cisco Systems, Inc.
   Pegasus Parc
   De kleetlaan 6a, DIEGEM  BRABANT 1831
   BELGIUM

   Email: cfilsfil@cisco.com


   Edward Crabbe
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: edward.crabbe@gmail.com


   Robert Raszuk
   NTT I3
   101 S. Ellsworth Ave
   San Mateo, CA  94401
   US

   Email: robert@raszuk.net


   Victor Lopez
   Telefonica I+D
   Don Ramon de la Cruz 82-84
   Madrid  28045
   Spain

   Email: vlopez@tid.es


   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   USA

   Email: jeff.tantsura@ericsson.com








Sivabalan, et al.        Expires January 4, 2015               [Page 18]