idnits 2.17.1 draft-lachos-multi-domain-sfc-alto-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '----AS1----' is mentioned on line 325, but not defined == Missing Reference: '-----AS2-----' is mentioned on line 325, but not defined == Missing Reference: '-----AS3-----' is mentioned on line 325, but not defined == Outdated reference: A later version (-04) exists of draft-lachosrothenberg-alto-brokermdo-00 == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-05 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-11 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-04 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-03 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-03 == Outdated reference: A later version (-06) exists of draft-xiang-alto-multidomain-analytics-01 == Outdated reference: A later version (-08) exists of draft-li-sfc-hhsfc-04 == Outdated reference: A later version (-05) exists of draft-bernardos-nfvrg-multidomain-04 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG D. Lachos 3 Internet-Draft Unicamp 4 Intended status: Informational Q. Xiang 5 Expires: January 3, 2019 Tongji/Yale University 6 C. Rothenberg 7 Unicamp 8 Y. Yang 9 Tongji/Yale University 10 July 2, 2018 12 Multi-domain Service Function Chaining with ALTO 13 draft-lachos-multi-domain-sfc-alto-00 15 Abstract 17 Currently, Service Function Chaining (SFC) that span domains with 18 different technology, administration or ownership are being defined 19 by the SFC WG. This document focuses on how the Application Layer 20 Traffic Optimization (ALTO) protocol can be used to advertise and 21 discover abstract topology, resource and service information from 22 different domains, and then compute inter-domain service function 23 paths. Another important concern of this draft is to initiate a 24 discussion (ALTO, SFC as well as other WGs) regarding if, how, and 25 under what conditions ALTO can be useful to improve the multi-domain 26 SFC process. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 3, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Context and Motivation . . . . . . . . . . . . . . . . . . . 3 70 3.1. Standardization Activities . . . . . . . . . . . . . . . 4 71 3.2. Research projects . . . . . . . . . . . . . . . . . . . . 4 72 4. ALTO for Multi-domain SFC . . . . . . . . . . . . . . . . . . 5 73 4.1. Advantages of using ALTO . . . . . . . . . . . . . . . . 5 74 4.1.1. Inter-domain info discovery with ALTO Property Map . 6 75 4.1.2. Inter-domain path computation with ALTO Cost Map . . 6 76 5. Motivating Use Cases . . . . . . . . . . . . . . . . . . . . 7 77 5.1. ALTO as part of the SFC eXchange Platform . . . . . . . . 7 78 5.2. Resource Orchestration for Multi-Domain, Geo-Distributed 79 Data Analytics . . . . . . . . . . . . . . . . . . . . . 8 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 11 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 The delivery of end-to-end services often requires various Service 92 functions (SFs) or Virtual Network Functions (VNFs). Service 93 Function Chaining (SFC) is constructed as an abstract sequence of SFs 94 or VNFs [RFC7665]. Multi-domain SFC is the ability to deploy SFC 95 across multiple domains with different technology and/or 96 administration. To do so, an inter-domain communication process 97 between different organizations is necessary to (i) exchange 98 topology, resource and service information, and then (ii) compute 99 inter-domain service function paths. 101 The ALTO WG has begun started to discuss the uses of ALTO as an 102 information model for representing network resource and services in 103 multi-domain scenarios: 105 o [DRAFT-ALTO-BROKER-MDO] proposes an ALTO-based Broker-assisted 106 architecture where a broker plane works as a coordinator between a 107 set of top-level control planes, i.e., Multi-domain Orchestrator 108 (MdOs). The ALTO services (with the proposed extensions) provides 109 abstract maps with a simplified, yet enough information view about 110 MdOs involved in the federation. This information includes the 111 abstract network topology, resource availability (e.g., CPUs, 112 Memory, and Storage) and capabilities (e.g., supported network 113 functions). 115 o The document [DRAFT-ALTO-UNICORN] presents Unicorn, a resource 116 orchestration framework for multi-domain, geo-distributed data 117 analytics. This work resorts in ALTO as the information model to 118 support the accurate, yet privacy-preserving resource discovery 119 across different domains. The key information to be provided by 120 the use of ALTO including different types of resources, e.g., the 121 computing, storage, and networking resources. 123 This draft offers concrete use case examples of how ALTO can be 124 incorporated in the multi-domain SFC architecture. The examples used 125 in this document are based on architectures and assumptions currently 126 being discussed in the SFC WG [DRAFT-HH-MDSFC] and in the ALTO WG 127 [DRAFT-ALTO-BROKER-MDO] [DRAFT-ALTO-UNICORN]. 129 The overall rationale of this document is to begin a discussion 130 between the SFC and the ALTO WG (other WGs are welcome) concerning 131 if, how, and under which conditions ALTO will be helpful in the SFC 132 traversing different administrative domains. 134 2. Terminology 136 This document makes use of the terminology defined in 137 [DRAFT-HH-MDSFC], [DRAFT-ALTO-UNICORN], and [DRAFT-ALTO-BROKER-MDO]. 139 3. Context and Motivation 141 Nowadays, different standardization activities (e.g., IETF and ETSI) 142 and research projects (e.g., 5GEx [H2020.5GEX], 5G-Transformer 144 [H2020-5G-TRANSFORMER], T-NOVA [T-NOVA], etc.) have been focused on 145 multi-domain network service chaining. 147 3.1. Standardization Activities 149 SFC that span domains owned by multiple administrative entities are 150 being discussed in the IETF SFC WG. [DRAFT-HH-MDSFC], for example, 151 describes SFC crossing different domains owned by various 152 organizations (e.g., ISPs) or by a single organization with 153 administration partitions. The proposed architecture uses a SFC 154 eXchange Platform (SXP) to collect and exchange information 155 (topology, service states, policies, etc.) between different 156 organizations and it works both in centralized (Multiple SFC domains 157 connected by a logical SXP) and distributed (SXP server as a broker) 158 environments. Another IETF initiative is the Network Function 159 Virtualization Research Group (NFVRG). The draft "Multi-domain 160 Network Virtualization" [DRAFT-MD-VIRT] envisions a complete end-to- 161 end logical network as stitching services offered by multiple domains 162 from multiple providers. It also points to the need for creating 163 solutions that enable the exchange of relevant information (resources 164 and topologies) across different providers. 166 The ETSI NFV ISG is paving the way toward viable architectural 167 options supporting the efficient placement of functions in different 168 administrative domains. More specifically, the document 169 [ETSI-NFV-IFA028] reports different NFV MANO architectural approaches 170 with use cases related to network services provided using multiple 171 administrative domains. Besides, it gives a non-exhaustive list of 172 key information to be exchanged between administrative domains 173 (monitoring parameters, topology view, resource capabilities, etc.) 174 and recommendations related to security to permit the correct and 175 proper operation of the final service. 177 3.2. Research projects 179 Several projects include an architectural model integrating NFV 180 management with SDN control capabilities to address the challenges 181 towards flexible, dynamic, cost-effective, and on-demand service 182 chaining. 184 [H2020.5GEX] aims to integrate multiple administrations and 185 technologies through the collaboration between operators in the 186 context of emerging 5G networking. [VITAL][T-NOVA] follow a 187 centralized approach where each domain advertises its capabilities to 188 a federation layer which will act as a broker. In order to avoid one 189 network operator per country or regions, [H2020-5G-NORMA] proposes 190 the use of management and control into a single virtual domain. 191 Also, the 5G-Transformer project [H2020-5G-TRANSFORMER] is defining 192 flexible slicing and federation of transport networking and computing 193 resources across multiple domains. 195 4. ALTO for Multi-domain SFC 197 A "dialogue" between potential domains that will provide multi-domain 198 SFC could be beneficial for more efficient use of resources and 199 increasing the SFC performance. However, constrained knowledge of 200 the network services and underlying network topology based only on 201 localized views from the point of view of a single domain limits the 202 potential and scope for multi-domain SFC. 204 To enable a highly customized multi-domains SFC, [DRAFT-HH-MDSFC] 205 proposes a SFC eXchange Platform to realize inter-domain 206 communication between top-level control planes. The SXP is a logical 207 entity deployed in future Software-defined IXP (as a trusted third- 208 party platform) or built by a single owner between different 209 networks. 211 On a high level, the scope of the SXP contains two main tasks: 213 o Provide end-to-end visibility through the collection of topology 214 information, service states, and policies from different domains. 216 o Compute inter-domain service function path to select the service 217 function location from multiple candidate domains. 219 The ALTO protocol [RFC7285] provides abstract network information in 220 the form of map services that can be consumed by applications in 221 order to become network-aware and to take optimized decisions 222 regarding traffic flows. Recently, ALTO is also being considered in 223 multi-domain orchestration scenarios [DRAFT-ALTO-UNICORN] 224 [DRAFT-ALTO-BROKER-MDO], in which an ALTO server can convey inter- 225 domain network resource and topology information. 227 In this context, the SXP can take advantage of multi-domain ALTO 228 services to obtain important inter-domain information to "guide" the 229 resource/service provider selection process in that the "best" domain 230 or candidate domains (according to established policies) can be 231 intelligently selected. The following ALTO services can be 232 identified: 234 4.1. Advantages of using ALTO 236 ALTO (and customized ALTO extensions) can be used to offer 237 aggregated/abstracted views on various types of information including 238 domain-level topology, storage resources, computation resources, 239 networking resources and PNF/VNF capabilities. This generic 240 representation contributing to a more simple and scalable solution 241 for resource and service discovery in multi-domain, multi-technology 242 environments. 244 In case of Multi-domain SFC, the following ALTO services could be 245 identified: 247 4.1.1. Inter-domain info discovery with ALTO Property Map 249 Each domain needs a global view of other potential candidate domains 250 to know who can provide part of the NF in the SFC. A brief list of 251 information to be exchanged between different domains includes: 253 o Resource capabilities, applicable to both IT (computing and 254 storage) and networking resources participant of the multi-domain 255 SFC, to assist on the decision of SFs placement. 257 o Access information (e.g., URL) to the orchestrator entry points 258 and Service Access Points (SAPs) for a corresponding network/ 259 domain. 261 The ALTO Property Map Service [DRAFT-ALTO-PM] can provide a clear 262 global view of the resource information offered by other domains. 263 This information allows discovering which candidate domains may be 264 contacted to deliver the remaining requirements of a requested end- 265 to-end service deployment. 267 4.1.2. Inter-domain path computation with ALTO Cost Map 269 Once the candidate domains are discovered, it is necessary to compute 270 inter-domain service function path to select the service function 271 location from those different candidate domains. 273 The connectivity information among discovered domains can be 274 retrieved by an ALTO Cost Map service, responding, for instance, a 275 path vector with the AS-level topology distance between the source 276 domain and candidate domains. Moreover, path vector constraints (as 277 described in the Multi-Cost Map [RFC8189]) can be applied to filter 278 out the list of unqualified domains. 280 In case of the Hybrid Hierarchical SFC architecture [DRAFT-HH-MDSFC], 281 the SXP (or the Path Calculation Element in the top-level control 282 plane) could use this information to compute multi-domain service 283 function paths. 285 5. Motivating Use Cases 287 5.1. ALTO as part of the SFC eXchange Platform 289 As mentioned earlier, the draft [DRAFT-HH-MDSFC] defines a multi- 290 domain SFC architecture that combines control planes to be deployed 291 either into a large domain consisting of smaller sub-domains owned by 292 the same organization or into multiple large domains with different 293 ownership. Figure 1 shows a SXP connecting three different domains 294 (AS1, AS2, AS3). Each domain provides different SFs: AS1 -> SF1; AS2 295 -> SF2 and SF3; AS3 -> SF3. The SXP includes an ALTO server 296 component to provide abstract topology, resource, and service 297 information for the high-level control plane in each domain. 299 SFC eXchange 300 Platform 301 +--------------------+ 302 | +--------+ | 303 | | ALTO | | 304 | | Server | | 305 | +--------+ | 306 +----> <-----+ 307 | +----------^---------+ | 308 | | | 309 | | | 310 | | | 311 +----v---+ +-----v--+ +------v-+ 312 |Control | |Control | |Control | 313 |Plane | |Plane | |Plane | 314 +--------+ +--------+ +--------+ 315 | | | 316 | | | 317 | | | 318 +--------+ +--------+ +--------+ 319 |Data | |Data | |Data | 320 |Plane -------Plane -------Plane | 321 +--------+ +--------+ +--------+ 322 SF1 SF2 SF3 323 SF3 325 [----AS1----][-----AS2-----][-----AS3-----] 327 Figure 1: ALTO as part of the SFC eXchange Platform 329 Every domain has a local Information Base Element; this component can 330 be used by the SXP to create hierarchical databases containing inter- 331 domain resource and topology information. This information source is 332 used by the ALTO server to create two different ALTO Map Services: 333 (i) Property Map and (ii) Cost Map. 335 The Property Map includes a property value grouped by Autonomous 336 System (AS), this value contains the supported network functions. 337 Additional properties could be considered such as resource 338 availability (e.g., CPUs, Memory, and Storage), orchestrator entry 339 points, etc. An example of the Property Map in our basic scenario 340 is: 342 +-----+--------------+-------------+-----+-----+---------+-----+ 343 | | Capabilities | Entry Point | CPU | MEM | Storage | ... | 344 +-----+--------------+-------------+-----+-----+---------+-----+ 345 | AS1 | {SF1} | http://... | ... | ... | ... | ... | 346 | AS2 | {SF2, SF3} | http://... | ... | ... | ... | ... | 347 | AS3 | {SF3} | http://... | ... | ... | ... | ... | 348 +-----+--------------+-------------+-----+-----+---------+-----+ 350 Table 1: ALTO Property Map 352 The Cost Map defines a path vector as an array of ASes, representing 353 the AS-level topological distance for a given SFC request. Table 2 354 below shows a brief example of a service request and its inter-domain 355 service function path response containing a list of potential domains 356 to be traversed to deliver such service. 358 +---------------+---------------------------------------+ 359 | SFC Request | Multi-domain Service Function Path(s) | 360 +---------------+---------------------------------------+ 361 | SF1->SF2->SF3 | 1:{AS1:SF1->AS2:SF2->AS2:SF3} | 362 | | 2:{AS1:SF1->AS2:SF2->AS3:SF3} | 363 +---------------+---------------------------------------+ 365 Table 2: ALTO Cost Map 367 5.2. Resource Orchestration for Multi-Domain, Geo-Distributed Data 368 Analytics 370 In addition to commercial SFC, ALTO is also used as a core 371 information model for collaborative data science networks. The 372 document [DRAFT-ALTO-UNICORN] presents the design of Unicorn, a 373 unified resource orchestration framework for multi-domain, geo- 374 distributed data analytics, currently being developed and deployed in 375 the CMS network, one of the largest scientific experiments in the LHC 376 network. 378 ALTO is well suited as a fundamental component in Unicorn for 379 providing a generic representation that (1) allows different types of 380 data analytics jobs to accurately describe their resource 381 requirements and (2) allows member networks to provide accurate 382 information on different types of resources they own and at the same 383 time maintain their privacies. 385 .-------------. .-------------. 386 |Application 1| ... |Application N| 387 '-------------' '-------------' 388 \ / 389 .- - - - - - - -\- - - - - - - - - - - -/- - - - - - - - - - - - - - -. 390 | Unicorn \ / | 391 | .-----------------------. | 392 | | Resource Orchestrator | .----------------------.| 393 | | | |Distributed Hash Table|| 394 | | .-----------. |---- | of Computing and || 395 | | |ALTO Client| | | Storage Resources || 396 | | '-----------' | '----------------------'| 397 | '-----------------------' | 398 | / | \ | 399 | / | \ | 400 | .-------------. .-----------. .-------------. | 401 | |ALTO Server 1| | Execution | |ALTO Server M| | 402 | '-------------' | Agents | '-------------' | 403 | | '-----------' | | 404 | | / \ | | 405 | .----------------./ \ .----------------. | 406 | | Site 1 | . . | Site N | | 407 | '----------------' '----------------' | 408 '- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -' 410 Figure 2: Architecture of Unicorn. 412 Figure 2 presents the architecture of Unicorn. Specifically, for 413 each member network, one or more ALTO servers are deployed to provide 414 accurate, yet privacy-preserving information of different types of 415 resources owned by the corresponding network. Examples of such 416 information include the link bandwidth between endpoints, the memory 417 I/O bandwidth and the CPU utilization at computing endpoints and the 418 storage space at storage endpoints. In addition to the basic ALTO 419 services defined in [RFC7285], The ALTO servers in Unicorn also 420 provide ALTO extension services such as the ALTO Multi-Cost Service 421 [RFC8189], the ALTO Server-Sent Event Service [DRAFT-ALTO-INCR-UPD] 422 and the ALTO Path Vector Service [DRAFT-ALTO-PV] to provide fine- 423 grained resource information. 425 Because the ALTO Path Vector service may expose additional private 426 information of each network, Unicorn develops an obfuscating protocol 427 which ensures that nor the orchestrator or any member networks can 428 associate any path vector information with a corresponding network. 430 To better address the scalability issue of multi-domain resource 431 discovery, Unicorn also develops a proactive full-mesh discovery 432 mechanism, which precomputes network-level ALTO path vector 433 information and performs projection using such information to compute 434 the fine-grained resource information in response to orchestrator's 435 resource discovery requests. 437 Details of the obfuscating protocol and the proactive full-mesh 438 discovery mechanism developed in Unicorn can be found in the 439 [DRAFT-ALTO-UNICORN] document. 441 6. IANA Considerations 443 This document includes no request to IANA. 445 7. Security Considerations 447 The ALTO base protocol has an extensive discussion on potential 448 security and privacy issues. Using the ALTO base protocol to support 449 multi-domain SFC will not raise new security and privacy issue. 450 However, the information provided by the ALTO base protocol is 451 considered coarse-grained in several recent use cases. As a result, 452 several ALTO extension services have been designed to provide fine- 453 grained network information to the application. Using these ALTO 454 extension services for multi-domain SFC would raise new security and 455 privacy concerns. Next, we list these issues on a per extension 456 basis. 458 The ALTO unified property extension [DRAFT-ALTO-PM] generalizes the 459 concept of endpoint properties to other entity domains, such as 460 abstract network element. The properties of these entities may 461 contain sensitive service-function-specific information. Exposing 462 such information may discourage networks to provide fine-grained 463 information to support multi-domain SFC. 465 The ALTO performance cost metrics extension [DRAFT-ALTO-METRICS] 466 proposes a set of ALTO cost metrics derived from traffic engineering 467 tools and protocols. It is stated in this extension that "sharing 468 network TE metric values in numerical mode requires full mutual 469 confidence between the entities managing the ALTO Server and Client." 470 In multi-domain SFC use case, such mutual confidence is needed not 471 only between ALTO server and client, but also among all networks, and 472 third-parties such as broker and a global orchestrator. How to 473 achieve such mutual confidence in multi-domain SFC use case requires 474 further investigation. 476 The ALTO path vector extension [DRAFT-ALTO-PV] allows ALTO clients to 477 query network information such as capacity region for a given set of 478 flows. Several related studies have shared concerns that this 479 extension may reveal more network internal structures than the more 480 abstract single-node abstraction used in the ALTO base protocol. In 481 multi-domain SFC, this concern will further be amplified as third- 482 party participants may access such information. The recent designed 483 Unicorn system proposes an obfuscating protocol that prevents the 484 receiver of the capacity region information from associating this 485 region to any network. This protocol sheds light for addressing the 486 privacy issue brought by the ALTO path vector extension. 488 The ALTO cost calendar [DRAFT-ALTO-CALENDAR] and the ALTO incremental 489 update [DRAFT-ALTO-INCR-UPD] extensions allow the ALTO client to get 490 temporal network information. The intention of these extensions is 491 to allow applications to make flexible decisions on when to use 492 network information. However, both extensions expose temporal policy 493 and traffic information of network so that a user may know when the 494 network is most vulnerable for overloading. This issue needs to be 495 carefully addressed in order for both extensions to be used for 496 multi-domain SFC. 498 8. Summary and Outlook 500 This draft provided arguments why ALTO is a meaningful protocol in 501 the context of SFC traversing different domains, and it presented use 502 case examples about the how ALTO can be used to advertise and 503 discover abstract topology, resource and service information from 504 different domains, and then compute inter-domain service function 505 paths. 507 The overall objective of this document is to arouse discussions in 508 the SFC WG in order to assess the suitability of the ALTO as a useful 509 protocol for multi-domain SFC scenarios. The result of such 510 discussions will be captured in future versions of this draft. 512 9. Acknowledgments 514 This work is supported by the Innovation Center of Ericsson S.A., 515 Brazil (grant agreement UNI.64). 517 Many thanks to Sabine Randriamasy, and Lyle Bertz for their feedback 518 on this draft. 520 10. References 522 10.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 530 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 531 "Application-Layer Traffic Optimization (ALTO) Protocol", 532 RFC 7285, DOI 10.17487/RFC7285, September 2014, 533 . 535 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 536 Chaining (SFC) Architecture", RFC 7665, 537 DOI 10.17487/RFC7665, October 2015, 538 . 540 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 541 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 542 DOI 10.17487/RFC8189, October 2017, 543 . 545 10.2. Informative References 547 [DRAFT-ALTO-BROKER-MDO] 548 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 549 Multi-domain Orchestration", draft-lachosrothenberg-alto- 550 brokermdo-00 (work in progress), March 2018. 552 [DRAFT-ALTO-CALENDAR] 553 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 554 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 555 calendar-05 (work in progress), June 2018. 557 [DRAFT-ALTO-INCR-UPD] 558 Roome, W., Yang, Y., and S. Chen, "ALTO Incremental 559 Updates Using Server-Sent Events (SSE)", draft-ietf-alto- 560 incr-update-sse-11 (work in progress), June 2018. 562 [DRAFT-ALTO-METRICS] 563 Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 564 "ALTO Performance Cost Metrics", draft-ietf-alto- 565 performance-metrics-04 (work in progress), June 2018. 567 [DRAFT-ALTO-PM] 568 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 569 Zhang, "Unified Properties for the ALTO Protocol", draft- 570 ietf-alto-unified-props-new-03 (work in progress), March 571 2018. 573 [DRAFT-ALTO-PV] 574 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 575 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 576 Vector Cost Type", draft-ietf-alto-path-vector-03 (work in 577 progress), March 2018. 579 [DRAFT-ALTO-UNICORN] 580 Xiang, Q., Le, F., Yang, Y., Newman, H., and H. Du, 581 "Unicorn: Resource Orchestration for Multi-Domain, Geo- 582 Distributed Data Analytics", draft-xiang-alto-multidomain- 583 analytics-01 (work in progress), March 2018. 585 [DRAFT-HH-MDSFC] 586 Li, G., Li, G., Li, T., Xu, Q., and H. Zhou, "Hybrid 587 Hierarchical Multi-Domain Service Function chaining", 588 draft-li-sfc-hhsfc-04 (work in progress), April 2018. 590 [DRAFT-MD-VIRT] 591 Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R., 592 Li, X., Paolucci, F., Sgambelluri, A., Martini, B., 593 Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad, 594 "Multi-domain Network Virtualization", draft-bernardos- 595 nfvrg-multidomain-04 (work in progress), March 2018. 597 [ETSI-NFV-IFA028] 598 ETSI, "Report on architecture options to support multiple 599 administrative domains V3.1.1", Jan 2018, 600 . 603 [H2020-5G-NORMA] 604 H2020, "5G-NORMA -- 5G Novel Radio Multiservice adaptive 605 network Architecture", 2015, . 607 [H2020-5G-TRANSFORMER] 608 H2020, "5G-Transformer -- 5G Mobile Transport Platform for 609 Vertical", 2017, . 611 [H2020.5GEX] 612 H2020, "5GEx -- 5G Exchange Project", 2014, 613 . 615 [T-NOVA] FP7 project T-NOVA, "T-NOVA Project, Network Functions as 616 a Service over Virtualised Infrastructures", 2014, 617 . 619 [VITAL] VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid 620 satellite-TerrestriAl systems for resilient and fLexible 621 future networks", 2015, . 623 Authors' Addresses 625 Danny Alex Lachos Perez 626 University of Campinas 627 Av. Albert Einstein 400 628 Campinas, Sao Paulo 13083-970 629 Brazil 631 Email: dlachosp@dca.fee.unicamp.br 632 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 634 Qiao Xiang 635 Tongji/Yale University 636 51 Prospect Street 637 New Haven, CT 638 USA 640 Email: qiao.xiang@cs.yale.edu 642 Christian Esteve Rothenberg 643 University of Campinas 644 Av. Albert Einstein 400 645 Campinas, Sao Paulo 13083-970 646 Brazil 648 Email: chesteve@dca.fee.unicamp.br 649 URI: https://intrig.dca.fee.unicamp.br/christian/ 651 Y. Richard Yang 652 Tongji/Yale University 653 51 Prospect St 654 New Haven, CT 655 USA 657 Email: yang.r.yang@gmail.com