Service Function Chaining Guanglei Li Guanwen Li Taixin Li Qi Xu Huachun Zhou Internet Draft Beijing Jiaotong University Intended status: Informational June 11, 2016 Expires: December 2016 Hybrid Hierarchical Multi-Domain Service Function chaining draft-li-sfc-hhsfc-00.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 December 11, 2016 [Page 1] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 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 ..................................9 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 December 11, 2016 [Page 2] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 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 and a flat distributed control plane 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 December 11, 2016 [Page 3] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 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 provide fine-grained packet forwarding and decoupled 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 impractical considering the scalability and complexity of control plane. Li Expires December 11, 2016 [Page 4] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 2016 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 compute service function paths according to the information it acquired. For an upper-level control plane in a domain, the path computation should concern inter- Li Expires December 11, 2016 [Page 5] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 2016 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. State sharing, context translation and policies negotiation are realized by horizontal interfaces. 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 SaaS 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 December 11, 2016 [Page 6] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 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 December 11, 2016 [Page 7] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 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 and serves as brokers orchestrating a Multi-Domain SFC. 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 domain can decide their own multi-domain SFP according to the states Li Expires December 11, 2016 [Page 8] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 2016 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. Dynamic and context aware Multi-domain SFC is also 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. 5.2. Informative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft-ietf-sfc-nsh-04 (work in progress), March 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), May 2016. Li Expires December 11, 2016 [Page 9] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 2016 [I-D.dolson-sfc-hierarchical] Dolson, D., Homma, S., Lopez, D., Boucadair, M., and D. Liu, "Hierarchical Service Function Chaining", draft-dolson-sfc-hierarchical-05 (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 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 Li Expires December 11, 2016 [Page 10] Internet-Draft Hybrid Hierarchical Multi-domain SFC June 2016 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 December 11, 2016 [Page 11]