Service Function Chaining (SFC) Use Cases
draft-liu-sfc-use-cases-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Will (Shucheng) LIU , Hongyu Li , Oliver Huang , Mohamed Boucadair , Nicolai Leymann , Zhen Cao , Jie Hu , Chuong Pham | ||
| Last updated | 2014-02-13 | ||
| Replaces | draft-liu-service-chaining-use-cases | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-sfc-use-cases-02
Internet-Draft Service Function Chaining Use Cases February 2014 ------ ------ // \\ ******************** // \\ +----+ | | * +---+ * +---+ | | |CPE |--->+ Metro +-->+BNG+>+-------+--->|CR +--->+ Internet | +----+ | | * +---+ | ^ * +---+ | | \\ // * v | * \\ // ------ * ++-------++ * ------ * | Service | * * | Chain | * * +---------+ * ******************** Service Function Chain deployment position Figure 1: An example of Service Function Chain in Broadband Networks Figure 1 illustrates a possible deployment position for Service Function Chaining: between BNG and CR (Core Router). The Service Function Chain shown 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. 3.2. Use Case of Service Function Chain in Mobile Core Network (a.k.a., Gi-LAN) 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 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. 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 Liu, et al. Expires August 17, 2014 [Page 5] Internet-Draft Service Function Chaining Use Cases February 2014 Gi Interface is still growing. Some of these functions are not needed to be invoked for all services/UEs, e.g.,: o TCP optimization function only for TCP flows o HTTP header enrichment only of HTTP traffic o Video optimization function for video flows o IPv6 firewall + NAT64 function for outgoing IPv6 packets o IPv4 firewall + NAT64 function for incoming IPv4 packets o Etc. 3GPP has defined Traffic Detection Function (TDF) which implements DPI (detection) functionality along with enforcement and charging of the corresponding detected applications [TS.23203]. 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. The current model that consists of adding new "boxes" to fulfill new business guidelines has shown its limit. Concretely, current deployments suffer from the following problems: o Complexity (and long time-to-market) to introduce new Service Functions because of the constraint on the underlying topology. * The quick time-to-market would allow innovative service launch strategy such as: subscribers are offered a new service feature for a limited period in time for test purposes before massive and industrial deployment of the service feature. The subscription can be managed through a dedicated portal to activate the service feature and trial it. The current constraint of the underlying topology makes such an approach prohibitively expensive and impractical. o Lack of visibility on dependency between Service Functions. o Lack of automated and flexible means to assess the impact of withdrawing a Service Function or a feature offered by a Service Function from the traffic forwarding path. o The connectivity service logic may be stalled because of the dependency on the physical topology. Liu, et al. Expires August 17, 2014 [Page 6] Internet-Draft Service Function Chaining Use Cases February 2014 o Sending all traffic through all Service Functions placed in series degrade the user experience, i.e., increased latency and unavailability risk for those subscribers who do not require all or some of the Service Functions to be invoked. o Sending all traffic through all Service Functions placed in series increases the capacity required in each Service Function unnecessarily. This would impact the CAPEX (Capital Expenditure). o Lack of deterministic means to: * Improve service provisioning and delivery. * Ease the manageability of the SGi/Gi Interface. Figure 2 illustrates a use case of Gi Interface scenario. Figure 2 involves many Service Functions that are enabled in the Gi Interface: WAP GW, TCP Optimizer, Video Optimizer, Content Caching, FW, NAT (44, 64), etc. This list is not exhaustive but it is provided for illustration purposes. *********************************** * 1 +------+ * * +--------->+WAP GW+----------+ * ------ * | +------+ | * // \\ +----+ +---+| +---------+ +-----+ v * | | |GGSN+--->|DPI|+>+Optimizer+->|Cache+ +----->+ Internet | +----+ +---+| +---------+ +--+--+ ^ * | | * | |2 | * \\ // * | v | * ------ * | 3 +-----+ +----+ | * * +----------->+Gi FW+->|NAT +-+ * * +-----+ +----+ * *********************************** Figure 2: An example of Service Function Chain scenario in the Gi Interface For example, the traffic from GGSN/PGW to Internet can be categorized and directed into the following Service Function Chains by DPI: o Chain 1: WAP GW. DPI performs traffic classification function, recognizes WAP protocol traffic, and directs these traffic to the WAP GW through Service Function Chain 1. o Chain 2: Optimizer + cache + Firewall + NAT. DPI recognizes and directs the HTTP traffic to the Optimizer, Cache, Firewall and NAT Liu, et al. Expires August 17, 2014 [Page 7] Internet-Draft Service Function Chaining Use Cases February 2014 in order, to perform HTTP video optimization, HTTP content cache, firewall and NAT function, respectively. o Chain 3: Firewall +NAT. For other traffic to the Internet, DPI directs these traffic by Service Function Chain 3, the traffic would travel the firewall and NAT in order. It is worth mentioning that customers (via their UEs) access to some services through the configuration of various APNs on terminals and GGSN (PDN-GW). In current deployments, a GGSN may be configured with up to hundreds of different APNs. These various APNs can be considered as a classification parameter; as such a GGSN (PDN-GW) can forward the traffic relying the APN name information. SFC allows for example some specific treatment for a given APN traffic, but still current APN-based forwarding is not challenged by SFC. SFC does not require new features in terminals or in GGSNs besides those already proposed (except if a SF Classifier function is instantiated in the GGSN). Other deployment use cases other than the one illustrated in Figure 2 can be considered in mobile networks. As shown in Figure 2, the DPI Service Function is set up once just after GGSN, but it can also be enabled in GGSN (PCEF function) or it can be enabled in various devices on the Gi Interface. Access to internal services is subject to dedicated policies. For example, a dedicated function to update HTTP flow with a UE identifier may be needed to avoid explicit identification when accessing some service platforms operated by the mobile operator. ------ // \\ +----+ +-----------------------+ | Internal | |GGSN+--->|HTTP Header Enrichment |----->+ Service | +----+ +-----------------------+ | Network | \\ // ------ Figure 3: HTTP Header Enrichment Figure 3 illustrates a use case of HHE (HTTP Header Enrichment). The HHE SF is able to inject the UE identifier to Internal Service Network for identification purpose. Liu, et al. Expires August 17, 2014 [Page 8] Internet-Draft Service Function Chaining Use Cases February 2014 Note, some mobile networks rely on regional-based service platforms (including interconnection links); while some of Service Functions are serviced in a centralized fashion. +----+ +---+| +---------+ |GGSN+->|DPI|+->+Optimizer+-+ +----+ +---+| +---------+ | ------ ------ | // \\ // \\ +----+ +---+| +---------+ | | | +-----+ +---+ | | |GGSN+->|DPI|+->+Optimizer+-+->+ Regional |->+Gi FW+->+NAT+->+ Internet | +----+ +---+| +---------+ | | Network | +-----+ +---+ | | | \\ // \\ // | ------ ------ ... ... -+ Figure 4: Cross-region services Figure 4 illustrates a use case of cross-region services, in which the functions that consist of the SFC are located at different regions and flows cross a regional network to go through the Service Function Chains. 3.3. Use Case for 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 August 17, 2014 [Page 9] Internet-Draft Service Function Chaining Use Cases February 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.4. Use Case of 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 5 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 5: Service Function Chain in Data Center 4. Use Cases of Service Function Chaining Technical Scenario There are several possible cases for the steering of traffic according to service characteristics due to specific requirements from operators and service providers. Liu, et al. Expires August 17, 2014 [Page 10] Internet-Draft Service Function Chaining Use Cases February 2014 4.1. General Use Case for Service Function Chaining 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 6: 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. 4.2. Use Case for Service Function Chain with NAT Function 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 August 17, 2014 [Page 11] Internet-Draft Service Function Chaining Use Cases February 2014 +---------+ +----------+ +----------+ | | | | | | ---->+ SF C +------->+ SF NAT +------->+ SF E +--> | | | | | | +---------+ +----------+ +----------+ Figure 7: Service Function Chain with NAT64 function Figure 7 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.3. Use Case for 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 | | | +->+ network +->+ +->+ IP network +->+ | | | | \\ // \\ // ------ ------ Figure 8: multiple underlay networks: Ethernet and IP Figure 8 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 August 17, 2014 [Page 12] Internet-Draft Service Function Chaining Use Cases February 2014 4.4. Use Case of 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. +---------+ +----------+ +----------+ | | | | | | ---->| Firewall+------->+ DPI +------->+anti-virus|---> | | | | | | +---------+ +-----+----+ +----------+ | | V +-----+----+ | | | Parental | | control | +-----+----+ | | V Figure 9: a forking service path Figure 9 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. 4.5. Use Case of Multiple Service Paths Share one Service Function 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 August 17, 2014 [Page 13] Internet-Draft Service Function Chaining Use Cases February 2014 SFC1 +---------+ +--------+ ------->+---------+------->+--------+---> SFC2 |Firewall | |Video | ------->+-->+ | |Opt | +---|-----+ +--------+ | v +---+-----+ | | | |Parental | |Control | +---+-----+ | v Figure 10: Two Service Function Chains share one Service Function In Figure 10, 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.6. Use Case of Service Layer Traffic Optimization In Figure 11, one SF has two instances SF_A1 and SF_A2 on different networking paths. When data traffic hits the first SF_0, it will be forwarded to SF_A1 or SF_A2 depending on the traffic load on different paths. Such service layer traffic optimization is the essential requirement for many computing-intensive service process functions. +----------+ | | +-----+ SF_A1 +---------+ / | | \ +-------+ / +----------+ \ | SF0 |____/ \______ | | \ / +-------+ \ +----------+ / \ | | / +-----+ SF_A2 +---------+ | | +----------+ Figure 11: service layer traffic optimization Liu, et al. Expires August 17, 2014 [Page 14] Internet-Draft Service Function Chaining Use Cases February 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.boucadair-sfc-framework]. 6. Acknowledgements Many thanks to the A. Goldner, R. Parker, and D. Binet for their comments. 7. Informative References [I-D.boucadair-sfc-framework] Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., Guichard, J., and C. Pignataro, "Service Function Chaining: Framework & Architecture", draft-boucadair-sfc- framework-02 (work in progress), February 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. [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", September 2012. Authors' Addresses Liu, et al. Expires August 17, 2014 [Page 15] Internet-Draft Service Function Chaining Use Cases February 2014 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 Nicolai Leymann Deutsche Telekom AG Email: n.leymann@telekom.de Zhen Cao China Mobile Email: caozhen@chinamobile.com Liu, et al. Expires August 17, 2014 [Page 16] Internet-Draft Service Function Chaining Use Cases February 2014 Jie Hu China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: huj@ctbri.com.cn Chuong Pham Telstra Corporation Email: Pham, Chuong D <Chuong.D.Pham@team.telstra.com> Liu, et al. Expires August 17, 2014 [Page 17]