Internet DRAFT - draft-fu-sfc-transport-network-usecase

draft-fu-sfc-transport-network-usecase







Internet Engineering Task Force                               Q. Fu, Ed.
Internet-Draft                                                   H. Deng
Intended status: Informational                                  W. Cheng
Expires: September 6, 2015                                  China Mobile
                                                           March 5, 2015


            Usecase of SFC for VCPE in the transport network
               draft-fu-sfc-transport-network-usecase-00

Abstract

   This document proposes a usecase of Service Function Chaining(SFC) to
   realize Virtual Customer Premises Equipment (VCPE) in the transport
   network.  In this document, the concept of VCPE is introduced into
   the transport network to provide value-added services for the
   enterprise customers.  The SFC is used to realize the VCPE and chains
   different services according to the requirement of the customers.
   Such architecture can provide value-added and self-defined services
   to the customers.  In the meantime, SDN controller is utilized in the
   usecase to direct certain traffic flows to the VCPE.  This usecase
   provides a practical mechanism to offer value-added and self-defined
   services in the transport network without complicating the CPE
   devices or increase OPEX and CAPEX cost.

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 September 6, 2015.

Copyright Notice

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





Fu, et al.              Expires September 6, 2015               [Page 1]

Internet-Draft      SFC usecase in transport network          March 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.  Advantage of VCPE . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Usecase in Current Transport Network  . . . . . . . . . . . .   5
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This document proposes a usecase of Service Function Chaining (SFC)
   to realize virtual CPE in the 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.
   In this draft, we will introduce Virtual Customer Premise Equipment
   (VCPE) into the transport network.  By utilizing SFC, the VCPE can
   provide value-added services, such as virtual firewall (vFW), virtual
   NAT (vNAT), and etc., 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



Fu, et al.              Expires September 6, 2015               [Page 2]

Internet-Draft      SFC usecase in transport network          March 2015


   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.

   In this document, we will talk about the usecases of VCPE using SFC
   in the transport network for enterprise customers.

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

3.  Advantage of VCPE

   The benefit of introduting VCPE into the transport network can be
   concluded as follows:

   1) It will avoid complicating the CPE devices when providing value-
   added L3-L7 services to the customers.  Traditionally, CPEs at the
   enterprise customer side are simple L2 devices in the transport
   network.  In order to meet the requirements for value-added L3-L7
   services from the customers, the CPEs should be redesigned to become
   L3 or even more complicated devices.  Such devices will result in an
   increase of manufacture and maintenance cost, and will also request
   addtional efforts for frequent update to meet the constantly
   increased requirements of the customers.  Nevertheless, by utilizing
   the VCPE achitecture, CPE can remain to be a simple L2 device, which
   is only responsible for L2 forwarding.  In this way, the manufacture
   and maintenance cost of the complicated CPEs can be saved.  In the
   meantime, frequent update of these CPEs is not necessary, which will
   greatly decrease both CAPEX and OPEX of the network operators.

   2) It will greatly speed up the service launching period.  Since most
   of the complicated functions are located at the VCPE in the network
   side, operators have more power over services.  Benefitting from the
   recent NFV (Network Function Virtualization) and cloud technologies,
   VCPE can be accomplished using SFC in the virtual network, where
   different services can act as different VNFs (Virtual Network
   Functions).  Operators only need to add new VNFs on the VCPE side to
   launch new services to the customers.  In this way, Operators can
   provide a variety of services through the transport network.

   3) It will provide user-define-network experience.  By introducing
   SFC concept into the VCPE, users can define his own service order and
   sequence.  Therefore, enterprise customers can enjoy the self-defined
   services over the public transport network.



Fu, et al.              Expires September 6, 2015               [Page 3]

Internet-Draft      SFC usecase in transport network          March 2015


4.  Architecture

   Figure 1 shows the architecture of the SFC 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 core network.

   All of the CPEs and the switches 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 switch connected to
   the VCPE.  And then this swich will forward the traffic to the VCPE
   for further operations.  After operations, the switch will forward
   the traffic to the destination CPE.  All these traffic flows are
   directed under the control of the SDN controller.

   In this architecture, the switch should be capable of bridging the L2
   packets to the L3 packets.  Such switch can be realized by updating
   some existing L3 transport switch.

   The VCPE is one or a set of devices following the SFC architecture,
   in which the Service Classification Function (SCF) is responsible for
   classifing traffic from different customer/network/service.  The SCF
   is controlled by the SDN-controller.  When a packet arrives, the SCF
   will ask the controller which Service Founction Path (SFP) this flow
   should follow, and put corresponding SFC encapsulation into the
   packet.  The packet then goes into the service founction region, and
   will be directed to different Service Founctions (SF) based on the
   encapsulation.  In the following architecture, the switch in front of
   the VCPE can also act as the SCF to classify packet flows.  Following
   the SFC architecture, VCPE can be realized by physical devices or
   virtual network functions as well.

















Fu, et al.              Expires September 6, 2015               [Page 4]

Internet-Draft      SFC usecase in transport network          March 2015


                         +-----------------------+
         ................+     SDN-Controller    +................
         :   :           +--+--------------------+           :   :
         :   :              :                                :   :
         :   :              :                                :   :
         :   :              :                                :   :
         :   :     +--------+--------------------------+     :   :
         :   :     | VCPE   :         +--------------+ |     :   :
         :   :     |        :         |Service       | |     :   :
         :   :     | +------+-------+ |Function Path | |     :   :
         :   :     | |   Service    | | +---+   +---+| |     :   :
         :   : +---+ +Classification+-+ |sf1|...|sf2|+ +---+ :   :
         :   : |   | |   Function   | | +---+   +---+| |   | :   :
         :   : |   | +--------------+ +--------------+ |   | :   :
         :   : |   +-----------------------------------+   | :   :
         : +-+-+--+                                     +--+-+-+ :
         : |Switch|                                     |Switch| :
         : +-+----+                                     +----+-+ :
         :   |Transport                             Transport|   :
         :   | Network                               Network |   :
         :   |                                               |   :
      +--+---+---+                                       +---+---+--+
      | ++---++  |                                       |  ++---++ |
      | | CPE |  |                                       |  | CPE | |
      | +-----+  |                                       |  +-----+ |
      |Enterprise|                                       |Enterprise|
      |  Branch  |                                       |  Branch  |
      +----------+                                       +----------+

     Figure 1: Architecture for SFC usecase for VCPE in the transport
                                  network

5.  Usecase in Current Transport Network

   Based on the above architecture, some value-added functions and
   services can be launched for the enterprise users using the transport
   network.  Examples may include VPN, FW, NAT and etc.. By utilizing
   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.

   Taking consideration that MPLS-TP is widely used in current transport
   network, some extention for SFC to support MPLS-TP should be
   considered.

   In the MPLS-TP packet, the PW lable can be used to classify service
   type.  Such information can be used for Service Founction
   Clasification.  Extra label can also be added into the PW lable to



Fu, et al.              Expires September 6, 2015               [Page 5]

Internet-Draft      SFC usecase in transport network          March 2015


   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, L2 packets should also be bridged to L3
   packets before entering the Service Function Region, and should be
   re-encapsulated to the L2 packets after leaving the Service Function
   Region.

   In such case, the Service Founction Classifier (SFC) should have the
   following capabilities:

   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) Bridging L2 packets to L3 packets by taking off the MPLS-TP
   header.

   Therefore, the following table should be maintained by the SFC, 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 2: Table in SFC

   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.

6.  Conclusion

   In this document, a usecase of utilizing SFC in the transport network
   is proposed.  Such usecase provides an agile mechanism for launching
   new value-added services in the transport network.  In this document,
   the concept of VCPE is introduced into the transport network to
   provide an easy way to deploy these value-added services.  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.

   The usecase proposed has the following advantages:



Fu, et al.              Expires September 6, 2015               [Page 6]

Internet-Draft      SFC usecase in transport network          March 2015


   1) It provides a practical way to launch value-added services, such
   as NAT, VPN, FW, and etc., in the traditional transport network
   without complicating the existing CPE devices.

   2) Operators can use the solution in this usecase to provide
   traditional private line service and value added NFV services using
   the same transport network platform.

   2) It provides more capabilities to the customers to define his own
   network.

   3) The SDN architecture utilized in this usecase provides flexibility
   and intelligence to the traditional transport network.

7.  Informative References

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

Authors' Addresses

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

   Email: fuqiao1@outlook.com


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

   Email: denghui@chinamobile.com


   Weiqiang Cheng
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   China

   Email: Chengweiqiang@chinamobile.com





Fu, et al.              Expires September 6, 2015               [Page 7]