Pce Working Group                                                  X. Xu
Internet-Draft                                                    J. You
Intended status: Standards Track                                  Huawei
Expires: December 24, 2014                                       H. Shah
                                                                   Ciena
                                                            L. Contreras
                                                          Telefonica I+D
                                                           June 22, 2014


                 PCEP Extensions for SFC in SR Networks
                         draft-xu-pce-sr-sfc-01

Abstract

   [I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC
   architecture in which the PCE is used to compute service function
   paths in SR networks.  Based on the above architecture, this document
   describes extensions to the Path Computation Element Protocol (PCEP)
   that allow a PCE to compute and instantiate service function paths 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/.

   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 24, 2014.







Xu, et al.              Expires December 24, 2014               [Page 1]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


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 Extensions for SFC in SR Networks  . . . . .   4
   4.  PCEP Message Extensions for SR-based SFC  . . . . . . . . . .   5
     4.1.  PCReq Message . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  PCRep Message . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Object Formats  . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  OPEN Object . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  SR-SFC PCE Capability TLV . . . . . . . . . . . . . .   6
     5.2.  RP Object . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Include Route Object  . . . . . . . . . . . . . . . . . .   7
     5.4.  SR-SFC-ERO Object . . . . . . . . . . . . . . . . . . . .   7
       5.4.1.  SR-SFC-ERO Subobject  . . . . . . . . . . . . . . . .   7
       5.4.2.  NSI Associated with SID . . . . . . . . . . . . . . .   9
       5.4.3.  SR-SFC-ERO Processing . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  PCEP Objects  . . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .   9
     6.3.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .  10
     6.4.  New Path Setup Type . . . . . . . . . . . . . . . . . . .  10
     6.5.  New IRO Sub-object Type . . . . . . . . . . . . . . . . .  10
   7.  Security considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11







Xu, et al.              Expires December 24, 2014               [Page 2]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


1.  Introduction

   Service Function Chaining (SFC) provides a flexible way to construct
   services.  When applying a particular service function chain to the
   traffic classified by the SFC classifier, the traffic needs to be
   steered through an ordered set of service functions in the network.
   This ordered set service functions in the network, referred to as a
   Service Function Path (SFP), is an instantiation of the service
   function chain in the network.  For example, as shown in Figure 1, an
   SFP corresponding to the SFC of {SF1, SF3} can be expressed as
   {Service Node 1, SF1, Service Node 2, SF3}.

            +-------+
         +--+  PCE  |
         |  +-------+
         |
         |
         |
         |   +-------------------------------------------------+
         |   |                                     SR Netowrks |
         |   |         +-----+   +-----+                       |
         |   |         | SF1 |   | SF2 |                       |
         |   |         +--+--+   +--+--+                       |
         |   |            |         |                          |
         |   |         ^  |         |                          |
         |   |      (2)|  +---+ +---+                          |
         |   |         +--+   | |                              |
        ++---------+      |   | |          +--------------+    |
        |    +----+|      V   | |          |+-----+       |    |
        |    |PCC || (1)  +---+-+----+ (3) || SF3 |       |    |
    --> |SFC +----+|----> | Service  |---->|+-----+       |---->
    ----+Classifier+------+ Node 1   +-----+Service Node 2+--------
        +----------+      +----------+     +--------------+    |
             |                                                 |
             +-------------------------------------------------+

             Figure 1: PCE-based Service Function Chaining in SR Network

   [I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC
   architecture in which the PCE is used to compute a service function
   path (i.e., instantiate a service function chain) in SR networks.
   This document describes extensions to the PCEP based on that
   architecture.








Xu, et al.              Expires December 24, 2014               [Page 3]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


2.  Terminology

   This section contains definitions for terms used frequently
   throughout this document.  However, many additional definitions can
   be found in [RFC5440], [I-D.sivabalan-pce-segment-routing] and
   [I-D.xu-spring-pce-based-sfc-arch].

      PCC: Path Computation Client

      PCE: Path Computation Element

      PCEP: Path Computation Element Protocol

      ERO: Explicit Route Object

      SF Identifier (SF ID): A unique identifier that represents a
      service function within an SFC-enabled domain.

      Service Function Path (SFP): The instantiation of an SFC in the
      network.  Specifically, it is an ordered list of service node
      locators and SF IDs.

      Compact SFP: An ordered list of service node locators.

      SID: Segment Identifier

      Service Function SID : A locally unique SID indicating a
      particular service function on a service node.

      SR: Segment Routing

      SR-specific SFP: An ordered list of node SIDs (representing
      service nodes) and Service Function SIDs.

      Compact SR-specific SFP: An ordered list of node SIDs
      (representing service nodes).

3.  Overview of PCEP Extensions for SFC in SR Networks

   As discussed in [I-D.xu-spring-pce-based-sfc-arch], the PCC provides
   an ordered list of SF IDs to the PCE and indicates to the PCE that
   what type of path is requested (e.g., an SFP, or a compact SFP, or an
   SR-specific SFP, or a compact SR-specific SFP), and then the PCE
   responds with a correponding path.







Xu, et al.              Expires December 24, 2014               [Page 4]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


4.  PCEP Message Extensions for SR-based SFC

4.1.  PCReq Message

   This document does not specify any changes to the PCReq message
   format.  This document requires the PATH-SETUP-TYPE TLV
   [I-D.sivabalan-pce-lsp-setup-type] to be carried in the RP Object in
   order for a PCC to request a particular type of path.  Four new Path
   Setup Types need to be defined for SR-based SFC, or SR-SFC in short
   (Section 5.2).  This document also requires the Include Route Object
   (IRO) to be carried in the PCReq message in order for a PCC to
   specify that the computed SFP must traverse a set of specified
   service functions.  A new IRO sub-object type needs to be defined for
   SFC (Section 5.3).

4.2.  PCRep Message

   This document defines the format of the PCRep message carrying an
   SFP.  The message is sent by a PCE to a PCC in response to a
   previously received PCReq message, where the PCC requested an SFP.
   The format of the SFC-specific PCRep message is as follows:

              <PCRep Message>::=<Common Header>
                                <response-list>

              Where:

               <response-list>::=<response>[<response-list>]

               <response>::=<RP>
                            [<NO-PATH>]
                            [<path-list>]


               Where:

                <path-list>::=<SR-SFC-ERO>[<path-list>]

   The RP and NO-PATH Objects are defined in [RFC5440].  The <SR-SFC-
   ERO> object contains the SFP and is defined in Section 5.4.

5.  Object Formats

5.1.  OPEN Object

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





Xu, et al.              Expires December 24, 2014               [Page 5]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


5.1.1.  SR-SFC PCE Capability TLV

   The SR-SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN
   Object to negotiate SR-SFC capability on the PCEP session.  The
   format of the SR-SFC-PCE-CAPABILITY TLV is shown in the following
   Figure 2:

     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 2: SR-SFC-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 and ignored on receipt.

5.1.1.1.  Negotiating SR-SFC Capability

   The SR-SFC capability TLV is contained in the OPEN object.  By
   including the TLV in the OPEN message to a PCE, a PCC indicates its
   support for SFPs.  By including the TLV in the OPEN message to a PCC,
   a PCE indicates that it is capable of computing SFPs.

5.2.  RP Object

   In order to setup an SFP, the RP object MUST carry a PATH-SETUP-TYPE
   TLV specified in [I-D.sivabalan-pce-lsp-setup-type].  This document
   defines four new Path Setup Types (PST) for SR-SFC as follows:

      PST = 2: The path is an SFP.

      PST = 3: The path is a compact SFP.

      PST = 4: The path is an SR-specific SFP.

      PST = 5: The path is a compact SR-specific SFP.







Xu, et al.              Expires December 24, 2014               [Page 6]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


5.3.  Include Route Object

   The IRO (Include Route Object) MUST be carried within PCReq messages
   to indicate a particular SFC.  Furthermore, the IRO MAY be carried in
   PCRep messages.  When carried within a PCRep message with the NO-PATH
   object, the IRO indicates the set of service functions that cause the
   PCE to fail to find a path.

   This document defines a new sub-object type for the SR-SFC as
   follows:

    Type       Sub-object

    5          Service Function ID

5.4.  SR-SFC-ERO Object

   Generally speaking, an SR-SFC-ERO object consists of one or more ERO
   subobjects described in the following sub-sections to represent a
   particular type of service function path.  In the ERO subobject, each
   SID is associated with an identifier that represents either a service
   node or a service function.  This identifier is referred to as the
   'Node or Service Identifier' (NSI).  As described later, an NSI can
   be represented in various formats (e.g., IPv4 address, IPv6 address,
   SF identifier, etc).  Specifically, in the SFP case, the NSI of every
   ERO subobject contained in the SR-SFC-ERO object represents a service
   node or a service function while the SID of each ERO subobject is set
   to null.  In the compact SFP case, the NSI of every ERO subobject
   contained in the SR-SFC-ERO object only represents a service node
   meanwhile the SID of every ERO subobject is set to null.  In the SR-
   specific SFP, the NSI of every ERO subobject contained in the SR-SFC-
   ERO object represents a service node or a service function while the
   SID of every ERO subject MUST NOT be null.  In the compact SR-
   specific SFP, the NSI of every ERO subobject contained in the SR-SFC-
   ERO object represents a service node meanwhile the SID of every ERO
   subobject MUST NOT be null.

5.4.1.  SR-SFC-ERO Subobject

   An SR-SFC-ERO subobject (as shown in Figure 3) consists of a 32-bit
   header followed by the SID and the NSI associated with the SID.  The
   SID is a 32-bit or 128 bit number.  The size of the NSI depends on
   its respective type, as described in the following sub-sections.








Xu, et al.              Expires December 24, 2014               [Page 7]


Internet-Draft      PCEP Extensions for SR-based SFC           June 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |    Length     |  NSIT   |  Flags    |P|F|S|C|M|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //         SID (variable:4 or 16 octets)                       //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //              NSI (variable)                                 //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: SR-SFC-ERO Subobject Format

   The fields in the ERO Subobject are as follows:

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

      Type: is the type of the SR-SFC-ERO Subobject.  This document
      defines the SR-SFC-ERO Subobject type.  A new code point will be
      requested for the SR-SFC-ERO Subobject from IANA.

      Length: contains the total length of the subobject in octets,
      including the L, Type and Length fields.  Length MUST be at least
      4, and MUST be a multiple of 4.

      NSI Type (NSIT): indicates the type of NSI associated with the
      SID.  The NSI-Type values are described later in this document.

      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.





Xu, et al.              Expires December 24, 2014               [Page 8]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


         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 Traffic Engineering Database
         (TED) using node/service identifier in the subobject body.

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

         P: When this bit is set, the SID value represents an IPv6
         address.

      SID: is the 4-octect or 16-octect Segment Identifier

      NSI: contains the NSI associated with the SID.  Depending on the
      value of NSIT, the NSI can have different format as described in
      the following sub-section.

5.4.2.  NSI Associated with SID

   This document defines the following NSIs:

      'IPv4 Node ID': is specified as an IPv4 address.  In this case,
      NSIT and Length are 1 and 12 respectively.

      'IPv6 Node ID': is specified as an IPv6 address.  In this case,
      NSIT and Length are 2 and 24 respectively.

      'Service ID': is specified as an SF ID.  In this case, NSIT and
      Length are TBD.

5.4.3.  SR-SFC-ERO Processing

   TBD.

6.  IANA Considerations

6.1.  PCEP Objects

   IANA is requested to allocate an ERO subobject type (recommended
   value= 6) for the SR-SFC-ERO subobject.

6.2.  PCEP-Error Object

   TBD.







Xu, et al.              Expires December 24, 2014               [Page 9]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


6.3.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs:

    Value     Meaning                  Reference

    27        SR-SFC-PCE-CAPABILITY    This document

6.4.  New Path Setup Type

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

     Value   Description                             Reference

     2       The path is an SFP.                     This document

     3       The path is a compact SFP.              This document

     4       The path is an SR-specific SFP.         This document

     5       The path is a compact SR-specific SFP.  This document

6.5.  New IRO Sub-object Type

   This document defines a new IRO sub-object type for the SFC as
   follows:

    Type       Sub-object

    5          Service Function ID

7.  Security considerations

   This document does not introduce any new security considerations.

8.  Acknowledgement

   TBD.

9.  References

9.1.  Normative References

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





Xu, et al.              Expires December 24, 2014              [Page 10]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


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

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

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

9.2.  Informative References

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

   [I-D.sivabalan-pce-segment-routing]
              Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and
              R. Raszuk, "PCEP Extensions for Segment Routing", draft-
              sivabalan-pce-segment-routing-02 (work in progress),
              October 2013.

   [I-D.xu-spring-pce-based-sfc-arch]
              Xu, X., "PCE-based SFC Architecture in SR Networks",
              draft-xu-spring-pce-based-sfc-arch-00 (work in progress),
              April 2014.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com


   Jianjie You
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing,  210012
   China

   Email: youjianjie@huawei.com





Xu, et al.              Expires December 24, 2014              [Page 11]


Internet-Draft      PCEP Extensions for SR-based SFC           June 2014


   Himanshu Shah
   Ciena

   Email: hshah@ciena.com


   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid,  28050
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://people.tid.es/LuisM.Contreras/




































Xu, et al.              Expires December 24, 2014              [Page 12]