Skip to main content

Service Function Chaining (SFC) Use Cases
draft-liu-sfc-use-cases-06

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 , Qiong Sun , Chuong Pham , Changcheng Huang , Jiafeng Zhu , Peng He
Last updated 2014-05-28
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-06
Network Working Group                                        W. Liu, Ed.
Internet-Draft                                                     H. Li
Intended status: Informational                                  O. Huang
Expires: November 27, 2014                           Huawei Technologies
                                                       M. Boucadair, Ed.
                                                          France Telecom
                                                              N. Leymann
                                                     Deutsche Telekom AG
                                                             Z. Cao, Ed.
                                                            China Mobile
                                                                  Q. Sun
                                                           China Telecom
                                                                 C. Pham
                                                     Telstra Corporation
                                                                C. Huang
                                                     Carleton University
                                                                  J. Zhu
                                                     Huawei Technologies
                                                                   P. He
                                                              Ciena Corp
                                                            May 26, 2014

               Service Function Chaining (SFC) Use Cases
                       draft-liu-sfc-use-cases-06

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

Liu, et al.             Expires November 27, 2014               [Page 1]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   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 November 27, 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Service Function Chaining Use Cases . . . . . . . . . . . . .   4
     3.1.  Service Function Chain in Fixed Broadband Networks  . . .   5
     3.2.  Service Function Chain in Mobile Networks . . . . . . . .   6
     3.3.  Common Service Chain Network  . . . . . . . . . . . . . .  10
     3.4.  Distributed Service Function Chain  . . . . . . . . . . .  11
     3.5.  Service Function Chain in Data Center . . . . . . . . . .  12
     3.6.  Service Function Chain in Cloud CPE . . . . . . . . . . .  12
   4.  Abstraction of SFC in Different Deployment Scenarios  . . . .  13
     4.1.  Per-service characteristic SFC  . . . . . . . . . . . . .  14
     4.2.  Per-user/subscription requirement SFC . . . . . . . . . .  15
     4.3.  TE-Oriented SFC . . . . . . . . . . . . . . . . . . . . .  15
     4.4.  SFC for Bi-directional Flow . . . . . . . . . . . . . . .  15
     4.5.  SFC over Multiple Underlay Networks . . . . . . . . . . .  16
     4.6.  SFC over Service Path Forking . . . . . . . . . . . . . .  17
     4.7.  Recursive SFC . . . . . . . . . . . . . . . . . . . . . .  18
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

Liu, et al.             Expires November 27, 2014               [Page 2]
Internet-Draft     Service Function Chaining Use Cases          May 2014

1.  Introduction

   The delivery of Value-Added Services (VAS) 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.

   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.

   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.

   o  The amount of instantiated SFCs can vary in time, service
      engineering objectives and service engineering choices.

Liu, et al.             Expires November 27, 2014               [Page 3]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   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.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.).

   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].

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

Liu, et al.             Expires November 27, 2014               [Page 4]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   section describes a set of scenarios for Service Function Chaining
   deployment.

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    -----   |         ------
                                        ///     \\\
                                      ||  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 depolyed 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
   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

Liu, et al.             Expires November 27, 2014               [Page 5]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   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

   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.,:

   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.

   3GPP has defined Traffic Detection Function (TDF) which implements
   DPI (detection) functionality along with enforcement and charging of

Liu, et al.             Expires November 27, 2014               [Page 6]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   the corresponding detected applications [TS.23203].  TDF resides on
   Gi/SGi interface.  In reference to the examples shown in Figure 2, a
   TDF function as defined by 3GPP can be used instead of some legacy
   DPI solutions.

      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.

   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.

   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).

Liu, et al.             Expires November 27, 2014               [Page 7]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   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/SGi Interface scenario.
   Figure 2 involves many Service Functions that are enabled in the Gi/
   SGi 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  |
   |PGW  |   +---+| +---------+  +--+--+       ^ *    |            |
   +-----+     *  |                 |2         | *     \\        //
               *  |                 v          | *        ------
               *  |     3      +-----+  +----+ | *
               *  +----------->+ 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
      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

Liu, et al.             Expires November 27, 2014               [Page 8]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   GGSN/PGW.  In current deployments, a GGSN/PGW may be configured with
   up to hundreds of different APNs.  These various APNs can be
   considered as a classification parameter; as such a GGSN/PGW 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/PGWs
   besides those already proposed (except if a SF Classifier function is
   instantiated in the GGSN/PGW).

   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/PGW, but it can also
   be enabled in GGSN/PGW (PCEF function) or it can be enabled in
   various devices on the Gi/SGi 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   |
   |PGW  |    +----------------------+      |  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.

   Note, some mobile networks rely on regional-based service platforms
   (including interconnection links); while some of Service Functions
   are serviced in a centralized fashion.

Liu, et al.             Expires November 27, 2014               [Page 9]
Internet-Draft     Service Function Chaining Use Cases          May 2014

+----+  +---+|  +---------+
|GGSN+->|DPI|+->+Optimizer+-+
|/PGW|  +---+|  +---------+ |      ------                          ------
+----+                      |   //        \\                    //        \\
+----+  +---+|  +---------+ |  |            |  +-----+  +---+  |            |
|GGSN+->|DPI|+->+Optimizer+-+->+  Regional  |->+ FW  +->+NAT+->+  Internet  |
|/PGW|  +---+|  +---------+ |  |  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.

   More details about Service Function Chain in Mobile Networks can be
   found in [I-D.ietf-sfc-use-case-mobility].

3.3.  Common Service Chain Network

   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.  Besides saving
   resource, 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 wifi 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.

Liu, et al.             Expires November 27, 2014              [Page 10]
Internet-Draft     Service Function Chaining Use Cases          May 2014

                                          ---
        ///--------\\\                 //-   -\\
      || Fixed Access ||   +---+      /         \          ------
      || Network      ||---|BNG|---- |           ||      //      \\
        \\\--------///     +---+    |   Service   |    ||          ||
                                    |   Chain     |----| Internet   |
        ///--------\\\              |   Network   |    ||          ||
      ||   Mobile     ||   +---+     |           |       \\      //
      ||   Network    ||---|PGW|----- \         /          ------
        \\\--------///     +---+       \\-   -//
                                          ---

                  Figure 5: Common Service Chain Network

   Figure 5 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 November 27, 2014              [Page 11]
Internet-Draft     Service Function Chaining Use Cases          May 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 6 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 6: 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 November 27, 2014              [Page 12]
Internet-Draft     Service Function Chaining Use Cases          May 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 7: 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 November 27, 2014              [Page 13]
Internet-Draft     Service Function Chaining Use Cases          May 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 8: 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 November 27, 2014              [Page 14]
Internet-Draft     Service Function Chaining Use Cases          May 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 November 27, 2014              [Page 15]
Internet-Draft     Service Function Chaining Use Cases          May 2014

        +---------+                            +----------+
   ====>+ SF C    +        +----------+        |   SF E   |===>+---+
   |    +---------+=======>|   SF     |=======>+----------+    |INT|
   +<======================|   NAT    |<=======================|NET|
                           +----------+                        +---+

           Figure 9: Service Function Chain with NAT64 function

   Figure 9 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  |            |  |
           +->+  network   +->+ +->+ IP network +->+
              |            |       |            |
               \\        //         \\        //
                  ------               ------

          Figure 10: multiple underlay networks: Ethernet and IP

   Figure 10 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 November 27, 2014              [Page 16]
Internet-Draft     Service Function Chaining Use Cases          May 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 11: a forking service path

   Figure 11 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 November 27, 2014              [Page 17]
Internet-Draft     Service Function Chaining Use Cases          May 2014

       SFC1    +---------+        +--------+
       ------->+---------+------->+--------+--->
       SFC2    |Firewall |        |Video   |
       ------->+-->+     |        |Opt     |
               +---|-----+        +--------+
                   |
                   v
               +---+-----+
               |   |     |
               |Parental |
               |Control  |
               +---+-----+
                   |
                   v

     Figure 12: Two Service Function Chains share one Service Function

   In Figure 12, 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 datacenter 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 November 27, 2014              [Page 18]
Internet-Draft     Service Function Chaining Use Cases          May 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

   Jie Hu 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(SFCWG), 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.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.

   [I-D.ietf-sfc-dc-use-cases]
              Surendra, S., Obediente, C., Tufail, M., Majee, S., and C.
              Captari, "Service Function Chaining Use Cases In Data
              Centers", draft-ietf-sfc-dc-use-cases-00 (work in
              progress), May 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-00 (work in
              progress), May 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 November 27, 2014              [Page 19]
Internet-Draft     Service Function Chaining Use Cases          May 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 November 27, 2014              [Page 20]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   Nicolai Leymann
   Deutsche Telekom AG

   Email: n.leymann@telekom.de

   Zhen Cao (editor)
   China Mobile

   Email: caozhen@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 November 27, 2014              [Page 21]
Internet-Draft     Service Function Chaining Use Cases          May 2014

   Peng He
   Ciena Corp

   Email: phe@ciena.com

Liu, et al.             Expires November 27, 2014              [Page 22]