[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                               Q. Fu, Ed.
Internet-Draft                                              China Mobile
Intended status: Informational                                J. Halpern
Expires: April 16, 2016                                         Ericsson
                                                                 H. Deng
                                                            China Mobile
                                                        October 14, 2015


               The topology of service function chaining
                        draft-fu-sfc-topology-01

Abstract

   This document proposes a deployment topology of Service Function
   Chaining(SFC).  The topology is in accordance with the SFC
   architecture in [I-D.ietf-sfc-architecture].  Currently, such
   architecture only includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs, without any instruction for the field deployment.
   It is still difficult to map from the architecture to a real
   deployment of SFC.  In this document, we propose this topology which
   will give instructions for the field deployments.  We further propose
   a VCPE usecase of SFC in the transport network, which explains the
   details of the deployment topology.

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 April 16, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Fu, et al.               Expires April 16, 2016                 [Page 1]


Internet-Draft              Topology for SFC                October 2015


   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.  Topology of SFC in current network  . . . . . . . . . . . . .   4
   4.  vCPE usecase of SFC . . . . . . . . . . . . . . . . . . . . .   5
   5.  Topology of VCPE Deployment . . . . . . . . . . . . . . . . .   6
   6.  Details of VCPE deployment in the MPLS-TP Network . . . . . .   8
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The definition and instantiation of an ordered set of service
   functions and subsequent 'steering' of traffic through them is termed
   as Service Function Chaining (SFC).  The definition of SFC can be
   found in [I-D.ietf-sfc-problem-statement].  In
   [I-D.ietf-sfc-architecture], an architecture for SFC is proposed,
   which includes the basic architectural concepts, principles, and
   components used in the construction of SFCs.  The high level logical
   architecture of SFC is shown in Figure.1, and a detailed architecture
   is shown in Figure.2.  The definition and functions for the
   components in these figures can be found in
   [I-D.ietf-sfc-architecture].

       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
       .  +--------------+                  +------------------~~~
       .  |   Service    |       SFC        |  Service  +---+   +---+
       .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
    +---->|   Function   |+---------------->|   Path    +---+   +---+
       .  +--------------+                  +------------------~~~
       . SFC-enabled Domain
       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


             Figure 1: High Level Logical Architecture for SFC




Fu, et al.               Expires April 16, 2016                 [Page 2]


Internet-Draft              Topology for SFC                October 2015


          +----------------+                        +----------------+
          |   SFC-aware    |                        |  SFC-unaware   |
          |Service Function|                        |Service Function|
          +-------+--------+                        +-------+--------+
                  |                                         |
            SFC Encapsulation                       No SFC Encapsulation
                  |                  SFC                    |
     +---------+  +----------------+ Encapsulation     +---------+
     |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
     |    SF   | ... ----------+  \  \   /             +---------+
     +---------+                \  \  \ /
                               +-------+--------+
                               |   SF Forwarder |
                               |      (SFF)     |
                               +-------+--------+
                                       |
                               SFC Encapsulation
                                       |
                           ... SFC-enabled Domain ...
                                       |
                           Network Overlay Transport
                                       |
                                   _,....._
                                ,-'        `-.
                               /              `.
                              |     Network    |
                              `.              /
                                `.__     __,-'
                                    `''''


                  Figure 2: Detailed Architecture for SFC

   However, the architecture proposed in [I-D.ietf-sfc-architecture]
   provides little instructions for field deployment of SFC.  The
   definitons for each component are abstract and are difficult to be
   mapped to current network.  Therefore, in this document, a topology
   of field deployment of SFC is proposed.  We further propose a usecase
   of vCPE using SFC to fully explain the topology.

2.  Terminology

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






Fu, et al.               Expires April 16, 2016                 [Page 3]


Internet-Draft              Topology for SFC                October 2015


3.  Topology of SFC in current network

   Figure.3 shows the topology of deployment of SFC in the current
   network.  In general, there are two choices of the deployment of the
   SFs.  One is to locate in the data centers of Operators.  And the
   other is to co-locate with the Openrator Gateways(GWs).  Such GWs can
   be in the aggregate networks or the core networks.  These two
   deployments both have their advantages.  For the first one, the
   traffic do not need to travel to the DC and back.  For the second
   one, it will be easier for us to manage and maintain these SFC
   devices.

   The Operator GWs should act as SCF(Service Classification Function)
   and SFF (Service function Forwarder) in the SFC architecture.  This
   SFF should be responsible for adding SFC-header to the packets.
   Multiple SFFs can be deployed after the GW in large scale use cases,
   so as to avoid large volume of traffic returning to the GW
   continiously.

   The deployment topology of colocating the SCF and SFF will simplify
   the classification and forwarding.  SFF can add the SFC header to the
   traffic flow directly according to the SCF result, and can support
   re-classification easily.  In the meantime, in some usecases, the SCF
   can act as classifier of traffic flows so as to classify the traffic
   that need to go through the SFC region and the others that do not
   need.  In the following VCPE usecase, we can show the colocation of
   the GW with the SCF and the SFF can greatly simplify the network
   deployment.  However, such topology will complicate the Operator GW.
   There are other deployments that the SCF and/or the SFF are located
   outside the GW, in which case interaction and interface between the
   GW, the SCF, and the SFF is required.




















Fu, et al.               Expires April 16, 2016                 [Page 4]


Internet-Draft              Topology for SFC                October 2015


                                           +---------------+
                                           |SFC Unaware SF3|
                                           +------+--------+
                                                  |
                                                  |
                   +-----+      +-----+      +----+----+
                   | SF1 |      | SF2 |      |SFC Proxy|
                   +--+--+      +--+--+      +--+------+
                      |            |            |
                      +------+     |      +-----+
                             |     |      |
                          +--+-+ +-+--+ +-+--+
                          |SFF1| |SFF2| |SFF3|
                          +--+-+ +-+--+ +-+--+
                             |     |      |
                           +-+-----+------+--+
                           |GW               |
      +------+             | +-----+ +-----+ |           +----------+
      | User +-------------+-+ SCF +-+ SFF +-+-----------+ Internet |
      +------+             | +-----+ +-----+ |           +----------+
                           +-----------------+

             Figure 3: Topology for SFC in the Mobile Networks

4.  vCPE usecase of SFC

   In this document, we also propose a usecase of Service Function
   Chaining (SFC) to realize virtual CPE in the Transport Network.  Such
   VCPE would provide value-added services, including L4-L7 network
   functions to the traditional transport network customers.  In order
   to flexibly control the traffic flow, we also introduce SDN-
   controller (Software Define Network Controller) into the transport
   network.  The SDN-controller is responsible for directing the traffic
   of certain enterprise customer, who has paid for the VCPE services,
   to the VCPE servers.

   The concept of VCPE is to shift most of the networking and service
   functionalities from the customer side to the network side.  In this
   way, the customer side's equipment, that is the CPE, can be
   simplified.  The VCPE refers to one or a set of equipments at the
   network side to execute the networking and service functionalities
   used to be executed at the CPE.  In such architecture, the CPE can be
   a simple L2 switch, which is only responsible for forwarding packets
   to a certain next hop.  The VCPE can be realized by a SFC in the
   physical network or the virtual network, in which the traffic of each
   customer is directed to one or several Service Founctions (SF)
   specified by the customer.




Fu, et al.               Expires April 16, 2016                 [Page 5]


Internet-Draft              Topology for SFC                October 2015


5.  Topology of VCPE Deployment

   Following the topology given in the previous section, we will propose
   a usecase of VCPE deployment in the current Transport network.  The
   traditional transport network uses static allocation mechanism in
   general.  In order to provide network connection between different
   locations for the enterprise customers, traditional transport network
   should allocate dedicated lines between each pair of the locations.
   Such architecture is not suitable when the enterprise customers
   require LAN access, and moreover, L3-L7 functions among different
   locations.  Therefore, we introduce Virtual Customer Premise
   Equipment (VCPE) into the Transport network.  By utilizing SFC, the
   VCPE can provide value-added services, such as firewall (FW), NAT,
   and etc., to the traditional transport network customers.  With the
   emergance of the NFV technologies, these services can be one or a set
   of VNFs on the VCPE servers.  Such architecture provides an agile
   mechanism for operators to launch value-added services for the
   transport network.

   Figure 4 shows the topology of deployment of the usecase for VCPE in
   the transport network.  The solid lines indicate data traffic flows,
   while the dash lines indicate control traffic flows.  In this
   architecture, the CPEs are located at different branches of the
   enterprise customer, and act as L2 forwarding switches.  The VCPE is
   located at the DC, or co-located with the aggregate GW.


























Fu, et al.               Expires April 16, 2016                 [Page 6]


Internet-Draft              Topology for SFC                October 2015


                     +-----------------------+
                .....+    SDN-Controller     +............
                :    +----+------------------+           :
                :         :                              :
                :         : +------------------------+   :
                :         : | VCPE                   |   :
                :         : | +---+   +---+   +---+  |   :
                :         : | |SF1|   |SF2|   |SF3|  |   :
                :         : | +-+-+   +-+-+   +-+-+  |   :
                :         : |   |       |       |    |   :
                :         : | +-+--+  +-+--+  +-+--+ |   :
                :         : | |SFF1|  |SFF2|  |SFF3| |   :
                :         : + +-+--+  +-+--+  +-+--+ |   :
                :         : +---+-------+-------+----+   :
                :         :     +---+   |   +---+        :
                :         :         |   |   |            :
            +---+------+  :      +--+---+---+-+     +----+-----+
            | +-+---+  |  .......++---+  +---+|     |  +-+---+ |
            | | CPE +--+---------++SCF+--+SFF++-----+--+ CPE | |
            | +-----+  |         |+---+  +---+|     |  +-----+ |
            |Enterprise|         |  Aggregate |     |Enterprise|
            |  Branch  |         | Network GW |     |  Branch  |
            +----------+         +------------+     +----------+


     Figure 4: Topology of Deployment of VCPE in the transport network

   All of the CPEs and the Aggregate Network GW can be controlled by the
   SDN-controller.  When the enterprise customer selects a set of the
   value-added services, the SDN-controller will inform the CPE of the
   customer to direct the traffic flow to a certain Aggregate Network GW
   connected to the VCPE.  The GW acts as SCF and SFF in the SFC region.
   It is responsible for classifing the traffic flow of the customers
   and adding SFC header.  And then it will act as SFF and forward the
   traffic tothe other SFFs in the VCPE based on the SFP (Service
   Function Path).  When finishing the SFP, the GW will remove the SFC
   header and forward the traffic flow to the destination CPE.  All
   these traffic flows are directed under the control of the SDN
   controller.

   There could be another architecture without the SDN controller, in
   which case, the SCF is used to classify which flow shoud go through
   the VCPE and enter the SFC region, and which flow should follow the
   traditional transport network routine and should be forwarded
   directly to the destination CPE.






Fu, et al.               Expires April 16, 2016                 [Page 7]


Internet-Draft              Topology for SFC                October 2015


6.  Details of VCPE deployment in the MPLS-TP Network

   Since MPLS-TP is widely used in the current transport network, we are
   going to propose this usecase based on the MPLS-TP transport network.
   The traditional transport network is only responsible for providing
   MPLS-TP connection between each two destinations.  No L3-L7 services
   can be provided based on it.  By introducing VCPE at the aggregate/
   core network, and using SFC, multiple L3-L7 services can be provided
   using the widely deployed MPLS-TP network.

   In the MPLS-TP packet, the PW lable, adhere to the packet by the CPE
   device at the customer side of the PTN network, can be used to
   classify service type.  Such information can be used for Service
   Clasification Function.  Extra label can also be added into the PW
   lable to indicate user/network specifics.  Therefore, the SFC can do
   the service clasification mapping based on the PW lable in the MPLS-
   TP packets.  In the meantime, MPLS-TP packets should also be
   transfered to L3 packets before entering the Service Function Region,
   and should be re-encapsulated to the MPLS-TP packets after leaving
   the Service Function Region.  According to the deployment topology,
   the aggregate GW is acting as both ingress and egress GW of the SFC
   region.  In this case, the aggregate GW should record the mapping
   relationship of the IP address and PW/LSP label of each packet, and
   should make sure pf adding the exact same MPLS-TP header to the
   packets when they finish the SFP and exit the SFC region, so that the
   packet can continue its path in the transport network using the MPLS-
   TP header.  Therefore, in the MPLT-TP network, the aggregate GW
   shoule follow the following steps when an MPLS-TP packet arrives at
   the aggregate network.

   1) Mapping PW lable to a certain Service Founction Path

   2) Recording mapping between IP address and PW/LSP lable, so as to
   re-encapsulate the L3 packets with a certain IP address.

   3) Transfering MPLS-TP packets to L3 packets by taking off the MPLS-
   TP header.

   4) Adding SFC header into the L3 packets.

   5) Acting as the SFF by forwarding the L3 packets according to the
   SFP.

   6) Taking off the SFC header when the SFP finishes.

   7) Transfering the L3 packets to MPLS-TP packets by adding
   corresponding MPLS-TP header according to the recorded mapping.




Fu, et al.               Expires April 16, 2016                 [Page 8]


Internet-Draft              Topology for SFC                October 2015


   8) Forwarding the MPLS-TP Packets to the destination.

   For step 2, the following table should be maintained by the GW, in
   which SFP indicates Service Function Path.

                  IP address | LSP label |PW label | SFP
                  -----------+-----------+---------+------
                      IP1    |    LSP1   |    PW1  | SFP1
                      IP2    |    LSP2   |    PW2  | SFP2
                      IP3    |    LSP3   |    PW3  | SFP3


                     Figure 5: Mapping table in the GW

   This proposed approach can reuse the existing MPLS-TP network, so
   that operators can use the same transport network platform to support
   both the traditional private line service and value added NFV
   services.  From the proposed steps, we can see that colocate the SCF
   and the SFF with the GW can greatly simplify the whole deployment,
   since we don't need to coordinate the mapping info between the SCF
   and the GW and the SFF.

7.  Conclusion

   In this document, a topology of SFC is proposed.  Such topology
   follows the definition and components of the SFC architecture in
   [I-D.ietf-sfc-architecture].  Comparing with the abstract
   architecture proposed, such topology provides deployable guidelines
   for SFC.

   A usecase of VCPE using SFC in the MPLS-TP transport network is
   further proposed to detailed the deployment topology.  Such usecase
   provides an agile mechanism for launching new value-added services in
   the transport network.  SFC is used in the VCPE to chain different
   SFs for different flows according to the customers' specification.
   In the meantime, traffic flows are directed with the help of the SDN-
   controller according to the customers' specification.

8.  Informative References

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-11 (work
              in progress), July 2015.







Fu, et al.               Expires April 16, 2016                 [Page 9]


Internet-Draft              Topology for SFC                October 2015


   [I-D.ietf-sfc-problem-statement]
              Quinn, P. and T. Nadeau, "Service Function Chaining
              Problem Statement", draft-ietf-sfc-problem-statement-13
              (work in progress), February 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Qiao Fu (editor)
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   China

   Email: fuqiao1@outlook.com


   Joel. Halpern
   Ericsson

   Email: jmh@joelhalpern.com


   Hui Deng
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   China

   Email: denghui@chinamobile.com

















Fu, et al.               Expires April 16, 2016                [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/