PCE Working Group X. Xu
Internet-Draft Huawei
Intended status: Standards Track J. You
Expires: July 2, 2017
S. Sivabalan
Cisco
H. Shah
Ciena
L. Contreras
Telefonica I+D
D. Bernier
Bell Canada
December 29, 2016

PCEP Extensions for MPLS Source Routing-based SFC
draft-xu-pce-sr-sfc-04

Abstract

Source Packet Routing in Networking (SPRING) WG is developing an MPLS source routing mechanism. This MPLS source routing mechanism can be leveraged to realize the service path layer functionality of the service function chaining (i.e., steering the selected traffic through a particular service function path) by encoding the service function path information as an MPLS label stack. This document describes extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and instantiate service function paths in the MPLS source routing based service function chaining context. The extensions specified in this document are applicable to both the stateless PCE model and the stateful PCE model.

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 RFC 2119 [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 July 2, 2017.

Copyright Notice

Copyright (c) 2016 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

Service Function Chaining [RFC7665] provides a flexible way to construct services. When applying a particular Service Function Chain (SFC) to the traffic classified by the Classifier, the traffic needs to be steered through an ordered set of Service Function Forwarders (SFF) and Service Functions (SF) in the network. This ordered set of SFFs and SFs in the network, referred to as a Service Function Path (SFP), is an instantiation of the SFC in the network. For example, as shown in Figure 1, an SFP corresponding to the SFC of {SF1, SF3} can be expressed as {SFF1, SF1, SFF2, SF3}.

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

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

[I-D.xu-mpls-service-chaining].

This document describes extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and instantiate service function paths in the MPLS source routing based service function chaining context. More specifically, the PCC provides an ordered list of SF IDs to the PCE and indicates to the PCE that what type SFs and paths are requested (e.g., an SFP, or a compact SFP, or an SR-specific SFP, or a compact SR-specific SFP) through the path computation request message, and then the PCE responds with a corresponding path through the path computation response message. The extensions specified in this document are applicable to both the stateless PCE model [RFC5440] and the stateful PCE model [I-D.ietf-pce-stateful-pce].

2. Terminology

This memo makes use of the terms defined in [RFC5440], [I-D.ietf-pce-segment-routing] and [I-D.xu-mpls-service-chaining]. In addition, this memo defines the following two additional terms:

3. PCEP Message Extensions for MPLS Source Routing-based SFC

3.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.ietf-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 MPLS source routing-based SFC (see Section 4.2). This document also requires the Include Route Object (IRO) to be carried in the PCReq message in order for a PCC to specify an SFC. A new IRO sub-object type needs to be defined for SF (see Section 4.3).

3.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 defined 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 an SFP and is defined in Section 4.4.

3.3. PCUpd Message

This document defines the format of the PCUpd message carrying an SFP update. The message is sent forwardly by a PCE to a PCC to update an previously computed SFP.

The format of the PCUpd message is defined as follows:

           <PCUpd Message>::=<Common Header>
                             <udpate-request-list>
           Where:
            <udpate-request-list>::=<udpate-request>[<udpate-request-list>]
            <udpate-request>::=<SRP><path-list>
            Where:
             <path-list>::=<SR-SFC-ERO>[<path-list>]

3.4. PCRpt Message

PCPRpt message sent from a PCC to PCE as a respond to a PCUpd message or in an unsolicited manner (e.g., during state synchronization).

The format of the PCUpd message is defined as follows:

              <PCUpd Message>::=<Common Header>
                                <state-report-list>
              Where:
               <state-report-list>::=<state-report>[<state-report-list>]
               <state-report>::=[<SRP>]<path-list>
               Where:
                <path-list>::=<SR-SFC-ERO>[<path-list>]

4. Object Formats

4.1. OPEN Object

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

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

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

4.2. RP/SRP Object

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

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

4.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 an SFF or an SF. 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 an SFF or an SF 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 an SFF 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 an SFF or an SF 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 an SFF meanwhile the SID of every ERO subobject MUST NOT be null.

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

      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

4.4.2. NSI Associated with SID

This document defines the following NSIs:

4.4.3. SR-SFC-ERO Processing

TBD

5. Acknowledgements

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

6.3. PCEP TLV Type Indicators

This document defines the following new PCEP TLV:

    Value     Meaning                  Reference

    27        SR-SFC-PCE-CAPABILITY    This document

6.4. New Path Setup Type

This document defines the following four new setup types for the PATH-SETUP-TYPE TLV:

     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 SFC as follows:

    Type       Sub-object

    5          Service Function ID

7. Security Considerations

This document does not introduce any new security considerations.

8. References

8.1. Normative References

[I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-18, 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.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009.

8.2. Informative References

[I-D.ietf-pce-lsp-setup-type] Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga, R., Tantsura, J. and J. Hardwick, "Conveying path setup type in PCEP messages", Internet-Draft draft-ietf-pce-lsp-setup-type-03, June 2015.
[I-D.ietf-pce-segment-routing] Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W. and J. Hardwick, "PCEP Extensions for Segment Routing", Internet-Draft draft-ietf-pce-segment-routing-08, October 2016.
[I-D.ietf-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., jefftant@gmail.com, j. and E. Crabbe, "Segment Routing with MPLS data plane", Internet-Draft draft-ietf-spring-segment-routing-mpls-05, July 2016.
[I-D.xu-mpls-service-chaining] Xu, X., Bryant, S., Assarpour, H., Shah, H., Contreras, L. and d. daniel.bernier@bell.ca, "Service Chaining using MPLS Source Routing", Internet-Draft draft-xu-mpls-service-chaining-00, October 2016.
[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.

Authors' Addresses

Xiaohu Xu Huawei EMail: xuxiaohu@huawei.com
JIanjie You EMail: jianjie.you@gmail.com
Siva Sivabalan Cisco EMail: msiva@cisco.com
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/
Daniel Bernier Bell Canada EMail: daniel.bernier@bell.ca