Internet DRAFT - draft-chen-sfc-traffic-offloading

draft-chen-sfc-traffic-offloading







Network Working Group                                       H. Chen, Ed.
Internet-Draft                                             J,. Yang, Ed.
Intended status: Informational             Huawei Technologies Co,. Ltd.
Expires: August 18, 2014                               February 14, 2014


     Utilizing traffic offloading to relieve burden of service node
                  draft-chen-sfc-traffic-offloading-00

Abstract

   This document analysis the possibility to relieve the burden of
   service node via introducing the traffic offloading mechanism into
   the service function chain scenario, which may ultimately improve the
   network efficiency.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, 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



Chen & Yang              Expires August 18, 2014                [Page 1]

Internet-Draft             traffic offloading              February 2014


   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 . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Concept of traffic offloading . . . . . . . . . . . . . . . .   3
   4.  Operation of traffic offloading . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Static deployment of service function in traditional network cannot
   fulfill nowadays requirement, such as adding and removing new
   services/functions elastically.  In this case, service function chain
   (SFC) was introduced into the current network deployment.  It may
   realize the end-to-end service functions delivery, including the
   traditional functions (e.g. firewalls, NAT, WAN optimization) as well
   as the application specific functions.

   This document proposes the traffic offloading mechanism, which mainly
   exploits the spare capacity of service entities (including the
   classifier, the service nodes), to effectively increase the
   utilization rate of these devices.  This document discusses the
   possibility to realize traffic offloading among the service entities
   along the same service path, and besides illustrates optional
   implementation methods for reference.

2.  Terminology

   This document makes use of the following terms, additional terms are
   defined in [I-D.ietf-sfc-problem-statement].

   Service function: A network or application based packet treatment,
   application, compute or storage resource, used singularly or in
   concert with other service functions within a service chain to enable
   a service offered by a network operator.





Chen & Yang              Expires August 18, 2014                [Page 2]

Internet-Draft             traffic offloading              February 2014


   Classifier: Locally instantiated policy and customer/network/service
   profile matching of traffic flows for identification of appropriate
   outbound forwarding actions.

   Service node: Physical or virtual element providing one or more
   service functions.

   Service entity: network device including the classifier and the
   service node.

   Service function chain: A service chain defines the required
   functions and associated order that must be applied to packets and/or
   frames.  A service chain does not specify the network location or
   specific instance of service functions.

   Service path: Instance of service function chain.

3.  Concept of traffic offloading

   A typical service function chain may consist of a classifier node
   followed by one or more service nodes in a certain order.  Figure.1
   shows a simple example of service function chain, where CF represents
   the classifier node while SN_1, SN_2 and SN_3 represent three service
   nodes respectively.  Service node may be any kind of service function
   according to the requirement, such as firewall, load balancer, IPS,
   IDS or WAN optimizer and so on.  In this simple example, traffic
   flows firstly come into CF that executes the flow identification
   function.  CF is responsible for distinguishing and marking flow that
   need to be forwarded to the following service entity (e.g. SN_1).
   The service path in this example can be indicated as
   CF->SN_1->SN_2->SN_3, as the dash line shows in Figure.1.

            *********************************************
            *                                           *
      +-----*----+          +----------+          +-----*----+          +----------+
      |******    |          |          |          |     *****|**********|****      |
----->|    CF    |--------->|   SN_1   |--------->|   SN 2   |--------->|   SN 3   |
      |          |          |          |          |          |          |          |
      +----------+          +----------+          +----------+          +----------+
      flow table entry      flow table entry
      a,b,c                 b,c

                   Figure 1: Traffic offloading example

   In some situations, it is possible that the adjacent nodes along the
   same service path have some flow table entries in common, or the
   upstream service entity is able to support the some flow rules that
   hold by the downstream node.  The action field of these flow table



Chen & Yang              Expires August 18, 2014                [Page 3]

Internet-Draft             traffic offloading              February 2014


   entries could be Drop, Pass-through or Forward.  For example,
   assuming SN_1 has the flow table entries b and c, CF has the flow
   table entries a, b and c. In this case, it is possible to process
   this flow traffic according to the action field of flow table entry b
   and c on CF instead of on SN_1, which means CF is able to offload
   traffic for SN_1.  Consequently, the service path will be changed
   from previously CF->SN_1->SN_2->SN_3 to CF->SN_2->SN_3, as the star
   line shows in Figure.1.  The condition to perform traffic offloading
   is that CF is capable to perform the same rules.

   This situation may also exist between two adjacent service nodes,
   such as between SN_1 and SN_2, or between SN_2 and SN_3, as long as
   they have flow table entries in common.

   Traffic offloading will not degrade the performance significantly,
   especially when the upstream node (e.g. CF in Figure.1) implement the
   traffic flow processing in hardware fashion, for example, the ASIC
   based flow processing.  The benefit is obvious: it may relieve the
   burden of the downstream service entity by implementing traffic
   offloading between the adjacent nodes along the service path.

   Considering that the service entity may be implemented by different
   venders, it is necessary to find a way to set up the traffic
   offloading mechanism among service entities along the same service
   path.

4.  Operation of traffic offloading

   To illustrate, Figure.2 shows one of the possible method to realize
   the traffic offloading along the service path.

   MS represents the SFC management system.  It manages all of the
   service entities, including the classifier (CF) and service node
   (SN_1, SN_2) within the same autonomous domain.  The main function of
   MS is to get the requirements from upper application, including the
   type of service functions required and their relative order with
   which the flow is going to go through.  According to this
   information, MS begins to configure the service entities within the
   same autonomous domain.  It creates the service path identifier for
   each flow, and then distributes it to the service entities.











Chen & Yang              Expires August 18, 2014                [Page 4]

Internet-Draft             traffic offloading              February 2014


                         +-----------------------+
               +---1-----|          MS           |----1----+
               |         |                       |         |
               |         +-----------+-----------+         |
               |                     1                     |
               |                     |                     |
         +-----V----+          +-----V----+          +-----V----+
         |          |----2---->|          |----2---->|          |
         |    CF    |          |   SN_1   |          |   SN_2   |
         |          |<---3-----|          |<---3-----|          |
         +-----+----+          +----------+          +-----^----+
               |                                           |
               |                                           |
               +---------------------4---------------------+

                 Figure 2: Method A for traffic offloading

   1.  According to requirements from upper application, MS chose the
       proper service nodes to realize corresponding service functions.
       MS can be realized in the form of a standalone system or a
       component of a large-scale system, for example, component of a
       SDN controller.  For example, on receiving the requirements from
       upper application, MS selects CF, SN_1 and SN_2 to form a
       specific service path.  The relative order that the flow has to
       go through is CF->SN_1->SN_2.

   2.  After configured by MS, each service entity along the service
       function path has to notify its own downstream nodes of its own
       support capability of flow table.  In figture.2, CF has to notify
       its own downstream node SN_1, and SN_1 has to notify its own
       downstream node SN_2.  The capability of flow table support
       refers to the match fields that flow table can support, and the
       actions that can be apply to packet flow.  If the upstream node
       has already notified its downstream node in other service
       function path, then there is no need to repeat the notification
       process.  On receiving the notification from its own upstream
       node, the downstream node will make record of the match fields
       and actions that upstream node is able to support.

   3.  When the first packet of flow arrives at CF, CF will forward this
       packet to its own downstream node SN_1 according to the generated
       flow table entry.  On receiving the first packet of flow from CF,
       SN_1 generates the corresponding flow table entry.  SN_1 will
       compare this generated flow table entry with CF's support
       capability of flow table that was previously recorded to see if
       there is any match entry.





Chen & Yang              Expires August 18, 2014                [Page 5]

Internet-Draft             traffic offloading              February 2014


       *  If the result is NO, which indicates that CF is not able to
          offload the traffic for SN_1, then SN_1 will not reply to CF.
          It will forward this first packet to SN_2 according to certain
          policy after processing it.  SN1 will process the residual
          packets of this flow on its own.

       *  If the result is YES, which indicates that CF is able to
          offload the traffic for SN_1, then SN_1 will notify CF the
          generated flow table information, including the corresponding
          match fields and actions.

   4.  On receiving the information of flow table entry, CF1 will add it
       to its own flow table or update its own flow table.  When the
       residual packets of this flow arrived, CF will take SN_1's place
       to process them instead, and then will forward these packets
       directly to SN_2 rather than forward them to SN_1 as before.

   Figure.3 shows an alternative method to implement the traffic
   offloading in SFC scenario.  MS represents the SFC management system.
   It manages all of the service entities, including the classifier (CF)
   and the service nodes (SN_1 and SN_2).

   1.  At the network initialization phase, each service entities have
       to announce its capability of flow table support to MS
       proactively, including the match field of flow table, and the
       actions that can be apply to the traffic flow.  On receiving
       these announcements, MS makes records for each service entity.
       For example, CF, SN_1 and SN_2 send the announcement to MS, MS
       makes records for each of them.

   2.  MS pushes each service entity's capability of flow table support
       to its downstream service entity.  For example, MS pushes CF1's
       capability of flow table support to SN_1, and pushes SN_1's
       capability of flow table support to SN_2.

   The following procedures are the same as steps 3 and 4 in method A.
   It is not necessary to describe repeatedly.














Chen & Yang              Expires August 18, 2014                [Page 6]

Internet-Draft             traffic offloading              February 2014


                        +-----------------------+
              +----2----|           MS          |----2-----+
              | +--1--->|                       |<---1---+ |
              | |       +-----------+-^---------+        | |
              | |                   2 1                  | |
              | |                   | |                  | |
         +----V-+---+          +----V-+---+          +---+-V----+
         |          |          |          |          |          |
         |    CF    |<---3-----|   SN_1   |          |   SN_2   |
         |          |          |          |          |          |
         +-----+----+          +----------+          +-----^----+
               |                                           |
               |                                           |
               +---------------------4---------------------+

                 Figure 3: Method B for traffic offloading

   This document does not specify the concrete formats for the
   capability of flow table support.  Alternative options may refer to
   the flow table's format defined in [Openflow-Specification].

   Iteration operation may be applied to the traffic offloading
   procedure.  It means that after offloading for the downstream service
   entity successfully, the upstream service entity may try to offload
   traffic for the service entity next to its downstream service entity.
   For example, if CF successfully offloads the traffic for SN_1, then
   it may try to offload for SN_2.  Recursively, if CF has successfully
   offloaded traffic for SN_2, it may try to offload for SN_2's
   downstream service entity (SN_3).

5.  Security Considerations

   Security considerations are not addressed in this document.

6.  IANA Considerations

   No IANA action is needed for this document.

7.  References

7.1.  Normative References

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







Chen & Yang              Expires August 18, 2014                [Page 7]

Internet-Draft             traffic offloading              February 2014


7.2.  Informative References

   [I-D.ietf-sfc-problem-statement]
              Quinn, P., Ed., "Service Function Chaining Problem
              statement, <draft-ietf-sfc-problem-statement-00>", January
              2014.

   [Openflow-Specification]
              "https://onfa.amsl.com/sdn-resources/onf-specifications/
              openflow", .

Authors' Addresses

   Hao Chen (editor)
   Huawei Technologies Co,. Ltd.
   101 Software Ave., Yuhuatai Dist.
   Nanjing, Jiangsu  210012
   China

   Phone: +86 025-5662-5335
   Email: philips.chenhao@huawei.com


   Jishang Yang (editor)
   Huawei Technologies Co,. Ltd.
   Huawei Base, Bantian, Longgang Dist.
   Shenzhen  518129
   China

   Phone: +86 755-2842-9186
   Email: Yangjishang@huawei.com




















Chen & Yang              Expires August 18, 2014                [Page 8]