idnits 2.17.1 draft-bernardos-nfvrg-multidomain-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFV RG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Informational LM. Contreras 5 Expires: May 4, 2017 TID 6 I. Vaishnavi 7 Huawei 8 October 31, 2016 10 Multi-domain Network Virtualization 11 draft-bernardos-nfvrg-multidomain-01 13 Abstract 15 This draft analyzes the problem of multi-provider multi-domain 16 orchestration, by first scoping the problem, then looking into 17 potential architectural approaches, and finally describing the 18 solutions being developed by the European 5GEx project. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 4, 2017. 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 respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Background: the ETSI NFV 57 architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Multidomain problem statement . . . . . . . . . . . . . . . . 6 59 5. Multi-domain architectural approaches . . . . . . . . . . . . 7 60 5.1. ETSI NFV approaches . . . . . . . . . . . . . . . . . . . 7 61 5.2. Hierarchical . . . . . . . . . . . . . . . . . . . . . . 10 62 5.3. Cascading . . . . . . . . . . . . . . . . . . . . . . . . 12 63 6. Virtualization and Control for 64 Multi-Provider Multi-Domain . . . . . . . . . . . . . . . . . 12 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 10. Informative References . . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 The telecommunications sector is experiencing a major revolution that 74 will shape the way networks and services are designed and deployed 75 for the next decade. We are witnessing an explosion in the number of 76 applications and services demanded by users, which are now really 77 capable of accessing them on the move. In order to cope with such a 78 demand, some network operators are looking at the cloud computing 79 paradigm, which enables a potential reduction of the overall costs by 80 outsourcing communication services from specific hardware in the 81 operator's core to server farms scattered in datacenters. These 82 services have different characteristics if compared with conventional 83 IT services that have to be taken into account in this cloudification 84 process. Also the transport network is affected in that it is 85 evolving to a more sophisticated form of IP architecture with trends 86 like separation of control and data plane traffic, and more fine- 87 grained forwarding of packets (beyond looking at the destination IP 88 address) in the network to fulfill new business and service goals. 90 Virtualization of functions also provides operators with tools to 91 deploy new services much faster, as compared to the traditional use 92 of monolithic and tightly integrated dedicated machinery. As a 93 natural next step, mobile network operators need to re-think how to 94 evolve their existing network infrastructures and how to deploy new 95 ones to address the challenges posed by the increasing customers' 96 demands, as well as by the huge competition among operators. All 97 these changes are triggering the need for a modification in the way 98 operators and infrastructure providers operate their networks, as 99 they need to significantly reduce the costs incurred in deploying a 100 new service and operating it. Some of the mechanisms that are being 101 considered and already adopted by operators include: sharing of 102 network infrastructure to reduce costs, virtualization of core 103 servers running in data centers as a way of supporting their load- 104 aware elastic dimensioning, and dynamic energy policies to reduce the 105 monthly electricity bill. However, this has proved to be tough to 106 put in practice, and not enough. Indeed, it is not easy to deploy 107 new mechanisms in a running operational network due to the high 108 dependency on proprietary (and sometime obscure) protocols and 109 interfaces, which are complex to manage and often require configuring 110 multiple devices in a decentralized way. 112 Network Function Virtualization (NFV) and Software Defined Networking 113 (SDN) are changing the way the telecommunications sector will deploy, 114 extend and operate their networks. TBD: add multi-domain. 116 2. Terminology 118 The following terms used in this document are defined by the ETSI NVF 119 ISG, and the ONF and the IETF: 121 NFV Infrastructure (NFVI): totality of all hardware and software 122 components which build up the environment in which VNFs are 123 deployed 125 NFV Management and Orchestration (NFV-MANO): functions 126 collectively provided by NFVO, VNFM, and VIM. 128 NFV Orchestrator (NFVO): functional block that manages the Network 129 Service (NS) lifecycle and coordinates the management of NS 130 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 131 resources (supported by the VIM) to ensure an optimized allocation 132 of the necessary resources and connectivity. 134 Network Service Orchestration (NSO): function responsible for the 135 Network Service lifecycle management, including operations such 136 as: On-board Network Service, Instantiate Network Service, Scale 137 Network Service, Update Network Service, etc. 139 OpenFlow protocol (OFP): allowing vendor independent programming 140 of control functions in network nodes. 142 Resource Orchestration (RO): subset of NFV Orchestrator functions 143 that are responsible for global resource management governance. 145 Service Function Chain (SFC): for a given service, the abstracted 146 view of the required service functions and the order in which they 147 are to be applied. This is somehow equivalent to the Network 148 Function Forwarding Graph (NF-FG) at ETSI. 150 Service Function Path (SFP): the selection of specific service 151 function instances on specific network nodes to form a service 152 graph through which an SFC is instantiated. 154 Virtualized Infrastructure Manager (VIM): functional block that is 155 responsible for controlling and managing the NFVI compute, storage 156 and network resources, usually within one operator's 157 Infrastructure Domain. 159 Virtualized Network Function (VNF): implementation of a Network 160 Function that can be deployed on a Network Function Virtualization 161 Infrastructure (NFVI). 163 Virtualized Network Function Manager (VNFM): functional block that 164 is responsible for the lifecycle management of VNF. 166 3. Background: the ETSI NFV architecture 168 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 169 quasi-standard IT virtualization technology to consolidate many 170 network equipment types into industry standard high volume servers, 171 switches, and storage. It enables implementing network functions in 172 software that can run on a range of industry standard server hardware 173 and can be moved to, or loaded in, various locations in the network 174 as required, without the need to install new equipment. To date, 175 ETSI NFV is by far the most accepted NFV reference framework and 176 architectural footprint [etsi_nvf_whitepaper]. The ETSI NFV 177 framework architecture framework is composed of three domains 178 (Figure 1): 180 o Virtualized Network Function, running over the NFVI. 182 o NFV Infrastructure (NFVI), including the diversity of physical 183 resources and how these can be virtualized. NFVI supports the 184 execution of the VNFs. 186 o NFV Management and Orchestration, which covers the orchestration 187 and life-cycle management of physical and/or software resources 188 that support the infrastructure virtualization, and the life-cycle 189 management of VNFs. NFV Management and Orchestration focuses on 190 all virtualization specific management tasks necessary in the NFV 191 framework. 193 +-------------------------------------------+ +---------------+ 194 | Virtualized Network Functions (VNFs) | | | 195 | ------- ------- ------- ------- | | | 196 | | | | | | | | | | | | 197 | | VNF | | VNF | | VNF | | VNF | | | | 198 | | | | | | | | | | | | 199 | ------- ------- ------- ------- | | | 200 +-------------------------------------------+ | | 201 | | 202 +-------------------------------------------+ | | 203 | NFV Infrastructure (NFVI) | | NFV | 204 | ----------- ----------- ----------- | | Management | 205 | | Virtual | | Virtual | | Virtual | | | and | 206 | | Compute | | Storage | | Network | | | Orchestration | 207 | ----------- ----------- ----------- | | | 208 | +---------------------------------------+ | | | 209 | | Virtualization Layer | | | | 210 | +---------------------------------------+ | | | 211 | +---------------------------------------+ | | | 212 | | ----------- ----------- ----------- | | | | 213 | | | Compute | | Storage | | Network | | | | | 214 | | ----------- ----------- ----------- | | | | 215 | | Hardware resources | | | | 216 | +---------------------------------------+ | | | 217 +-------------------------------------------+ +---------------+ 219 Figure 1: ETSI NFV framework 221 The NFV architectural framework identifies functional blocks and the 222 main reference points between such blocks. Some of these are already 223 present in current deployments, whilst others might be necessary 224 additions in order to support the virtualization process and 225 consequent operation. The functional blocks are (Figure 2): 227 o Virtualized Network Function (VNF). 229 o Element Management (EM). 231 o NFV Infrastructure, including: Hardware and virtualized resources, 232 and Virtualization Layer. 234 o Virtualized Infrastructure Manager(s) (VIM). 236 o NFV Orchestrator. 238 o VNF Manager(s). 240 o Service, VNF and Infrastructure Description. 242 o Operations and Business Support Systems (OSS/BSS). 244 +--------------------+ 245 +-------------------------------------------+ | ---------------- | 246 | OSS/BSS | | | NFV | | 247 +-------------------------------------------+ | | Orchestrator +-- | 248 | ---+------------ | | 249 +-------------------------------------------+ | | | | 250 | --------- --------- --------- | | | | | 251 | | EM 1 | | EM 2 | | EM 3 | | | | | | 252 | ----+---- ----+---- ----+---- | | ---+---------- | | 253 | | | | |--|-| VNF | | | 254 | ----+---- ----+---- ----+---- | | | manager(s) | | | 255 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 256 | ----+---- ----+---- ----+---- | | | | | 257 +------|-------------|-------------|--------+ | | | | 258 | | | | | | | 259 +------+-------------+-------------+--------+ | | | | 260 | NFV Infrastructure (NFVI) | | | | | 261 | ----------- ----------- ----------- | | | | | 262 | | Virtual | | Virtual | | Virtual | | | | | | 263 | | Compute | | Storage | | Network | | | | | | 264 | ----------- ----------- ----------- | | ---+------ | | 265 | +---------------------------------------+ | | | | | | 266 | | Virtualization Layer | |--|-| VIM(s) +-------- | 267 | +---------------------------------------+ | | | | | 268 | +---------------------------------------+ | | ---------- | 269 | | ----------- ----------- ----------- | | | | 270 | | | Compute | | Storage | | Network | | | | | 271 | | | hardware| | hardware| | hardware| | | | | 272 | | ----------- ----------- ----------- | | | | 273 | | Hardware resources | | | NFV Management | 274 | +---------------------------------------+ | | and Orchestration | 275 +-------------------------------------------+ +--------------------+ 277 Figure 2: ETSI NFV reference architecture 279 4. Multidomain problem statement 281 Market fragmentation results from having a multitude of 282 telecommunications network and cloud operators each with a footprint 283 focused to a specific region. This makes it difficult to deploy cost 284 effective infrastructure services, such as virtual connectivity or 285 compute resources, spanning multiple countries as no single operator 286 has a big enough footprint. Even if operators largely aim to provide 287 the same infrastructure services (VPN connectivity, compute resources 288 based on virtual machines and block storage), inter-operator 289 collaboration tools for providing a service spanning several 290 administrative boundaries are very limited and cumbersome. This 291 makes service development and provisioning very time consuming. For 292 example, having a VPN with end-points in several countries, in order 293 to connect multiple sites of a business (such as a hotel chain), 294 requires contacting several network operators. Such an approach is 295 possible only with significant effort and integration work from the 296 side of the business. This is not only slow, but also inefficient 297 and expensive, since the business also needs to employ networking 298 specialists to do the integration instead of focusing on its core 299 business 301 Technology fragmentation also represents a major bottleneck 302 internally for an operator. Different networks and different parts 303 of a network may be built as different domains using separate 304 technologies, such as optical or packet switched (with different 305 packet switching paradigms included); having equipment from different 306 vendors; having different control paradigms, etc. Managing and 307 integrating these separate technology domains requires substantial 308 amount of effort, expertise, and time. The associated costs are paid 309 by both network operators and vendors alike, who need to design 310 equipment and develop complex integration features. In addition to 311 technology domains, there are other reasons for having multiple 312 domains within an operator, such as, different geographies, different 313 performance characteristics, scalability, policy or simply historic 314 (e.g., result of a merge or an acquisition). Multiple domains in a 315 network are a necessary and permanent feature however, these should 316 not be a roadblock towards service development and provisioning, 317 which should be fast and efficient. 319 A solution is needed to deal with both the multi-operator 320 collaboration issue, and address the multi-domain problem within a 321 single network operator. While these two problems are quite 322 different, they also share a lot of common aspects and can benefit 323 from having a number of common tools to solve them. 325 5. Multi-domain architectural approaches 327 This section summarizes different architectural options that can be 328 considered to tackle the multi-domain orchestration problem. 330 5.1. ETSI NFV approaches 332 Recently, the ETSI NFV ISG has started to look into viable 333 architectural options supporting the placement of functions in 334 different administrative domains. In the document [etsi_nvf_ifa009], 335 different approaches are considered, which we summarize next. 337 The first option (shown in Figure 3) is based on a split of the NFVO 338 into Network Service Orchestrator (NSO) and Resource Orchestrator 339 (RO). A use case that this separation could enable is the following: 340 a network operator offering its infrastructure to different 341 departments within the same operator, as well as to a different 342 network operator like in cases of network sharing agreements. In 343 this scenario, an administrative domain can be defined as one or more 344 data centers and VIMs, providing an abstracted view of the resources 345 hosted in it. 347 A service is orchestrated out of VNFs that can run on infrastructure 348 provided and managed by another Service Provider. The NSO manages 349 the lifecycle of network services, while the RO provides an overall 350 view of the resources present in the administrative domain to which 351 it provides access and hides the interfaces of the VIMs present below 352 it. 354 ------- 355 | NSO | 356 /-------\ 357 / \ 358 -------- / -------- \ -------- 359 | VNFM | | | VNFM | | | VNFM | 360 -------- / -------- \ -------- 361 / ____/ / \ \____ \ 362 / / _________/ \_________ \ \ 363 / / / \ \ \ 364 +-----------/-/-/---------+ +----------\-\-\----------+ 365 | --------- | | --------- | 366 | | RO | | | | RO | | 367 | --------- | | --------- | 368 | / | \ | | / | \ | 369 | / | \ | | / | \ | 370 | / | \ | | / | \ | 371 | ------- ------- ------- | | ------- ------- ------- | 372 | |VIM 1| |VIM 2| |VIM 3| | | |VIM 1| |VIM 2| |VIM 3| | 373 | ------- ------- ------- | | ------- ------- ------- | 374 | Administrative domain A | | Administrative domain B | 375 +-------------------------+ +-------------------------+ 377 Figure 3: Infrastructure provided using multiple administrative 378 domains (from ETSI GS NFV-IFA 009 V1.1.1) 380 The second option (shown in Figure 4) is based on having an umbrella 381 NFVO. A use case enabled by this is the following: a Network 382 Operator offers Network Services to different departments within the 383 same operator, as well as to a different network operator like in 384 cases of network sharing agreements. In this scenario, an 385 administrative domain is compose of one or more Datacentres, VIMs, 386 VNFMs (together with their related VNFs) and NFVO, allowing distinct 387 specific sets of network services to be hosted and offered on each. 389 A top Network Service can include another Network Service. A Network 390 Service containing other Network Services might also contain VNFs. 391 The NFVO in each admin domain provides visibility of the Network 392 Services specific to this admin domain. The umbrella NFVO is 393 providing the lifecycle management of umbrella network services 394 defined in this NFVO. In each admin domain, the NFVO is providing 395 standard NFVO functionalities, with a scope limited to the network 396 services, VNFs and resources that are part of its admin domain. 398 ------------ 399 | Umbrella | 400 | NFVO | 401 ------------ 402 / | \ 403 / | \ 404 / -------- \ 405 / | VNFM | \ 406 / -------- \ 407 / | \ 408 / ------- \ 409 / |VIM 1| \ 410 / ------- \ 411 --------------/------------ -------------\------------- 412 | -------- | | -------- | 413 | | NFVO | | | | NFVO | | 414 | -------- | | -------- | 415 | | | | | | | | | | 416 | -------- | | | -------- | | -------- | | | -------- | 417 | | VNFM | | | | | VNFM | | | | VNFM | | | | | VNFM | | 418 | -------- | | | -------- | | -------- | | | -------- | 419 | | \__/__|__\_/_ | | | | \__/__|__\_/_ | | 420 | | __/___|___/\ \ | | | | __/___|___/\ \ | | 421 | | / / | \ \ | | | | / / | \ \ | | 422 | ------- ------- ------- | | ------- ------- ------- | 423 | |VIM 1| |VIM 2| |VIM 3| | | |VIM 1| |VIM 2| |VIM 3| | 424 | ------- ------- ------- | | ------- ------- ------- | 425 | Administrative domain A | | Administrative domain B | 426 +-------------------------+ +-------------------------+ 428 Figure 4: Network services provided using multiple administrative 429 domains (from ETSI GS NFV-IFA 009 V1.1.1) 431 5.2. Hierarchical 433 Considering the potential split of the NFVO into a Network Service 434 Orchestrator (NSO) and a Resource Orchestrator (RO), multi-provider 435 hierarchical interfaces may exist at their northbound APIs. Figure 5 436 illustrates the various interconnection options, namely: 438 E/NSO (External NSO): an evolved NFVO northbound API based on 439 Network Service (NS). 441 E/RO (External RO): VNF-FG oriented resource embedding service. A 442 received VNF-FG that is mapped to the northbound resource view is 443 embedded into the distributed resources collected from southbound, 444 i.e., VNF-FG_in = VNF-FG_out_1 + VNF-FG_out_2 + ... + VNF- 445 FG_out_N, where VNF-FG_out_j corresponds to a spatial embedding to 446 subordinate domain "j". For example, Provider 3's MP-NFVO/RO 447 creates VNF-FG corresponding to its E/RO and E/VIM sub-domains. 449 E/VIM (External VIM): a generic VIM interface offered to an 450 external consumer. In this case the NFVI-PoP may be shared for 451 multiple consumers, each seeing a dedicated NFVI-PoP. This 452 corresponds to IaaS interface. 454 I/NSO (Internal NSO): if a Multi-provider NSO (MP-NSO) is 455 separated from the provider's operational NSO, e.g., due to 456 different operational policies, the MP-NSO may need this interface 457 to realize its northbound E/NSO requests. Provider 1 illustrates 458 a scenario the MP-NSO and the NSO are logically separated. 459 Observe that Provider 1's tenants connect to the NSO and MP-NSO 460 corresponds to "wholesale" services. 462 I/RO (Internal RO): VNF-FG oriented resource embedding service. A 463 received VNF-FG that is mapped to the northbound resource view is 464 embedded into the distributed resources collected from southbound, 465 i.e., VNF-FG_in = VNF-FG_out_1 + VNF-FG_out_2 + ... + VNF- 466 FG_out_N, where VNF-FG_out_j corresponds to a spatial embedding to 467 subordinate domain "j". For example, Provider 1's MP-NFVO/RO 468 creates VNF-FG corresponding to its I/RO and I/VIM sub-domains. 470 I/VIM (Internal VIM): a generic VIM interface at an NFVI-PoP. 472 Nfvo-Vim: a generic VIM interface between a (monolithic) NFVO and 473 a VIM. 475 We would like to explore use-cases and potential benefits for the 476 above multi-provider interfaces as well as to learn how much they may 477 differ from their existing counterparts. For example, are (E/RO, I/ 478 RO), (E/NSO, I/NSO), (E/VIM, I/VIM) pairs different? 479 Tenants 480 * Provider | 481 * * Domain 4 +--+-----------+ 482 * * |MP-NFVO/NSO: | 483 * * |Network Serv. | 484 * Provider * |Orchestrator | 485 * Domain 3 * +--+-----------+ 486 * Tenants * |E/RO 487 * | ************|************* 488 * ++-------------+ | 489 * |MP-NFVO/NSO: | | 490 Provider * |Network Serv. | | 491 Domain 1 * |Orchestrator | | 492 * +-+-----+------+ | 493 * E/NSO| | I/RO / 494 *.---------' +-+---------+--+ 495 /* |MP-NFVO/RO: | 496 / * |Rersource | 497 Tenants / * |Orchestrator | 498 | | * +--+---+-------+ 499 | +-----------+--+ *************|***|******************** 500 | |MP-NFVO/NSO: | | * \ Provider 501 | |Network Serv. | E/RO / * \ E/VIM Domain 2 502 | |Orchestrator | .-----------' * `-------. 503 | +-+------+-----+ | * | 504 | |I/NSO |I/RO | * | 505 | | +--+--------+--+ * | 506 | | |MP-NFVO/RO: | * | 507 | | |Rersource | * | 508 \ | |Orchestrator | * +------+-------+ 509 \ | +----+---- --+-+ * |VIM: | 510 +--+-----+ |I/RO |I/VIM * |Virtualized | 511 |NFVO/NSO| | | * |Pys mapping | 512 +------+-+ | | * +--------------+ 513 I/RO| | | * 514 +------+----+---+ | * 515 | NFVO/RO | | * 516 ++-------------++ | * 517 |Nfvo-Vim | | * 518 ++-------+ ++----+--+ * 519 |WIM|VIM || |VIM|WIM | * 520 +--------+| +--------+ * 521 +--------+ * 523 Figure 5: NSO-RO Split: possible multi-provider APIs - an 524 illustration 526 5.3. Cascading 528 Cascading is an alternative way of relationship among providers, from 529 the network service point of view. In this case, service 530 decomposition is implemented in a paired basis. This can be extended 531 in a recursive manner, then allowing for a concatenation of cascaded 532 relations between providers. 534 As a complement to this, from a service perspective, the cascading of 535 two remote providers (i.e., providers not directly interconnected) 536 could require the participation of a third provider (or more) 537 facilitating the necessary communication among the other two. In 538 that sense, the final service involves two providers while the 539 connectivity imposes the participation of more parties at resource 540 level. 542 6. Virtualization and Control for Multi-Provider Multi-Domain 544 Orchestration operation in multi-domain is somewhat different from 545 that in a single domain as the assumption in single domain single 546 provider orchestration is that the orchestrator is aware of the 547 entire topology and resource availability within its domain as well 548 as has complete control over those resources. This assumption of 549 technical control cannot be made in a multi domain scenario, 550 furthermore the assumption of the knowledge of the resources and 551 topologies cannot be made across providers. In such a scenario 552 solutions are required that enable the exchange of relevant 553 information across these orchestrators. This exchange needs to be 554 standardized as shown in Figure 6. 556 | | 557 + IF1 + 558 _____|____ ____|_____ 559 | Multi | IF2 | Multi | 560 | Provider |<--------+---------->| Provider | 561 |___Orch___| |___Orch___| 562 /\ /\ 563 / \ / \ 564 / \ IF3 / \ 565 _______/__ _\_________ ________/_ _\________ 566 | Domain | | Domain | | Domain | | Domain | 567 |___Orch___| |___Orch___| |___Orch___| |___Orch___| 569 Figure 6: Multi Domain Multi Provider reference architecture 571 The figure shows the Multi Provider orchestrator exposing an 572 interface 1 (IF1) to the tenant, interface 2 (IF2) to other Multi 573 Provider Orchestrator (MPO) and an interface 3 (IF3) to individual 574 domain orchestratrators. Each one of these interfaces could be a 575 possible standardization candidate. Interface 1 is exposed to the 576 tennnt who could request his specific services and/or slices to be 577 deployed. Interface 2 is between the orchestrator and is a key 578 interface to enable multi-provider operation. Interface 3 focuses on 579 abstracting the technology or vendor dependent implementation details 580 to support orchestration. 582 The proposed operation of the MPO follows three main technical steps. 583 First, over interface 2 various functions such as abstracted topology 584 discovery, pricing and service details are detected. Second, once a 585 request for deploying a service is received over interface 1 the 586 Multi Provider Orchestrator evaluates the best orchestrators to 587 implement parts of this request. The request to deploy these parts 588 are sent to the different domain orchestrators over IF2 and IF3 and 589 the acknowledgement that these are deployed in different domain are 590 received back over those interfaces. Third, on receipt of the 591 acknowledgement the slice specific assurance management is started 592 within the MPO. This assurance function collects the appropriate 593 information over IF2 and IF3 and reports the performance back to the 594 tenant over IF1. The assurance is also responsible for detecting any 595 failures in the service and violations in the SLA and recomending to 596 the orchestration engine the reconfiguration of the service or slice 597 which again needs to performed over IF2 and IF3. 599 Each of the three steps is assigned to a specific block in our high 600 level architecture shown in Figure 7. 602 | | 603 + IF1 + 604 ______________|______________ ____|_____ 605 | Multi Provider Orch | | Multi | 606 | ______ ________ _______ |<------+------->| Provider | 607 ||Assur-| | | | Catal-|| IF2 |___Orch___| 608 ||-ance | | NFVO | | logue || 609 || Mgmt.| | | | Topo. || 610 ||______| |________| |_Mgmt._|| 611 |_____________________________| 612 /\ 613 / \ IF3 615 Figure 7: Detailed MPO reference architecture 617 The catalogue and topology management system is responsible for step 618 1. It discovers the service as well as the resources exposed by the 619 other domains both on IF2 and IF3. The combination of these services 620 with coverage over the detected topology is provided to the user over 621 IF1. In turn the catalogue and topology management system is also 622 responsible for exposing the topology and service deployment 623 capabilities to the other domain. The exposure over interface 2 to 624 other MPO maybe abstracted and the mapping of this abstracted view to 625 the real view when requested byt he NFVO. 627 The NFVO (Network Function Virtualization Orchestrator) is 628 responsible for the second step. It deploys the service or slice as 629 is received from the tenant over IF2 and IF3. It then hands over the 630 deployment decisions to the Assurance managmeent subsystem which use 631 this information to collect the periodic monitoring tickets in step 632 3. On the other end it is responsible for receiving the request over 633 IF2 to deploy a part of the service, consult with the catalogue and 634 topology management system on the translation of the abstraction to 635 the received request and then for the actual deployment over the 636 domains using IF3. The result of this deployment and the management 637 and control handles to access the deployed slice or service is then 638 returned to the requesting MPO. 640 The assurance management component periodically studies the collected 641 results to report the overall service performance to the tenant or 642 the requesting MPO as well as to ensure that the service is 643 functioning within the specified parameters. In case of failures or 644 violations the Assurance management system recomends reconfigurations 645 to the NFVO. 647 7. IANA Considerations 649 N/A. 651 8. Security Considerations 653 TBD. 655 9. Acknowledgments 657 The authors would like to thank Robert Szabo for his contributions to 658 this draft. 660 This work is supported by 5G-PPP 5GEx, an innovation action project 661 partially funded by the European Community under the H2020 Program 662 (grant agreement no. 671636). The views expressed here are those of 663 the authors only. The European Commission is not liable for any use 664 that may be made of the information in this presentation. 666 10. Informative References 668 [etsi_nvf_ifa009] 669 "Report on Architectural Options, ETSI GS NFV-IFA 009 670 V1.1.1", July 2016. 672 [etsi_nvf_whitepaper] 673 "Network Functions Virtualisation (NFV). White Paper 2", 674 October 2014. 676 Authors' Addresses 678 Carlos J. Bernardos 679 Universidad Carlos III de Madrid 680 Av. Universidad, 30 681 Leganes, Madrid 28911 682 Spain 684 Phone: +34 91624 6236 685 Email: cjbc@it.uc3m.es 686 URI: http://www.it.uc3m.es/cjbc/ 688 Luis M. Contreras 689 Telefonica I+D 690 Ronda de la Comunicacion, S/N 691 Madrid 28050 692 Spain 694 Email: luismiguel.conterasmurillo@telefonica.com 696 Ishan Vaishnavi 697 Huawei Technologies Dusseldorf GmBH 698 Riesstrasse 25, 699 Munich 80992 700 Germany 702 Email: Ishan.vaishnavi@huawei.com