Network Working Group W. Liu, Ed. Internet-Draft H. Li Intended status: Informational O. Huang Expires: March 21, 2015 Huawei Technologies M. Boucadair, Ed. France Telecom N. Leymann Deutsche Telekom AG Q. Fu China Mobile Q. Sun China Telecom C. Pham Telstra Corporation C. Huang Carleton University J. Zhu Huawei Technologies P. He Ciena Corp September 17, 2014 Service Function Chaining (SFC) General Use Cases draft-liu-sfc-use-cases-08 Abstract The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context and other deployment-specific considerations. Having a single use case document eases the effort of deriving requirements that are to be met by SFC solution(s). Moreover, it allows to identify commonalities between the various use cases that are of interest. This document presents a set of general use cases of Service Function Chaining (SFC). 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 Liu, et al. Expires March 21, 2015 [Page 1] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 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 21, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Service Function Chaining Use Cases . . . . . . . . . . . . . 5 3.1. Service Function Chain in Fixed Broadband Networks . . . 5 3.2. Service Function Chain in Mobile Networks: Brief Overview 6 3.3. Common Service Chain Network: A Convergence Tool . . . . 7 3.4. Distributed Service Function Chain . . . . . . . . . . . 8 3.5. Service Function Chain in Data Center . . . . . . . . . . 9 3.6. Service Function Chain in Cloud CPE . . . . . . . . . . . 9 4. Abstraction of SFC in Different Deployment Scenarios . . . . 10 4.1. Per-service characteristic SFC . . . . . . . . . . . . . 11 4.2. Per-user/subscription requirement SFC . . . . . . . . . . 12 4.3. TE-Oriented SFC . . . . . . . . . . . . . . . . . . . . . 12 4.4. SFC for Bi-directional Flow . . . . . . . . . . . . . . . 12 4.5. SFC over Multiple Underlay Networks . . . . . . . . . . . 13 4.6. SFC over Service Path Forking . . . . . . . . . . . . . . 14 4.7. Recursive SFC . . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Liu, et al. Expires March 21, 2015 [Page 2] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 1. Introduction The delivery of Value-Added Services (VAS) relies on the invocation of various Service Functions (SFs). Typically, the traffic is forwarded through a set of Network Elements embedding Service Functions, e.g.: a. Direct a portion of the traffic to a Network Element for monitoring and charging purposes. b. Before sending traffic to DC servers, steer the traffic to cross a load balancer to distribute the traffic load among several links, Network Elements, etc. c. Mobile network operators split mobile broadband traffic and steer them along an offloading path. d. Use a firewall to filter the traffic for IDS (Intrusion Detection System)/IPS (Intrusion Protection System). e. Use a security gateway to encrypt/decrypt the traffic. SSL offloading function can also be enabled. f. If the traffic has to traverse different networks supporting distinct address families, for example IPv4/IPv6, direct the traffic to a CGN (Carrier Grade NAT, [RFC6888][RFC6674]) or NAT64 [RFC6146]. g. Some internal service platforms rely on implicit service identification. Dedicated Service Functions are enabled to enrich packets (e.g., HTTP header enrichment) with the identity of the subscriber or the UE (User Equipment). h. Operators offer VAS on a per subscription basis. It is desirable to steer traffic only from the subscribers, who have subscribed to VAS, to the relevant service platforms. Having a single use case document eases the effort of deriving requirements that are to be met by SFC solution(s). Moreover, it allows to identify commonalities between the various use cases that are of interest. This document describes some use cases of Service Function Chaining (SFC). It is not the purpose of this document to be exhaustive, but instead, we try to draw the set of deployments context that are likely to see SFC solutions deployed. For most of the use cases presented in this document: o Instantiated SFC are driven by business and engineering needs. Liu, et al. Expires March 21, 2015 [Page 3] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 o The amount of instantiated SFCs can vary in time, service engineering objectives and service engineering choices. o The amount of instantiated SFCs are policy-driven and are local to each administrative entity. o The technical characterization of each Service Function is not frozen in time. A Service Function can be upgraded to support new features or disable an existing feature, etc. o Some stateful SFs (e.g., NAT or firewall) may need to treat both outgoing and incoming packets. The design of SF Maps must take into account such constraints, otherwise, the service may be disturbed. The set of SFs that need to be invoked for both direction is up to the responsibility of each administrative entity operating an SFC-enabled domain. o For subscription-based traffic steering, subscriber-awareness capability is required. A UE is allocated a dynamic IPv4 address and/or IPv6 prefix when attaching to a network. This IPv4 address and/or IPv6 prefix can change from time to time. The requirement is to be able to correlate an IPv4 address and/or IPv6 prefix to a subscriber identity from that will be used to trigger the invocation of some Service Functions. o Some Service Functions may be in the same subnet; while others may not. Service Functions are deployed directly on physical hardware, as one or more Virtual Machines, or any combination thereof. 2. Terminology This document makes use of the terms defined in [I-D.ietf-sfc-architecture]. Service Flow: packets/frames with specific service characteristics (e.g., packets matching a specific tuple of fields in the packet header and/or data) or determined by some service-inferred policies (such as access port and etc.). Gi interface: 3GPP defines the Gi interface as the reference point between the GGSN (Gateway GPRS Support Node) and an external PDN (Packet Domain Network). This interface reference point is called SGi in 4G networks (i.e., between the PDN Gateway (PGW) and an external PDN)[RFC6459]. Liu, et al. Expires March 21, 2015 [Page 4] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 3. Service Function Chaining Use Cases Service Function Chains can be deployed in a diversity of scenarios such as broadband networks, mobile networks, and DC center. This section describes a set of scenarios for Service Function Chaining deployment. Please note that for each SFC there is a corresponding symmetrical reverse chain, so we added bidirectional links to each SFC use case figure below. For those links that do not have a directional mark, they are bidirectional by default. 3.1. Service Function Chain in Fixed Broadband Networks In fixed broadband networks, users may be accessed into the network via different technologies, which typically includes DSL, Ethernet and PON. Whatever the access technology is, the architecture for access and metro network is similarly comprised of Access Nodes (ANs) and Broadband Network Gateways (BNGs), where the AN is usually a device providing access to network for customers with variant access technologies and the BNG is the first IP node and providing subscriber authorization, authentication and accounting. ------ // \\ +--------+ +------+ +---+ || || |Customer|---|Access|----|BNG|-----------------------| Internet | |Network | |Node | +---+ ^ ^ || || +--------+ +------+ | | \\ // V ----- v ------ /// \\\ || Service || | Chain | || Network || \\\ /// ----- Service Function Chain in Fixed Broadband Networks Figure 1: An example of Service Function Chain in Broadband Networks Figure 1 illustrates a fixed broadband network with Service Chaining. Service Chain Network is deployed behind BNG and before Internet. The Service Function Chain in Figure 1 may include several Service Functions to perform services such as DPI, NAT44, DS-Lite, NPTv6, Parental control, Firewall, load balancer, Cache, etc. The Broadband Forum (BBF) is developing a study document (SD-326) about Flexible Service Chaining, whose scope includes identifying and Liu, et al. Expires March 21, 2015 [Page 5] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 documenting use cases relevant to fixed broadband networks. Though SD-326 is an internal project within BBF, the content related to use cases has been communicated to IETF per the following Liaison Statement: Broadband Forum Work on Flexible Service Chaining (SD-326) (http://datatracker.ietf.org/liaison/1304/). As BBF is the leading organization on fixed broadband network architectures, this liaison will serve as reference for service chaining use cases applicable in such fixed broadband context. Future liaison statements from BBF may provide additional use cases, and will be referenced here as appropriate. 3.2. Service Function Chain in Mobile Networks: Brief Overview 3GPP defines the Gi interface as the reference point between the GGSN (Gateway GPRS Support Node) and an external PDN (Packet Domain Network) [RFC6459]. This interface reference point is called SGi in 4G networks (i.e., between the PDN Gateway (PGW) and an external PDN) [RFC6459]. Note, there is no standard specification of such reference points (i.e., Gi and SGi) in terms of functions to be located in that segment. Note: The use cases do not include 3GPP release details. For more information on the 3GPP releases detail, the reader may refer to Section 6.2 of [RFC6459]. Traffic is directed to/from Internet traversing one or more Service Functions. Note, these Service Functions are called "enablers" by some operators. One example of enabler function is a HTTP Header Enrichment Function. There are also other VAS function such as Parental Control or network-based Firewall. Subscribers can opt-in and opt-out to these services anytime using a self-served portal or by calling the Operator's customer service. In light of current deployments, plenty of Service Functions are enabled in the Gi Interface (e.g., DPI, billing and charging, TCP optimization, web optimization, video optimization, header enrichment, etc.). Some of these Service Functions are co-located on the same device while others are enabled in standalone boxes. In order to fulfill new business needs, especially to offer innovative added-value services, the number of enabled Service Functions in the Gi Interface is still growing. Some of these functions are not needed to be invoked for all services/UEs, e.g.,: TCP optimization function only for TCP flows, HTTP header enrichment only of HTTP traffic, Video optimization function for video flows, IPv6 firewall + NAT64 function for outgoing IPv6 packets, IPv4 firewall + NAT64 function for incoming IPv4 packets, etc.. Liu, et al. Expires March 21, 2015 [Page 6] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 3GPP has defined Traffic Detection Function (TDF) which implements DPI (detection) functionality along with enforcement and charging of the corresponding detected applications [TS.23203]. TDF resides on Gi/SGi interface. Note: It was tempting to use TDF and DPI terms interchangeably, but given the diversity of deployments involving DPI modules the text uses DPI to refer to legacy deployments. The behavior of such DPI modules is deployment-specific. Several (S)Gi Interfaces can be deployed within the same PLMN (Public Land Mobile Network). This depends mainly on the number of PDNs and other factors. Each of these interfaces may involve a differentiated set of Service Functions to be involved. More details about SFC usage within Mobile Networks can be found in [I-D.ietf-sfc-use-case-mobility]. 3.3. Common Service Chain Network: A Convergence Tool From previous two use cases, we can see commonalities in service chaining. Even though fixed and mobile broadband networks are deployed separately, for integrated operators that running both networks it is obviously beneficial to provide service chaining to both networks from a common service chain network. In addition to resource optimisation, a common service chain network can also enable seamless service switchover from one network to the other. For example, a customer is watching football game on his mobile phone via 3G network. After he arrives home, he can switch over to the WLAN on his home gateway, which is backhauled to the network by Fiber To The Home (FTTH, a typical PON service), 100 Mbps broadband access. In the case, it is easier to provide seamless service from a common service chain network. SFC can be used as a tool to better address convergence needs (including adjust the service delivery to the access network constraints or to the capabilities of connected devices). Liu, et al. Expires March 21, 2015 [Page 7] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 --- ///--------\\\ //- -\\ || Fixed Access || +---+ / \ ------ || Network ||---|BNG|---- | || // \\ \\\--------/// +---+ | Service | || || | Chain |----| Internet | ///--------\\\ | Network | || || || Mobile || +---+ | | \\ // || Network ||---|PGW|----- \ / ------ \\\--------/// +---+ \\- -// --- Figure 2: Common Service Chain Network Figure 2 illustrates a common Service Chain Network is shared by both fixed and mobile broadband networks. Such a common service chain network can be deployed as consisting of only network nodes with specific functions, or in a data center. In both cases, service nodes, whether physical or virtual, are shared by both wireline and wireless networks. Operators manage service chains universally for both networks and traffic from both networks may go through the same service chain. 3.4. Distributed Service Function Chain Besides the deployment use cases listed above, a Service Function Chain is not necessarily implemented in a single location but can also be distributed crossing several portions of the network (e.g., data centers) or even using a Service Function that is located at an network element close to the customer (e.g. certain security functions). Multiple SFC-enabled domains can be enabled in the same administrative domain. For steering traffic to subscription-based Service Functions, the SFC Classifier needs to understand which subscriber a flow belong to in order to retrieve the service profile to apply to this flow. In some contexts, it is not possible to identify in a permanent manner the subscriber by the source IP address because that IP address may be assigned dynamically. Out-of-band methods to correlate the source IP address and a subscriber identifier may be needed in a given administrative domain. The SFC Classifier can rely on pull or push methods to correlate an IP address and/or IPv6 prefix to a subscriber identity. Examples are querying the PCRF or receiving RADIUS Accounting messages respectively. Liu, et al. Expires March 21, 2015 [Page 8] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 For steering traffic to traffic management Service Functions such as video optimisation platform, in mobile network, it is desirable to perform optimisation on when required. That is when there is congestion in the Radio cells. One option for the SFC Classifier to have this congestion-awareness is for the network to provide this information to the SFC Classifier, directly, or via an intermediate actionable-intelligence function, which can combine other inputs or policies. How those policies and feedback data are configured to the SFC Classifier may be specific to each administrative domain. 3.5. Service Function Chain in Data Center In DC (Data Center), like in broadband and mobile networks, Service Function Chains may also be deployed to provide added-value services. Figure 3 illustrates a possible scenario for Service Function Chain in Data Center: SFs are located between the DC Router (access router) and the Servers. From Servers to Internet, there are multiple Service Functions such as IDS/IPS, FW, NAT lined up and a monolithic SFC created for all incoming traffic. *********************************************** * +------+ * * |Server+<+ * * +------+ | * ------ * | * // \\ * +------+ | +-------+ +--+ +---+ +---------+ | | * |Server+<+->|IDS/IPS+<->|FW+<->|NAT+<->|DC Router|<->+ Internet | * +------+ | +-------+ +--+ +---+ +---------+ | | * | * \\ // * | * ------ * ... <+ * * * * ... * * * * DC * *********************************************** Figure 3: Service Function Chain in Data Center More details about Service Function Chain in Data Center can be found in [I-D.ietf-sfc-dc-use-cases]. 3.6. Service Function Chain in Cloud CPE Cloud CPE is one deployment scenario where the value-added service functions are centralized (e.g., hosted in the network or cloud side), leaving the subscriber side box with basic L2/L3 Liu, et al. Expires March 21, 2015 [Page 9] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 functionalities. In this scenario, all the value added services are configured by subscribers and enabled in the network side. Subscribers can define their own added value services. The Cloud CPE will translate those services requests into chains of Service Functions. Such architecture must support means to differentiate subscribers and their traffic. +------+ +------Cloud CPE-----+ |L2-CPE|--+ | +---+ | +------+ | | +--+ /|ACL|-- | +------------+ ... |==Encapsulation==|---|FW|-- +---+ \__|_____| Internet | +------+ | | +--+ \ / | +------------+ |L2-CPE|--+ | +-----+ | +------+ | |TCP-O| | | +-----+ | +--------------------+ Figure 4: SFC in Cloud CPE 4. Abstraction of SFC in Different Deployment Scenarios This section presents the SFC scenarios from a different angle, i.e., the abstraction of SFC use cases in different deployment scenarios. Each of the use case may belong to one or many of the categories listed below: Liu, et al. Expires March 21, 2015 [Page 10] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 +---------------------+-------------------------------------------+ |Category | Description | +---------------------+-------------------------------------------+ |Per-service | Chain different Service Functions based | |Characteristic SFC | on service/application characteristics | +---------------------+-------------------------------------------+ |Per-user/subscription| Chain different Service Functions based | |SFC | on user requirements or subscription | | | information. Note, this does not mean | | | that millions of SFCs will be instantiated| | | but SF classification is subscriber-aware.| +---------------------+-------------------------------------------+ |TE-Oriented SF | Chain different Service Functions for | | | Traffic Engineering purposes. This may | | | includes load, utilisation, planned | | | maintenance, etc. | +---------------------+-------------------------------------------+ |Bi-directional Flow | Function path that contain bi-directional | |SFC | Service Functions | +---------------------+-------------------------------------------+ |SFC over Multi- | Service Functions distributed over differ-| |Underlay Networks | ent underlay networks | +---------------------+-------------------------------------------+ |SFC over Service | SFC that contains the paths for different | |Functions Forking | service or applications | +---------------------+-------------------------------------------+ 4.1. Per-service characteristic SFC The traffic in a network is usually forwarded based on destination IP or MAC addresses. In an operator's network, some Service Functions are implemented, where traffic is steered through these Service Functions in a certain sequence according to service characteristics and objectives. +---------------------------+ +-------->|Service Function Chaining A +------------+ | +---------------------------+ ------->|Service |<-->| |Classifier | | +---------------------------+ +------------+ +-------->|Service Function Chaining B| +---------------------------+ Figure 5: General Service Function Chain Traffic enters a SFC-enabled domain in a service classifier, which identifies traffic and classifies it into service flows. Service flows are forwarded on a per SF Map basis. Liu, et al. Expires March 21, 2015 [Page 11] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 4.2. Per-user/subscription requirement SFC In operator networks with user subscription information, it is considered as a value added service to provide different subscribers with differentiated services. Subscribers may subscribe different services and the order handling at the operator side will translate those subscription request into configuration operations so that the service will be appropriately delivered to the subscribers. Configuration operations include in particular the provisioning of classification rules. 4.3. TE-Oriented SFC TE-oriented SFC is required by operators in achieving flexible service operating. For example, if certain paths are congested or certain Service Functions are overloaded, SFC forwarding should be inferred accordingly. 4.4. SFC for Bi-directional Flow Some Service Functions, for example, NAT or TCP optimization, need to handle bi-directional flows, while others SFs such as video optimization don't need to handle bi-directional flows. Due to IPv4 address exhaustion, more and more operators have deployed or are about to deploy IPv6 transition technologies such as NAT64 [RFC6146]. The traffic traversing a NAT64 function may go through different types of IP address domains. One key feature of this scenario is that characteristics of packets before and after processed by the service processing function are different, e.g., from IPv6 to IPv4. The unpredictability of processed packets, due to the algorithm in the Service Function, brings difficulties in steering the traffic. A variety of hosts can be connected to the same network: IPv4-only, dual-stack, and IPv6-only. A differentiated forwarding path can be envisaged for each of these hosts. In particular, DS hosts should not be provided with a DNS64, and as such there traffic should not be delivered to a NAT64 device. Means to guide such differentiated path can be implemented at the host side; but may also be enabled in the network side as well. Liu, et al. Expires March 21, 2015 [Page 12] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 +---------+ +----------+ ====>+ SF C + +----------+ | SF E |<==>+---+ | +---------+<======>| SF |<======>+----------+ |INT| +<=====================>| NAT |<======================>|NET| +----------+ +---+ Figure 6: Service Function Chain with NAT64 function Figure 6 shows a specific example of Service Function Chain with NAT function. Service flow1 is processed by SF(Service Function) C, NAT and E sequentially. In this example, the SF NAT performs NAT64. As a result, packets after processing by the SF NAT are in IPv4, which is a different version of IP header from the packets before processing. Service Function Chaining in this scenario should be able to identify the flow even if it is changed after processed by Service Functions. 4.5. SFC over Multiple Underlay Networks Operators may need to deploy their networks with various types of underlay technologies. Therefore, Service Function Chaining needs to support different types of underlay networks. +---------+ +----------+ +----------+ ---+ SF A | | SF B | | SF C +--- +----+----+ +---+-+----+ +-----+----+ ^ ^ ^ ^ | ------ | | ------ | | // \\ | | // \\ | | | Ethernet | v v | | | +->+ network +--+ +--+ IP network +<-+ | | | | \\ // \\ // ------ ------ Figure 7: multiple underlay networks: Ethernet and IP Figure 7 illustrates an example of Ethernet and IP network, very common and easy for deployment based on existing network status, as underlay networks. SF(Service Functions) A, B and C locate in Ethernet and IP networks respectively. To build a Service Function Chain of SF A, B and C, Service Function Chaining needs to support steering traffic across Ethernet and IP underlay networks. Liu, et al. Expires March 21, 2015 [Page 13] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 4.6. SFC over Service Path Forking To enable service or content awareness, operators need DPI functions to look into packets. When a DPI function is part of a Service Function Chain, packets processed by the DPI function may be directed to different paths according to result of DPI processing. That means a forking service path. In this use case, the switching SF is another classifier which need to classify flow and shepherd them to different paths. +---------+ +----------+ +----------+ | | | | | | -----| Firewall+<------>+ DPI +<------>+anti-virus|---- | | | | | | +---------+ +-----+----+ +----------+ ^ V +-----+----+ | | | Parental | | control | +-----+----+ | V Figure 8: a forking service path Figure 8 shows the use case of a forking service path. Traffic first goes through a firewall and then arrives at DPI function which discerns virus risk. If a certain pre-configured pattern is matched, the traffic is directed to an anti-virus function. Such DPI function may fork out more than one path. Service function sharing is sub-category of the service function forking. Some carrier grade hardware box or Service Functions running on high performance servers can be shared to support multiple Service Function Chains. Following is an example. Liu, et al. Expires March 21, 2015 [Page 14] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 SFC1 +---------+ +--------+ ------->+---------+------->+--------+---> SFC2 |Firewall | |Video | ------->+-->+ | |Opt | +---|-----+ +--------+ | v +---+-----+ | | | |Parental | |Control | +---+-----+ | v Figure 9: Two Service Function Chains share one Service Function In Figure 9, there are three Service Functions, firewall, VideoOpt and Parental Control, and two Service Functions Chains SFC1 and SFC2. SFC1 serves broadband user group1 which subscribes to secure web surfing and Internet video optimization, while SFC2 serves broadband user group2 which subscribes to secure web surfing with parental control. SF Firewall is shared by both Service Function Chains. 4.7. Recursive SFC SFCs can be provided in a recursive manner. A Level 1 service provider can sell SFC services to multiple clients. Each client can further partition its SFC and serve as a Level 2 service provider to sell differentiated SFCs to different clients. This process can continue several iterations making recursive service a new business model which is becoming popular today. Consider a use case where an enterprise leases a virtual service network from a data canter provider. The enterprise then creates two service chains out of the virtual service network. The first service chain, designed for its employees, will force traffic flows to go through NAT, DPI, firewall, LB, and various servers. The second one, designed for its customers, will only go through NAT and web servers. Its customers can create specific websites for different departments such as purchase department, service department, etc. An important characteristic of recursive service is that each service provider is a separate entity who owns the SFC it purchased from lower level provider and who also decides the SFCs it creates for its clients. Liu, et al. Expires March 21, 2015 [Page 15] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 5. Security Considerations This document does not define an architecture nor a protocol. It focuses on listing use cases and typical Service Function examples. Some of these functions are security-related. SFC-related security considerations are discussed in [I-D.ietf-sfc-architecture]. 6. Acknowledgements Jie Hu and Zhen Cao contributed to an earlier version of this document. This document has benefited from reviews, suggestions, comments and proposed text provided by the following members of the Service Function Chaining Working Group(sfc WG), listed in alphabetical order: David Binet, Hui Deng, Alla Goldner, Yuanlong Jiang, Jerome Moisand, Lehong Niu, Ron Parker, and Lucy Yong. 7. Informative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-01 (work in progress), September 2014. [I-D.ietf-sfc-dc-use-cases] Surendra, S., Tufail, M., Majee, S., Captari, C., and S. Homma, "Service Function Chaining Use Cases In Data Centers", draft-ietf-sfc-dc-use-cases-01 (work in progress), July 2014. [I-D.ietf-sfc-use-case-mobility] Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", draft-ietf-sfc-use-case-mobility-01 (work in progress), July 2014. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. Liu, et al. Expires March 21, 2015 [Page 16] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. [TS.23203] 3GPP, "Policy and charging control architecture", December 2013. Authors' Addresses Will(Shucheng) Liu (editor) Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Hongyu Li Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: hongyu.li@huawei.com Oliver Huang Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: oliver.huang@huawei.com Mohamed Boucadair (editor) France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Liu, et al. Expires March 21, 2015 [Page 17] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 Nicolai Leymann Deutsche Telekom AG Email: n.leymann@telekom.de Qiao Fu China Mobile Email: fuqiao@chinamobile.com Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Chuong Pham Telstra Corporation Level 8, 18 Smith Street Parramatta 2150 Australia Email: Pham, Chuong D Changcheng Huang Carleton University 1125 Colonel By Drive Ottawa ON K1S 5B6 Canada Email: huang@sce.carleton.ca Jiafeng Zhu Huawei Technologies Santa Clara,CA US Email: Jiafeng.zhu@huawei.com Liu, et al. Expires March 21, 2015 [Page 18] Internet-Draft Service Function Chaining General Use CasesSeptember 2014 Peng He Ciena Corp Email: phe@ciena.com Liu, et al. Expires March 21, 2015 [Page 19]