Internet Engineering Task Force Q. Fu, Ed. Internet-Draft China Mobile Intended status: Informational J. Halpern Expires: January 6, 2016 Ericsson H. Deng China Mobile July 5, 2015 The topology of service function chaining draft-fu-sfc-topology-00 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 January 6, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Fu, et al. Expires January 6, 2016 [Page 1] Internet-Draft Topology for SFC July 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. Advantage of VCPE . . . . . . . . . . . . . . . . . . . . . . 6 6. Topology of VCPE Deployment . . . . . . . . . . . . . . . . . 6 7. Details of VCPE deployment in the MPLS-TP Network . . . . . . 8 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 10 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 January 6, 2016 [Page 2] Internet-Draft Topology for SFC July 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 January 6, 2016 [Page 3] Internet-Draft Topology for SFC July 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 January 6, 2016 [Page 4] Internet-Draft Topology for SFC July 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 January 6, 2016 [Page 5] Internet-Draft Topology for SFC July 2015 5. 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. 6. 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, Fu, et al. Expires January 6, 2016 [Page 6] Internet-Draft Topology for SFC July 2015 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. +-----------------------+ .....+ 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 Fu, et al. Expires January 6, 2016 [Page 7] Internet-Draft Topology for SFC July 2015 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. 7. 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. Fu, et al. Expires January 6, 2016 [Page 8] Internet-Draft Topology for SFC July 2015 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. 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. 8. 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. Fu, et al. Expires January 6, 2016 [Page 9] Internet-Draft Topology for SFC July 2015 In the meantime, traffic flows are directed with the help of the SDN- controller according to the customers' specification. 9. Informative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-09 (work in progress), June 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, March 1997. 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 January 6, 2016 [Page 10]