Network Working Group H. Li Internet-Draft Q. Wu Intended status: Standards Track O. Huang Expires: March 26, 2015 Huawei M. Boucadair C. Jacquenet France Telecom W. Haeffner Vodafone September 22, 2014 Service Function Chaining (SFC) Control Plane Achitecture draft-ww-sfc-control-plane-03 Abstract This document defines the control plane architecture which include control plane components and interface between control plane component and data plane component. This document further describes how Service Functions Chains are structured and how Service Function Chaining path is provisioned and setup. 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 March 26, 2015. 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 Li, et al. Expires March 26, 2015 [Page 1] Internet-Draft SFC CP September 2014 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. Conventions used in this document . . . . . . . . . . . . . . 3 3. Data plane basic assumption . . . . . . . . . . . . . . . . . 3 4. SFC Control Plane: An Overview . . . . . . . . . . . . . . . 4 4.1. SFC Control plane . . . . . . . . . . . . . . . . . . . . 7 4.2. F interface . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. C1 interface . . . . . . . . . . . . . . . . . . . . . . 7 4.4. C2 interface . . . . . . . . . . . . . . . . . . . . . . 8 5. Signaling procedure . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service Topology Building . . . . . . . . . . . . . . . . 8 5.2. Service Function Chain Structuring . . . . . . . . . . . 9 5.3. Service Function Path Determining . . . . . . . . . . . . 9 5.4. Service Function Chaining Path Setup and Policy Table configuration . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. SFC Control Plane Components Deployment Consideration in Mobile Backbone (MBB) Environment . 11 Appendix B. SFC Control Plane Components Deployment Consideration in Fixed Backbone (FBB) Environment . 13 Appendix C. SFC Control Plane Components Deployment Consideration in Data Center(DC) Environment . . . . 14 Appendix D. SFC Control Plane Components Deployment Consideration in Data Center (DC) Environment . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The dynamic enforcement of a service-derived, adequate forwarding policy for packets entering a network that supports advanced Service Functions (SFs) has become a key challenge for operators and service providers. Service Function Chaining (SFC) typically observe, alter or even terminate and re-establish session flows between user equipment and application platforms (Web, Video, VoIP etc.) by invoking, in a given Li, et al. Expires March 26, 2015 [Page 2] Internet-Draft SFC CP September 2014 order, a set of Service Functions [I.D-ietf-sfc-problem-statement]. Service functions involved in a given SFC may include load-balancing, firewalling, intrusion prevention, etc. A given SFC-enabled domain may involve several instances of the same Service Function. Service function instances can be automatically added to or removed from a given SFC. SFs can be co-located or embedded in distinct physical nodes, or virtualized. This document describes SFC control plane architecture and discusses how the Service Function Chains are structured and how Service Function Chaining path is provisioned and setup. 2. Conventions used in this document 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 [RFC2119]. 3. Data plane basic assumption This document defines the control plane architecture while the data plane architecture is defined in [I.D-ietf-sfc-architecture]. The SFC data plane characteristics considered as basic assumptions by the SFC control architecture are summarized below: o Traffic that enters a SFC-enabled domain is classified according to the rules the SFC Control Plane provides to the Classifier. After classification, the traffic is forwarded into the SFC- enabled domain passing a set of Service Functions as defined in the corresponding SFC instructions. SFC-specific forwarding information is used by Service Forwarder Entity (i.e., a node which include service forwarder function (SFF)) to make traffic forwarding decisions and pass the traffic to the next Service Function instance within the chain, through the Service Function Path derived from Control Plane Information and instantiated from the Classifier. o The Service Forwarder Entity forwards packets according to the entries maintained in the SFC Policy rule base. A Service Forwarder Entity can be a virtualized or physical L2/L3 network device that serves Service Functions within a given chain. A Service Forwarder Entity may serve one or more Service Functions (Fig. 1). Li, et al. Expires March 26, 2015 [Page 3] Internet-Draft SFC CP September 2014 o When a Service Forwarder Entity needs to forward a packet to an SFC-unware legacy node, the packet is likely to be forwarded by a SFC proxy to SFC-unaware legacy node. 4. SFC Control Plane: An Overview For the purpose of defining the SFC control plane architecture, the SFC control plane is broken up into five distinct components: Chain Selection Policy Control Chain Selection Policy Control component maintains SFC-related information models (chain structures, classification rules) derived from business or operational models. Chain Management Policy Control This component is responsible for: * Structuring a SFC chain, based upon various inputs that include Service Function information as collected through the management interface (e.g., the outcomes of a negotiation between a customer and a service provider, as documented in [RFC7297], business guidelines, etc.). * Adjusting a chain based on the external policy context or any path change computed by Service Overlay Topology management component. Service Overlay Topology management This is an optional component that is not needed particularly when SFC forwarding is fully distributed. This component is responsible for: * Creating the service topology which consist of Service Function-related information and network topology information. * Helping Chain Mapping and forwarding Control Component determine forwarding path in case the said forwarding path is traffic engineered. Service Function (SF) Management Li, et al. Expires March 26, 2015 [Page 4] Internet-Draft SFC CP September 2014 This component allows for the dynamic discovery of locations of Service Functions and is used to help the SFC control plane to gather Service Function-related information from various Service Functions available within a SFC-enabled domain. SFC Mapping and Forwarding Control This is a component that helps the SFC Control plane to dynamically: * Map SFCs to the specific Service Function path. * Populate forwarding rules on the data plane. Li, et al. Expires March 26, 2015 [Page 5] Internet-Draft SFC CP September 2014 +-------------------------------------------------+ | SFC Control Plane | | +---------------+ +---------------+ | +-------| |Chain Management |Service Overlay| | | | |Policy Control | |Topo Management| | | | +---------------+ +---------------+ | | | +---------------+ +---------------+ | +---------|Chain Selection| | Chain Mapping | +----------+| | | | Policy Control| | and Forwarding| |External SF| | +---------------+ | Control | |Management|| | | +---------------+ +----------+| C1 +------^-----------^-------------^----------------+ +---------------------|F----------|-------------|-------------+ | | +----+ | | | | | | SF | |C2 |C2 | | +----+ | | | | +----V--- --+ | | | | | | SFC | +----+ +-|--+ +----+ | | |Classifier |---->|SFF |----->|SFF |------->|SFF | | | | Node |<----| |<-----| |<-------| | | | +-----------+ +----+ +----+ +----+ | | | | | | | |C2 ------- | | | | | | +-----------+ F | | V +----+ +----+ | SFC Proxy |--> | | | SF | |SF | +-----------+ | | +----+ +----+ | | |F |F | | SFC Data Plane Components V V | | | +-------------------------------------------------------------+ Figure 1: SFC Control Plane Overview There are three interfaces connected to the SFC control plane. C1 Interface: the interface between the SFC control plane and the SFC Classifiers. Classification rules are installed on the SFC Classifier Node(s) via this interface.In addition, this Interface may be used by the control plane to instantiate of traffic- engineered paths that will be used to forward traffic according to SFC information. C2 Interface: the interface between the SFC control plane and the Service Forwarder Function. SFC-based forwarding entries on Service Function nodes are provided by the SFC Control plane via this interface. Li, et al. Expires March 26, 2015 [Page 6] Internet-Draft SFC CP September 2014 F Interface: This interface is used by Service Function to feedback service or application level information of a data flow to the SFC control plane. 4.1. SFC Control plane The SFC control plane is in charge of Service Function chain creation and maintenance, service chain path instantiation (in case of the traffic-engineered SFCs), mapping between SFC and Service Function path, SFC Policy Table creation and configuration, including the sequence of Service Functions in a Service Function chain, Service Function information, SFC paths information. The SFC control plane may be fed with Service Function chain information from the Management application. A SFC service template information may look like: {{MBR>1Mbps, RAT='UMTS', protocol='HTTP', QOS='Gold'},goto'sfc1'} The SFC Control plane also creates classification rules and installs them on the classifier nodes. The SFC control plane also assigns SFC identification and installs SFC Policy Tables in the Service forwarder function. 4.2. F interface Service Functions, e.g., deep packet inspection (DPI) or firewall may need to output some processing results of packets to the control system. This information can be used by the SFC control plane to update the SFC classification and SFC forwarding entries. The F Interface is used to collect such kind of feedback information from the Service Functions or the SF nodes. 4.3. C1 interface This interface is used to install SFC classification rules in Service Classifier nodes. These rules are created by the SFC control Plane. They may be updated by information provided by the Service Function nodes (in case a change of the network topology has occurred, for example). SFC Classifier Node binds incoming traffic to SFCs according to these classification rules. Li, et al. Expires March 26, 2015 [Page 7] Internet-Draft SFC CP September 2014 4.4. C2 interface Service forwarder entity make traffic forwarding decisions according to the entries maintained in their SFC Policy Table. Such Table is populated by the SFC control plane through the C2 interface. Each Service Function has a unique Service Function identifier to identify itself in the SFC forwarding plane. The Service Function locator is typically referred to as a network address. In case the Service Function instance is directly connected to a Service forwarder entity, the forwarding entry may also include the port through which the Service Function instance can be reached. Some proxy function may also use the C2 interface to retrieve the mapping between a Service Function Identifier and a Service Function locator from the SFC control plane. 5. Signaling procedure 5.1. Service Topology Building When a Service Function is instantiated into the network it is necessary to select the locator of the specific instances of Service Functions that will be used, and to construct the service overlay using Service Function's network locator. The service overlay is built on top of the underlying network. The resulting service overlay is meant to facilitate SFC-enabled domain operation, as it may provide a better, up-to-date, network-wise overview of the Service Functions status and usage. A service specific overlay utilized by SFC then results in the creation of the service topology. Service topology information consists of network topology information collected from the underlying network and Service Function-related information (such as Service Function administration information and Service Function capability information) that may be collected from the management interface. For example, Network topology information can be collected from the network using an IGP or BGP-LS [I.D-draft-idr-ls- distribution]. Service Function-related information includes Service Function Identifier, Service Function Locator, Service Function administration information (e.g., available memory, CPU utilization, available storage capacity, etc.) or Service Function capability information (e.g., supported ACL numbers, virtual context number). This information can be retrieved by various means (e.g., registration mechanism that provides binding between Service Function Identifier Li, et al. Expires March 26, 2015 [Page 8] Internet-Draft SFC CP September 2014 and Service Function Locator(s) and allows for the dynamic discovery of locations of Service Functions). Network topology is not required for dynamically structuring service chains, but it may be helpful during service troubleshooting and diagnostics. The creation of the service topology is not conditioned by the creation of the network topology: what is required is the mapping between Service Function-related information and existing network topology information. Additional Service Functions or Service Function instances, for redundancy or load distribution purposes, can be added to or removed from the service topology as required. Means to dynamically discover the location of available Service Function instances may be supported. 5.2. Service Function Chain Structuring The chain management component of the SFC control plane is responsible for the dynamic structuring of Service Function chains (i.e., define an ordered list of Service Function identifiers) that can be supported, as a function of the services that can be delivered, among other information that may include subscriber- specific information. For example, a Service Function chain can be structured as follows: service-chain 100 { 10 url-filter 20 web-cache 30 web-optimizer 40 firewall } In this Service Function chain, each Service Function needs to be assigned with a unique Service Function identifier and can be located using Service Function locators. A Service Function chain should be assigned an SFC Index. A Service Function identifier does not necessarily hint the service offered by that Service Function; its purpose is to uniquely identify a Service Function among those present in a SFC-enabled domain. 5.3. Service Function Path Determining The Chain Mapping and forwarding Control Component of the SFC control plane is a component that is responsible for Service Function path determination based on Service Overlay Topology information maintained in the Service Overlay Topology management component. However, not all SFC deployments may require Service Function path Li, et al. Expires March 26, 2015 [Page 9] Internet-Draft SFC CP September 2014 determination (e.g., SFC forwarding is fully distributed ). Service Function path determination is referred to determine an ordered list of locators of each Service Function that belongs to a Service Function chain. The Service Function path determining may be static or pre-determined using specific Service Function instances, or dynamic - choosing explicit Service Function instances at the time of delivering traffic to the Service Function. When there are multiple instances of a given Service Function that belongs to a given SFC, each of these instances is assigned a unique locator. These multiple instances may actually be invoked within the context of a single chain, or within the context of multiple chains depending on how the said chains are structured. The latter case may lead to multiple SFPs. In some other cases, a Service Function path can pre-determined by SFC mapping and forwarding component for traffic engineering purposes by interacting with Service Overlay Topology management component. However Service Function path doesn't need to be pre- determined. The chain management component responsible for structuring the service chains cannot decide in advance the actual path that will be followed by packets. In addition, the SFC mapping and forwarding component also maintains the mapping between Service Function chains and Service Function paths. When Service Function chain structuring is complete, the SFC control plane will use the SFC forwarding and mapping component to determine the locator of each specific Service Function instance in the chain and return a set of Service Function locators associated with a Service Function chain. 5.4. Service Function Chaining Path Setup and Policy Table configuration Once a SFC is structured, traffic classification rules are derived and provided to the classifier nodes, along with other information maintained in Policy Tables. The policy table is built based on SFC policy and service information(e.g.,subscriber being mapped into a service class related to a SFC) captured by using policy related components, when a Service Function path is determined. The policy table will be populated at each participating node involved in the application of a Service Function chain and used by them to make their forwarding decisions on a typical hop-by-hop basis. Li, et al. Expires March 26, 2015 [Page 10] Internet-Draft SFC CP September 2014 6. Security Considerations The SFC Control and the participating SFC functional elements must be mutually authenticated. Means to protect against an attacker who would install/remove/modify classification rules must be supported. When means to dynamically discover the location of SF instances are in use, they should be designed to avoid illegitimate SFs to belong to the SFC-enabled domain. 7. Acknowledgements The author would like to thank Shibi Huang for providing input and LAC Chidung for his review and comments that helped improve this document. 8. References 8.1. Normative References [I.D-ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", ID draft-ietf-sfc-architecture-01, September 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 8.2. Informative References [I.D-ietf-sfc-problem-statement] Quinn, P., "Network Service Chaining Problem Statement", ID draft-ietf-sfc-problem-statement-10, August 2014. [I.D-wu-pce-traffic-steering-sfc] Wu, Q., Dhody, D., Boucadair, M., Boucadair, C., and J. Tantsura, "PCEP Extensions for traffic steering support in Service Function Chaining", ID draft-wu-pce-traffic- steering-sfc-05, September 2014. Appendix A. SFC Control Plane Components Deployment Consideration in Mobile Backbone (MBB) Environment Li, et al. Expires March 26, 2015 [Page 11] Internet-Draft SFC CP September 2014 +---------------------------------------------------------------+ | SFC Control Plane +----------------------+ | | | +------------+ | | | | | SFC | | | | +----------------|Orchestrator-----------+ | | | | +------------+ | | | | | | SFC Management System| | | | | +----------------------+ | | | | | | | | | | |+------|-------------+ +--------|------------+ | ||+-----|----+ | | +------|---------+ | | |||SFC Policy| | | | SFC Forwarding | | | ||| Control | | |-------| Control -----|----+ ||+-----|----+ | | | +----------------+ | | | || Enhancement in PCRF| | | SFC Controller | | | |+------|-------------+ | | | | | | | | +---------------------+ | | +-------|-------------------------|-----------------------------+ | +-------|-------------------------|------------------------------------+ |+--------------------+ +---------------+ +---------------+ | | ||Enhancement in PCEF | | Enhancement in| | Enhancement in| | | || or TDF | | ToR switch or | | ToR Switch or | | | ||+-----|-------+ | | Router | | Router | | | ||| SFC | | |+----|--+ | |+-------+ | | | ||| Classifier |-----------|| |------------- | | | | | ||| Function | | || SFF1 | | || SFF2 ---------+ | ||+-------------+ | || | | || | | | |+--------------------+ |+---|---+ | |+---|---+ | | | +----|----------+ +----|----------+ | | ------------ -----|------ | | | | | | | | +----+ +---+ +----+ +---+ | | | SF1| |SF2| | SF3| |SF4| | | +----+ +---+ +----+ +---+ | |SFC Data Plane | -----------------------------------------------------------------------+ SFC in MBB In MBB environment, Policy Control component and Chain Management Policy Control component defined in section 4 can be supported using Enhanced PCRF. Service Overlay Topology management defined in section 4 can be supported using SFC Orchestrator. SFC Mapping and Forwarding Control component defined in section 4 can be supported using SFC Controller. Note that 3GPP is considering integrating Li, et al. Expires March 26, 2015 [Page 12] Internet-Draft SFC CP September 2014 Chain Selection Policy Control component and Chain Management Policy Control component using PCRF. Appendix B. SFC Control Plane Components Deployment Consideration in Fixed Backbone (FBB) Environment +---------------------------------------------------------------+ | SFC Control Plane +----------------------+ | | | +------------+ | | | | | SFC | | | | +----------------|Orchestrator-----------+ | | | | +------------+ | | | | | | SFC Management System| | | | | +----------------------+ | | | | | | | | | | |+------|-------------+ +--------|------------+ | ||+-----|----+ | | +------|---------+ | | |||SFC Policy| | | | SFC Forwarding | | | ||| Control | | -|-------| Control -----|----+ ||+-----|----+ | | | +----------------+ | | | || Enhancement in RADIUS | | SFC Controller | | | |+------|-------------+ | | | | | | | | +---------------------+ | | +---------------------------------------------------------------+ | +----------------------------------------------------------------------+ |+--------------------+ +---------------+ +---------------+ | | ||Enhancement in BRAS | | Enhancement in| | Enhancement in| | | || or BNG | | ToR switch or | | ToR Switch or | | | ||+-----|-------+ | | Router | | Router | | | ||| SFC | | |+----|--+ | |+-------+ | | | ||| Classifier |-----------|| |------------- | | | | | ||| Function | | || SFF1 | | || SFF2 ---------+ | ||+-------------+ | || | | || | | | |+--------------------+ |+---|---+ | |+---|---+ | | | +----|----------+ +----|----------+ | | ------------ -----|------ | | | | | | | | +----+ +---+ +----+ +---+ | | | SF1| |SF2| | SF3| |SF4| | | +----+ +---+ +----+ +---+ | |SFC Data Plane | -----------------------------------------------------------------------+ SFC in FBB Li, et al. Expires March 26, 2015 [Page 13] Internet-Draft SFC CP September 2014 In FBB environment, Policy Control component and Chain Management Policy Control component defined in section 4 can be supported using Enhanced RADIUS. Service Overlay Topology management defined in section 4 can be supported using SFC Orchestrator. SFC Mapping and Forwarding Control component defined in section 4 can be supported using SFC Controller. Note that BBF is considering integrating Chain Selection Policy Control component and Chain Management Policy Control component using RADIUS. Appendix C. SFC Control Plane Components Deployment Consideration in Data Center(DC) Environment Li, et al. Expires March 26, 2015 [Page 14] Internet-Draft SFC CP September 2014 +---------------------------------------------------------------+ | SFC Control Plane +----------------------+ | | | +------------+ | | | | | SFC | | | | +----------------|Orchestrator-----------+ | | | | +------------+ | | | | | | SFC Management System| | | | | +----------------------+ | | | | | | | | | | | |Download Classifier +--------|------------+ | | | Rule directly | +------|---------+ | | | | | | SFC Forwarding | | | | | -|-------| Control -----|----+ | | | | +----------------+ | | | | | | | SFC Controller | | | | | | | | | | | | | +---------------------+ | | +-------|-------------------------------------------------------+ | +-------|--------------------------------------------------------------+ |+------|-------------+ +---------------+ +---------------+ | | || Enhancement in DC | | Enhancement in| | Enhancement in| | | || | Gateway | | ToR switch or | | ToR Switch or | | | ||+-----|-------+ | | Router | | Router | | | ||| SFC | | |+----|--+ | |+-------+ | | | ||| Classifier |-----------|| |------------- | | | | | ||| Function | | || SFF1 | | || SFF2 ---------+ | ||+-------------+ | || | | || | | | |+--------------------+ |+---|---+ | |+---|---+ | | | +----|----------+ +----|----------+ | | ------------ -----|------ | | | | | | | | +----+ +---+ +----+ +---+ | | | SF1| |SF2| | SF3| |SF4| | | +----+ +---+ +----+ +---+ | |SFC Data Plane | -----------------------------------------------------------------------+ SFC in DC Environment In DC environment, Policy Control component and Chain Management Policy Control component, Service Overlay Topology management defined in section 4 can be supported using SFC Orchestrator. SFC Mapping and Forwarding Control component defined in section 4 can be supported using SFC Controller. Li, et al. Expires March 26, 2015 [Page 15] Internet-Draft SFC CP September 2014 Appendix D. SFC Control Plane Components Deployment Consideration in Data Center (DC) Environment +---------------------------------------------------------------+ | SFC Control Plane | | +------------------------+ | | | stateful PCE | | | +-------------| +-------+ +-------+ | | | | | |Policy | | TE-DB | |<-------| | | | | +-------+ +-------+ | | | | | +------------------------+ | | | | ---------------|-----| | | | SFC Controller | | | | | | +----------------+ | | | | +---------------------------| Policy Control| | | | | | | +----------------+ | | | | | +------ ------ --+ | | | | | | SFC Forwarding | | | | | | +-------| Control -----|----+ | | | | | +----------------+ | | | | | | | +---------------------+ | | +-------|-----|-------------------------------------------------+ | +-------|-----|--------------------------------------------------------+ |+------|-----|-------+ +---------------+ +---------------+ | | || Enhancement in DC | | Enhancement in| | Enhancement in| | | || | Gateway | | ToR switch or | | ToR Switch or | | | ||+-----|-------+ | | Router | | Router | | | ||| SFC | | |+----|--+ | |+-------+ | | | ||| Classifier |-----------|| |------------- | | | | | ||| Function | | || SFF1 | | || SFF2 ---------+ | ||+-------------+ | || | | || | | | |+--------------------+ |+---|---+ | |+---|---+ | | | +----|----------+ +----|----------+ | | ------------ -----|------ | | | | | | | | +----+ +---+ +----+ +---+ | | | SF1| |SF2| | SF3| |SF4| | | +----+ +---+ +----+ +---+ | |SFC Data Plane | -----------------------------------------------------------------------+ SFC in DC Environment Alternatively, In DC environment, Policy Control component and Chain Management Policy Control component, Service Overlay Topology management defined in section 4 can be supported, SFC Mapping and Forwarding Control component defined in section 4 can be supported together using SFC Controller. In addtion, SFC Controler operates a Li, et al. Expires March 26, 2015 [Page 16] Internet-Draft SFC CP September 2014 stateful PCE and its instantiation mechanism to compute and instantiate Service Function Paths (SFP). The PCE maybe co-located with the SFC Control plane component or an external entity (e.g., [I.D-wu-pce-traffic-steering-sfc]). Authors' Addresses Hongyu Li Huawei Huawei Industrial Base,Bantian,Longgang Shenzhen China Email: hongyu.li@huawei.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Yong(Oliver) Huang Huawei Huawei Industrial Base,Bantian,Longgang Shenzhen China Email: oliver.huang@huawei.com Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Li, et al. Expires March 26, 2015 [Page 17] Internet-Draft SFC CP September 2014 Christian Jacquenet France Telecom Rennes 35000 France Email: christian.jacquenet@orange.com Walter Haeffner Vodafone D2 GmbH Ferdinand-Braun-Platz 1 Duesseldorf 40549 DE Email: walter.haeffner@vodafone.com Li, et al. Expires March 26, 2015 [Page 18]