Usecase of SFC for VCPE in the transport network

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

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 .

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.

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.

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

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.

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