idnits 2.17.1 draft-li-sfc-hhsfc-01.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 (October 21, 2016) is 2743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7665' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'I-D.unify-sfc-control-plane-exp' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'MD2-NFV' is defined on line 432, 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-01 Summary: 1 error (**), 0 flaws (~~), 8 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 October 21, 2016 8 Expires: April 2017 10 Hybrid Hierarchical Multi-Domain Service Function chaining 11 draft-li-sfc-hhsfc-01.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 November 25, 2016. 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 4. Security Considerations ..................................... 9 78 5. References .................................................. 9 79 5.1. Normative References ................................... 9 80 5.2. Informative References ................................ 10 81 6. Acknowledgments ............................................ 10 83 1. Introduction 85 Service Function Chaining supports customer traffic passing through 86 an ordered list of functions as required. 88 The [I-D.ietf-sfc-nsh] creates a service plane via Network Service 89 Headers (NSH), which provide data-plane information to construct 90 service paths and transfer metadata. 92 The document [I-D.ietf-sfc-control-plane] describes requirements for 93 conveying information between SFC control plane and data plane in a 94 SFC-enabled domain. The document [I-D.dolson-sfc-hierarchical] 95 proposes a hierarchical SFC for multiple domains, which are 96 controlled by a single organization and trusted by each other, and 97 focus on data plane. [I-D. unify-sfc-control-plane-exp] provides an 98 insight into a Service Function Chain (SFC) control and Network 99 Function Virtualization (NFV) orchestration proof of concept 100 implementation and experimentation in multi-domain/technology 101 environments, which adopts a recursive control plane, but does not 102 consider the business model between different virtual network 103 providers or infrastructure providers to support a SFC spanning 104 domains with different ownership. 106 In this document, we consider SFCs traversing different domains 107 owned by different organizations (e.g., ISPs) or by a single 108 organization with administration partitions (e.g., for purpose of 109 security isolation), which means an overarching orchestrator or 110 manager is infeasible for multi-domain SFC. 112 The Hybrid Hierarchical SFC combines flat distributed control plane 113 and centralized hierarchical control plane. A centralized recursive, 114 hierarchical control plane is recommended to be deployed into a 115 large administration domain consisting of smaller sub-domains while 116 a flat distributed control plane is recommend to be deployed into 117 multiple large administration domains. 119 1.1. Scope 121 The "domain" discussed in this document is a logical concept. Domain 122 division depends on circumstances including but not limited to: geo- 123 location, technology, administration, security policy or ownership. 124 While a logical centralized control plane over multiple physical 125 domains might still be feasible with virtual network embedding, the 126 distributed control plane aims at those circumstances where a 127 centralized paradigm is inapplicable. 129 This document focus on control plan. [I-D.dolson-sfc-hierarchical] 130 gives many discussions about data plane, especially internal 131 boundary node (IBN) path configuration. The four methods to 132 manipulate NSH are still practicable in this document. 134 In a recursive hierarchical control plane, an upper level plane is 135 responsible to abstract a lower level plane's topologies and 136 services. A mapping element is also needed in every control plane 137 level. The control protocol, abstraction, mapping mechanism and 138 interfaces are out of this document's scope. 140 In a flat distributed control plane, horizontal interfaces are used 141 to realize state sharing, context translation and policies 142 negotiation between domains. The protocol is out of this document's 143 scope. 145 1.2. Terminology 147 o Sub-domains: Smaller domains in a large administration/physical 148 domain. 150 o Multi-Domain Service Function Chaining A service function 151 chaining pass through multiple domains. 153 o SFC eXchange Platform: A logical entity that is used for the 154 negotiation between domains. It can be a trusted third-party 155 platform (e.g., deployed in future software defined IXP) or built 156 by a single owner between heterogeneous networks. 158 o Abstraction Element (AE) A logical entity that abstracts the 159 lower-level topology and services. 161 o Mapping Element (ME) A logical entity that map upper-level 162 instructions to lower-level control entities. 164 o Path Calculation Element (PCE): A logical entity that computes 165 service function paths (SFP). 167 o Information Base Element (IBE): A logical information base entity 168 that stores topology and service information acquired from the 169 abstraction element and provide them to the mapping element and 170 path calculation element. 172 1.3. Assumptions 174 We assume flexible and dynamic SFCs are based on Software Defined 175 Networking (SDN) and NFV that provides fine-grained packet 176 forwarding and decouples network functions from hardware 177 respectively. 179 Network virtualization and network function virtualization create 180 new business models such as service function as a service, e.g., a 181 third-part Software Defined IXP (SDX) between ISPs can provides a 182 negotiation platform to support Multi-domain SFC. 184 In this document, a domain consists of sub-domains, every sub-domain 185 has its own control plane. A single-level control plane is 186 impractical considering the scalability and complexity of control 187 plane. 189 2. Hybrid Hierarchical Service Function Chaining 191 2.1. Architecture 193 Figure 1 shows an example of two-level and two-domain hybrid 194 hierarchical structure. In practice, there could be more levels and 195 domains. In every single domain, each control plane instance manages 196 a single level. Each control plane is agnostic about other levels of 197 hierarchy. Sub-domain control-planes are agnostic about control- 198 planes of other sub-domains. The expectations to control plane in 199 the document [draft-dolson-sfc-hierarchical] are satisfied. 201 +------------+ +------------+ 202 | +->IBE-+ | | +->IBE-+ | 203 | | + v <----------------------> | + v | 204 | v v PCE | | v v PCE | 205 | AE ME<-+ | upper-level | AE ME<-+ | 206 +-^-+-----+-^+Control Plane +^-+------^--+ 207 | | | | | | | | 208 | | | | | | | | 209 +---------v-+ +v----------+ +----------v+ +v----------+ 210 | +->IBE-+ | | +->IBE-+ | | +->IBE-+ | | +->IBE-+ | 211 | | + v | | | + v | | | + v | | | + v | 212 | v v PCE | | v v PCE | | v v PCE | | v v PCE | 213 | AE ME<-+ | | AE ME<-+ | | AE ME<-+ | | AE ME<-+ | 214 +--+--------+ +---^-------+ +---^-------+ +---^-------+ 215 ^ | lower-level | | 216 | | Control Plane | | 217 +-----+-------+ +---v---------+ +----v--------+ +--v---------+ 218 | Data Plane | | Data Plane | | Data Plane | | Data Plane| 219 | | | | | | | | 220 | Sub-Domain | | Sub-Domain | | Sub-Domain | | Sub-Domain| 221 +-------------+ +-------------+ +-------------+ +------------+ 222 Figure 1: Architecture 224 2.2. Control plane 226 2.2.1. Intra-domain 228 Several important elements are required in every level control plane 229 to realize intra-domain global optimization. 231 Abstraction Elements abstracts lower-level topology, service and 232 resource. Each level control plane computes service function paths 233 according to the information it acquired. For an upper-level control 234 plane in a domain, the path computation should concern inter- 235 subdomain optimization in a centralized way. For a lower-level 236 control plane, it only cares about the governed sub-domain. 238 Mapping Elements are responsible to translate the upper-level 239 instructions, which could contain abstracted services requirements, 240 service quality and overlay forwarding behaviors, to the lower-level 241 control instances. 243 Each level control plane has its own Information Base Elements. 244 Abstraction elements create, update or delete the information in 245 Information Base Elements. The information is utilized by Mapping 246 Elements and Path Calculation Elements. 248 2.2.2. Inter-domain 250 Horizontal interfaces should be deployed in the top level control 251 plane to realize inter-domain communication, including State sharing, 252 context translation and policies negotiation. 254 Considering the circumstance that domains owned by different ISPs 255 connected by the Internet eXchange Ports, which could be a datacenter 256 implemented SDN technology in the future, a SFC eXchange Platform 257 (SXP) was proposed to support rich business models between different 258 organizations. Their distributed, multi-domain nature makes it 259 possible to enable a highly customized multi-domains SFC. 261 Figure 2 shows a SFC eXchange Platform connecting three different 262 domains. Figure 3 shows an overview of layered domains and SFC 263 eXchange Platform. In a function as service business model, inter- 264 domain path computation can be driven by service agreements. 265 Horizontal interfaces should be designed between domains and SFC 266 eXchange Platform. Figure 4 shows domains connected by distributed 267 SFC eXchange Platform. SFC eXchange Platforms server as brokers, 268 which orchestrate multi-domains SFC in a distributed way. 270 +-------------------+ 271 | +------+ +------+ | 272 | |Sub | |Sub | | 273 | |Domain| |Domain| | 274 | +------+ +------+ | 275 | Domain 2 | 276 +--------> +------+ +------+ | 277 +-------------------+ | | |Sub | |Sub | | 278 | +------+ +------+ | | | |Domain| |Domain| | 279 | |Sub | |Sub | | | | +------+ +------+ | 280 | |Domain| |Domain| | +------v--+ +-------------------+ 281 | +------+ +------+ | |SFC | 282 | Domain 1 | |eXchange | +-------------------+ 283 | +------+ +------+ <---->Platform | | +------+ +------+ | 284 | |Sub | |Sub | | | <-----> |Sub | |Sub | | 285 | |Domain| |Domain| | +---------+ | |Domain| |Domain| | 286 | +------+ +------+ | | +------+ +------+ | 287 +-------------------+ | Domain 3 | 288 | +------+ +------+ | 289 | |Sub | |Sub | | 290 | |Domain| |Domain| | 291 | +------+ +------+ | 292 +-------------------+ 294 Figure 2: Multiple SFC domains connected by a SFC eXchange Platform 296 +-------------------+ +-------------------+ 297 | Domain 1 | | Domain 2 | 298 | +---------------+ | | +---------------+ | 299 | | SFC <---+ +------------------+ +---> SFC | | 300 | |Control Plane | | | | SFC eX Platform | | | | Control Plane| | 301 | |Orchestrator | | | | +--------------+ | | | | Orchestrator | | 302 | |SDN Controler | | +---> Negotiation <---+ | | SDN Controler| | 303 | +---------------+ | | | Orchestrator | | | +---------------+ | 304 | | | +--------------+ | | | 305 | +---------------+ | | | | | | +---------------+ | 306 | | | | | |SDN Controller| | | | | | 307 | | Data Plane | | | +--------------+ | | | Data Plane| | 308 | | <-----> | Data Plane | <-----> | | 309 | +---------------+ | | +--------------+ | | +---------------+ | 310 +-------------------+ +------------------+ +-------------------+ 311 Figure 3: Service Function Chaining Exchanging Platform 313 +-------+ +-------+ +-------+ 314 | | +--------+ | | +--------+ | | 315 | | | SFC | | | | SFC | | | 316 |Domains<--->eXchange<--->Domains<--->eXchange<--->Domains| 317 | | |Platform| | | |Platform| | | 318 +-------+ +--------+ +-------+ +--------+ +-------+ 319 Figure 4: Distributed SFC eX Platforms 321 2.3. Data plane 323 2.3.1. Intra-domain 325 The discussion about SFC data plane components in top levels and 326 lower levels in the document [draft-dolson-sfc-hierarchical] can be 327 applied in the recursive hierarchical domain defined by this 328 document. 330 The document [draft-dolson-sfc-hierarchical] proposes four methods 331 to restore packets to original upper-level after exiting a path in 332 the sub-domain, including flow-stateful IBN, encoding upper-level 333 paths in metadata, using unique paths per upper-level path and 334 nesting upper-level NSH within lower-level NSH, which are also 335 feasible. 337 2.3.2. Inter-domain 339 When packets go out of a domain, the inter-domain NSH should be 340 added. Encoding inter-domain path in metadata or using unique path 341 is recommended to manipulate inter-domain NSH. 343 When domains are connected by SDN-enabled SFC eXchange Platforms, 344 which act as SFFs for Multi-domain SFC, the SFC eXchange Platforms 345 will forwarding traffics according to the inter-domain Service Path 346 Identifier (SPI). 348 3. SFC eXchange Platform 350 The inter-domain traffic classify rules should be negotiated and 351 decided by administrators of each domain with service agreements and 352 policies. Distributed SFC eXchange Platforms select the service 353 function location from multiple candidate domains. 355 3.1. Inter-domain negotiation 357 As a trusted third-party platform, the SFC eXchange platform may not 358 orchestrate the Multi-Domain SFC directly. In other words, it only 359 exchanges and collect domains' service states and policies. Every 360 domain can decide their own multi-domain SFP according to the states 361 and agreements. The SFC eXchange Platform also implements the 362 negotiation results and decisions for domains, such as flow-specific 363 peering. 365 Based on the SFC eXchange Platform, rich business models may appear, 366 such as competitive models for service functions. Service providers 367 may compete to provide high availability and bandwidth to attract 368 traffic and increase customer acquisition. 370 3.2. End-to-end orchestration 372 In a multi-domain environment, end-to-end visibility could be 373 realized by the exchange platform. One of all exchange platforms 374 (e.g. the nearest one) can be selected as a manager and takes charge 375 of the end-to-end performance. Exchange platforms communicate with 376 each other and exchange neighboring domains' SFC performance. 377 Optimal sub-domains can be selected from all candidates by the 378 manager. If the performance deteriorates in certain domain, the 379 manager could coordinate with other domains and switch flows to 380 another domain. 382 Dynamic and context aware Multi-domain SFC is achievable relaying on 383 the exchange platform. For example, if a mobile user's location is 384 added in a context header at local SFC-enabled sub-domain ingress 385 node, when it moves to a new locations, a new Multi-domain SFP with 386 better delay performance can be applied according to the new 387 location. 389 4. Security Considerations 391 Authentication mechanism must be applied between intra-domain 392 control plane levels and inter-domain control elements. Lower-level 393 control plane elements must ignore any instructions from 394 authenticated upper-level control plane elements. 396 If SFC eXchange Platforms are implemented, the access to this 397 platform must be authenticated. 399 5. References 401 5.1. Normative References 403 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 404 Chaining (SFC) Architecture", RFC 7665, DOI 405 10.17487/RFC7665, October 2015. 407 5.2. Informative References 409 [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", 410 draft-ietf-sfc-nsh-10 (work in progress), September 2016. 412 [I-D.ietf-sfc-control-plane] Li, H., Wu, Q., Huang, O., Boucadair, 413 M., Jacquenet, C., Haeffner, W., Lee, S., Parker, R., 414 Dunbar, L., Malis, A., Halpern, J., Reddy, T., and P. 415 Patil, "Service Function Chaining (SFC) Control Plane 416 Components & Requirements", draft-ietf-sfc-control-plane- 417 06 (work in progress), August 2016. 419 [I-D.dolson-sfc-hierarchical] Dolson, D., Homma, S., Lopez, D., 420 Boucadair, M., D. Liu, Ao, T. and Vu, V. "Hierarchical 421 Service Function Chaining", draft-ietf-sfc-hierarchical-01 422 (work in progress), Mar 2016 424 [I-D.unify-sfc-control-plane-exp] Szabo, R. and B. Sonkoly, "SFC 425 Control Plane Experiment: UNIFYed Approach", draft-unify- 426 sfc-control-plane-exp-00, March 2016. 428 [Software Defined internet exchange] Gupta A, Vanbever L, Shahbaz M, 429 et al. Sdx: A software defined internet exchange. ACM 430 SIGCOMM Computer Communication Review, 2015. 432 [MD2-NFV] Rosa R V, Silva Santos M A, Esteve Rothenberg C. Md2-nfv: 433 The case for multi-domain distributed network functions 434 virtualization. Networked Systems (NetSys), 2015 435 International Conference and Workshops on. 437 6. Acknowledgments 439 The work in this document was supported by National High Technology 440 of China ("863 program") under Grant No.2015AA015702. 442 Authors' Addresses 444 Guanglei Li 445 Beijing Jiaotong University 446 Beijing, 100044, P.R. China 448 Email: 15111035@bjtu.edu.cn 449 Guanwen Li 450 Beijing Jiaotong University 451 Beijing, 100044, P.R. China 453 Email: 14120079@bjtu.edu.cn 455 Taixin Li 456 Beijing Jiaotong University 457 Beijing, 100044, P.R. China 459 Email: 14111040@bjtu.edu.cn 461 Qi Xu 462 Beijing Jiaotong University 463 Beijing, 100044, P.R. China 465 Email: 15111046@bjtu.edu.cn 467 Huachun Zhou 468 Beijing Jiaotong University 469 Beijing, 100044, P.R. China 471 Email: hchzhou@bjtu.edu.cn