Internet DRAFT - draft-li-sfc-hhsfc
draft-li-sfc-hhsfc
Service Function Chaining Guanglei Li
Guanwen Li
Qi Xu
Huachun Zhou
Bohao Feng
Beijing Jiaotong University
Internet Draft
Intended status: Informational March 26, 2020
Expires: September 2020
Hybrid Hierarchical Multi-Domain Service Function chaining
draft-li-sfc-hhsfc-08.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 March 26, 2020.
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
Li Expires March 25, 2020 [Page 1]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
(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.
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 multi-domain scene 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
3.1. Inter-domain negotiation ................................ 8
3.2. End-to-end orchestration ................................ 9
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.
Li Expires September 26, 2020 [Page 2]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
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.
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.
Besides, the document only focuses 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 providers to support SFC spanning domains with different
ownership.
In this document, we consider SFC traversing different domains owned
by different organizations, which means an overarching orchestrator
or manager is infeasible.
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 domain consisting of smaller sub-domains owned by the same
organization and a flat distributed control plane is recommended to
be deployed into multiple large domains with different ownership.
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, or ownership.
This document focuses on control plan. [I-D.dolson-sfc-hierarchical]
gives many discussions about data plane, especially internal
boundary node (IBN) path configuration, where methods to manipulate
NSH are still practicable in this document.
In a recursive hierarchical control plane, an upper level plane is
responsible to abstract 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 September 26, 2020 [Page 3]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
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
Flexible and dynamic SFC is enabled by Software Defined Networking
(SDN) and NFV. Distributed NFV crossing different domains makes the
hybrid hierarchical control plane necessary.
Network virtualization and network function virtualization create
new business models such as service function as a service, 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 and 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 September 26, 2020 [Page 4]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
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-ietf-sfc-hierarchical-02] 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.
Abstraction Elements abstracts lower-level topology, service and
resource. Each level control plane computes service function paths
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.
Li Expires September 26, 2020 [Page 5]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
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, an 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 an 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 September 26, 2020 [Page 6]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
+-------------------+
| +------+ +------+ |
| |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 September 26, 2020 [Page 7]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
+-------+ +-------+ +-------+
| | +--------+ | | +--------+ | |
| | | 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-ietf-sfc-hierarchical-02] can be
applied in the recursive hierarchical domain defined by this
document.
2.3.2. Inter-domain
When packets go out of a domain, the inter-domain NSH should be
added. 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 SPI/SI.
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
domain can decide their own multi-domain SFP according to the states
and agreements. The SFC eXchange Platform implements the negotiation
results and decisions for domains, such as flow-specific peering.
Based on the SFC eXchange Platform, rich business models may appear.
Li Expires September 26, 2020 [Page 8]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
3.2. End-to-end orchestration
In a multi-domain environment, end-to-end visibility could be
realized by the exchange platform. One of them (e.g. the one close
to customer) 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' quality of service provided.
Better 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 one.
Dynamic and context aware Multi-domain SFC is achievable relaying on
the exchange platform.
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.
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-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.ietf-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-02
(work in progress), Mar 2016
Li Expires September 26, 2020 [Page 9]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
[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: 16111011@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 September 26, 2020 [Page 10]
Internet-Draft Hybrid Hierarchical Multi-domain SFC March 2020
Bohao Feng
Beijing Jiaotong University
Beijing, 100044, P.R. China
Email: bhfeng@bjtu.edu.cn
Li Expires September 26, 2020 [Page 11]
