Skip to main content

Service Chaining Use Cases
draft-liu-service-chaining-use-cases-01

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 "Replaced".
Authors Will (Shucheng) LIU , Hongyu Li , Oliver Huang , Nicolai Leymann , Zhen Cao
Last updated 2013-07-15
Replaced by draft-liu-sfc-use-cases, draft-liu-sfc-use-cases, draft-liu-sfc-use-cases
RFC stream (None)
Formats
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-service-chaining-use-cases-01
Network Working Group                                             W. Liu
Internet-Draft                                                     H. Li
Intended status: Informational                                  O. Huang
Expires: January 16, 2014                            Huawei Technologies
                                                              N. Leymann
                                                     Deutsche Telekom AG
                                                                  Z. Cao
                                                            China Mobile
                                                           July 15, 2013

                       Service Chaining Use Cases
                draft-liu-service-chaining-use-cases-01

Abstract

   For some network services, traffic is forwarded through a sequence of
   network functions, which usually have dedicated capabilities other
   than forwarding, e.g. firewall.  Forwarding of traffic along a
   sequence of service processing functions is usually based on service
   characteristics, but not destination addresses.  We call such way of
   forwarding as service chaining.  This memo describes use cases of
   service chaining.

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 January 16, 2014.

Copyright Notice

   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

Liu, et al.             Expires January 16, 2014                [Page 1]
Internet-Draft         Service Chaining Use Cases              July 2013

   (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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases of Service Chaining . . . . . . . . . . . . . . . .   3
     3.1.  General use case for service chain  . . . . . . . . . . .   3
     3.2.  Use case for service chain with NAT function  . . . . . .   4
     3.3.  Use case for multiple underlay networks . . . . . . . . .   5
     3.4.  Use case of service path forking  . . . . . . . . . . . .   5
     3.5.  Use case of multiple service paths share one network
           service function  . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Use case for distributed service chain  . . . . . . . . .   7
     3.7.  Use case of service layer traffic optimization  . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Service flow traffic is forwarded through some network middle boxes
   for specific purposes, for example:

      a) Direct some kinds of traffic to a domain border gateway for
      monitoring and charging.

      b) Before sending traffic to DC servers, steer the traffic to go
      through a load balancer to distribute performance pressure.

      c) Mobile network operators split mobile broadband traffic and
      steer them along an offloading path.

      d) Use firewall for filtering traffic for IDS(Intrusion Detection
      System)/IPS(Intrusion Protection System).

      e) Use security gateway to encrypt/decrypt traffic.

      f) When traffic has to traverse different network technology
      segments, for example IPv4/IPv6, direct the traffic to CGNAT.

Liu, et al.             Expires January 16, 2014                [Page 2]
Internet-Draft         Service Chaining Use Cases              July 2013

   Cloud computing technology has been more mature in recent years and
   triggers an idea that moves above service processing functions from
   purpose-designed hardware box into general computing servers.  This
   idea can greatly save operators' cost for buying/maintaining the
   network middle boxes and give a big chance to operators on value
   added services.

   We call the mechanism of steering traffic to service processing
   functions/service nodes before the traffic arrive their destination
   as Service chaining.

   This document describes some use cases of service chaining.

2.  Terminology

   The following terms are used in this document:

   Service Classifier: functionality inside the network which identifies
   and classifies traffic into different service flows based on their
   service characteristics or some policies, in order to send it through
   the corresponding service chain.

   Service Processing Function: a logical entity which can provide one
   or more service processing functions for packets/frames such as
   firewall, DPI (Deep Packet Inspection), LI (Lawful Intercept) and
   etc.  Usually these processing functions are computation intensive.

   Service Chain: one or more service processing functions in a specific
   order which are chained to provide a composite service, and packets/
   frames from one or more service flow should follow.

   Service Path: a path that traffic flows are forwarded through in a
   service chain.  There might be multiple paths in a service chain.

   Service Flow: packets/frames with specific service characteristics
   (e.g., packets matching a specific tuple of fields in Ethernet, IP,
   TCP, HTTP headers and etc.) or determined by some service policies
   (such as access port and etc.)

3.  Use Cases of Service Chaining

3.1.  General use case for service chain

   Traffic in a network is usually forwarded based on destination IP or
   MAC addresses.  In an operator's network, some service processing
   functions or middle boxes are implemented, where traffic is steered
   through these service processing functions in a certain sequence
   according to service characters of traffic.

Liu, et al.             Expires January 16, 2014                [Page 3]
Internet-Draft         Service Chaining Use Cases              July 2013

                                          +-------------------------+
                                          |Service Chain A          |
                             ------------>|                         |
                             |            +-------------------------+
           +------------+    |
           |Service     |    |
   ------->|Classifier  |--->|
           +------------+    |
                             |            +-------------------------+
                             |            |Service Chain B          |
                             ------------>|                         |
                                          +-------------------------+

                           General Service Chain

   Traffic comes to a service classifier, which identifies traffic and
   classifies it into service flows.  Service flows are forwarded to
   service chains respectively per service chain forwarding rules.

3.2.  Use case for service 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 NAT.  The
   traffic traversing a NAT function may go through different types of
   IP address domain.  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 IPv4 to IPv6.  The
   unpredictability of processed packets, due to the algorithm in the
   service processing function, brings difficulties in steering the
   traffic.

        +---------+        +----------+        +----------+
        |         |        |          |        |          |
   ---->+ SPF C   +------->+  SPF NAT +------->+ SPF E    +-->
        |         |        |          |        |          |
        +---------+        +----------+        +----------+

                 Figure 1: service chain with NAT function

   Figure 1 shows a specific example of service chain with NAT function.
   Service flow1 is processed by service processing function C, (NAT)
   and E sequentially.  In this example, the service processing
   function(NAT) performs a NAT46 operation onto the flow.  As a result,
   packets after processing by the service processing function(NAT) are
   in IPv6, which is a different version of IP header from the packets
   before processing.  Service chaining in this scenario should be able
   to identify the flow even if it is changed after processed by service
   processing functions.

Liu, et al.             Expires January 16, 2014                [Page 4]
Internet-Draft         Service Chaining Use Cases              July 2013

3.3.  Use case for multiple underlay networks

   Operators may need to deploy their networks with various types of
   underlay technologies.  Therefore, service chaining needs to support
   different types of underlay networks.

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

           Figure 2: multiple underlay networks: Ethernet and IP

   Figure 2 illustrates an example of Ethernet and IP network, very
   common and easy for deployment based on existing network status, as
   underlay networks.  Service processing functions A, B and C locate in
   Ethernet and IP networks respectively.  To build a service chain of
   SPF A, B and C, service chaining needs to support steering traffic
   across Ethernet and IP underlay networks.

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

Liu, et al.             Expires January 16, 2014                [Page 5]
Internet-Draft         Service Chaining Use Cases              July 2013

                           | control  |
                           +-----+----+
                                 |
                                 |
                                 V

                     Figure 3: a forking service path

   Figure 3 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 preconfigured pattern is matched,
   the traffic is directed to an anti-virus function.

   Such DPI function may fork out more than one path.

3.5.  Use case of multiple service paths share one network service
      function

   Some carrier grade hardware box or service processing functions
   running on high performance servers can be shared to support multiple
   service chains.  Following is an example.

       SC1     +---------+        +--------+
       ------->+---------+------->+--------+--->
       SC2     |Firewall |        |Video   |
       ------->+-->+     |        |Optimise|
               +---|-----+        +--------+
                   |
                   v
               +---+-----+
               |   |     |
               |Parental |
               |Control  |
               +---+-----+
                   |
                   v

    Figure 4: Two service chains share one service processing function

   In Figure 4, there are three service processing functions, firewall,
   VideoOpt and Parental Control, and two service chains SC1 and SC2.
   SC1 serves broadband user group1 which subscribes to secure web
   surfing and Internet video optimization, while SC2 serves broadband
   user group2 which subscribes to secure web surfing with parental
   control.  SPF Firewall is shared by both service chains.

Liu, et al.             Expires January 16, 2014                [Page 6]
Internet-Draft         Service Chaining Use Cases              July 2013

3.6.  Use case for distributed service chain

   A service chain is not necessarily implemented in a single location
   (e.g. data center) but can also be distributed crossing several data
   centers or even a using a service processing functions which is
   located at an network element close to the customer (e.g. certain
   security functions).

3.7.  Use case of service layer traffic optimization

                         +----------+
                         |          |
                   +-----+  SPF_A1  +---------+
                  /      |          |          \
   +-------+     /       +----------+           \
   | SPF0  |____/                                \______
   |       |    \                                /
   +-------+     \       +----------+           /
                  \      |          |          /
                   +-----+  SPF_A2  +---------+
                         |          |
                         +----------+

                    service layer traffic optimization

   In Figure.5, one SPF has two instances SPF_A1 and SPF_A2 on different
   networking paths.  When data traffic hits the first SPF_0, it will be
   forwarded to SPF_A1 or SPF_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.

4.  Security Considerations

   N/A.

5.  Acknowledgements

   N/A.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

Liu, et al.             Expires January 16, 2014                [Page 7]
Internet-Draft         Service Chaining Use Cases              July 2013

   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

   Nicolai Leymann,
   Deutsche Telekom AG

   Email: n.leymann@telekom.de

   Zhen Cao
   China Mobile

   Email: caozhen@chinamobile.com

Liu, et al.             Expires January 16, 2014                [Page 8]