idnits 2.17.1 draft-li-sfc-hhsfc-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 37 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2020) is 1486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.dolson-sfc-hierarchical' is mentioned on line 126, but not defined == Unused Reference: 'RFC7665' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-hierarchical' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'I-D.unify-sfc-control-plane-exp' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'MD2-NFV' is defined on line 405, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-06 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-02 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Function Chaining Guanglei Li 2 Guanwen Li 3 Qi Xu 4 Huachun Zhou 5 Bohao Feng 6 Beijing Jiaotong University 7 Internet Draft 8 Intended status: Informational March 26, 2020 9 Expires: September 2020 11 Hybrid Hierarchical Multi-Domain Service Function chaining 12 draft-li-sfc-hhsfc-08.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on March 26, 2020. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 This document describes a Hybrid Hierarchical Multi-Domain Service 55 Function Chaining (hhSFC) architecture that extends Service Function 56 Chaining (SFC) to multiple domains with different technology, 57 administration or ownership. 59 The goals of Hybrid Hierarchical SFC are to reduce the complexity of 60 the control plane in a multi-domain scene and make the negotiation 61 between different domains possible. 63 Table of Contents 65 1. Introduction ................................................ 2 66 1.1. Scope .................................................. 3 67 1.2. Terminology ............................................ 4 68 1.3. Assumptions ............................................ 4 69 2. Hybrid Hierarchical Service Function Chaining ................ 5 70 2.1. Architecture ........................................... 5 71 2.2. Control plane .......................................... 5 72 2.2.1. Intra-domain ....................................... 5 73 2.2.2. Inter-domain ....................................... 6 74 2.3. Data plane ............................................. 8 75 2.3.1. Intra-domain ....................................... 8 76 2.3.2. Inter-domain ....................................... 8 77 3. SFC eXchange Platform ........................................ 8 78 3.1. Inter-domain negotiation ................................ 8 79 3.2. End-to-end orchestration ................................ 9 80 4. Security Considerations ...................................... 9 81 5. References .................................................. 9 82 5.1. Normative References .................................... 9 83 5.2. Informative References .................................. 9 84 6. Acknowledgments ............................................ 10 86 1. Introduction 88 Service Function Chaining supports customer traffic passing through 89 an ordered list of functions as required. 91 The [I-D.ietf-sfc-nsh] creates a service plane via Network Service 92 Headers (NSH), which provide data-plane information to construct 93 service paths and transfer metadata. 95 The document [I-D.ietf-sfc-control-plane] describes requirements for 96 conveying information between SFC control plane and data plane in a 97 SFC-enabled domain. The document [I-D.dolson-sfc-hierarchical] 98 proposes a hierarchical SFC for multiple domains, which are 99 controlled by a single organization and trusted by each other. 100 Besides, the document only focuses on data plane. [I-D. unify-sfc- 101 control-plane-exp] provides an insight into a Service Function Chain 102 (SFC) control and Network Function Virtualization (NFV) 103 orchestration proof of concept implementation and experimentation in 104 multi-domain/technology environments, which adopts a recursive 105 control plane, but does not consider the business model between 106 different providers to support SFC spanning domains with different 107 ownership. 109 In this document, we consider SFC traversing different domains owned 110 by different organizations, which means an overarching orchestrator 111 or manager is infeasible. 113 The Hybrid Hierarchical SFC combines flat distributed control plane 114 and centralized hierarchical control plane. A centralized recursive, 115 hierarchical control plane is recommended to be deployed into a 116 large domain consisting of smaller sub-domains owned by the same 117 organization and a flat distributed control plane is recommended to 118 be deployed into multiple large domains with different ownership. 120 1.1. Scope 122 The "domain" discussed in this document is a logical concept. Domain 123 division depends on circumstances including but not limited to: geo- 124 location, technology, administration, or ownership. 126 This document focuses on control plan. [I-D.dolson-sfc-hierarchical] 127 gives many discussions about data plane, especially internal 128 boundary node (IBN) path configuration, where methods to manipulate 129 NSH are still practicable in this document. 131 In a recursive hierarchical control plane, an upper level plane is 132 responsible to abstract lower level plane's topologies and services. 133 A mapping element is also needed in every control plane level. The 134 control protocol, abstraction, mapping mechanism and interfaces are 135 out of this document's scope. 137 In a flat distributed control plane, horizontal interfaces are used 138 to realize state sharing, context translation and policies 139 negotiation between domains. The protocol is out of this document's 140 scope. 142 1.2. Terminology 144 o Sub-domains: Smaller domains in a large administration/physical 145 domain. 147 o Multi-Domain Service Function Chaining A service function 148 chaining pass through multiple domains. 150 o SFC eXchange Platform: A logical entity that is used for the 151 negotiation between domains. It can be a trusted third-party 152 platform (e.g., deployed in future software defined IXP) or built 153 by a single owner between heterogeneous networks. 155 o Abstraction Element (AE) A logical entity that abstracts the 156 lower-level topology and services. 158 o Mapping Element (ME) A logical entity that map upper-level 159 instructions to lower-level control entities. 161 o Path Calculation Element (PCE): A logical entity that computes 162 service function paths (SFP). 164 o Information Base Element (IBE): A logical information base entity 165 that stores topology and service information acquired from the 166 abstraction element and provide them to the mapping element and 167 path calculation element. 169 1.3. Assumptions 171 Flexible and dynamic SFC is enabled by Software Defined Networking 172 (SDN) and NFV. Distributed NFV crossing different domains makes the 173 hybrid hierarchical control plane necessary. 175 Network virtualization and network function virtualization create 176 new business models such as service function as a service, a third- 177 part Software Defined IXP (SDX) between ISPs can provides a 178 negotiation platform to support Multi-domain SFC. 180 In this document, a domain consists of sub-domains and every sub- 181 domain has its own control plane. A single-level control plane is 182 impractical considering the scalability and complexity of control 183 plane. 185 2. Hybrid Hierarchical Service Function Chaining 187 2.1. Architecture 189 Figure 1 shows an example of two-level and two-domain hybrid 190 hierarchical structure. In practice, there could be more levels and 191 domains. In every single domain, each control plane instance manages 192 a single level. Each control plane is agnostic about other levels of 193 hierarchy. Sub-domain control-planes are agnostic about control- 194 planes of other sub-domains. The expectations to control plane in 195 the document [draft-ietf-sfc-hierarchical-02] are satisfied. 197 +------------+ +------------+ 198 | +->IBE-+ | | +->IBE-+ | 199 | | + v <----------------------> | + v | 200 | v v PCE | | v v PCE | 201 | AE ME<-+ | upper-level | AE ME<-+ | 202 +-^-+-----+-^+Control Plane +^-+------^--+ 203 | | | | | | | | 204 | | | | | | | | 205 +---------v-+ +v----------+ +----------v+ +v----------+ 206 | +->IBE-+ | | +->IBE-+ | | +->IBE-+ | | +->IBE-+ | 207 | | + v | | | + v | | | + v | | | + v | 208 | v v PCE | | v v PCE | | v v PCE | | v v PCE | 209 | AE ME<-+ | | AE ME<-+ | | AE ME<-+ | | AE ME<-+ | 210 +--+--------+ +---^-------+ +---^-------+ +---^-------+ 211 ^ | lower-level | | 212 | | Control Plane | | 213 +-----+-------+ +---v---------+ +----v--------+ +--v---------+ 214 | Data Plane | | Data Plane | | Data Plane | | Data Plane| 215 | | | | | | | | 216 | Sub-Domain | | Sub-Domain | | Sub-Domain | | Sub-Domain| 217 +-------------+ +-------------+ +-------------+ +------------+ 218 Figure 1: Architecture 220 2.2. Control plane 222 2.2.1. Intra-domain 224 Several important elements are required in every level control plane. 226 Abstraction Elements abstracts lower-level topology, service and 227 resource. Each level control plane computes service function paths 228 according to the information it acquired. For an upper-level control 229 plane in a domain, the path computation should concern inter- 230 subdomain optimization in a centralized way. For a lower-level 231 control plane, it only cares about the governed sub-domain. 233 Mapping Elements are responsible to translate the upper-level 234 instructions, which could contain abstracted services requirements, 235 service quality and overlay forwarding behaviors, to the lower-level 236 control instances. 238 Each level control plane has its own Information Base Elements. 239 Abstraction elements create, update or delete the information in 240 Information Base Elements. The information is utilized by Mapping 241 Elements and Path Calculation Elements. 243 2.2.2. Inter-domain 245 Horizontal interfaces should be deployed in the top-level control 246 plane to realize inter-domain communication, including state sharing, 247 context translation and policies negotiation. 249 Considering the circumstance that domains owned by different ISPs 250 connected by the Internet eXchange Ports, which could be a datacenter 251 implemented SDN technology in the future, an SFC eXchange Platform 252 (SXP) was proposed to support rich business models between different 253 organizations. Their distributed, multi-domain nature makes it 254 possible to enable a highly customized multi-domains SFC. 256 Figure 2 shows an SFC eXchange Platform connecting three different 257 domains. Figure 3 shows an overview of layered domains and SFC 258 eXchange Platform. In a function as service business model, inter- 259 domain path computation can be driven by service agreements. 260 Horizontal interfaces should be designed between domains and SFC 261 eXchange Platform. Figure 4 shows domains connected by distributed 262 SFC eXchange Platform. SFC eXchange Platforms server as brokers, 263 which orchestrate multi-domains SFC in a distributed way. 265 +-------------------+ 266 | +------+ +------+ | 267 | |Sub | |Sub | | 268 | |Domain| |Domain| | 269 | +------+ +------+ | 270 | Domain 2 | 271 +--------> +------+ +------+ | 272 +-------------------+ | | |Sub | |Sub | | 273 | +------+ +------+ | | | |Domain| |Domain| | 274 | |Sub | |Sub | | | | +------+ +------+ | 275 | |Domain| |Domain| | +------v--+ +-------------------+ 276 | +------+ +------+ | |SFC | 277 | Domain 1 | |eXchange | +-------------------+ 278 | +------+ +------+ <---->Platform | | +------+ +------+ | 279 | |Sub | |Sub | | | <-----> |Sub | |Sub | | 280 | |Domain| |Domain| | +---------+ | |Domain| |Domain| | 281 | +------+ +------+ | | +------+ +------+ | 282 +-------------------+ | Domain 3 | 283 | +------+ +------+ | 284 | |Sub | |Sub | | 285 | |Domain| |Domain| | 286 | +------+ +------+ | 287 +-------------------+ 289 Figure 2: Multiple SFC domains connected by a SFC eXchange Platform 291 +-------------------+ +-------------------+ 292 | Domain 1 | | Domain 2 | 293 | +---------------+ | | +---------------+ | 294 | | SFC <---+ +------------------+ +---> SFC | | 295 | |Control Plane | | | | SFC eX Platform | | | | Control Plane| | 296 | |Orchestrator | | | | +--------------+ | | | | Orchestrator | | 297 | |SDN Controler | | +---> Negotiation <---+ | | SDN Controler| | 298 | +---------------+ | | | Orchestrator | | | +---------------+ | 299 | | | +--------------+ | | | 300 | +---------------+ | | | | | | +---------------+ | 301 | | | | | |SDN Controller| | | | | | 302 | | Data Plane | | | +--------------+ | | | Data Plane| | 303 | | <-----> | Data Plane | <-----> | | 304 | +---------------+ | | +--------------+ | | +---------------+ | 305 +-------------------+ +------------------+ +-------------------+ 306 Figure 3: Service Function Chaining Exchanging Platform 308 +-------+ +-------+ +-------+ 309 | | +--------+ | | +--------+ | | 310 | | | SFC | | | | SFC | | | 311 |Domains<--->eXchange<--->Domains<--->eXchange<--->Domains| 312 | | |Platform| | | |Platform| | | 313 +-------+ +--------+ +-------+ +--------+ +-------+ 314 Figure 4: Distributed SFC eX Platforms 316 2.3. Data plane 318 2.3.1. Intra-domain 320 The discussion about SFC data plane components in top levels and 321 lower levels in the document [draft-ietf-sfc-hierarchical-02] can be 322 applied in the recursive hierarchical domain defined by this 323 document. 325 2.3.2. Inter-domain 327 When packets go out of a domain, the inter-domain NSH should be 328 added. Using unique path is recommended to manipulate inter-domain 329 NSH. 331 When domains are connected by SDN-enabled SFC eXchange Platforms, 332 which act as SFFs for Multi-domain SFC, the SFC eXchange Platforms 333 will forwarding traffics according to the inter-domain SPI/SI. 335 3. SFC eXchange Platform 337 The inter-domain traffic classify rules should be negotiated and 338 decided by administrators of each domain with service agreements and 339 policies. Distributed SFC eXchange Platforms select the service 340 function location from multiple candidate domains. 342 3.1. Inter-domain negotiation 344 As a trusted third-party platform, the SFC eXchange platform may not 345 orchestrate the Multi-Domain SFC directly. In other words, it only 346 exchanges and collect domains' service states and policies. Every 347 domain can decide their own multi-domain SFP according to the states 348 and agreements. The SFC eXchange Platform implements the negotiation 349 results and decisions for domains, such as flow-specific peering. 350 Based on the SFC eXchange Platform, rich business models may appear. 352 3.2. End-to-end orchestration 354 In a multi-domain environment, end-to-end visibility could be 355 realized by the exchange platform. One of them (e.g. the one close 356 to customer) can be selected as a manager and takes charge of the 357 end-to-end performance. Exchange platforms communicate with each 358 other and exchange neighboring domains' quality of service provided. 359 Better domains can be selected from all candidates by the manager. 360 If the performance deteriorates in certain domain, the manager could 361 coordinate with other domains and switch flows to another one. 362 Dynamic and context aware Multi-domain SFC is achievable relaying on 363 the exchange platform. 365 4. Security Considerations 367 Authentication mechanism must be applied between intra-domain 368 control plane levels and inter-domain control elements. Lower-level 369 control plane elements must ignore any instructions from 370 authenticated upper-level control plane elements. 372 5. References 374 5.1. Normative References 376 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 377 Chaining (SFC) Architecture", RFC 7665, DOI 378 10.17487/RFC7665, October 2015. 380 5.2. Informative References 382 [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", 383 draft-ietf-sfc-nsh-10 (work in progress), September 2016. 385 [I-D.ietf-sfc-control-plane] Li, H., Wu, Q., Huang, O., Boucadair, 386 M., Jacquenet, C., Haeffner, W., Lee, S., Parker, R., 387 Dunbar, L., Malis, A., Halpern, J., Reddy, T., and P. 388 Patil, "Service Function Chaining (SFC) Control Plane 389 Components & Requirements", draft-ietf-sfc-control-plane- 390 06 (work in progress), August 2016. 392 [I-D.ietf-sfc-hierarchical] Dolson, D., Homma, S., Lopez, D., 393 Boucadair, M., D. Liu, Ao, T. and Vu, V. "Hierarchical 394 Service Function Chaining", draft-ietf-sfc-hierarchical-02 395 (work in progress), Mar 2016 397 [I-D.unify-sfc-control-plane-exp] Szabo, R. and B. Sonkoly, "SFC 398 Control Plane Experiment: UNIFYed Approach", draft-unify- 399 sfc-control-plane-exp-00, March 2016. 401 [Software Defined internet exchange] Gupta A, Vanbever L, Shahbaz M, 402 et al. Sdx: A software defined internet exchange. ACM 403 SIGCOMM Computer Communication Review, 2015. 405 [MD2-NFV] Rosa R V, Silva Santos M A, Esteve Rothenberg C. Md2-nfv: 406 The case for multi-domain distributed network functions 407 virtualization. Networked Systems (NetSys), 2015 408 International Conference and Workshops on. 410 6. Acknowledgments 412 The work in this document was supported by National High Technology 413 of China ("863 program") under Grant No.2015AA015702. 415 Authors' Addresses 417 Guanglei Li 418 Beijing Jiaotong University 419 Beijing, 100044, P.R. China 421 Email: 15111035@bjtu.edu.cn 423 Guanwen Li 424 Beijing Jiaotong University 425 Beijing, 100044, P.R. China 427 Email: 16111011@bjtu.edu.cn 429 Qi Xu 430 Beijing Jiaotong University 431 Beijing, 100044, P.R. China 433 Email: 15111046@bjtu.edu.cn 435 Huachun Zhou 436 Beijing Jiaotong University 437 Beijing, 100044, P.R. China 439 Email: hchzhou@bjtu.edu.cn 440 Bohao Feng 441 Beijing Jiaotong University 442 Beijing, 100044, P.R. China 444 Email: bhfeng@bjtu.edu.cn