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