idnits 2.17.1 draft-lachosrothenberg-alto-brokermdo-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 date (March 5, 2018) is 2245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 707 -- Looks like a reference, but probably isn't: '2' on line 710 -- Looks like a reference, but probably isn't: '3' on line 713 -- Looks like a reference, but probably isn't: '4' on line 716 -- Looks like a reference, but probably isn't: '5' on line 719 -- Looks like a reference, but probably isn't: '6' on line 722 -- Looks like a reference, but probably isn't: '7' on line 724 -- Looks like a reference, but probably isn't: '8' on line 727 -- Looks like a reference, but probably isn't: '9' on line 730 -- Looks like a reference, but probably isn't: '10' on line 733 -- Looks like a reference, but probably isn't: '11' on line 736 == Missing Reference: 'TBD' is mentioned on line 534, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-01 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). 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: September 6, 2018 March 5, 2018 7 ALTO-based Broker-assisted Multi-domain Orchestration 8 draft-lachosrothenberg-alto-brokermdo-00 10 Abstract 12 Evolving networking scenarios (e.g., 5G) demand new multiple 13 administrative domain (aka multi-domain) orchestration models. This 14 document proposes the use of Application-Layer Traffic Optimization 15 (ALTO) services to offer topology and resources addressing network 16 service discovery and provisioning by multi-domain orchestrators. 17 The ALTO services with the proposed protocol extensions offer 18 aggregated views on various types of resources contributing to a more 19 simple and scalable solution for resource and service discovery in 20 multi-domain, multi-technology environments. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Problem Statement and Challenges . . . . . . . . . . . . . . 5 66 5. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Inter-domain Resource (IdR) Component . . . . . . . . . . 6 68 5.2. Inter-domain Topology (IdT) Component . . . . . . . . . . 7 69 5.3. ALTO Server Functionalities . . . . . . . . . . . . . . . 7 70 5.4. Required ALTO Extensions . . . . . . . . . . . . . . . . 7 71 5.4.1. Property Map Extensions . . . . . . . . . . . . . . . 7 72 5.4.2. Filtered Cost Map Extensions . . . . . . . . . . . . 8 73 5.5. Examples of Message Exchange . . . . . . . . . . . . . . 10 74 5.5.1. Property Map Service . . . . . . . . . . . . . . . . 10 75 5.5.2. Filtered Cost Map Service . . . . . . . . . . . . . . 11 76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 9.2. Informative References . . . . . . . . . . . . . . . . . 15 82 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Proof of Concept Use Case Implementation . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 Envisioned 5G network architectures and related service models 89 consider broader cooperation between stakeholders in order to provide 90 flexible multi-operator multi-domain services. These multi-provider 91 orchestration operations will require the information exchange across 92 Multi-domain Orchestrators (MdOs). The key information to be 93 exchanged between MdOs includes the abstract network topology, 94 resource availability (e.g., CPUs, Memory, and Storage) and 95 capability (e.g., supported network functions). 97 This document presents a federation networking paradigm where a 98 broker-plane works on top of the management and orchestration plane 99 to assist and coordinate the creation of an End-to-End Network 100 Service (E2ENS) spanning over multi-operator multi-domain networks. 101 Our design resorts to the Application-Layer Traffic Optimization 102 (ALTO) protocol [RFC7285] to address the lack of abstractions to 103 discover and adequately represent in confidentiality-preserving 104 fashion the resource and topology information from different 105 administrative domains. Moreover, this draft introduces some 106 extensions to the ALTO base protocol to support the main 107 functionalities in our proposed architecture. 109 2. Terminology 111 We use the following definitions, as established in [ETSI-NFV-DEF]: 113 Administrative Domain: Collection of systems and networks operated 114 by a single organization or administrative authority. 116 Network Function (NF): Functional block within a network 117 infrastructure that has well-defined external interfaces and well- 118 defined functional behaviour. 120 Network Functions Virtualisation (NFV): The principle of separating 121 network functions from the hardware they run on by using virtual 122 hardware abstraction. 124 NF Forwarding Graph: (NFFG): Graph of logical links connecting NF 125 nodes for the purpose of describing traffic flow between these 126 network functions. 128 Network Service Orchestration (NSO): Function responsible for 129 network service lifecycle management. 131 Resource Orchestration (RO): Function responsible for global 132 resource management governance. 134 Our proof of concept implementation follows the architectural 135 proposal of the 5GEx project [H2020.5GEX]. Some additional 5GEx 136 terms commonly used in this document are defined below: 138 Domain Orchestrator (DO): Performs Resource Orchestration and/or 139 Service Orchestration within the same administrative domain. 141 Multi-domain Orchestrator (MdO): Coordinates resource and/or service 142 orchestration at multi-domain level, where multi-domain may refer 143 to multiple DOs or multiple administrative domains. 145 Resource Topology (RT): Functional module that is responsible for 146 keeping an updated global view of the underlying infrastructure 147 topology exposed by DOs. 149 Service Graph (SG): A high-level data model for defining flexible 150 network services (including traffic steering primitives). 152 Service Access Point (SAP): A named/tagged port supporting stitching 153 (service to service, domain to domain, etc.) 155 3. Scope 157 Existing proposals for the network service orchestration are 158 intrinsically conceived for single administrative domain scenarios. 159 For example, in the standard service orchestration model described in 160 ETSI NFV MANO framework [ETSI-NFV-MANO], one orchestrator is supposed 161 to work within one administrative domain. The analysis of 162 orchestration and management of network Services over multiple 163 administrative domains have begun to be addressed by ETSI 164 in [ETSI-NFV-MANO-MDO]. 166 Envisioned 5G scenarios are expected to work not only with 167 heterogeneous technologies but also across different network 168 operators. Many ongoing initiatives and projects related are 169 addressing the multi-provider multi-domain orchestration challenges 170 under different approaches. For example, [H2020.5GEX] seeks to 171 integrate multiple administrations and technologies through the 172 collaboration between operations. Other studies are envisioned to 173 use a centralized approach, where each domain advertises its 174 capabilities to a federation layer which will act as a 175 broker [VITAL][T-NOVA]. The proposed architecture in [ICAF] allows 176 the creation of cloud services from different administrative domains, 177 however, it is not related to the provisioning of NFV-based cross- 178 domain network services. 180 All such proposals described above envision the potential 181 introduction of new business model approaches, including federation 182 models [PPP-5:2013] among administrative domains. In this context, 183 this document considers each network operator involved in the 184 community advertises its abstracted capabilities (e.g., software/ 185 hardware resources, physical/virtual network functions, etc.) to a 186 broker (i.e., 3rd party). This latter, in its turn, provides or 187 assists coordinate E2E network services spanning multi-domain 188 networks. 190 4. Problem Statement and Challenges 192 The provision of value-added services through a brokerage level of 193 orchestration requires mechanisms through which single domains can 194 describe their network capabilities in an interoperable manner. 195 Different interfaces, subject to potential standardization 196 opportunities, are necessary to advertise capabilities, resources, 197 and VNFs to trusted entities. 199 Network service orchestration in Multi-domain (Multi-operator/multi- 200 technology) environments is not trivial due to series of challenges: 202 Scalability: Involves the distribution of topology and resource 203 information in a peer-to-peer fashion (MdO-to-MdO). Multi- 204 operator multi-domain environments where the information 205 distribution is advertised in a peer-to-peer model scales 206 linearly. It means more MdO interconnections one has, the more 207 it "costs" to distribute. 209 Flexibility: Considers that a distributed approach does not allow 210 domains without physical infrastructure (e.g., without BGP or 211 BGP-LS) to advertise resource capabilities and networking 212 resources. Such procedures consist in deploying and configuring 213 physical peering points for these domains. 215 Complexity: Refers to the discovery mechanism to pre-select 216 candidate domains, accounting for resources and capabilities, 217 necessary for an end-to-end network service deployment An 218 intrinsic complexity exists in the process of assembling, 219 logically organizing, and enabling abstraction views of 220 different resources and capabilities in multi-domain scenarios. 222 5. Proposed Approach 224 The primary design goal for ALTO-based Broker-assisted Multi-domain 225 Orchestration is to discover resource and topology information from 226 different administrative domains involved in the federation, while 227 also safeguarding the privacy and autonomy of every domain. 229 In the architectural proposal shown in Figure 1, a broker component 230 is conceived to be working as coordinator of a set of MdOs, whose key 231 components are: the Inter-domain Resource (IdR), the Inter-domain 232 Topology (IdT) and the ALTO Server. 234 BROKER COMPONENT 235 +--------------------------------------------+ 236 | | 237 | +-----------------+ | 238 | | | | 239 XXXXXXXXXXXXXXXXXXX ALTO SERVER(s) | | 240 X | | + | 241 X | +----------------+\ | 242 X | / \ | 243 X | / \ | 244 X | +------+/+-------+ +---------------+ | 245 X | | Inter-domain | | Inter-domain | | 246 X | | Topology (IdT) | | Resource (IdR)| | 247 X | +-^------^-------+ +---^-------^---+ | 248 X | | | | | | 249 X +--------------------------------------------+ 250 X | | | | 251 X | | | | 252 +--X--------+---+--------------------+ | 253 | | | | 254 | | +------------+------------+---+ 255 | MdO1 | | | 256 | +<------------->+ +---+ 257 +---------------+ | MdO2 | | 258 | | | 259 +-+--------------+ | 260 | | 261 Legend: | MdO(n) | 262 XXX ALTO Protocol +------------------+ 264 Figure 1: Broker-assisted Multi-operator Network Architecture 266 5.1. Inter-domain Resource (IdR) Component 268 It creates a hierarchical database that contains inter-domain 269 resource information such as resource availability (i.e., CPU, 270 memory, and storage), Virtual Network Functions (VNFs) and Physical 271 Network Functions (PNFs) supported and Service Access Points (SAPs) 272 to access those resources. UNIFY [UNIFY.NFFG], TOSCA [TOSCA], ETSI- 273 NFV [ETSI-NFV-MANO], among other data models can be used to create 274 the interface between IdR and MdOs. 276 5.2. Inter-domain Topology (IdT) Component 278 A hierarchical TED (Traffic Engineering Database) that contains 279 inter-domain network topology information including additional key 280 parameters (e.g., throughput and latency of links). This information 281 can be retrieved from each MdO through BGP-LS or REST interfaces. 283 5.3. ALTO Server Functionalities 285 The ALTO server component is the core of the broker layer. Multiple 286 logically centralized ALTO servers use the information collected from 287 IdR and IdT modules to create and provide abstract maps with a 288 simplified view, yet enough information about MdOs involved in the 289 federation. This information includes domain-level topology, storage 290 resources, computation resources, networking resources and PNF/VNF 291 capabilities. 293 As an ALTO client, each MdO sends ALTO service queries to the ALTO 294 server. This server provides aggregated inter-domain information 295 exposed as set ALTO base services defined in [RFC7285], e.g., Network 296 Map, Cost Map and ALTO extension services, e.g., Property 297 Map [DRAFT-PM], Multi-Cost Map [RFC8189], Path Vector [DRAFT-PV]. 299 For example, when a source MdO receives a customer service request, 300 it checks whether or not it can deliver the full service. If it is 301 unable to do so, the MdO consumes from the ALTO Server the Property 302 Map service to have a clear global view of the resource information 303 offered by other MdOs. This information allows discovering which 304 candidate MdOs may be contacted to deliver the remaining requirements 305 of a requested end-to-end service deployment. The connectivity 306 information among discovered MdOs can be retrieved by a Cost Map 307 service, responding, for instance, a path vector with the AS-level 308 topology distance between the source MdO and candidate MdOs. 310 5.4. Required ALTO Extensions 312 The Property Map and the Cost Map examples defined in the previous 313 section can be supported with some proposed extensions to the ALTO 314 base protocol. 316 In this section, we introduce a non-normative overview of the 317 Property Map and Filtered Cost Map extensions. 319 5.4.1. Property Map Extensions 321 The ALTO server MUST return multiple values for each property in the 322 Property Map. For example, MdOs exchange (among others) a list NFs 323 and SAPs which are supported by them. So in this scenario, an array 324 of values can provide sufficient information that is not possible 325 with single string values. 327 The specifications for the "Media Types", "HTTP Method", "Accept 328 Input Parameters", "Capabilities" and "Uses" (described in 329 Section 4.1 [1], Section 4.2 [2], Section 4.3 [3], Section 4.4 [4], 330 Section 4.5 [5] of [DRAFT-PM] [6], respectively) remain unchanged. 332 The response is the same as Section 4.6 of [DRAFT-PM] [7], except 333 that for each property name defined in the resource's "capabilities" 334 list, the corresponding property value MUST be encoded as JSONArray 335 instead of JSONString. 337 Section 5.5.1 gives an example of a property map request and its 338 response. 340 5.4.2. Filtered Cost Map Extensions 342 The ALTO server MUST provide connectivity information for every SG 343 link in the SG path for an E2E requirement. This information is the 344 AS-level topology distance in the form of path vector, and it 345 includes all possible ways for each (source node, destination node) 346 pair in the SG link. 348 In this section, we propose an extension of the Filtered Cost Map 349 defined in Section 6.1 of [DRAFT-PV] [8]. 351 The specifications for the "Media Types", "HTTP method", 352 "Capabilities" and "Uses" (described in Section 6.1 of [DRAFT-PV] 353 [9]) are unchanged. 355 5.4.2.1. Accept Input Parameters 357 The ReqFilteredCostMap object in Section 6.1.2 of [DRAFT-PV] [10] is 358 extended as follow: 360 object { 361 [NFFG sg;] 362 } ReqFilteredCostMap; 364 object { 365 JSONString nfs<1..*>; 366 JSONString saps<1..*>; 367 NextHops sg_links<1..*>; 368 REQs reqs<1..*>; 369 } NFFG; 371 object { 372 JSONNumber id; 373 JSONString src-node; 374 JSONString dst-node; 375 } NextHops; 377 object { 378 JSONString id; 379 JSONString src-node; 380 JSONString dst-node; 381 JSONNumber sg-path<1..*>; 382 } REQs; 384 sg: If present, the ALTO Server MUST allow the request input to 385 include an SG with a formatted body as an NFFG object. An NFFG 386 object contains NFs, SAPs, SG links representing logical 387 connections between NFs, SAPs or both and E2E requirements as a 388 list of ids of SG links. 390 It is worth noting that further versions of this draft will define a 391 more elaborated NFFG object to support extended parameters such as 392 monitoring parameters, resource requirements, etc. 394 5.4.2.2. Response 396 If the ALTO client includes the path vector cost mode in the "cost- 397 type" or "multi-cost-types" field of the input parameter, the 398 response for each SG link in each E2E requirement MUST be encoded as 399 a JSONArray of JSONArrays of JSONStrings. Anyone of the sub-arrays 400 indicates a potential candidate path calculated as the per-domain 401 topological distance corresponding to the amount of traversing 402 domains. 404 Moreover, as defined in Section 6.3.6 of [DRAFT-PV] [11], If an ALTO 405 client sends a request of the media type "application/alto- 406 costmapfilter+json" and accepts "multipart/related", the ALTO server 407 MUST provide path vector information along with the associated 408 Property Map information (e.g., entry points of the corresponding 409 foreign domains), in the same body of the response. 411 Section 5.5.2 gives an example of the Filtered Cost Map query and the 412 corresponding responses. 414 5.5. Examples of Message Exchange 416 This section list a couple of examples of the Property Map and 417 Filtered Cost Map queries and the corresponding responses. These 418 responses are based on the information in Table 1 and Table 2 of a 419 use case implementation described in Appendix A. 421 5.5.1. Property Map Service 423 In this example, the ALTO client wants to retrieve the entire 424 Property Map for PID entities with the "entry-point", "cpu", "mem", 425 "storage", "port" and "nf" properties. 427 GET /propmap/full/inet-ucmspn HTTP/1.1 428 Host: alto.example.com 429 Accept: application/alto-propmap+json,application/alto-error+json 431 HTTP/1.1 200 OK 432 Content-Length: ### 433 Content-Type: application/alto-propmap+json 434 { 435 "property-map": { 436 "pid:AS1": { 437 "entry-point": [ "http://172.25.0.10:8888/escape" ], 438 "cpu": [ "50.0" ], 439 "mem": [ "60.0" ], 440 "storage": [ "70.0" ], 441 "port": [ "SAP1" ], 442 "nf": [ "NF1", "NF3" ] 443 }, 444 "pid:AS2": { 445 "entry-point": [ "http://172.26.0.10:8888/escape" ], 446 "cpu": [ "10.0" ], 447 "mem": [ "20.0" ], 448 "storage": [ "30.0" ], 449 "nf": [ "NF2" ] 450 }, 451 "pid:AS3": { 452 "entry-point": [ "http://172.27.0.10:8888/escape" ], 453 "cpu": [ "80.0" ], 454 "mem": [ "90.0" ], 455 "storage": [ "100.0" ], 456 "port": [ "SAP2" ], 457 "nf": [ "NF1", "NF3" ] 458 } 459 } 460 } 462 5.5.2. Filtered Cost Map Service 464 The following example uses the Filtered Cost Map service to request 465 the path vector for a given E2E requirement. The SG request 466 information in Table 2 is used to describe the service, and it is 467 composed of three NFs (NF1, NF2, and NF3) and two SAPs (SAP1 and 468 SAP2). Links connecting the NFs and SAPs ("sg_links" tag) are also 469 included, followed by an E2E requirement ("reqs" tag) with 470 information about the order in which NFs are traversed from SAP1 to 471 SAP2. 473 Note that the request accepts "multipart/related" media type. This 474 means the ALTO server will include associated property information in 475 the same response. 477 POST /costmap/pv HTTP/1.1 478 Host: alto.example.com 479 Accept: multipart/related, application/alto-costmap+json, 480 application/alto-propmap+json, application/alto-error+json 481 Content-Length: [TBD] 482 Content-Type: application/alto-costmapfilter+json 484 { 485 "cost-type": { 486 "cost-mode": "array", 487 "cost-metric": "ane-path" 488 }, 489 "sg": { 490 "nfs": [ "NF1", "NF2", "NF3" ], 491 "saps": [ "SAP1", "SAP2" ], 492 "sg_links":[ 493 { 494 "id": 2, 495 "src-node": "SAP1", 496 "dst-node": "NF1", 498 }, 499 { 500 "id": 2, 501 "src-node": "NF1", 502 "dst-node": "NF2", 503 }, 504 { 505 "id": 3, 506 "src-node": "NF2", 507 "dst-node": "NF3", 508 }, 509 { 510 "id": 4, 511 "src-node": "NF3", 512 "dst-node": "SAP2", 513 } 514 ], 515 "reqs": [ 516 { 517 "id": 1, 518 "src-node": "SAP1", 519 "dst-node": "SAP2", 520 "sg-path": [ 1, 2, 3, 4 ] 521 } 522 ] 523 } 524 } 526 The ALTO server returns connectivity information for the E2E 527 requirement provided by the ALTO Client request of the above example. 528 Also, the response includes Property Map information for each element 529 in the path vector. In this case, it is retrieved a Property Map 530 with the "entry-point" property, i.e., the URL of the MdO entry point 531 for the corresponding network. 533 HTTP/1.1 200 OK 534 Content-Length: [TBD] 535 Content-Type: multipart/related; boundary=example 537 --example 538 Content-Type: application/alto-endpointcost+json 540 { 541 "meta": { 542 "cost-type": { 543 "cost-mode": "array", 544 "cost-metric": "ane-path" 545 }, 546 }, 548 "cost-map": { 549 "SAP1": { 550 "SAP2": { 551 "SAP1": { 552 "NF1": [ 553 [ "AS1" ], [ "AS1", "AS2", "AS3" ] 554 ] 555 }, 556 "NF1": { 557 "NF2": [ 558 [ "AS1", "AS2" ], [ "AS3", "AS2" ] 559 ] 560 }, 561 "NF2": { 562 "NF3": [ 563 [ "AS2", "AS1" ], [ "AS2", "AS3" ] 564 ] 566 }, 567 "NF3": { 568 "SAP2": [ 569 [ "AS1", "AS2", "AS3" ], [ "AS3" ] 570 ] 571 } 572 } 573 } 574 } 575 } 577 --example 578 Content-Type: application/alto-propmap+json 580 { 581 "property-map": { 582 "pid:AS1": { "entry-point": "http://172.25.0.10:8888/escape" }, 583 "pid:AS2": { "entry-point": "http://172.26.0.10:8888/escape" }, 584 "pid:AS3": { "entry-point": "http://172.27.0.10:8888/escape" } 585 } 586 } 588 --example-- 590 6. Acknowledgments 592 This work is supported by the Innovation Center of Ericsson S.A., 593 Brazil (grant agreement UNI.62). 595 Thank you to Robert Szabo (Ericsson Research, Hungary) for the 596 contribution and substantial feedback and suggestions in this 597 document. 599 7. IANA Considerations 601 This document includes no request to IANA. 603 8. Security Considerations 605 TBD. 607 9. References 608 9.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997, 612 . 614 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 615 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 616 "Application-Layer Traffic Optimization (ALTO) Protocol", 617 RFC 7285, DOI 10.17487/RFC7285, September 2014, 618 . 620 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 621 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 622 DOI 10.17487/RFC8189, October 2017, 623 . 625 9.2. Informative References 627 [DRAFT-PM] 628 Roome, W., Chen, S., xinwang2014@hotmail.com, x., Yang, 629 Y., and J. Zhang, "Extensible Property Maps for the ALTO 630 Protocol", draft-ietf-alto-unified-props-new-01 (work in 631 progress), December 2017. 633 [DRAFT-PV] 634 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 635 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 636 Vector Cost Type", draft-ietf-alto-path-vector-02 (work in 637 progress), December 2017. 639 [ETSI-NFV-DEF] 640 ETSI, "Network Functions Virtualisation (NFV); Terminology 641 for Main Concepts in NFV V1.3.1", Jan 2018, 642 . 646 [ETSI-NFV-MANO] 647 ETSI, "Network Functions Virtualisation (NFV) Management 648 and Orchestration V1.1.1", Dec 2014, 649 . 652 [ETSI-NFV-MANO-MDO] 653 ETSI, "Network Functions Virtualisation (NFV) Release 3; 654 Management and Orchestration; Report on architecture 655 options to support multiple administrative domains 656 V3.1.1", Jan 2018, . 660 [H2020.5GEX] 661 Bernardos, C., Dugeon, O., Galis, A., Morris, D., Simon, 662 C., and R. Szabo, "5G Exchange (5GEx)--Multi-domain 663 Orchestration for Software Defined Infrastructures", 664 focus vol. 4, no.5, p.2, 2015. 666 [H2020.5GEX.ESCAPE] 667 5GEx Project, "ESCAPE: Extensible Service ChAin 668 Prototyping Environment", 2015, 669 . 671 [ICAF] Demchenko, Y., Makkes, M., Strijkers, R., Ngo, C., and C. 672 Laat, "Intercloud Architecture Framework for Heterogeneous 673 Multi-Provider Cloud based Infrastructure Services 674 Provisioning", International Journal of Next-Generation 675 Computing vol. 4, no.2, 2013. 677 [PPP-5:2013] 678 5G-PPP, "Advanced 5G Network Infrastructure for the Future 679 Internet", 2013, . 683 [T-NOVA] FP7 project T-NOVA, "T-NOVA Project, Network Functions as 684 a Service over Virtualised Infrastructures", 2014, 685 . 687 [TELEFONICA.NET.TOPO] 688 Telefonica I+D, "Netphony-Topology", 2016, 689 . 691 [TOSCA] OASIS, "TOSCA: Topology and Orchestration Specification 692 for Cloud Applications V1.0", 2013, . 695 [UNIFY.NFFG] 696 UNIFY Deliverable D3.2a, "Network Function Forwarding 697 Graph specification", 2015, . 701 [VITAL] VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid 702 satellite-TerrestriAl systems for resilient and fLexible 703 future networks", 2015, . 705 9.3. URIs 707 [1] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new- 708 01#section-4.1 710 [2] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new- 711 01#section-4.2 713 [3] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new- 714 01#section-4.3 716 [4] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new- 717 01#section-4.4 719 [5] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new- 720 01#section-4.5 722 [6] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-01 724 [7] https://tools.ietf.org/html/draft-ietf-alto-unified-props-new- 725 01#section-4.6 727 [8] https://tools.ietf.org/html/draft-ietf-alto-path-vector- 728 02#section-6.1 730 [9] https://tools.ietf.org/html/draft-ietf-alto-path-vector- 731 02#section-6.1 733 [10] https://tools.ietf.org/html/draft-ietf-alto-path-vector- 734 02#section-6.1.2 736 [11] https://tools.ietf.org/html/draft-ietf-alto-path-vector- 737 02#section-6.3.6 739 Appendix A. Proof of Concept Use Case Implementation 741 A strawman use case scenario has been implemented following the 742 architectural proposal of the 5GEx project [H2020.5GEX]. It refers 743 to an E2ENS orchestration involving three administrative domains. 745 As shown in Figure 2, each administrative domain has an MdO (MdO-AS1, 746 MdO-AS2, and MdO-AS3) to coordinate resource and/or service 747 orchestration at multi-operator level via interface I2 APIs. For the 748 orchestration within the same administrative domain, each MdO uses 749 emulated DOs with emulated I3 interfaces, since no data-plane is 750 present. DOs use static configuration files to load local 751 information about resources (I3-RC) and topology (I3-RT). The 752 different MdO components are based on existing open source tools such 753 as ESCAPE [H2020.5GEX.ESCAPE] (Service/Resource Orchestrator) and 754 Netphony-topology [TELEFONICA.NET.TOPO] (Resource Topology) and run 755 in Docker containers on a single computer. Besides, MdOs expose I1 756 interfaces to the tenants who request services and/or slices which 757 should follow a Network Function Forwarding Graph (NFFG) [UNIFY.NFFG] 758 format. 760 In case of the broker layer, the IdR and IdT components use a UNIFY 761 Virtualizer API [UNIFY.NFFG] (broker-based I2-RC API) and a REST API 762 (broker-based I2-RT API) respectively, in order to create the 763 hierarchical databases. Regarding the IdT, the administrative domain 764 2 is a transit provider so that the domain-level topology computed 765 is: AS1-AS2-AS3. From the inter-domain information are created the 766 two different ALTO Map Services: (i) Property Map and (ii) Cost Map. 768 +----------------------------------------+ 769 | +---------------+ BROKER LAYER| 770 XXXXXXXXXXXXXX ALTO Server | | 771 X | +--------+----+-+ | 772 X | / \ | 773 X | +-----------+/+--+ +-\-------------+ | 774 X | | Inter-domain | | Inter-domain | | 775 +-----------+ X | | Topology (IdT) | | Resource (IdR)| | 776 | Service | X | +----------------+ +---------------+ | 777 | Graph (SG)| X +---------^-^----------------^--^--------+ 778 | Request | X * * ............. . 779 +-----+-----+ X * * . .............. 780 | X * * . . MdO-AS3 781 I1| X * * . . +--------------+ 782 | X MdO-AS1 * * . . | | 783 +-----|---------X-----------+ * * . . | MdO-AS2 | 784 | | | * * . . +---------------+ | 785 | +---v-------------------+ | * * . . | +-----------+ | | 786 | | | | * * . . | | | | | 787 | | Network Service Orch.| | * * . . | | NSO | | | 788 | | (NSO) | | * * . . | | | | | 789 | +-----------------------+ | * * . . | +-----------+ | | 790 | | * * . . | | | 791 | +---------+ | * * . . | +---+ | | 792 | | Resource........................... . | | | | | 793 | | Topoloy | | * * .......RT | | | 794 | | (RT) | +-----------+ | * * | | | | | 795 | +---------+ |Resource | | * * | +---+ +---+ | | 796 | |Orch. | | * ********************** | | | 797 | |(RO) ****** | |RO | +-+ 798 | +-----------+ | | | | | 799 | |<------------->| +---+ | 800 +---------------------------+ I2 +-----+---------+ 801 / \ | 802 I3/ \ |I3 803 +-------+---+ +-----------+ +-----------+ 804 | Domain | | Domain | | Domain | 805 | Orch (DO) | | Orch (DO) | | Orch (DO) | 806 +-----------+ +-----------+ +-----------+ 807 Legend: 808 XXX ALTO Protocol 809 ... broker-based I2-RT API 810 *** broker-based I2-RC API 812 Figure 2: Broker-assisted 5GEx Info Exchange 814 The Property Map includes property values grouped by Autonomous 815 System (AS). Such values are SAPs, NFs and the 5GEx Entry Point 816 (e.g., the URL of the ESCAPE orchestrator). An example of the 817 Property Map in our prototype is: 819 +-----+------------+-------+--------------+-----+-----+-------+-----+ 820 | | Entry | Port | Capabilities | CPU | MEM | Stor | ... | 821 | | Point | SAP | | | | age | | 822 +-----+------------+-------+--------------+-----+-----+-------+-----+ 823 | AS1 | http://... | SAP1 | {NF1, NF3} | 50 | 60 | 70 | ... | 824 | AS2 | http://... | - | {NF2} | 10 | 20 | 30 | ... | 825 | AS3 | http://... | SAP2 | {NF1, NF3} | 80 | 90 | 100 | ... | 826 +-----+------------+-------+--------------+-----+-----+-------+-----+ 828 Table 1: ALTO Property Map 830 The Cost Map defines a path vector as an array of ASes, representing 831 the AS-level topological distance for a given E2ENS request. Path 832 vector constraints (as described in the Multi-Cost Map [RFC8189]) can 833 be applied to restricts the response to costs that satisfy a list of 834 simple predicates. 836 Table 2 below shows a brief example of an SG request and its path 837 vector response containing a list of potential providers to be 838 traversed to deliver such service. Every AS path is computed from 839 the inter-domain topology information in the IdT module. In our 840 scenario, MdO-AS2 is a transit provider, so that the domain-level 841 topology map is AS1<->AS2<->AS3. 843 +--------------------+----------------------------------------------+ 844 | Service Graph (SG) | Path(s) Vector | 845 | Request | | 846 +--------------------+----------------------------------------------+ 847 | SAP1->NF1->NF2->NF | 1:{AS1:SAP1->AS1:NF1->AS2:NF2->AS3:NF3->AS3: | 848 | 3->SAP2 | SAP2} | 849 | | 2:{AS1:SAP1->AS1:NF1->AS2:NF2->AS1:NF3->AS2- | 850 | | >AS3:SAP2} | 851 | | 3:{AS1:SAP1->AS2->AS3:NF1->AS2:NF2->AS3:NF3- | 852 | | AS3:SAP2} | 853 | | 4:{AS1:SAP1->AS2->AS3:NF1->AS2:NF2->AS1:NF3- | 854 | | >AS2->AS3:SAP2} | 855 +--------------------+----------------------------------------------+ 857 Table 2: ALTO Cost Map 859 Authors' Addresses 861 Danny Alex Lachos Perez 862 University of Campinas 863 Av. Albert Einstein 400 864 Campinas, Sao Paulo 13083-970 865 Brazil 867 Email: dlachosp@dca.fee.unicamp.br 868 URI: https://intrig.dca.fee.unicamp.br/ 870 Christian Esteve Rothenberg 871 University of Campinas 872 Av. Albert Einstein 400 873 Campinas, Sao Paulo 13083-970 874 Brazil 876 Email: chesteve@dca.fee.unicamp.br 877 URI: https://intrig.dca.fee.unicamp.br/christian/