Internet DRAFT - draft-xu-spring-pce-based-sfc-arch

draft-xu-spring-pce-based-sfc-arch







Spring 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


               PCE-based SFC Architecture in SR Networks
                 draft-xu-spring-pce-based-sfc-arch-01

Abstract

   Service Function Chaining (SFC) provides a flexible way to construct
   services.  When applying a particular service function chain to the
   traffic, the traffic needs to be steered through an ordered set of
   service functions in the network.  This ordered set of service
   functions in the network, referred to as a Service Function Path
   (SFP), is an instantiation of the service function chain in the
   network.  Segment Routing (SR) technique can be leveraged to steer
   the traffic through the SFP in SR networks.  This document 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.

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




Xu, et al.              Expires December 24, 2014               [Page 1]

Internet-Draft             PCE-based SFC Arch                  June 2014


   This Internet-Draft will expire on December 24, 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  PCE-based SFC Architecture in SR Networks . . . . . . . . . .   4
     3.1.  PCC Requests SFP  . . . . . . . . . . . . . . . . . . . .   6
     3.2.  PCC Requests SR-specific SFP  . . . . . . . . . . . . . .   6
     3.3.  PCEP Extensions Discussion  . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Service Function Chaining 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, a
   SFP corresponding to the SFC of {SF1, SF3} can be expressed as
   {Service Node 1, SF1, Service Node 2, SF3}.







Xu, et al.              Expires December 24, 2014               [Page 2]

Internet-Draft             PCE-based SFC Arch                  June 2014


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


                Figure 1: Service Function Chaining in SR Network

   Segment Routing (SR) [I-D.filsfils-spring-segment-routing] technique
   leverages the source routing and tunneling paradigms, which can be
   used to steer traffic through an ordered set of routers.  SR can be
   applied to both MPLS data plane [I-D.gredler-spring-mpls],
   [I-D.filsfils-spring-segment-routing-mpls] and IPv6 data plane
   [I-D.previdi-6man-segment-routing-header].
   [I-D.sivabalan-pce-segment-routing] specifies extensions to the Path
   Computation Element Protocol (PCEP) [RFC5440] that allow a stateful
   PCE to compute and instantiate an SR path.
   [I-D.xu-spring-sfc-use-case] describes a use case for SPRING where
   the SR mechanism is leveraged to realize the service path layer
   functionality of the SFC.

   This document describes an architecture for PCEP in which a stateful
   PCE is used to compute an SFP in SR networks.

2.  Terminology

   This section contains definitions for terms used frequently
   throughout this document.  However, many additional definitions can
   be found in [I-D.quinn-sfc-arch].

      Service Function (SF): A function that is responsible for specific
      treatment of received packets.




Xu, et al.              Expires December 24, 2014               [Page 3]

Internet-Draft             PCE-based SFC Arch                  June 2014


      Service Function Chain (SFC): A service function chain defines an
      ordered set of service functions that must be applied to packets
      and/or frames selected as a result of classification.

      Service Node (SN): Physical or virtual element that hosts one or
      more service functions and has one or more network locators
      associated with it for reachability and service delivery.

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

      SFC Classifier: An entity that classifies packets for service
      function chaining according to classification rules.  Packets are
      then marked with the corresponding SFC header.  SFC classifier is
      embedded in a SFC ingress node.

      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.

      SR: Segment Routing.

      SR Header: an MPLS label stack or an IPv6 address list.

      SID: Segment Identifier.

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

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

      PCC: Path Computation Client.

      PCE: Path Computation Element.

      PCEP: Path Computation Element Protocol.

3.  PCE-based SFC Architecture in SR Networks

   When a packet enters an SFC-enabled domain, the SFC classifier
   classifies the packet for service function chaining according to the
   local policy rules, and then attaches an SFC header



Xu, et al.              Expires December 24, 2014               [Page 4]

Internet-Draft             PCE-based SFC Arch                  June 2014


   [I-D.quinn-sfc-nsh] to the packet which should include the SFP
   information.  As in this document SR technique is leveraged to steer
   the packet through the SFP, the SFC classifier therefore needs to
   attach a segment list which represents the SFP to the packet.
   [RFC5440] describes PCEP for communication between a Path Computation
   Client (PCC) and a Path Control Element (PCE).  In this document, the
   PCE is responsible for computing the SFP or the SR-specific SFP,
   while the SFC classifier constructs the SR header according to the
   path computation result returned from the PCE (as shown in Figure 2).

                     +---------+
                     |         |
           +--------->   PCE   |
           |         |         |
           |         +---------+
           |
           |
           |
           |
           |   +---------------------------------------------------+
           |   |                                       SR Netowrks |
           |   |                                                   |
           |   |                   -------------                   |
        +--V--------+         /////             \\\\\              |
        |    +-----+|       //  +-----+   +-----+    \\            |
        |    | PCC ||      |    | SF1 |   | SF2 |      |           |
  ----> |SFC +-----+|     |     +-----+   +-----+       |        ----->
  ------+Classifier +------           +-----+           ----------------
        +-----------+      |          | SF3 |          -           |
               |            \\        +-----+        //            |
               |              \\\\\             /////              |
               |                   -------------                   |
               +---------------------------------------------------+

               Figure 2: PCE-based SFC Architecture in SR Networks

   Two methods will be discussed depending on the requested path type
   from the PCC:

      (1) The PCC requests an SFP.

      (2) The PCC requests an SR-specific SFP.

   In the first case, the SFC classifier needs to transform the SFP
   information to the SR-specific SFP information and then attach an SR
   header containing the SR-specific SFP information to the packets.
   For the second case, the SFC classifier can directly attach an SR




Xu, et al.              Expires December 24, 2014               [Page 5]

Internet-Draft             PCE-based SFC Arch                  June 2014


   header containing the SR-specific SFP information to the packets.
   The detailed will be discussed in the following sub-sections.

3.1.  PCC Requests SFP

   The PCE is responsible for computing the SFP based on the network
   information, SF information, service requirements, etc.  How PCE
   computes the SFP is out of scope of this document.  The SFC
   classifier is responsible to transform the SFP to the SR-specific
   SFP.  The detailed procedures are described below:

      Step 1: The SFC classifier acting as a PCC sends a PCReq message
      to the PCE to request an SFP or a compact SFP.  Two new setup
      types of the PATH-SETUP-TYPE TLV must be carried, indicating that
      an SFP or a compact SFP needs to be setup.  The PCReq message also
      needs to carry an ordered set of SF Identifiers which indicates
      the SFC.

      Step 2: The PCE sends a response to the PCC, carrying an SFP or a
      compact SFP.

      Step 3: If the PCE returns an SFP, the SFC classifier transforms
      the SFP information into the SR-specific SFP information.  If the
      PCE returns a compact SFP, the SFC classifier needs to insert the
      corresponding SF identifier after each service node and then
      transform it into the SR-specific SFP information .

      Step 4: Upon receiving the packets, the SFC classifier classifies
      them for service function chain according to classification rules.
      Packets are then attacheded with an SR header containing the
      corresponding SR-specific SFP information.

3.2.  PCC Requests SR-specific SFP

   The PCE is responsible to compute the SR-specific SFP based on the
   network information, SF information, service requirements, etc.  How
   PCE computes the SR-specific SFP is out of scope of this document.
   The SFC classifier is responsible to attach an SR header containing
   the SR-specific SFP information to the selected packets.  The
   detailed procedures are described below:

      Step 1: The SFC classifier sends a PCReq message to the PCE to
      request an SR-specific SFP.  A new setup type of the PATH-SETUP-
      TYPE TLV must be carried, indicating that an SR-specific SFP needs
      to be setup.  The PCC also needs to carry an ordered set of SF
      identifiers.





Xu, et al.              Expires December 24, 2014               [Page 6]

Internet-Draft             PCE-based SFC Arch                  June 2014


      Step 2: The PCE sends a response to the PCC, carrying an SR-
      specific SFP.

      Step 3: Upon receiving the packets, the SFC classifier classifies
      them for service chaining according to classification rules.
      Packets are then attched with an SR header containning the
      corresponding SR-specific SFP information.

3.3.  PCEP Extensions Discussion

   The possible PCEP extensions for supporting the two methods proposed
   in this document will be specified in a separate document.

4.  IANA Considerations

   TBD.

5.  Security considerations

   This document does not introduce any new security considerations.

6.  Acknowledgement

   TBD.

7.  References

7.1.  Normative References

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

7.2.  Informative References

   [I-D.filsfils-spring-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-spring-
              segment-routing-03 (work in progress), June 2014.







Xu, et al.              Expires December 24, 2014               [Page 7]

Internet-Draft             PCE-based SFC Arch                  June 2014


   [I-D.filsfils-spring-segment-routing-mpls]
              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 with MPLS data plane", draft-filsfils-
              spring-segment-routing-mpls-02 (work in progress), June
              2014.

   [I-D.gredler-spring-mpls]
              Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu,
              "Supporting Source/Explicitly Routed Tunnels via Stacked
              LSPs", draft-gredler-spring-mpls-06 (work in progress),
              May 2014.

   [I-D.previdi-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
              Segment Routing Header (SRH)", draft-previdi-6man-segment-
              routing-header-01 (work in progress), June 2014.

   [I-D.quinn-sfc-arch]
              Quinn, P. and J. Halpern, "Service Function Chaining (SFC)
              Architecture", draft-quinn-sfc-arch-05 (work in progress),
              May 2014.

   [I-D.quinn-sfc-nsh]
              Quinn, P., Guichard, J., Fernando, R., Surendra, S.,
              Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A.,
              Elzur, U., McConnell, B., and C. Wright, "Network Service
              Header", draft-quinn-sfc-nsh-02 (work in progress),
              February 2014.

   [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-sfc-use-case]
              Xu, X., Li, Z., and H. Shah, "Service Function Chaining
              Use Case for SPRING", draft-xu-spring-sfc-use-case-01
              (work in progress), June 2014.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com



Xu, et al.              Expires December 24, 2014               [Page 8]

Internet-Draft             PCE-based SFC Arch                  June 2014


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

   Email: youjianjie@huawei.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/



























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