idnits 2.17.1 draft-lachosrothenberg-alto-md-e2e-ns-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: ---------------------------------------------------------------------------- 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 (July 13, 2020) is 1381 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-lachosrothenberg-alto-brokermdo-03 == Outdated reference: A later version (-06) exists of draft-xiang-alto-multidomain-analytics-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG D. Lachos 3 Internet-Draft C. Rothenberg 4 Intended status: Informational Unicamp 5 Expires: January 14, 2021 July 13, 2020 7 Multi-domain E2E Network Services 8 draft-lachosrothenberg-alto-md-e2e-ns-02 10 Abstract 12 Evolving networking scenarios (e.g., 5G) are considering the 13 provision of value-added and on-demand end-to-end (E2E) network 14 services in multi-domain (multi-operator/multi-technology) 15 environments. This document presents different initiatives, mainly 16 within standardization efforts and research projects, working on E2E 17 network services across multiple domains. Problem statement and a 18 layered network model are also described. In addition, this document 19 raises an initial proposal towards a new ALTO service in support of 20 E2E network service requirements. Finally, another important 21 objective of this document is to begin a discussion about motivating 22 use cases in scope of the ALTO WG after the re-chartering process. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 14, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Context and Motivation . . . . . . . . . . . . . . . . . . . 3 60 2.1. Standardization Activities . . . . . . . . . . . . . . . 3 61 2.1.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1.2. ETSI . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.3. MEF . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Research projects . . . . . . . . . . . . . . . . . . . . 5 65 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Network Function Placement Decisions . . . . . . . . . . 6 67 3.2. Network Inventory . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Publishing Information . . . . . . . . . . . . . . . . . 6 69 4. Network Function Virtualization Architectures and 70 Infrastructures . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Layered Network Model . . . . . . . . . . . . . . . . . . 8 72 5. ALTO Extension: E2E Network Service Requirements 73 Representation . . . . . . . . . . . . . . . . . . . . . . . 10 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 9.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 The fifth generation (5G) of cellular networks is not only considered 85 an evolution but a revolution in the field of information and 86 communication technologies [WHITE-PAPER-5G]. 5G will support the 87 creation of new and novel End-to-End (E2E) services, applications and 88 complex use case scenarios, such as massive Internet of Things, 89 extreme real-time communications, broadband access everywhere, higher 90 user mobility. All these scenarios and services are triggering a 91 modification in the way telecommunications sector deploy new network 92 services, shifting from a commonly manual and long process to a 93 flexible and programmable process. 95 In this context, cloud computing , Software Defined Networking (SDN), 96 and Network Function Virtualization (NFV) arise as technological 97 pillars to achieve the necessary function programmability, network 98 programmability, and resource virtualization during the provision of 99 E2E network services. 101 The delivery of an E2E network service, or simply E2E service, often 102 requires VNFs and their specific order [RFC7665]. Network operators 103 start offering to their customers the possibility of configuring 104 network services with specific requirements in terms of resources 105 (e.g., cpu, memory, hard-disk) and performance objectives (e.g., 106 bandwidth, latency) [VNF-PLAC]. Such demands are usually composed by 107 distributed resources which are expected to available across multiple 108 domains with different technology and/or administration. 110 This document offers an overview of standardization activities and 111 research projects, including problem statement, behind building E2E 112 services traversing different domains (technological and/or 113 administrative). Moreover, from a layered network model, it is 114 proposed a potential ALTO extension related to E2E Network Service 115 requirements representation based on the ETSI NFV MANO data model. 117 The overall rationale of this document is to arouse discussions into 118 the ALTO WG concerning potential new items to be considered for the 119 re-charter. 121 2. Context and Motivation 123 Different standardization efforts (e.g., IETF, MEF, ETSI) and 124 research projects activities (e.g., 5GEx [H2020.5GEX], 5G-Transformer 125 [H2020-5G-TRANSFORMER], T-NOVA [T-NOVA]) have been focused on multi- 126 domain network service chaining. Standardization is essential to 127 provide recommendations to create interoperable architectures with 128 standardized protocols, and solutions (being developed by different 129 projects) are addressing a diverse range of requirements to provide 130 network services provided using multiple domains. 132 This section briefly describes, on the one hand, main standardization 133 efforts delivering collections of norms and recommendations, while on 134 the other hand it also provides an overview of several projects 135 formed to develop network services across multiple domains. 137 2.1. Standardization Activities 139 2.1.1. IETF 141 SFC that span domains owned by single or multiple administrative 142 entities are being proposed. The Hierarchical Service Function 143 Chaining (hSFC) [RFC8459], for example, defines an architecture to 144 deploy SFC in large networks. This RFC proposes to decompose the 145 network into smaller domains (domains under the control of a single 146 organization). Another proposed initiative is [DRAFT-HH-MDSFC] that 147 describes SFC crossing different domains owned by various 148 organizations (e.g., ISPs) or by a single organization with 149 administration partitions. The proposed architecture uses a SFC 150 eXchange Platform (SXP) to collect and exchange information 151 (topology, service states, policies, etc.) between different 152 organizations and it works both in centralized (Multiple SFC domains 153 connected by a logical SXP) and distributed (SXP server as a broker) 154 environments. 156 More recently, the IETF ALTO WG started to discuss the uses of ALTO 157 as an information model for representing network resource and 158 services in multi-domain scenarios: 160 o [DRAFT-ALTO-BROKER-MDO] proposes an ALTO-based Broker-assisted 161 architecture where a broker plane works as a coordinator between a 162 set of top-level control planes, i.e., Domain Orchestrators (DOs) 163 and Multi-Domain Orchestrators (MdOs). The ALTO services (with 164 the proposed extensions) provides abstract maps with a simplified, 165 yet enough information view about MdOs involved in the federation. 166 This information includes the abstract network topology, resource 167 availability (e.g., CPUs, Memory, and Storage) and capabilities 168 (e.g., supported network functions). 170 o [DRAFT-ALTO-UNICORN] presents Unicorn, a resource orchestration 171 framework for multi-domain, geo-distributed data analytics. This 172 work resorts in ALTO as the information model to support the 173 accurate, yet privacy-preserving resource discovery across 174 different domains. The key information to be provided by the use 175 of ALTO including different types of resources, e.g., the 176 computing, storage, and networking resources. 178 o [DRAFT-MD-SFC-ALTO] describes different standardization activities 179 and research projects addressing the challenges posed by Service 180 Function Chaining (SFC) across multiple domains (specifically, 181 multiple administrative domains). In addition, this document 182 presents an initial approach to realize inter-domain service 183 chaining leveraging the ALTO protocol. Finally, another important 184 concern of this document is to initiate a discussion (ALTO, SFC as 185 well as 9other WGs) regarding if, how, and under what conditions 186 ALTO can be useful to improve the multi-domain SFC process. 188 2.1.2. ETSI 190 The ETSI NFV ISG is paving the way toward viable architectural 191 options supporting the efficient placement of functions in different 192 administrative domains. More specifically, the document 194 [ETSI-NFV-IFA028] reports different NFV MANO architectural approaches 195 with use cases related to network services provided using multiple 196 administrative domains. Besides, it gives a non-exhaustive list of 197 key information to be exchanged between administrative domains 198 (monitoring parameters, topology view, resource capabilities, etc.) 199 and recommendations related to security to permit the correct and 200 proper operation of the final service. 202 2.1.3. MEF 204 With its work on the Service Operations Specification MEF 205 55 [MEF-SOE-MEF55], MEF has defined a reference architecture and 206 framework for describing functional management entities (and 207 interfaces between them) needed to support Lifecycle Service 208 Orchestration (LSO). This LSO architecture enables automated 209 management and control of E2E connectivity services across multiple 210 operator networks. The automated service management includes 211 fulfillment, control, performance, assurance, usage, security, 212 analytics, and policy capabilities that make it possible, for 213 example, expanding the footprint of service providers to interact 214 with potentially several operators to manage and control the access 215 portions of E2E services. 217 2.2. Research projects 219 Several projects include an architectural model integrating NFV 220 management with SDN control capabilities to address the challenges 221 towards flexible, dynamic, cost-effective, and on-demand service 222 chaining. 224 [H2020.5GEX] aims to integrate multiple administrations and 225 technologies through the collaboration between operators in the 226 context of emerging 5G networking. [VITAL][T-NOVA] follow a 227 centralized approach where each domain advertises its capabilities to 228 a federation layer which will act as a broker. In order to avoid one 229 network operator per country or regions, [H2020-5G-NORMA] proposes 230 the use of management and control into a single virtual domain. 231 Also, the 5G-Transformer project [H2020-5G-TRANSFORMER] is defining 232 flexible slicing and federation of transport networking and computing 233 resources across multiple domains. The NECOS project [H2020-NECOS], 234 focused on the realization of E2E multi-domain cloud network slicing, 235 proposes an architectural approach with slice information interfaces 236 for resource exposure and resource discovery during slice 237 provisioning. In addition , the architecture includes a slice 238 marketplace interface between domain orchestrators and a marketplace 239 broker. 241 3. Problem Statement 243 3.1. Network Function Placement Decisions 245 An E2E service request specify virtual nodes (a set of required VNFs) 246 as well as virtual links (the order in which they must be executed). 247 Virtual nodes are deployed in virtual machines hosted by different 248 physical servers, and virtual links correspond to physical paths that 249 connect those servers hosting VNFs. Both virtual nodes and virtual 250 links are limited resources and both may also be located on different 251 technological domains in a single administration and even crossing 252 multiple administrations [VNF-MOB][SFC-ORC]. So that the placement 253 decision problem involves to discover "best" candidate resources and 254 "best" feasible paths between such resources. 256 3.2. Network Inventory 258 Placement decisions are a fundamental step for the management and 259 orchestration of network services. Management systems (e.g., DOs, 260 MdOs) need to maintain an inventory of the network providing a real- 261 time representation or view of available infrastructure resources, 262 software resources, and their relationships. However, The size of a 263 network inventory can be very large in scenarios, such as distributed 264 cloud and edge computing. As a result, management systems experiment 265 scalability problems processing large amounts of data to decide where 266 to instantiate a service or part of the service. Therefore, building 267 a network inventory, under these circumstances, needs aggregation 268 mechanisms to reduce time for discovery of resources and to simplify 269 and optimize management of them. 271 3.3. Publishing Information 273 Once a network inventory is built, a mechanism for publishing 274 information is also necessary so that the network inventory can 275 provide a simplified, yet enough network information view to 276 management systems. In order to retrieve such information to perform 277 placement decisions, a communication protocol between management 278 systems and network inventory is also necessary. 280 Therefore, on the one hand, network information (e.g., network 281 locations, costs between them, endhost properties) needs to be 282 advertised to the network applications and, on the other hand, 283 network applications (e.g., DOs, MdOs) needs to describe their 284 requirements and obtain information about resources that suit such 285 requirements. 287 4. Network Function Virtualization Architectures and Infrastructures 289 With the introduction of NFV, network functions (e.g., switches, 290 routers, firewalls), and also complex network functions (e.g., EPC) 291 are able to be virtualized and implemented as a collection of virtual 292 machines (VMs) deployed over the virtualized infrastructure. In 293 turn, the virtualized infrastructure is instantiated on a substrate 294 network. 296 In this context, one of the most accepted NFV architectural 297 frameworks is the proposed by the ETSI ISG NFV working 298 group [ETSI-NFV-WHITEPAPER]. Figure 1 [DRAFT-MD-VIRT] shows this NFV 299 reference architecture. On the left, we can see the data plane: 300 NFVIs hardware/software, VNFs, and optional element management 301 systems. On the right, we see the control plane: VIM which is 302 something like Openstack or Kubernetes, virtual network function 303 managers, and the NFV Orchestrator on the top. 305 +--------------------+ 306 +-------------------------------------------+ | ---------------- | 307 | OSS/BSS | | | NFV | | 308 +-------------------------------------------+ | | Orchestrator +-- | 309 | ---+------------ | | 310 +-------------------------------------------+ | | | | 311 | --------- --------- --------- | | | | | 312 | | EM 1 | | EM 2 | | EM 3 | | | | | | 313 | ----+---- ----+---- ----+---- | | ---+---------- | | 314 | | | | |--|-| VNF | | | 315 | ----+---- ----+---- ----+---- | | | manager(s) | | | 316 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 317 | ----+---- ----+---- ----+---- | | | | | 318 +------|-------------|-------------|--------+ | | | | 319 | | | | | | | 320 +------+-------------+-------------+--------+ | | | | 321 | NFV Infrastructure (NFVI) | | | | | 322 | ----------- ----------- ----------- | | | | | 323 | | Virtual | | Virtual | | Virtual | | | | | | 324 | | Compute | | Storage | | Network | | | | | | 325 | ----------- ----------- ----------- | | ---+------ | | 326 | +---------------------------------------+ | | | | | | 327 | | Virtualization Layer | |--|-| VIM(s) +-------- | 328 | +---------------------------------------+ | | | | | 329 | +---------------------------------------+ | | ---------- | 330 | | ----------- ----------- ----------- | | | | 331 | | | Compute | | Storage | | Network | | | | | 332 | | | hardware| | hardware| | hardware| | | | | 333 | | ----------- ----------- ----------- | | | | 334 | | Hardware resources | | | NFV Management | 335 | +---------------------------------------+ | | and Orchestration | 336 +-------------------------------------------+ +--------------------+ 338 Figure 1: ETSI MANO Reference Architecture 340 4.1. Layered Network Model 342 Based on the ETSI NFV reference architecture, a layered network model 343 is identified: Network Service layer, VNF layer, and Resource Layer. 344 This model allows a separation of network relationships in different 345 levels of abstraction. For example, network services can be queried 346 at different levels of abstraction or we can map service paths in 347 different layers (from an abstract to a more concrete layer). 349 In Figure 2, we have a network service with a set of interconnected 350 VNFs. This network service topology is represented by the Network 351 Service layer. 353 A VNF is typically divided into a set of virtual function components 354 (VFCs) which comprise the VNF Layer. Each VFC is an application 355 running within a single VM or container. 357 In case of the resource layer, we have virtual layer and physical 358 layer. The virtual layer represents the virtual overlay network and 359 the physical layer represents the substrate network. Virtualized 360 infrastructures (e.g., VMs, virtual routers) are instantiated on a 361 physical infrastructure. 363 +----------+ 364 | | 365 | +------+ | 366 Network | | NFVO | | +-----+ +------+ +------+ +------+ 367 Service | +---+--+ | | SRC +--->-|VNF1 +---->+ VNF2 +---->+ DST | 368 Layer | | | +-----+ +--+---+ +------+ +------+ 369 | | | | 370 +--------------------------------------------------------------------+ 371 | | | | 372 | | | +------------v------------------+ 373 | | | | VNF1 | 374 | | | +-------+-----+--------------+--+ 375 | +---+--+ | | | | Repeat for 376 VNF | | VNFM | | | | | each VNF 377 Layer | +---+--+ | +----+ | | +----+ +-+--+ 378 | | | |VFC +----+ +----+VFC | |VFC | 379 | | | +-+--+ +-+--+ +-+--+ 380 | | | | | | 381 +-------+----------+-------------------------------------------------+ 382 | | | | V 383 | | | | | | i 384 | | | +-+-+ +---+ +-+-+ +-+-+ +---+ r 385 | | | |VM | |VM | |VM | |VM | |VM | t 386 | | | +-+-+ ++--+ +-+-+ +-+-+ ++--+ u 387 | | | | | | | | a 388 | | | | +---+ | | | | l 389 | +---+-+ | | |VM | | | | | 390 Resource| | VIM | | | ++--+ | | | | 391 Layer | +-----+ | | | | +-----v-------v--+ | P 392 | | | | | XXXX| Host/Hypervisor|XXX | h 393 | | | | | X +----------------+ X | y 394 | | | | | X X | s 395 | | +---v---> +-v-X---+ +----X-v+ i 396 | | | Host/ + | Host/ XXXXXXXXXXXXXXX| Host/ | c 397 | NFV | | Hyp XXX| Hyp + | Hyp | a 398 | MANO | +-------+ +-------+ +-------+ l 399 +----------+ 401 Figure 2: ETSI MANO Reference Architecture 403 5. ALTO Extension: E2E Network Service Requirements Representation 405 From the layered network model described in the previous section, we 406 are considering an ALTO extension related to E2E Network Service 407 requirements representation. An initial proposal has been presented 408 in the ALTO-based Broker-assisted MdO draft [DRAFT-ALTO-BROKER-MDO] 409 where network applications (as ALTO clients) can specify a set of 410 basic E2E service requirements to an ALTO server in order to obtain 411 candidate resources (domains) and candidate paths. 413 This initial E2E service requirement representation is inspired on 414 the ETSI NFV MANO data model [ETSI-NFV-MAN001]. This model defines 415 network services as a composition of network functions including the 416 specification of deployment and operational requirements. Such 417 specifications are captured in templates called Network Service 418 Descriptor (NSD) and Virtual Network Function Descriptor (VNFD) that 419 contain (relatively) static information used in the process of on- 420 boarding network services and VNFs, respectively. 422 o High level objects in a NSD include (among others) 423 [ETSI-NFV-MAN001][OSM-DM]: 425 * Constituent VNFs: List of VNFDs that are part of the network 426 service. 428 * VNF Dependencies: This describes dependencies between VNFs. 429 For example, the order in which the VNFs inside a network 430 service should be started. 432 * Network service Connection Points: Each network service has one 433 or more external connection points (which act as endpoints) 434 used to link two network services or to link external networks. 436 * Virtual Links: List of Virtual Link Descriptors (VLDs) that 437 describe how VNFs (in the NSD) are connected. 439 o High level objects in a VNFD include (among others) 440 [ETSI-NFV-MAN001][OSM-DM]: 442 * Constituent VDUs: List of virtual deployment units (VDUs) in a 443 specific VNF. Each VDU (also referred to VFC) describes the 444 VM/Container capabilities (e.g., CPU, RAM, disks). 446 * VDU Dependencies: List of VDU dependencies used for determining 447 the order of startup for VDUs. 449 * VNF Connection Points: List of external connection points used 450 for connecting a VNF to other VNFs or to external networks. 452 * Internal VLDs: List of internal virtual links to connect 453 various VDUs/VFCs. 455 6. IANA Considerations 457 This document includes no request to IANA. 459 7. Security Considerations 461 TBD. 463 8. Acknowledgments 465 This work is supported by the Innovation Center of Ericsson S.A., 466 Brazil (grant agreement UNI.64). This document however does not 467 necessary represent Ericsson's official viewpoint. 469 9. References 471 9.1. Normative References 473 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 474 Chaining (SFC) Architecture", RFC 7665, 475 DOI 10.17487/RFC7665, October 2015, 476 . 478 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 479 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 480 DOI 10.17487/RFC8459, September 2018, 481 . 483 9.2. Informative References 485 [DRAFT-ALTO-BROKER-MDO] 486 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 487 Multi-domain Orchestration", draft-lachosrothenberg-alto- 488 brokermdo-03 (work in progress), March 2020. 490 [DRAFT-ALTO-UNICORN] 491 Xiang, Q., Zhang, J., Le, F., Yang, Y., and H. Newman, 492 "Resource Orchestration for Multi-Domain, Exascale, Geo- 493 Distributed Data Analytics", draft-xiang-alto-multidomain- 494 analytics-03 (work in progress), March 2020. 496 [DRAFT-HH-MDSFC] 497 Li, G., Li, G., Xu, Q., Zhou, H., and B. Feng, "Hybrid 498 Hierarchical Multi-Domain Service Function chaining", 499 draft-li-sfc-hhsfc-08 (work in progress), March 2020. 501 [DRAFT-MD-SFC-ALTO] 502 Perez, D., Xiang, Q., Rothenberg, C., and Y. Yang, "Multi- 503 domain Service Function Chaining with ALTO", draft-lachos- 504 multi-domain-sfc-alto-01 (work in progress), March 2020. 506 [DRAFT-MD-VIRT] 507 Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R., 508 Li, X., Paolucci, F., Sgambelluri, A., Martini, B., 509 Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad, 510 "Multi-domain Network Virtualization", draft-bernardos- 511 nfvrg-multidomain-05 (work in progress), September 2018. 513 [ETSI-NFV-IFA028] 514 ETSI, "Report on architecture options to support multiple 515 administrative domains V3.1.1", Jan 2018, 516 . 519 [ETSI-NFV-MAN001] 520 ETSI, "Network Functions Virtualisation (NFV); Management 521 and Orchestration", Dec 2014, 522 . 525 [ETSI-NFV-WHITEPAPER] 526 ETSI, "Network Functions Virtualisation - White Paper 2", 527 Oct 2013, 528 . 530 [H2020-5G-NORMA] 531 H2020, "5G-NORMA -- 5G Novel Radio Multiservice adaptive 532 network Architecture", 2015, . 534 [H2020-5G-TRANSFORMER] 535 H2020, "5G-Transformer -- 5G Mobile Transport Platform for 536 Vertical", 2017, . 538 [H2020-NECOS] 539 H2020 EU-Brazil, "NECOS -- Novel Enablers for Cloud 540 Slicing", 2018, . 542 [H2020.5GEX] 543 Bernardos, C., Dugeon, O., Galis, A., Morris, D., Simon, 544 C., and R. Szabo, "5G Exchange (5GEx)-- Multi-domain 545 Orchestration for Software Defined Infrastructures", 546 focus vol. 4, no.5, p.2, 2015. 548 [MEF-SOE-MEF55] 549 Metro Ethernet Forum, "Lifecycle Service Orchestration 550 (LSO): Reference Architecture and Framework", Mar 2016, 551 . 554 [OSM-DM] Open Source MANO, "OSM - Data Model", 2016, 555 . 558 [SFC-ORC] Sun, G., Li, Y., Liao, D., and V. Chang, "Service Function 559 Chain Orchestration across Multiple domains: A Full Mesh 560 Aggregation Approach", IEEE Transactions on Network and 561 Service Management 1175--1191, 2018. 563 [T-NOVA] FP7 project T-NOVA, "T-NOVA Project, Network Functions as 564 a Service over Virtualised Infrastructures", 2014, 565 . 567 [VITAL] VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid 568 satellite-TerrestriAl systems for resilient and fLexible 569 future networks", 2015, . 571 [VNF-MOB] Patel, A., Vutukuru, M., and D. Krishnaswamy, "Mobility- 572 aware VNF placement in the LTE EPC", IEEE Conference on 573 Network Function Virtualization and Software Defined 574 Networks (NFV-SDN) 1--7, 2017. 576 [VNF-PLAC] 577 Slim, F., Guillemin, F., Gravey, A., and Y. Hadjadj-Aoul, 578 "Towards a dynamic adaptive placement of virtual network 579 functions under ONAP", IEEE Conference on Network Function 580 Virtualization and Software Defined Networks (NFV-SDN) 581 210--215, 2017. 583 [WHITE-PAPER-5G] 584 NetWorld2020, ETP, "5g: Challenges, research priorities, 585 and recommendations", Journal: Joint White Paper 586 September, 2014. 588 Authors' Addresses 589 Danny Alex Lachos Perez 590 University of Campinas 591 Av. Albert Einstein 400 592 Campinas, Sao Paulo 13083-970 593 Brazil 595 Email: dlachosp@dca.fee.unicamp.br 596 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 598 Christian Esteve Rothenberg 599 University of Campinas 600 Av. Albert Einstein 400 601 Campinas, Sao Paulo 13083-970 602 Brazil 604 Email: chesteve@dca.fee.unicamp.br 605 URI: https://intrig.dca.fee.unicamp.br/christian/