Internet DRAFT - draft-liu-sfc-nesting-use-case

draft-liu-sfc-nesting-use-case







Service Function Chaining Working Group                           D. Liu
Internet-Draft                                                    J. Cao
Intended status: Standards Track                           Alibaba Group
Expires: January 6, 2016                                   July 05, 2015


           Use Case of Hierarchical Service Function Chaining
                   draft-liu-sfc-nesting-use-case-01

Abstract

   This document proposes use case and requirement of hierarchical
   service function chaining.

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 RFC 2119 [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 January 6, 2016.

Copyright Notice

   Copyright (c) 2015 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



Liu & Cao                Expires January 6, 2016                [Page 1]

Internet-Draft              Hierarchical SFC                   July 2015


   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.  Use case of Hierarchical SFC  . . . . . . . . . . . . . . . .   2
   2.  Requirement of Hierarchical Service Function Chaining . . . .   8
   3.  contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Use case of Hierarchical SFC

   The advantage of hierarchical service function chaining compared with
   normal or flat service function chaining is that it can reduce the
   management complexity significantly.  This section discusses the use
   cases that shows the advantage of hierarchical service chaining.

   Use case 1: Traffic Identificaiton

   The scenario discussed in this section is called hierarchical service
   function chaining.  As shown in figure 1, there are two types of
   service function chains.  The first type is SFC1.  There are two sub-
   type service function chains of SFC1, SFC1_1 and SFC1_2.  SFC1_1 and
   SFC1_2 belongs to the same type of service function chain type SFC1.
   The second type of service function chain is SFC2.  There are two
   sub-type service function chains of SFC2, namely SFC2_1 and SFC2_2.
   There are two more types of service function chain of sub-type
   SFC2_1, namely SFC2_1_1 and SFC2_1_2.  For service function chain
   SFC2, there is one sub-type of service function chain called SFC2_2.

   o  As figure 1 shows, there are two tenants in a public cloud.  All
      of the first tenant's traffic is identified as SFC1 and all of the
      second tenant's traffic is identified as SFC2.  A more concrete
      example is that the first tenant is social networking service and
      the second tenant is online gaming service.

   o  For the social networking service traffic SFC1, the first sub-type
      of SFC1 is the traffic between users and it is identified as
      SFC1_1.  The second sub-type of SFC1 is the traffic for
      advertisement and it is identified as SFC1_2.  The traffic of both
      SFC1_1 and SFC1_2 belong to the same social networking service



Liu & Cao                Expires January 6, 2016                [Page 2]

Internet-Draft              Hierarchical SFC                   July 2015


      tenant but it may have different policies.  For example, the
      traffic between users may have higher priority compared with the
      traffic for advertisement.

   o  For the online gaming service SFC2, the first sub-type of SFC2 is
      the traffic of gaming interaction and it is identified as SFC2_1.
      There two more sub-type of SFC2_1, the first sub-type is the
      traffic that belongs to VIP users and it is identified as
      SFC2_2_1.  The other sub-type is the traffic that belongs to
      normal user and it is identified as SFC2_1_2.  Both the traffic of
      SFC2_1_1 and SFC2_1_2 belong to online gaming interaction traffic
      but it may have different policy.  For example, the traffic of
      SFC2_1_1 may have higher priority compared with the traffic of
      SFC2_1_2.

   o  The second sub-type of online gaming service is user payment
      traffic and it is identified as SFC2_2.  Both of traffic SFC2_1
      and SFC2_2 belong to the online gaming service tenant but it may
      have different policies.  For example, the online gaming
      interaction traffic may have higher priority compared with the
      payment traffic.

   Data center operator can use hierachical service function chaining to
   identify user tarffic in different granularity.  For example, data
   center operator could manage all the social networking traffic using
   SFC1.  They can also manage the advertisement traffic within the
   social networking traffic as SFC1_1.  The management complexity could
   be reduced compared with normal SFC.























Liu & Cao                Expires January 6, 2016                [Page 3]

Internet-Draft              Hierarchical SFC                   July 2015


  +----------------+       +-----------------+
  |   +--------+   |       |    +--------+   |
  |   |  VM1   |<--|-------|----|   VM1  |---|----> SFC1/SFC1_1
  |   +--------+   |   +-- |----+--------+---|----> SFC1/SFC1_2
  |   +--------+   |   |   |    +--------+   |
  |   |  VM2   |<--|---+ +-|----|   VM2  |---|----> SFC2/SFC2_1/SFC2_1_1
  |   +--------+   |     | |    +--------+   |
  |   +--------+<--|-----+ |    +--------+   |
  |   |  VM3   |<--|-------|----|   VM3  |---|----> SFC2/SFC2_1/SFC2_1_2
  |   +--------+   |       |    +--------+   |
  |   +--------+   |       |    +--------+   |
  |   |  VM4   |<--|-------|----|   VM4  |---|----> SFC2/SFC2_2
  |   +--------+   |       |    +--------+   |
  |      ...       |       |                 |
  +----------------+       +-----------------+
        DB                        Web



   Figure 1: Hierarchical Service Function Chaining Scenario

   Use case 2: Inter-Datacenter SFC

   Hierarchical service chaining could be used to simplify inter-
   datacenter SFC management. [draft-ietf-sfc-dc-use-cases-02] has
   discussed the inter-datacenter SFC use case.  One concrete example of
   inter-datacenter SFC is shown in figure 3.  Multiple local data-
   centers are deployed in a geographically distributed manner.  A
   central datacenter which contains service functions that can not be
   virtualized and have low usage rate is deployed centrally.  Deploying
   those service function in every local datacenter will increase the
   CAPEX/OPEX.  So the datacenter operator prefer to deploy those
   service functions in a central datacenter.

   When we use "Flat(Normal) SFC", the number of SFPs managed in central
   datacenter may increase and the change of SFP configuration in the
   central datacenter will affect other data-centers.  For example, as
   shown in figure 4, when we put a new SF in the central datacenter and
   set a new SFP, change of SFP configuration would be required for each
   datacenter.  On the other hand, if we use hierarchical SFC approach,
   we can manage each datacenter independently, and the management
   complexity can be reduced.









Liu & Cao                Expires January 6, 2016                [Page 4]

Internet-Draft              Hierarchical SFC                   July 2015


                    .--.__.--.__.--.
                    (                )-.
                   .'                   )
                  (       Internet      )
                   (                  -'
                     '-(           __)
                    ^   '---'~'---'   ^
                    |        ^        |
            +-------+        |        +-------+
            |           +----+----+           |
            |           | Central | <=========|====== Central DC:
            |           |   DC    |           |       Some HW APL
            |           ++---+---++           |       which have
            |            |   |   |            |       low usage
            |   +--------+   |   +--------+   |       rate are
            |   |            v            |   |       deployed in
            |   |         [ UEs ]         |   |       central DC.
          +-+---+-+       Area#x        +-+---+-+
          | Local |                     | Local | <== Local DCs
          | DC#1  |         ...         | DC#n  |     are deployed
          +---+---+                     +---+---+     geographically
              |                             |         distributed.
              |                             |
              v                             v
           [ UEs ]                       [ UEs ]
           Area#a                        Area#n


   Figure 2:Inter-DC SFC in distributed DCs network






















Liu & Cao                Expires January 6, 2016                [Page 5]

Internet-Draft              Hierarchical SFC                   July 2015


             ---> : Existing Path
             ===> : New Path


                  .---------.                .---------.
                 /   LDC#1   \              /    CDC    \
               +--+          |             |             |    -+
               |CF|----------------------------------------->  |
               |  |----------------------------------------->  |
               |  |=========================================>  |
               +--+          |      +----------------------->  |
                 \          /       |  +-------------------->  |
                  '--------'        |  |  #=================>  |
                                    |  |  # \           /     -+
                  .---------.       |  |  #  '---------'
                 /   LDC#2   \      |  |  #
               +--+          |      |  |  #
               |CF|-----------------+  |  #
               |  |--------------------+  #
               |  |=======================#
               +--+          |
                 \          /
                  '--------'
               |             |
               +------v------+



   Figure 3: Issues of inter-DC SFC as flat SFC

   Use case 3: Simplify SFC management

   In this use case, hierarchical service chaining is used to simplify
   service function chaining management by reducing the number of SFP.

   As shown in figure 4, there are two types of user traffic: HTTP and
   video.  There are five security functions deployed in the security
   domain.  The datacenter operator want to enforce the five different
   security policies to these two types of traffic separately.  If we
   use flat SFC (normal branching), 10 SFPs is needed in each domain.
   On the other hand, if we use hierarchical SFC, only 5 SFPs in
   domain#1 and 2 SFPs in domain#2 will be required as shown in figure
   5.








Liu & Cao                Expires January 6, 2016                [Page 6]

Internet-Draft              Hierarchical SFC                   July 2015


               . . . . . . . . . . ..   . . . . . . . . . . . . . . ..
               .   Domain#1         .   .        Domain#2            .
               .   Security Domain  .   .      HTTP with WAF         .
               .                    .   .  +->[  HHE  ]----->[ NAT ] :
               .                    .   .  |                         :
               .                    .   .  |   Video Traffic with WAF.
               . +---->[ WAF ]------.------+->[Video Opt.]-->[ NAT ] :
               . |                  .   .                            :
               . |                  .   .    HTTP with Anti-Virus    .
               . |                  .   .  +->[  HHE  ]----->[ NAT ] :
               . |                  .   .  |                         :
               . |                  .   .  | Video with Anti-Virus   .
               . +---->[Anti-Virus]--------+->[Video Opt.]-->[ NAT ] :
               . |                  .   .                            :
               . |                  .   .    HTTP with IPS           .
               . |                  .   .  +->[  HHE  ]----->[ NAT ] :
               . |                  .   .  |                         :
    [CF]->[DPI]------->[ IPS ]-------------+ Video Traffic with IPS  .
               . |                  .   .  +->[Video Opt.]-->[ NAT ] :
               . |                  .   .                            :
               . |                  .   .    HTTP with IDS           .
               . +---->[ IDS ]-------------+->[  HHE  ]----->[ NAT ] :
               . |                  .   .  |                         :
               . |                  .   .  | Video Traffic with IDS  .
               . |                  .   .  +->[Video Opt.]-->[ NAT ] :
               . |                  .   .                            :
               . |                  .   .   HTTP with Traffic Monitor.
               . +---->[Traffic]-----------+->[  HHE  ]----->[ NAT ] :
               .        Monitor     .   .  |                         :
               .                    .   .  |Video with Traffic Monitor
               .                    .   .  +->[Video Opt.]-->[ NAT ] :
               . . . . . . .. . . . .   . . . . . . ... . . . . . . ..



   Figure 4: Flat SFC in separated domains network















Liu & Cao                Expires January 6, 2016                [Page 7]

Internet-Draft              Hierarchical SFC                   July 2015


       . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . ..
       .  Domain#1(Security Domain)  .  .           Domain#2           .
       .                             .  .                              .
 [CF]---->[  DPI(Sub-domain GW)   ]------>[Sub-domain GW ]------------->
       .    |                  ^     .  .  |                         ^ .
       .    +----->[ WAF ]-----+     .  .  +-->[ HHE ]------>[ NAT ]-+ .
       .    |                  |     .  .  |                         | .
       .    +-->[Anti-Virus]---+     .  .  +-->[Video Opt.]->[ NAT ]-+ .
       .    |                  |     .  .                              .
       .    +----->[ IPS ]-----+     .  . . . . . . . . . . . . .. . . .
       .    |                  |     .
       .    +----->[ IDS ]-----+     .
       .    |                  |     .
       .    +-->[ Monitor ]----+     .
       . . . . . . . . . . . . . . . .


   Figure 5: Hierarchical in separated domains network

2.  Requirement of Hierarchical Service Function Chaining

   The requirement of hierarchical service function chaining is:

   o  The service function chain solution should allow hierarchical
      structure.

   o  One service function chain may have multiple sub-domain of service
      function chain.

   o  The number of levels of the hierarchical structure of a service
      function chain should not be limited.

   o  Increase of the number of SFP by SFC across multiple DCs could be
      limited

   o  The control and configuration in each domain should be independent

   o  metadata could be maintaind between some domains

   o  The paths in bi-direction could be symmetry in each domain

3.  contributors

   Shunsuke Homma: NTT Email: homma.shunsuke@lab.ntt.co.jp







Liu & Cao                Expires January 6, 2016                [Page 8]

Internet-Draft              Hierarchical SFC                   July 2015


4.  IANA Considerations

   This document makes no request of IANA.

5.  Security Considerations

   TBD

6.  Acknowledgements

   The authors would like to thank Shunsuke Homma for the useful
   comments and suggestions.

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.

7.2.  Informative References

   [draft-ietf-sfc-architecture-07]
              "Service Function Chaining (SFC) Architecture", February
              2015.

   [draft-ietf-sfc-dc-use-cases]
              "Service Function Chaining Use Cases In Data Centers",
              January 2015.

Authors' Addresses

   Dapeng Liu
   Alibaba Group
   Beijing
   China

   Phone: +86-13911788933
   Email: maxpassion@gmail.com


   Jie Cao
   Alibaba Group
   Hangzhou
   China






Liu & Cao                Expires January 6, 2016                [Page 9]