Internet DRAFT - draft-liu-sfc-use-cases
draft-liu-sfc-use-cases
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 <Chuong.D.Pham@team.telstra.com>
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]
