[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Service Function Chaining                                 Guanglei Li
                                                           Guanwen Li
                                                            Taixin Li
                                                                Qi Xu
                                                          Huachun Zhou
Internet Draft                             Beijing Jiaotong University
Intended status: Informational                        October 21, 2016
Expires: April 2017



         Hybrid Hierarchical Multi-Domain Service Function chaining
                         draft-li-sfc-hhsfc-01.txt


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 25, 2016.

Copyright Notice

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



Li                     Expires April 21, 2017                 [Page 1]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   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.

Abstract

   This document describes a Hybrid Hierarchical Multi-Domain Service
   Function Chaining (hhSFC) architecture that extends Service Function
   Chaining (SFC) to multiple domains with different technology,
   administration or ownership.

   The goals of Hybrid Hierarchical SFC are to reduce the complexity of
   the control plane in a single domain and make the negotiation
   between different domains possible.

Table of Contents

   1. Introduction ................................................ 2
      1.1. Scope .................................................. 3
      1.2. Terminology ............................................ 4
      1.3. Assumptions ............................................ 4
   2. Hybrid Hierarchical Service Function Chaining ............... 5
      2.1. Architecture ........................................... 5
      2.2. Control plane .......................................... 5
         2.2.1. Intra-domain ...................................... 5
         2.2.2. Inter-domain ...................................... 6
      2.3. Data plane ........./................................... 8
         2.3.1. Intra-domain ...................................... 8
         2.3.2. Inter-domain ...................................... 8
   3. SFC eXchange Platform ....................................... 8
   4. Security Considerations ..................................... 9
   5. References .................................................. 9
      5.1. Normative References ................................... 9
      5.2. Informative References ................................ 10
   6. Acknowledgments ............................................ 10

1. Introduction

   Service Function Chaining supports customer traffic passing through
   an ordered list of functions as required.

   The [I-D.ietf-sfc-nsh] creates a service plane via Network Service
   Headers (NSH), which provide data-plane information to construct
   service paths and transfer metadata.




Li                     Expires April 21, 2017                 [Page 2]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   The document [I-D.ietf-sfc-control-plane] describes requirements for
   conveying information between SFC control plane and data plane in a
   SFC-enabled domain. The document [I-D.dolson-sfc-hierarchical]
   proposes a hierarchical SFC for multiple domains, which are
   controlled by a single organization and trusted by each other, and
   focus on data plane. [I-D. unify-sfc-control-plane-exp] provides an
   insight into a Service Function Chain (SFC) control and Network
   Function Virtualization (NFV) orchestration proof of concept
   implementation and experimentation in multi-domain/technology
   environments, which adopts a recursive control plane, but does not
   consider the business model between different virtual network
   providers or infrastructure providers to support a SFC spanning
   domains with different ownership.

   In this document, we consider SFCs traversing different domains
   owned by different organizations (e.g., ISPs) or by a single
   organization with administration partitions (e.g., for purpose of
   security isolation), which means an overarching orchestrator or
   manager is infeasible for multi-domain SFC.

   The Hybrid Hierarchical SFC combines flat distributed control plane
   and centralized hierarchical control plane. A centralized recursive,
   hierarchical control plane is recommended to be deployed into a
   large administration domain consisting of smaller sub-domains while
   a flat distributed control plane is recommend to be deployed into
   multiple large administration domains.

1.1. Scope

   The "domain" discussed in this document is a logical concept. Domain
   division depends on circumstances including but not limited to: geo-
   location, technology, administration, security policy or ownership.
   While a logical centralized control plane over multiple physical
   domains might still be feasible with virtual network embedding, the
   distributed control plane aims at those circumstances where a
   centralized paradigm is inapplicable.

   This document focus on control plan. [I-D.dolson-sfc-hierarchical]
   gives many discussions about data plane, especially internal
   boundary node (IBN) path configuration. The four methods to
   manipulate NSH are still practicable in this document.

   In a recursive hierarchical control plane, an upper level plane is
   responsible to abstract a lower level plane's topologies and
   services. A mapping element is also needed in every control plane
   level. The control protocol, abstraction, mapping mechanism and
   interfaces are out of this document's scope.


Li                     Expires April 21, 2017                 [Page 3]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   In a flat distributed control plane, horizontal interfaces are used
   to realize state sharing, context translation and policies
   negotiation between domains. The protocol is out of this document's
   scope.

1.2. Terminology

   o Sub-domains: Smaller domains in a large administration/physical
      domain.

   o Multi-Domain Service Function Chaining A service function
      chaining pass through multiple domains.

   o SFC eXchange Platform: A logical entity that is used for the
      negotiation between domains. It can be a trusted third-party
      platform (e.g., deployed in future software defined IXP) or built
      by a single owner between heterogeneous networks.

   o Abstraction Element (AE) A logical entity that abstracts the
      lower-level topology and services.

   o Mapping Element (ME) A logical entity that map upper-level
      instructions to lower-level control entities.

   o Path Calculation Element (PCE): A logical entity that computes
      service function paths (SFP).

   o Information Base Element (IBE): A logical information base entity
      that stores topology and service information acquired from the
      abstraction element and provide them to the mapping element and
      path calculation element.

1.3. Assumptions

   We assume flexible and dynamic SFCs are based on Software Defined
   Networking (SDN) and NFV that provides fine-grained packet
   forwarding and decouples network functions from hardware
   respectively.

   Network virtualization and network function virtualization create
   new business models such as service function as a service, e.g., a
   third-part Software Defined IXP (SDX) between ISPs can provides a
   negotiation platform to support Multi-domain SFC.

   In this document, a domain consists of sub-domains, every sub-domain
   has its own control plane. A single-level control plane is



Li                     Expires April 21, 2017                 [Page 4]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   impractical considering the scalability and complexity of control
   plane.

2. Hybrid Hierarchical Service Function Chaining

2.1. Architecture

   Figure 1 shows an example of two-level and two-domain hybrid
   hierarchical structure. In practice, there could be more levels and
   domains. In every single domain, each control plane instance manages
   a single level. Each control plane is agnostic about other levels of
   hierarchy. Sub-domain control-planes are agnostic about control-
   planes of other sub-domains. The expectations to control plane in
   the document [draft-dolson-sfc-hierarchical] are satisfied.

            +------------+                      +------------+
            | +->IBE-+   |                      | +->IBE-+   |
            | |  +   v   <----------------------> |  +   v   |
            | v  v  PCE  |                      | v  v  PCE  |
            | AE ME<-+   | upper-level          | AE ME<-+   |
            +-^-+-----+-^+Control Plane         +^-+------^--+
              | |     | |                        | |    | |
              | |     | |                        | |    | |
      +---------v-+  +v----------+      +----------v+  +v----------+
      | +->IBE-+  |  | +->IBE-+  |      | +->IBE-+  |  | +->IBE-+  |
      | |  +   v  |  | |  +   v  |      | |  +   v  |  | |  +   v  |
      | v  v  PCE |  | v  v  PCE |      | v  v  PCE |  | v  v  PCE |
      | AE ME<-+  |  | AE ME<-+  |      | AE ME<-+  |  | AE ME<-+  |
      +--+--------+  +---^-------+      +---^-------+  +---^-------+
         ^               |      lower-level |              |
         |               |    Control Plane |              |
   +-----+-------+   +---v---------+   +----v--------+  +--v---------+
   |  Data Plane |   |  Data Plane |   |  Data Plane |  |  Data Plane|
   |             |   |             |   |             |  |            |
   |  Sub-Domain |   |  Sub-Domain |   |  Sub-Domain |  |  Sub-Domain|
   +-------------+   +-------------+   +-------------+  +------------+
                          Figure 1: Architecture

2.2. Control plane

2.2.1. Intra-domain

   Several important elements are required in every level control plane
   to realize intra-domain global optimization.

   Abstraction Elements abstracts lower-level topology, service and
   resource. Each level control plane computes service function paths


Li                     Expires April 21, 2017                 [Page 5]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   according to the information it acquired. For an upper-level control
   plane in a domain, the path computation should concern inter-
   subdomain optimization in a centralized way. For a lower-level
   control plane, it only cares about the governed sub-domain.

   Mapping Elements are responsible to translate the upper-level
   instructions, which could contain abstracted services requirements,
   service quality and overlay forwarding behaviors, to the lower-level
   control instances.

   Each level control plane has its own Information Base Elements.
   Abstraction elements create, update or delete the information in
   Information Base Elements. The information is utilized by Mapping
   Elements and Path Calculation Elements.

2.2.2. Inter-domain

   Horizontal interfaces should be deployed in the top level control
   plane to realize inter-domain communication, including State sharing,
   context translation and policies negotiation.

   Considering the circumstance that domains owned by different ISPs
   connected by the Internet eXchange Ports, which could be a datacenter
   implemented SDN technology in the future, a SFC eXchange Platform
   (SXP) was proposed to support rich business models between different
   organizations. Their distributed, multi-domain nature makes it
   possible to enable a highly customized multi-domains SFC.

   Figure 2 shows a SFC eXchange Platform connecting three different
   domains. Figure 3 shows an overview of layered domains and SFC
   eXchange Platform. In a function as service business model, inter-
   domain path computation can be driven by service agreements.
   Horizontal interfaces should be designed between domains and SFC
   eXchange Platform. Figure 4 shows domains connected by distributed
   SFC eXchange Platform. SFC eXchange Platforms server as brokers,
   which orchestrate multi-domains SFC in a distributed way.












Li                     Expires April 21, 2017                 [Page 6]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


                                            +-------------------+
                                            | +------+ +------+ |
                                            | |Sub   | |Sub   | |
                                            | |Domain| |Domain| |
                                            | +------+ +------+ |
                                            |      Domain 2     |
                                   +--------> +------+ +------+ |
   +-------------------+           |        | |Sub   | |Sub   | |
   | +------+ +------+ |           |        | |Domain| |Domain| |
   | |Sub   | |Sub   | |           |        | +------+ +------+ |
   | |Domain| |Domain| |    +------v--+     +-------------------+
   | +------+ +------+ |    |SFC      |
   |     Domain 1      |    |eXchange |     +-------------------+
   | +------+ +------+ <---->Platform |     | +------+ +------+ |
   | |Sub   | |Sub   | |    |         <-----> |Sub   | |Sub   | |
   | |Domain| |Domain| |    +---------+     | |Domain| |Domain| |
   | +------+ +------+ |                    | +------+ +------+ |
   +-------------------+                    |      Domain 3     |
                                            | +------+ +------+ |
                                            | |Sub   | |Sub   | |
                                            | |Domain| |Domain| |
                                            | +------+ +------+ |
                                            +-------------------+

    Figure 2: Multiple SFC domains connected by a SFC eXchange Platform

   +-------------------+                          +-------------------+
   |  Domain 1         |                          |        Domain 2   |
   | +---------------+ |                          | +---------------+ |
   | |     SFC       <---+ +------------------+ +--->       SFC     | |
   | |Control Plane  | | | | SFC eX Platform  | | | |  Control Plane| |
   | |Orchestrator   | | | | +--------------+ | | | |  Orchestrator | |
   | |SDN Controler  | | +---> Negotiation  <---+ | |  SDN Controler| |
   | +---------------+ |   | | Orchestrator | |   | +---------------+ |
   |                   |   | +--------------+ |   |                   |
   | +---------------+ |   | |              | |   | +---------------+ |
   | |               | |   | |SDN Controller| |   | |               | |
   | | Data Plane    | |   | +--------------+ |   | |     Data Plane| |
   | |               <-----> | Data Plane   | <----->               | |
   | +---------------+ |   | +--------------+ |   | +---------------+ |
   +-------------------+   +------------------+   +-------------------+
          Figure 3: Service Function Chaining Exchanging Platform







Li                     Expires April 21, 2017                 [Page 7]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   +-------+                +-------+                +-------+
   |       |   +--------+   |       |   +--------+   |       |
   |       |   | SFC    |   |       |   | SFC    |   |       |
   |Domains<--->eXchange<--->Domains<--->eXchange<--->Domains|
   |       |   |Platform|   |       |   |Platform|   |       |
   +-------+   +--------+   +-------+   +--------+   +-------+
                  Figure 4: Distributed SFC eX Platforms

2.3. Data plane

2.3.1. Intra-domain

   The discussion about SFC data plane components in top levels and
   lower levels in the document [draft-dolson-sfc-hierarchical] can be
   applied in the recursive hierarchical domain defined by this
   document.

   The document [draft-dolson-sfc-hierarchical] proposes four methods
   to restore packets to original upper-level after exiting a path in
   the sub-domain, including flow-stateful IBN, encoding upper-level
   paths in metadata, using unique paths per upper-level path and
   nesting upper-level NSH within lower-level NSH, which are also
   feasible.

2.3.2. Inter-domain

   When packets go out of a domain, the inter-domain NSH should be
   added. Encoding inter-domain path in metadata or using unique path
   is recommended to manipulate inter-domain NSH.

   When domains are connected by SDN-enabled SFC eXchange Platforms,
   which act as SFFs for Multi-domain SFC, the SFC eXchange Platforms
   will forwarding traffics according to the inter-domain Service Path
   Identifier (SPI).

3. SFC eXchange Platform

   The inter-domain traffic classify rules should be negotiated and
   decided by administrators of each domain with service agreements and
   policies. Distributed SFC eXchange Platforms select the service
   function location from multiple candidate domains.

3.1. Inter-domain negotiation

   As a trusted third-party platform, the SFC eXchange platform may not
   orchestrate the Multi-Domain SFC directly. In other words, it only
   exchanges and collect domains' service states and policies. Every


Li                     Expires April 21, 2017                 [Page 8]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   domain can decide their own multi-domain SFP according to the states
   and agreements. The SFC eXchange Platform also implements the
   negotiation results and decisions for domains, such as flow-specific
   peering.

   Based on the SFC eXchange Platform, rich business models may appear,
   such as competitive models for service functions. Service providers
   may compete to provide high availability and bandwidth to attract
   traffic and increase customer acquisition.

3.2. End-to-end orchestration

   In a multi-domain environment, end-to-end visibility could be
   realized by the exchange platform. One of all exchange platforms
   (e.g. the nearest one) can be selected as a manager and takes charge
   of the end-to-end performance. Exchange platforms communicate with
   each other and exchange neighboring domains' SFC performance.
   Optimal sub-domains can be selected from all candidates by the
   manager. If the performance deteriorates in certain domain, the
   manager could coordinate with other domains and switch flows to
   another domain.

   Dynamic and context aware Multi-domain SFC is achievable relaying on
   the exchange platform. For example, if a mobile user's location is
   added in a context header at local SFC-enabled sub-domain ingress
   node, when it moves to a new locations, a new Multi-domain SFP with
   better delay performance can be applied according to the new
   location.

4. Security Considerations

   Authentication mechanism must be applied between intra-domain
   control plane levels and inter-domain control elements. Lower-level
   control plane elements must ignore any instructions from
   authenticated upper-level control plane elements.

   If SFC eXchange Platforms are implemented, the access to this
   platform must be authenticated.

5. References

5.1. Normative References

   [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
             Chaining (SFC) Architecture", RFC 7665, DOI
             10.17487/RFC7665, October 2015.



Li                     Expires April 21, 2017                 [Page 9]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


5.2. Informative References

   [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header",
             draft-ietf-sfc-nsh-10 (work in progress), September 2016.

   [I-D.ietf-sfc-control-plane] Li, H., Wu, Q., Huang, O., Boucadair,
             M., Jacquenet, C., Haeffner, W., Lee, S., Parker, R.,
             Dunbar, L., Malis, A., Halpern, J., Reddy, T., and P.
             Patil, "Service Function Chaining (SFC) Control Plane
             Components & Requirements", draft-ietf-sfc-control-plane-
             06 (work in progress), August 2016.

   [I-D.dolson-sfc-hierarchical] Dolson, D., Homma, S., Lopez, D.,
             Boucadair, M., D. Liu, Ao, T. and Vu, V. "Hierarchical
             Service Function Chaining", draft-ietf-sfc-hierarchical-01
             (work in progress), Mar 2016

   [I-D.unify-sfc-control-plane-exp] Szabo, R. and B. Sonkoly, "SFC
             Control Plane Experiment: UNIFYed Approach", draft-unify-
             sfc-control-plane-exp-00, March 2016.

   [Software Defined internet exchange] Gupta A, Vanbever L, Shahbaz M,
             et al. Sdx: A software defined internet exchange. ACM
             SIGCOMM Computer Communication Review, 2015.

   [MD2-NFV] Rosa R V, Silva Santos M A, Esteve Rothenberg C. Md2-nfv:
             The case for multi-domain distributed network functions
             virtualization. Networked Systems (NetSys), 2015
             International Conference and Workshops on.

6. Acknowledgments

   The work in this document was supported by National High Technology
   of China ("863 program") under Grant No.2015AA015702.

Authors' Addresses

   Guanglei Li
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 15111035@bjtu.edu.cn







Li                     Expires April 21, 2017                [Page 10]


Internet-Draft  Hybrid Hierarchical Multi-domain SFC      October 2016


   Guanwen Li
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 14120079@bjtu.edu.cn


   Taixin Li
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 14111040@bjtu.edu.cn


   Qi Xu
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 15111046@bjtu.edu.cn


   Huachun Zhou
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: hchzhou@bjtu.edu.cn






















Li                     Expires April 21, 2017                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/