idnits 2.17.1 draft-li-sfc-hhsfc-02.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 (April 17, 2017) is 2565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.dolson-sfc-hierarchical' is mentioned on line 127, but not defined == Unused Reference: 'RFC7665' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-hierarchical' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'I-D.unify-sfc-control-plane-exp' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'MD2-NFV' is defined on line 410, 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 Taixin Li 4 Qi Xu 5 Huachun Zhou 6 Internet Draft Beijing Jiaotong University 7 Intended status: Informational April 17, 2017 8 Expires: October 2017 10 Hybrid Hierarchical Multi-Domain Service Function chaining 11 draft-li-sfc-hhsfc-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on October 18, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document describes a Hybrid Hierarchical Multi-Domain Service 54 Function Chaining (hhSFC) architecture that extends Service Function 55 Chaining (SFC) to multiple domains with different technology, 56 administration or ownership. 58 The goals of Hybrid Hierarchical SFC are to reduce the complexity of 59 the control plane in a single domain and make the negotiation 60 between different domains possible. 62 Table of Contents 64 1. Introduction ................................................ 2 65 1.1. Scope .................................................. 3 66 1.2. Terminology ............................................ 4 67 1.3. Assumptions ............................................ 4 68 2. Hybrid Hierarchical Service Function Chaining ................5 69 2.1. Architecture ........................................... 5 70 2.2. Control plane .......................................... 5 71 2.2.1. Intra-domain....................................... 5 72 2.2.2. Inter-domain....................................... 6 73 2.3. Data plane ............................................. 8 74 2.3.1. Intra-domain....................................... 8 75 2.3.2. Inter-domain....................................... 8 76 3. SFC eXchange Platform........................................ 8 77 3.1. Inter-domain negotiation................................ 8 78 3.2. End-to-end orchestration................................ 9 79 4. Security Considerations...................................... 9 80 5. References .................................................. 9 81 5.1. Normative References.................................... 9 82 5.2. Informative References.................................. 9 83 6. Acknowledgments ............................................ 10 85 1. Introduction 87 Service Function Chaining supports customer traffic passing through 88 an ordered list of functions as required. 90 The [I-D.ietf-sfc-nsh] creates a service plane via Network Service 91 Headers (NSH), which provide data-plane information to construct 92 service paths and transfer metadata. 94 The document [I-D.ietf-sfc-control-plane] describes requirements for 95 conveying information between SFC control plane and data plane in a 96 SFC-enabled domain. The document [I-D.dolson-sfc-hierarchical] 97 proposes a hierarchical SFC for multiple domains, which are 98 controlled by a single organization and trusted by each other, and 99 focus on data plane. [I-D. unify-sfc-control-plane-exp] provides an 100 insight into a Service Function Chain (SFC) control and Network 101 Function Virtualization (NFV) orchestration proof of concept 102 implementation and experimentation in multi-domain/technology 103 environments, which adopts a recursive control plane, but does not 104 consider the business model between different virtual network 105 providers or infrastructure providers to support a SFC spanning 106 domains with different ownership. 108 In this document, we consider SFCs traversing different domains 109 owned by different organizations (e.g., ISPs) or by a single 110 organization with administration partitions, which means an 111 overarching orchestrator or manager is infeasible for multi-domain 112 SFC. 114 The Hybrid Hierarchical SFC combines flat distributed control plane 115 and centralized hierarchical control plane. A centralized recursive, 116 hierarchical control plane is recommended to be deployed into a 117 large domain consisting of smaller sub-domains while a flat 118 distributed control plane is recommended to be deployed into 119 multiple large domains. 121 1.1. Scope 123 The "domain" discussed in this document is a logical concept. Domain 124 division depends on circumstances including but not limited to: geo- 125 location, technology, administration, or ownership. 127 This document focus on control plan. [I-D.dolson-sfc-hierarchical] 128 gives many discussions about data plane, especially internal 129 boundary node (IBN) path configuration. The four methods to 130 manipulate NSH are still practicable in this document. 132 In a recursive hierarchical control plane, an upper level plane is 133 responsible to abstract a lower level plane's topologies and 134 services. A mapping element is also needed in every control plane 135 level. The control protocol, abstraction, mapping mechanism and 136 interfaces are out of this document's scope. 138 In a flat distributed control plane, horizontal interfaces are used 139 to realize state sharing, context translation and policies 140 negotiation between domains. The protocol is out of this document's 141 scope. 143 1.2. Terminology 145 o Sub-domains: Smaller domains in a large administration/physical 146 domain. 148 o Multi-Domain Service Function Chaining A service function 149 chaining pass through multiple domains. 151 o SFC eXchange Platform: A logical entity that is used for the 152 negotiation between domains. It can be a trusted third-party 153 platform (e.g., deployed in future software defined IXP) or built 154 by a single owner between heterogeneous networks. 156 o Abstraction Element (AE) A logical entity that abstracts the 157 lower-level topology and services. 159 o Mapping Element (ME) A logical entity that map upper-level 160 instructions to lower-level control entities. 162 o Path Calculation Element (PCE): A logical entity that computes 163 service function paths (SFP). 165 o Information Base Element (IBE): A logical information base entity 166 that stores topology and service information acquired from the 167 abstraction element and provide them to the mapping element and 168 path calculation element. 170 1.3. Assumptions 172 We assume flexible and dynamic SFCs are based on Software Defined 173 Networking (SDN) and NFV that provides fine-grained packet 174 forwarding and decouples network functions from hardware 175 respectively. 177 Network virtualization and network function virtualization create 178 new business models such as service function as a service, e.g., a 179 third-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, every sub-domain 183 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 227 to realize intra-domain global optimization. 229 Abstraction Elements abstracts lower-level topology, service and 230 resource. Each level control plane computes service function paths 231 according to the information it acquired. For an upper-level control 232 plane in a domain, the path computation should concern inter- 233 subdomain optimization in a centralized way. For a lower-level 234 control plane, it only cares about the governed sub-domain. 236 Mapping Elements are responsible to translate the upper-level 237 instructions, which could contain abstracted services requirements, 238 service quality and overlay forwarding behaviors, to the lower-level 239 control instances. 241 Each level control plane has its own Information Base Elements. 242 Abstraction elements create, update or delete the information in 243 Information Base Elements. The information is utilized by Mapping 244 Elements and Path Calculation Elements. 246 2.2.2. Inter-domain 248 Horizontal interfaces should be deployed in the top-level control 249 plane to realize inter-domain communication, including State sharing, 250 context translation and policies negotiation. 252 Considering the circumstance that domains owned by different ISPs 253 connected by the Internet eXchange Ports, which could be a datacenter 254 implemented SDN technology in the future, a SFC eXchange Platform 255 (SXP) was proposed to support rich business models between different 256 organizations. Their distributed, multi-domain nature makes it 257 possible to enable a highly customized multi-domains SFC. 259 Figure 2 shows a SFC eXchange Platform connecting three different 260 domains. Figure 3 shows an overview of layered domains and SFC 261 eXchange Platform. In a function as service business model, inter- 262 domain path computation can be driven by service agreements. 263 Horizontal interfaces should be designed between domains and SFC 264 eXchange Platform. Figure 4 shows domains connected by distributed 265 SFC eXchange Platform. SFC eXchange Platforms server as brokers, 266 which orchestrate multi-domains SFC in a distributed way. 268 +-------------------+ 269 | +------+ +------+ | 270 | |Sub | |Sub | | 271 | |Domain| |Domain| | 272 | +------+ +------+ | 273 | Domain 2 | 274 +--------> +------+ +------+ | 275 +-------------------+ | | |Sub | |Sub | | 276 | +------+ +------+ | | | |Domain| |Domain| | 277 | |Sub | |Sub | | | | +------+ +------+ | 278 | |Domain| |Domain| | +------v--+ +-------------------+ 279 | +------+ +------+ | |SFC | 280 | Domain 1 | |eXchange | +-------------------+ 281 | +------+ +------+ <---->Platform | | +------+ +------+ | 282 | |Sub | |Sub | | | <-----> |Sub | |Sub | | 283 | |Domain| |Domain| | +---------+ | |Domain| |Domain| | 284 | +------+ +------+ | | +------+ +------+ | 285 +-------------------+ | Domain 3 | 286 | +------+ +------+ | 287 | |Sub | |Sub | | 288 | |Domain| |Domain| | 289 | +------+ +------+ | 290 +-------------------+ 292 Figure 2: Multiple SFC domains connected by a SFC eXchange Platform 294 +-------------------+ +-------------------+ 295 | Domain 1 | | Domain 2 | 296 | +---------------+ | | +---------------+ | 297 | | SFC <---+ +------------------+ +---> SFC | | 298 | |Control Plane | | | | SFC eX Platform | | | | Control Plane| | 299 | |Orchestrator | | | | +--------------+ | | | | Orchestrator | | 300 | |SDN Controler | | +---> Negotiation <---+ | | SDN Controler| | 301 | +---------------+ | | | Orchestrator | | | +---------------+ | 302 | | | +--------------+ | | | 303 | +---------------+ | | | | | | +---------------+ | 304 | | | | | |SDN Controller| | | | | | 305 | | Data Plane | | | +--------------+ | | | Data Plane| | 306 | | <-----> | Data Plane | <-----> | | 307 | +---------------+ | | +--------------+ | | +---------------+ | 308 +-------------------+ +------------------+ +-------------------+ 309 Figure 3: Service Function Chaining Exchanging Platform 311 +-------+ +-------+ +-------+ 312 | | +--------+ | | +--------+ | | 313 | | | SFC | | | | SFC | | | 314 |Domains<--->eXchange<--->Domains<--->eXchange<--->Domains| 315 | | |Platform| | | |Platform| | | 316 +-------+ +--------+ +-------+ +--------+ +-------+ 317 Figure 4: Distributed SFC eX Platforms 319 2.3. Data plane 321 2.3.1. Intra-domain 323 The discussion about SFC data plane components in top levels and 324 lower levels in the document [draft-ietf-sfc-hierarchical-02] can be 325 applied in the recursive hierarchical domain defined by this 326 document. It proposes five methods to restore packets to original 327 upper-level after exiting a path in the sub-domain, which are also 328 feasible. 330 2.3.2. Inter-domain 332 When packets go out of a domain, the inter-domain NSH should be 333 added. Using unique path is recommended to manipulate inter-domain 334 NSH. 336 When domains are connected by SDN-enabled SFC eXchange Platforms, 337 which act as SFFs for Multi-domain SFC, the SFC eXchange Platforms 338 will forwarding traffics according to the inter-domain SPI/SI. 340 3. SFC eXchange Platform 342 The inter-domain traffic classify rules should be negotiated and 343 decided by administrators of each domain with service agreements and 344 policies. Distributed SFC eXchange Platforms select the service 345 function location from multiple candidate domains. 347 3.1. Inter-domain negotiation 349 As a trusted third-party platform, the SFC eXchange platform may not 350 orchestrate the Multi-Domain SFC directly. In other words, it only 351 exchanges and collect domains' service states and policies. Every 352 domain can decide their own multi-domain SFP according to the states 353 and agreements. The SFC eXchange Platform implements the negotiation 354 results and decisions for domains, such as flow-specific peering. 355 Based on the SFC eXchange Platform, rich business models may appear. 357 3.2. End-to-end orchestration 359 In a multi-domain environment, end-to-end visibility could be 360 realized by the exchange platform. One of all exchange platforms 361 (e.g. the nearest one) can be selected as a manager and takes charge 362 of the end-to-end performance. Exchange platforms communicate with 363 each other and exchange neighboring domains' SFC performance. 364 Optimal domains can be selected from all candidates by the manager. 365 If the performance deteriorates in certain domain, the manager could 366 coordinate with other domains and switch flows to another domain. 367 Dynamic and context aware Multi-domain SFC is achievable relaying on 368 the exchange platform. 370 4. Security Considerations 372 Authentication mechanism must be applied between intra-domain 373 control plane levels and inter-domain control elements. Lower-level 374 control plane elements must ignore any instructions from 375 authenticated upper-level control plane elements. 377 5. References 379 5.1. Normative References 381 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 382 Chaining (SFC) Architecture", RFC 7665, DOI 383 10.17487/RFC7665, October 2015. 385 5.2. Informative References 387 [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", 388 draft-ietf-sfc-nsh-10 (work in progress), September 2016. 390 [I-D.ietf-sfc-control-plane] Li, H., Wu, Q., Huang, O., Boucadair, 391 M., Jacquenet, C., Haeffner, W., Lee, S., Parker, R., 392 Dunbar, L., Malis, A., Halpern, J., Reddy, T., and P. 393 Patil, "Service Function Chaining (SFC) Control Plane 394 Components & Requirements", draft-ietf-sfc-control-plane- 395 06 (work in progress), August 2016. 397 [I-D.ietf-sfc-hierarchical] Dolson, D., Homma, S., Lopez, D., 398 Boucadair, M., D. Liu, Ao, T. and Vu, V. "Hierarchical 399 Service Function Chaining", draft-ietf-sfc-hierarchical-02 400 (work in progress), Mar 2016 402 [I-D.unify-sfc-control-plane-exp] Szabo, R. and B. Sonkoly, "SFC 403 Control Plane Experiment: UNIFYed Approach", draft-unify- 404 sfc-control-plane-exp-00, March 2016. 406 [Software Defined internet exchange] Gupta A, Vanbever L, Shahbaz M, 407 et al. Sdx: A software defined internet exchange. ACM 408 SIGCOMM Computer Communication Review, 2015. 410 [MD2-NFV] Rosa R V, Silva Santos M A, Esteve Rothenberg C. Md2-nfv: 411 The case for multi-domain distributed network functions 412 virtualization. Networked Systems (NetSys), 2015 413 International Conference and Workshops on. 415 6. Acknowledgments 417 The work in this document was supported by National High Technology 418 of China ("863 program") under Grant No.2015AA015702. 420 Authors' Addresses 422 Guanglei Li 423 Beijing Jiaotong University 424 Beijing, 100044, P.R. China 426 Email: 15111035@bjtu.edu.cn 428 Guanwen Li 429 Beijing Jiaotong University 430 Beijing, 100044, P.R. China 432 Email: 14120079@bjtu.edu.cn 434 Taixin Li 435 Beijing Jiaotong University 436 Beijing, 100044, P.R. China 438 Email: 14111040@bjtu.edu.cn 440 Qi Xu 441 Beijing Jiaotong University 442 Beijing, 100044, P.R. China 444 Email: 15111046@bjtu.edu.cn 445 Huachun Zhou 446 Beijing Jiaotong University 447 Beijing, 100044, P.R. China 449 Email: hchzhou@bjtu.edu.cn