Network Working Group W. Liu
Internet-Draft H. Li
Intended status: Informational O. Huang
Expires: August 15, 2014 Huawei Technologies
M. Boucadair
France Telecom
N. Leymann
Deutsche Telekom AG
Z. Cao
China Mobile
J. Hu
China Telecom
February 11, 2014
Service Function Chaining (SFC) Use Cases
draft-liu-sfc-use-cases-01
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.
This document presents a set of 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
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 August 15, 2014.
Liu, et al. Expires August 15, 2014 [Page 1]
Internet-Draft Service Function Chaining Use Cases February 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Service Function Chaining Deployment Scenarios . . . . . . . 4
3.1. Use Case of Service Function Chain in Broadband Network . 4
3.2. Use Case of Service Function Chain in Mobile Core Network
(a.k.a., Gi-LAN) . . . . . . . . . . . . . . . . . . . . 5
3.3. Use Case for Distributed Service Function Chain . . . . . 8
3.4. Use Case of Service Function Chain in Data Center . . . . 8
4. Use Cases of Service Function Chaining Technical Scenario . . 9
4.1. General Use Case for Service Function Chaining . . . . . 9
4.2. Use Case for Service Function Chain with NAT Function . . 10
4.3. Use Case for Multiple Underlay Networks . . . . . . . . . 10
4.4. Use Case of Service Path Forking . . . . . . . . . . . . 11
4.5. Use Case of Multiple Service Paths Share one Service
Function . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Use Case of Service Layer Traffic Optimization . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The delivery of value-added services relies on the invocation of
various Service Functions (SFs). Indeed, 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.
Liu, et al. Expires August 15, 2014 [Page 2]
Internet-Draft Service Function Chaining Use Cases February 2014
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 (e.g., HTTP header enrichment) with the identity of the
subscriber or the UE (User Equipment).
This document describes some use cases of Service Function Chaining
(SFC).
For most of the use cases presented in this document,
o Instantiated SFC are driven by business and engineering needs.
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.
Liu, et al. Expires August 15, 2014 [Page 3]
Internet-Draft Service Function Chaining Use Cases February 2014
o Some Service Functions may be in the same subnet; while others may
not.
2. Terminology
This document makes use of the terms defined in
[I-D.boucadair-sfc-framework].
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.).
3. Service Function Chaining Deployment Scenarios
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.
3.1. Use Case of Service Function Chain in Broadband Network
In broadband networks, an operator may deploy value-added service
nodes on POP (Point of Presence) site. These service nodes compose
different Service Function Chains to deliver added-value services.
------ ------
// \\ ******************** // \\
+----+ | | * +---+ * +---+ | |
|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.
Liu, et al. Expires August 15, 2014 [Page 4]
Internet-Draft Service Function Chaining Use Cases February 2014
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.
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.,:
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.
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 to introduce new Service Functions because of the
constraint on the underlying topology.
Liu, et al. Expires August 15, 2014 [Page 5]
Internet-Draft Service Function Chaining Use Cases February 2014
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.
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 15, 2014 [Page 6]
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 15, 2014 [Page 7]
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.
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.
Liu, et al. Expires August 15, 2014 [Page 8]
Internet-Draft Service Function Chaining Use Cases February 2014
***********************************************
* +------+ *
* |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.
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
Liu, et al. Expires August 15, 2014 [Page 9]
Internet-Draft Service Function Chaining Use Cases February 2014
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.
+---------+ +----------+ +----------+
| | | | | |
---->+ 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.
Liu, et al. Expires August 15, 2014 [Page 10]
Internet-Draft Service Function Chaining Use Cases February 2014
+---------+ +----------+ +----------+
| | | | | |
-->+ 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.
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.
Liu, et al. Expires August 15, 2014 [Page 11]
Internet-Draft Service Function Chaining Use Cases February 2014
+---------+ +----------+ +----------+
| | | | | |
---->| 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 15, 2014 [Page 12]
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 15, 2014 [Page 13]
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
N/A.
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-00 (work in progress), October 2013.
[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.
Authors' Addresses
Will(Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Liu, et al. Expires August 15, 2014 [Page 14]
Internet-Draft Service Function Chaining Use Cases February 2014
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
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
Jie Hu
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: huj@ctbri.com.cn
Liu, et al. Expires August 15, 2014 [Page 15]