Internet DRAFT - draft-liu-service-chaining-use-cases

draft-liu-service-chaining-use-cases







Network Working Group                                             W. Liu
Internet-Draft                                                     H. Li
Intended status: Informational                                  O. Huang
Expires: March 29, 2014                              Huawei Technologies
                                                            M. Boucadair
                                                          France Telecom
                                                              N. Leymann
                                                     Deutsche Telekom AG
                                                                  Z. Cao
                                                            China Mobile
                                                                   J. Hu
                                                           China Telecom
                                                      September 25, 2013


                  Service Function Chaining Use Cases
                draft-liu-service-chaining-use-cases-02

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 March 29, 2014.

Copyright Notice





Liu, et al.              Expires March 29, 2014                 [Page 1]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   Copyright (c) 2013 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 . . . . .   7
     3.4.  Use Case of Service Function Chain in Data Center . . . .   7
   4.  Use Cases of Service Function Chaining Technical Scenario . .   8
     4.1.  General Use Case for Service Function Chaining  . . . . .   8
     4.2.  Use Case for Service Function Chain with NAT Function . .   9
     4.3.  Use Case for Multiple Underlay Networks . . . . . . . . .   9
     4.4.  Use Case of Service Path Forking  . . . . . . . . . . . .  10
     4.5.  Use Case of Multiple Service Paths Share one Service
           Function  . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.6.  Use Case of Service Layer Traffic Optimization  . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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.

   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.



Liu, et al.              Expires March 29, 2014                 [Page 2]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   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).The overall SFC Framework is defined in
   [I-D.boucadair-service-chaining-framework].

   For most of the use cases presented in this document,

   o  SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in the network.
      Deployments cases that would require per-subscriber SFCs are out
      of scope.

   o  Instantiated SFC are driven by service creation and offering
      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.









Liu, et al.              Expires March 29, 2014                 [Page 3]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   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  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-service-chaining-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



Liu, et al.              Expires March 29, 2014                 [Page 4]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   Figure 1 illustrates a possible deployment position for Service
   Function Chaining: between BNG and CR (Core Router).  The Service
   Function Chain shown in Figure 1 may include several Service
   Functions to perform services such as DPI, NAT44, DS-Lite, NPTv6,
   Parental control, Firewall, load balancer, Cache, etc.

3.2.  Use Case of Service Function Chain in Mobile Core Network (a.k.a.,
      Gi-LAN)

   Gi interface is a reference point between the GGSN (Gateway GPRS
   Support Node) and an external PDN (Packet Domain Network) [RFC6459].
   In 4G networks, this reference point is called SGi.  The following
   notes are made:

   o  There is no standard specification of such reference points (i.e.,
      Gi and SGi) in term of Service Functions to be located in that
      segment.

   o  Several (S)Gi Interfaces can be deployed within the same PLMN
      (Public Land Mobile Network); this depends on the number of PDNs
      and other factors

   Traffic is directed to/from Internet traversing one or more Service
   Functions.  Note, these Service Functions are called "enablers" by
   some operators.

   Plenty of Service Functions are enabled in that segment.  Some of
   these functions are co-located on the same device while other
   standalone boxes can be deployed to provide some other Service
   Functions.  The number of these SFs is still growing due to the
   deployment of new value-added services.  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.

   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,



Liu, et al.              Expires March 29, 2014                 [Page 5]

Internet-Draft     Service Function Chaining Use Cases    September 2013


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

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



Liu, et al.              Expires March 29, 2014                 [Page 6]

Internet-Draft     Service Function Chaining Use Cases    September 2013


                     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.

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



Liu, et al.              Expires March 29, 2014                 [Page 7]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   and the Servers.  From Servers to Internet, there are multiple
   Service Functions such as IDS/IPS, FW, NAT lined up and a monolithic
   SFC created for all incoming traffic.

   ***********************************************
   * +------+                                    *
   * |Server+-+                                  *
   * +------+ |                                  *            ------
   *          |                                  *         //        \\
   * +------+ |  +-------+   +--+   +---+   +---------+   |            |
   * |Server+-+->|IDS/IPS+-->|FW+-->|NAT+-->|DC Router|-->+  Internet  |
   * +------+ |  +-------+   +--+   +---+   +---------+   |            |
   *          |                                  *         \\        //
   *          |                                  *            ------
   *   ...   -+                                  *
   *                                             *
   *   ...                                       *
   *                                             *
   *                     DC                      *
   ***********************************************

              Figure 5: Service Function Chain in Data Center

4.  Use Cases of Service Function Chaining Technical Scenario

   There are several possible cases for the steering of traffic
   according to service characteristics due to specific requirements
   from operators and service providers.

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             |



Liu, et al.              Expires March 29, 2014                 [Page 8]

Internet-Draft     Service Function Chaining Use Cases    September 2013


                                          +-------------------------+

                 Figure 6: General Service Function Chain

   Traffic enters a SFC-enabled domain in a service classifier, which
   identifies traffic and classifies it into service flows.  Service
   flows are forwarded on a per SF Map basis.

4.2.  Use Case for Service Function Chain with NAT Function

   Due to IPv4 address exhaustion, more and more operators have deployed
   or are about to deploy IPv6 transition technologies such as NAT64
   [RFC6146].  The traffic traversing a NAT64 function may go through
   different types of IP address domains.  One key feature of this
   scenario is that characteristics of packets before and after
   processed by the service processing function are different, e.g.,
   from IPv6 to IPv4.  The unpredictability of processed packets, due to
   the algorithm in the Service Function, brings difficulties in
   steering the traffic.

   A variety of hosts can be connected to the same network: IPv4-only,
   dual-stack, and IPv6-only.  A differentiated forwarding path can be
   envisaged for each of these hosts.  In particular, DS hosts should
   not be provided with a DNS64, and as such there traffic should not be
   delivered to a NAT64 device.  Means to guide such differentiated path
   can be implemented at the host side; but may also be enabled in the
   network side as well.

        +---------+        +----------+        +----------+
        |         |        |          |        |          |
   ---->+ 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





Liu, et al.              Expires March 29, 2014                 [Page 9]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   Operators may need to deploy their networks with various types of
   underlay technologies.  Therefore, Service Function Chaining needs to
   support different types of underlay networks.

      +---------+         +----------+       +----------+
      |         |         |          |       |          |
   -->+ SF A    |         | SF B     |       | SF C     +-->
      |         |         |          |       |          |
      +----+----+         +---+-+----+       +-----+----+
           |                  ^ |                  ^
           |      ------      | |      ------      |
           |   //        \\   | |   //        \\   |
           |  |  Ethernet  |  | v  |            |  |
           +->+  network   +->+ +->+ IP network +->+
              |            |       |            |
               \\        //         \\        //
                  ------               ------

           Figure 8: multiple underlay networks: Ethernet and IP

   Figure 8 illustrates an example of Ethernet and IP network, very
   common and easy for deployment based on existing network status, as
   underlay networks.  SF(Service Functions) A, B and C locate in
   Ethernet and IP networks respectively.  To build a Service Function
   Chain of SF A, B and C, Service Function Chaining needs to support
   steering traffic across Ethernet and IP underlay networks.

4.4.  Use Case of Service Path Forking

   To enable service or content awareness, operators need DPI functions
   to look into packets.  When a DPI function is part of a Service
   Function Chain, packets processed by the DPI function may be directed
   to different paths according to result of DPI processing.  That means
   a forking service path.

        +---------+        +----------+        +----------+
        |         |        |          |        |          |
   ---->| Firewall+------->+  DPI     +------->+anti-virus|--->
        |         |        |          |        |          |
        +---------+        +-----+----+        +----------+
                                 |
                                 |
                                 V
                           +-----+----+
                           |          |
                           | Parental |
                           | control  |
                           +-----+----+



Liu, et al.              Expires March 29, 2014                [Page 10]

Internet-Draft     Service Function Chaining Use Cases    September 2013


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

       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





Liu, et al.              Expires March 29, 2014                [Page 11]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   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

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-service-chaining-framework].

6.  Acknowledgements

   N/A.

7.  Informative References

   [I-D.boucadair-service-chaining-framework]
              Boucadair, M., Jacquenet, C., Parker, R., Lopez, D.,
              Guichard, J., and C. Pignataro, "Differentiated Service
              Function Chaining Framework", draft-boucadair-service-
              chaining-framework-00 (work in progress), August 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.





Liu, et al.              Expires March 29, 2014                [Page 12]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   [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


   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



Liu, et al.              Expires March 29, 2014                [Page 13]

Internet-Draft     Service Function Chaining Use Cases    September 2013


   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 March 29, 2014                [Page 14]