idnits 2.17.1 draft-lachos-alto-multi-domain-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 673 has weird spacing: '...|10Gbps x...' == Line 682 has weird spacing: '...100Gbps x ...' -- The document date (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '----AS1----' is mentioned on line 368, but not defined == Missing Reference: '-----AS2-----' is mentioned on line 368, but not defined == Missing Reference: '-----AS3-----' is mentioned on line 368, but not defined == Missing Reference: 'DRAFT-ALTO-PM' is mentioned on line 372, but not defined ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-22) exists of draft-ietf-alto-cdni-request-routing-alto-11 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-09 == Outdated reference: A later version (-06) exists of draft-zhang-alto-multipart-03 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-10 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-11 == Outdated reference: A later version (-04) exists of draft-lachosrothenberg-alto-brokermdo-02 == Outdated reference: A later version (-03) exists of draft-randriamasy-alto-cost-context-02 == Outdated reference: A later version (-07) exists of draft-gao-alto-fcs-06 == Outdated reference: A later version (-08) exists of draft-li-sfc-hhsfc-07 == Outdated reference: A later version (-06) exists of draft-xiang-alto-multidomain-analytics-02 == Outdated reference: A later version (-02) exists of draft-lachosrothenberg-alto-md-e2e-ns-00 == Outdated reference: A later version (-01) exists of draft-lachos-multi-domain-sfc-alto-00 == Outdated reference: A later version (-03) exists of draft-xiang-alto-unified-representation-01 Summary: 2 errors (**), 0 flaws (~~), 20 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 Q. Xiang 6 Y. Yang 7 Yale University 8 B. Ohlman 9 Ericsson Research 10 S. Randriamasy 11 Nokia Bell Labs 12 F. Boten 13 Sprint 14 LM. Contreras 15 Telefonica 16 J. Zhang 17 Tongji University 18 K. Gao 19 Sichuan University 20 July 13, 2020 22 Supporting Multi-domain Use Cases with ALTO 23 draft-lachos-alto-multi-domain-use-cases-01 25 Abstract 27 The goal of this document is to summarize current standardization 28 efforts in the IETF ALTO working group to support important multi- 29 domain use cases and show how they can benefit from network 30 information exposure using ALTO. Besides, key design requirements of 31 network information exposure to support multi-domain use cases are 32 also presented along with information about novel mechanisms and 33 abstractions to improve the base ALTO framework in multi-domain 34 scenarios. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 14, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Network Information Exposure: Current ALTO Context . . . . . 4 72 3. Multi-domain Use Cases . . . . . . . . . . . . . . . . . . . 5 73 3.1. Multi-domain, collaborative data sciences . . . . . . . . 5 74 3.1.1. How can multi-domain resource orchestration benefit 75 from ALTO? . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Multi-domain SFC . . . . . . . . . . . . . . . . . . . . 7 78 3.2.1. How can multi-domain SFC benefit from ALTO? . . . . . 8 79 3.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.3. Multi-domain SDN . . . . . . . . . . . . . . . . . . . . 10 81 3.3.1. How can flexible interdomain routing benefit from 82 ALTO? . . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 11 84 4. Requirements on Multi-domain Network Information Exposure . . 11 85 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 11 86 4.2. Existing Efforts in the ALTO Working Group . . . . . . . 12 87 5. Novel Multi-domain Mechanisms and Abstractions . . . . . . . 13 88 5.1. Multi-domain Aggregation . . . . . . . . . . . . . . . . 13 89 5.1.1. Workflow . . . . . . . . . . . . . . . . . . . . . . 14 90 5.2. Multi-resource Abstraction . . . . . . . . . . . . . . . 15 91 5.2.1. Mathematical Programming Constraints: Basic Idea . . 15 92 5.2.2. Removing Redundant Linear Inequalities . . . . . . . 16 93 5.2.3. From Single Domain to Multiple Domains . . . . . . . 16 94 5.3. Multi-domain Programming Information Abstraction . . . . 19 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 99 8.2. Informative References . . . . . . . . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 Many multi-domain use cases are emerging with the development of new 105 technologies, such as software-defined networking (SDN), network 106 function virtualization (NFV), and 5G. Examples of such use cases 107 include multi-domain, collaborative data 108 sciences [CMS][LCLS][LHC][SKA], multi-domain service function 109 chaining (SFC) [NGMN-5G][SFC-MD][MD-ORCH-NFV][ETSI-ZSM], and multi- 110 domain SDN [SFP][SDX][RFC5575]. Such use cases can benefit 111 substantially from the exposure of network information, with which 112 users can perform application-layer resource optimization to improve 113 the performance. 115 The Application-Layer Optimization Protocol (ALTO) [RFC7285] already 116 introduces basic mechanisms (e.g., modularity, dependency) and 117 abstractions (e.g., map services) for applications to take optimized 118 actions based on network information. However, exposing network 119 information to support multi-domain use cases places additional 120 requirements that existing solutions such as the current ALTO design 121 do not satisfy. First, abstractions that aggregate multiple networks 122 into a single, virtual network are required to simplify the 123 application-layer optimization conducted by end-users. Second, such 124 abstractions need to provide a unified representation of multiple 125 resources (e.g., networking, computation, and storage) in multiple 126 networks. 128 This document reviews the current ALTO architecture to expose network 129 information for applications (Section 2), and it then presents 130 several important multi-domain use cases that can benefit 131 substantially from network information exposure (Section 3). Next, 132 it elaborates the key design requirements of network information 133 exposure to support these use cases (Section 4), followed by proposed 134 extensions in the ALTO working group to satisfy the design 135 requirements [MD-E2E-NS][UNIF-REPR] 136 [MD-USE-CASES][BROKER-MDO][MD-ANALYTICS][MD-SFC-ALTO]. Finally, it 137 summarizes novel mechanisms and abstractions based on recent research 138 to improve the ALTO framework in the multi-domain set- 139 up [MERCATOR][BOXOPT][SDI] (Section 5). 141 2. Network Information Exposure: Current ALTO Context 143 ALTO already provides a generic framework to expose network 144 information for applications to improve their performance. Figure 1 145 presents a high-level overview of key ALTO mechanisms and 146 abstractions. 148 In particular, ALTO introduces generic mechanisms such as: 150 o Modularity and flexibility through an explicit division of ALTO 151 network information into (network) information resources. 153 o An information resource directory (IRD) providing a list of 154 available information resources in an ALTO server. 156 o Information consistency (tag, dependency, multi-info 157 resources [ALTO-MULTIPART]) to specify a dependency among 158 different information resources. 160 o A generic framework with Server-Sent Events (SSEs) [ALTO-SSE] to 161 perform stream-control, push, incremental update of information 162 resources. 164 ALTO also introduces abstractions modules, such as: 166 o Network and cost maps to provide network location groupings and 167 costs between them. 169 o A multi-cost map [RFC8189] to retrieve several cost metrics in a 170 single query/response transaction. 172 o The path vector abstraction [ALTO-PATH] to provide more detailed 173 routing information using Abstract Network Elements (ANEs). 175 o Capability maps (e.g., CDNI [ALTO-CDNI] and unified property 176 Map [ALTO-PROP]). 178 Another generic concept introduced is filter so that information 179 resources can be filtered (e.g., Filtered network map, filtered cost 180 map). Besides, each individual information resource is provided as a 181 RESTful service with a very simple, but well-working grammar 182 (essentially JSON grammar [RFC7159]). 184 Server discovery [RFC7286] and cross-domain server 185 discovery [ALTO-XDOM] are also introduced in order to identify a 186 topologically nearby ALTO server or ALTO servers outside of a network 187 domain, respectively. 189 ALTO SERVER 190 +--------------------------------------------------------------------+ 191 | | 192 | ABSTRACTIONS | 193 | +----------------------------------------------------------------+ | 194 | | | | 195 | |+-------------+ +-------------+ +-------------+ +-------------+ | | 196 | || | | | | | | Capability | | | 197 | || Network | | Cost Map | | Path | | Footprints/ | | | 198 | || Map | | (Calendar, | | Vector | | Unified | | | 199 | || | | ...) | | | | Properties | | | 200 | |+-------------+ +-------------+ +-------------+ +-------------+ | | 201 | +----------------------------------------------------------------+ | 202 | | 203 | MECHANISMS | 204 | +----------------------------------------------------------------+ | 205 | | | | 206 | | +------------------+ +------------------+ +------------------+ | | 207 | | | Information | | Information | | Information | | | 208 | | | Resource | | Consistency | | Update Model | | | 209 | | | Directory | | (Tag,Dependency) | |(SSE,Incremental) | | | 210 | | +------------------+ +------------------+ +------------------+ | | 211 | +----------------------------------------------------------------+ | 212 +----------------------------------^---------------------------------+ 213 | 214 | 215 | 216 +------------------------------v-----------------------------+ 217 | Infrastructure | 218 +------------------------------------------------------------+ 220 Figure 1: High Level ALTO Architecture. 222 3. Multi-domain Use Cases 224 Multi-domain network information exposure can be beneficial in 225 supporting multiple important use cases, including multi-domain, 226 collaborative data sciences, multi-domain SFC, and multi-domain SDN. 228 3.1. Multi-domain, collaborative data sciences 230 Many of today's premier science experiments, such as the Large Hadron 231 Collider (LHC) [LHC] and the Square Kilometre Array (SKA) [SKA], rely 232 on finely-tuned workflows that coordinate geographically distributed 233 resources (e.g., instrument, compute, storage) to enable scientific 234 discoveries. One example is the movement of LHC data from Tier 0 235 (i.e., the data center at the European Organization for Nuclear 236 Research, known as CERN) to Tier 1 (i.e., national laboratories) 237 storage sites around the world. Another example is that the Fermilab 238 is experimenting with moving the exascale LHC workflow to Amazon EC2 239 for more computation power [HEPCLOUD]. 241 The key to supporting these distributed workflows is the ability to 242 orchestrate multiple resources across multiple network domains to 243 facilitate predictable workflow performance (e.g., available 244 bandwidth, packet loss rate [ALTO-METRICS]). As such, multi-domain 245 network information exposure is a cornerstone to enable this ability. 247 3.1.1. How can multi-domain resource orchestration benefit from ALTO? 249 One key design challenge for multi-domain resource orchestration is 250 its resource information model. Existing design options such as 251 resource graph and ClassAds are inadequate because they cannot 252 simultaneously (1) allow member networks to provide accurate 253 information on different types of resource, (2) avoid the exposure of 254 private information of member networks such as topology, and (3) 255 allow data analytics jobs to describe their requirements of different 256 types of resources accurately. In contrast, ALTO is well suited for 257 providing a generic representation that (1) allows different types of 258 data analytics jobs to accurately describe their resource 259 requirements and (2) allows member networks to provide accurate 260 information on different types of resources they own and at the same 261 time maintain their privacies. 263 3.1.2. Example 265 Consider an example of three member networks in Figure 2, where s1 266 and s2 are storage endpoints, and d1 and d2 are computation 267 endpoints. Assume a data analytics job is composed of two parallel 268 tasks T1 and T2. T1 needs dataset X as input, and T2 needs dataset Y 269 as input. 271 .------------. 272 | Network B | 273 .-------------. ingB| | 274 | Network A o--------|o-----d1 | 275 | /| '------------' 276 | s1\ / | 277 | o--o | .------------. 278 | s2/ \ | | Network C | 279 | \| ingC| | 280 | o--------|o-----d2 | 281 '-------------' '------------' 283 Figure 2: Multi-domain resource orchestration. 285 Using the ALTO endpoint property service, an ALTO client in the 286 resource orchestrator can discover that d1 satisfies the computing 287 requirements of T1, and d2 satisfies the computing requirements of 288 T2. Hence there are only two candidate endpoint pairs: (s1, d1) and 289 (s2, d2). 291 Afterward, using the ALTO path vector extension, the ALTO client can 292 retrieve the bandwidth sharing information of task T1 and T2, denoted 293 as x1 and x2, respectively, as follows: 295 A: x1 + x2 <= 10Mbps 296 B: x1 <= 3Mbps 297 C: x2 <= 3Mbps 299 With such information, the resource orchestrator can make the optimal 300 resource orchestration decision to reserve 3 Mbps bandwidth for task 301 T1, and 3 Mbps bandwidth for task T2. 303 3.2. Multi-domain SFC 305 This use case refers to building end-to-end services by composing 306 multiple service functions (SFs) in an abstract sequence across 307 multiple network domains [SFC-MD]. It is identified as an important 308 value-added service in 5G [MD-ORCH-NFV][ETSI-ZSM]. Exposing multi- 309 domain network and resource information (e.g., link bandwidth, CPU 310 utilization) can substantially improve the efficiency of constructing 311 and managing such SFCs. 313 3.2.1. How can multi-domain SFC benefit from ALTO? 315 A "dialogue" between potential domains that provide multi-domain SFC 316 could be beneficial for more efficient use of resources and 317 increasing the SFC performance. However, constrained knowledge of 318 the network services and underlying network topology based only on 319 localized views from the point of view of a single domain limits the 320 potential and scope for multi-domain SFC. ALTO (and customized ALTO 321 extensions) can be used to offer aggregated/abstracted views on 322 various types of information, including domain-level topology, 323 storage resources, computation resources, networking resources, and 324 SF capabilities. This generic representation contributes to a more 325 simple and scalable solution for resource and service discovery in 326 multi-domain, multi-technology environments. 328 3.2.2. Example 330 Figure 3 shows a SFC eXchange Platform (SXP), connecting three 331 different domains (AS1, AS2, AS3). A SXP is a logical entity to make 332 possible the negotiation between different domains, and it could be 333 deployed, for example, in future Software-defined IXP (as a trusted 334 third-party platform) [HH-MDSFC]. 336 In this scenario, each domain provides different SFs: AS1 = {SF1}; 337 AS2 = {SF2, SF3}; and AS3 = {SF3}. The SXP also includes an ALTO 338 server component to provide abstract topology, resource, and service 339 information for the high-level control plane in each domain 340 [MD-SFC-ALTO]. 342 SFC eXchange 343 Platform 344 +--------------------+ 345 | +--------+ | 346 | | ALTO | | 347 | | Server | | 348 | +--------+ | 349 +----> <-----+ 350 | +----------^---------+ | 351 | | | 352 | | | 353 | | | 354 +----v---+ +-----v--+ +------v-+ 355 |Control | |Control | |Control | 356 |Plane | |Plane | |Plane | 357 +--------+ +--------+ +--------+ 358 | | | 359 | | | 360 | | | 361 +--------+ +--------+ +--------+ 362 |Data | |Data | |Data | 363 |Plane -------Plane -------Plane | 364 +--------+ +--------+ +--------+ 365 SF1 SF2 SF3 366 SF3 368 [----AS1----][-----AS2-----][-----AS3-----] 370 Figure 3: Multi-domain SFC Architecture with ALTO. 372 The ALTO Property Map Service [DRAFT-ALTO-PM] can provide a clear 373 global view of the resource information offered by other domains. 374 This information allows discovering which candidate domains may be 375 contacted to deliver the remaining requirements of a requested end- 376 to-end service deployment. In our example, the Property Map (see 377 Table 1) includes a property value grouped by AS. This value 378 contains the supported SFs. Additional properties could be 379 considered, such as resource availability (e.g., CPUs, Memory, and 380 Storage), orchestrator entry points, etc. 382 +-----+--------------+-------------+-----+-----+---------+-----+ 383 | | Capabilities | Entry Point | CPU | MEM | Storage | ... | 384 +-----+--------------+-------------+-----+-----+---------+-----+ 385 | AS1 | {SF1} | http://... | ... | ... | ... | ... | 386 | AS2 | {SF2, SF3} | http://... | ... | ... | ... | ... | 387 | AS3 | {SF3} | http://... | ... | ... | ... | ... | 388 +-----+--------------+-------------+-----+-----+---------+-----+ 390 Table 1: ALTO Property Map 392 Once the candidate domains are discovered, it is necessary to compute 393 multi-domain SF paths to select the SF location from those different 394 candidate domains. The connectivity information among discovered 395 domains can be retrieved by an ALTO Cost Map service. In our 396 example, the Cost Map defines a path vector as an array of ASes, 397 representing the AS-level topological distance for a given SFC 398 request. Table 2 below shows a brief example of a service request 399 and its multi-domain SF path response containing a list of potential 400 domains to be traversed to deliver such service. 402 +---------------+---------------------------------------+ 403 | SFC Request | Multi-domain Service Function Path(s) | 404 +---------------+---------------------------------------+ 405 | SF1->SF2->SF3 | 1:{AS1:SF1->AS2:SF2->AS2:SF3} | 406 | | 2:{AS1:SF1->AS2:SF2->AS3:SF3} | 407 +---------------+---------------------------------------+ 409 Table 2: ALTO Cost Map 411 3.3. Multi-domain SDN 413 Network providers are expanding the fine-grained capability of SDN 414 from intradomain set-up to multi-domain settings to provide flexible 415 interdomain routing as a valuable service [SFP][SDX][RFC5575]. Users 416 of this service can specify routing actions at the provider network 417 based on flexible matching conditions of flow parameters such as TCP/ 418 IP 5-tuple. This service requires provider networks to expose their 419 available routing information to users. However, handling routing 420 information of each network individually is too complex for users. 421 As such, a multi-domain network exposure solution that aggregates 422 information of multiple networks into a single abstraction can 423 simplify the use of this service. 425 3.3.1. How can flexible interdomain routing benefit from ALTO? 427 ALTO provides provider ASes a standardized approach to expose its 428 routing capability to client ASes. Traditional interdomain routing 429 protocols such as BGP are not good options because they only expose 430 the currently used routes, limiting client ASes' choices to specify 431 flexible routes. In contrast, ALTO and its extensions provide 432 interfaces for provider ASes to expose not only currently used 433 routes, but also available yet unused routes, to client ASes so that 434 they can have the flexibility to specify different routes for 435 different data traffic. 437 3.3.2. Example 439 Consider the example in Figure 4. AS A is compromised and being used 440 to send DDoS traffic to AS E. Without flexible interdomain routing, 441 AS E can setup a firewall locally, but normal traffic from B to E 442 will still be congested at C-D-E due to the existence of malicious 443 traffic from A to E. If AS C provides flexible interdomain routing 444 service, AS E can specify such a firewall at AS C to block DDoS 445 traffic from A, and at the same time avoid the congestion of normal 446 traffic from B to E. 448 +-----+ DDoS traffic 449 | AS A|_ 450 | | \ +--+---+ +---+--+ +------+ 451 +-----+ \ | | | | | | 452 \_| AS C +---------+ AS D |--------| AS E | 453 +-----+ / | | | | | | 454 | AS B|__/ +------+ +------+ +------+ 455 | | 456 +-----+ Normal traffic 458 Figure 4: Flexible interdomain routing for DDoS mitigation. 460 4. Requirements on Multi-domain Network Information Exposure 462 Supporting previous use cases with multi-domain network information 463 exposure places new, key requirements, which are not fully satisfied 464 by existing exposure solutions. This section discusses these 465 requirements and briefly review existing efforts in the ALTO working 466 group aiming to satisfy them. 468 4.1. Design Requirements 470 o Unified Resource Capability Representation. Modern use cases 471 require information on properties and capabilities of diverse in- 472 network resources, including transport resources (e.g., available 473 bandwidth), processing resources (e.g., SFs), and storage 474 resources. These use cases may then conduct orchestration of 475 multiple resources in multiple networks (e.g., RAN, transport, 476 core in 5G). As such, a unified representation of capabilities of 477 multiple resources is key requirement for multi-domain network 478 information exposure to support multi-domain use cases. 480 o Multi-domain, easy-to-compose, end-to-end representation. 481 Existing representations (e.g., ALTO network/cost maps, generic 482 YANG models) tend to focus on a single domain. In multi-domain 483 use cases, related information can be retrieved from multiple 484 networks to compute end-to-end information. As such, abstractions 485 that support aggregation of multiple networks into a single, 486 virtual network ("one-big-network") are a key requirement. 488 o Providing interfaces for more flexible queries. With the emerging 489 of new networking architecture (e.g., SDN and NFV) and the fine- 490 grained resource requirement of applications (e.g., link-disjoint 491 paths and endpoint precedence), applications need a more flexible 492 interface to specify queries of resource information. 494 4.2. Existing Efforts in the ALTO Working Group 496 Several documents have been submitted to the ALTO working group, with 497 the aim to satisfy one or more of the design requirements discussed 498 above. 500 o [DRAFT-RSA][DRAFT-UNICORN-INFO] documents propose and apply the 501 ALTO path vector extension to provide accurate networking resource 502 information to support multi-domain resource orchestration. 504 o [BROKER-MDO] proposes to use ALTO to support resource 505 orchestration for multi-domain SFC, and proposes a new ALTO 506 extension to retrieve AS path of network functions across 507 different networks. 509 o [DRAFT-CONTEXT] proposes to extend cost information specified in 510 [RFC7285] by providing several possible cost values for the same 511 cost metric where each value depends on qualitative criteria as 512 opposed to quantitative criteria such as time. 514 o [UNIF-REPR] makes a proposal to use mathematical programming 515 constraint as a generic representation of multiple resources. 517 o [DRAFT-FCS] proposes a flexible flow query extension service to 518 allow applications to specify query entities based on flexible 519 matching conditions (e.g., TCP/IP 5-tuple) instead of IP addresses 520 only. 522 5. Novel Multi-domain Mechanisms and Abstractions 524 This section presents novel mechanisms and abstractions based on 525 recent research to allow the ALTO framework supporting the important 526 multi-domain settings. 528 5.1. Multi-domain Aggregation 530 Figure 5 shows a generic aggregation framework of using ALTO in 531 multi-domain use cases [BROKER-MDO][MERCATOR][BOXOPT]. It includes a 532 multi-domain aggregation mechanism on top of the existing single 533 domain architecture. This new mechanism aggregates network 534 information from ALTO servers in multiple networks to provide a 535 single, consistent, updated, "virtual" domain abstraction. Network 536 maps, cost maps, unified entity properties, network capabilities, and 537 routing path abstractions (path vectors) of individual networks are 538 consistently integrated to provide the abstraction of a single, 539 coherent network to the users, satisfying the multi-domain 540 aggregation requirement. 542 +-------------+ 543 | Application | 544 +------|------+ 545 |(1) 546 | 547 +---------------+ (2) +-------v-------+ 548 (3)| <-----+ Multi-domain | 549 xxxxx> AGGREGATOR | | Orchestrator | 550 x | +-----> | 551 x +-----------^---^ (5) +-------|-------+ 552 x x x -/ |(6) \-- 553 x x x -/ | \-- 554 x x x -/ | \- 555 x x xxxxxxxxxxxxxxxxxxxxxxxxxx \-- 556 x x -/ | x \-- 557 x(4) x -/ | x \-- 558 +----v---+ +------+ x/ +--------+ +---v--+ +v-------+ +-\>---+ 559 | ALTO | | Dom Server | | Orch | | Server | | Orch | 561 +--------+ +------+ +--------+ +------+ +--------+ +------+ 562 +-----------------+ +-----------------+ +-----------------+ 563 | Infrastructure | | Infrastructure | | Infrastructure | 564 +-----------------+ +-----------------+ +-----------------+ 566 Network 1 Network 2 Network 3 568 Figure 5: Generic framework of using ALTO in multi-domain use cases. 570 5.1.1. Workflow 572 The basic workflow of this framework is as follows: 574 o A user (e.g., an application) submits a network service request to 575 the Multi-domain Orchestrator (MdO). 577 o The MdO receives the network service and queries the aggregator to 578 discover multi-resource network information (e.g., bandwidth, 579 delay, and loss rate). 581 o The aggregator determines the member networks that the network 582 service will traverse, and queries the ALTO server in each of 583 these member networks to discover their resource information. 585 o Upon receiving the query from the aggregator, each ALTO server 586 computes the resource abstraction of the corresponding member 587 network, and send the network resource information to the 588 aggregator. 590 o The aggregator collects the resource abstractions from the 591 relevant member networks, and derives this aggregated, unified 592 resource information to the MdO. 594 o Based on the received information, the MdO determines the resource 595 allocation for the network service, and sends a reservation 596 request to the Domain Orchestrators (DOs). 598 5.2. Multi-resource Abstraction 600 Although the existing abstractions (network/cost map, unified 601 property, and path vector) are already powerful, they cannot handle 602 the multi-resource information requirement. To this end, this 603 document presents a recent, unified resource abstraction, based on 604 mathematical programming constraints as a generic representation of 605 the feasible resource capability of networks [MERCATOR], which users 606 can consume via different resource management systems. 608 5.2.1. Mathematical Programming Constraints: Basic Idea 610 Consider a network as shown in Figure 6. Assume that the bandwidth 611 of every link is 100 Gbps. An application (e.g., a large data 612 analytics system) wants to reserve two circuits from S1 to D1 and S2 613 to D2, respectively. Assume the application is only interested in 614 the bandwidth of both circuits. The route of f1 (S1 -> D1) is S1 -> 615 sw1 -> sw5 -> sw6 -> sw8 -> sw3 -> D1, and the route of f2 (S2 -> D2) 616 is S2 -> sw2 -> sw5 -> sw6 -> sw8 -> sw4 -> D2. The routes for the 617 two circuits share common links l3 and l4, making it infeasible for 618 both circuits to each reserve a 100 Gbps bandwidth. 620 +-----+ l2 l3 +-----+ l4 l5 +-----+ 621 +--+ l1 | -----+ +----- |-----+ +----- | l6 +--+ 622 |S1-------- SW1 | | | | SW6 | | | | SW3 -------|D1| 623 +--+ +-----+ +-|--|+ +-----+ +-|--|+ +-----+ +--+ 624 | | | | 625 | SW5 | | SW8 | 626 +-----+ +-|--|+ +-----+ +-|--|+ +-----+ 627 +--+ l7 | | | | | | | | | | l12 +--+ 628 |S2-------- SW2 -----+ +----- SW7 |-----+ +----- SW4 -------|D2| 629 +--+ +-----+ l8 l9 +-----+ l10 l11 +-----+ +--+ 631 Figure 6: Network Topology Example. 633 The use of mathematical programming constraints is to generate a set 634 of linear inequalities to provide a compact representation for 635 different important properties of network resources (e.g., bandwidth, 636 delay, loss rate). In the previous example, the following set of 637 linear inequalities are generated: 639 f1 <= 100, for {l1, l2, l5, l6} ..... (le1) 640 f2 <= 100, for {l7, l8, l11, l12} ... (le2) 641 f1 + f2 <= 100, for {l3, l4} ............. (le3) 643 which accurately captures the bandwidth sharing among two circuits' 644 routes. 646 5.2.2. Removing Redundant Linear Inequalities 648 Taking a deeper look at the set of previous linear inequalities, one 649 can conclude that inequalities of le1 and le2 can be implicitly 650 derived from that of le3. Thus, these inequalities are considered 651 redundant. The problem of finding redundant linear constraints has 652 been widely studied [PAULRAJ10COMP]. Specifically, redundant linear 653 inequalities are removed via a polynomial-time, optimal algorithm 654 [KARMARKAR84]. In our example, the compressed set will only contain 655 one inequality: f1 + f2 <= 100, for {l3, l4} (le3). 657 5.2.3. From Single Domain to Multiple Domains 659 To illustrate the basic aggregation abstraction from a single network 660 to multiple networks, consider a collaboration network composed of 661 three member networks, as shown in Figure 7. A user wants to reserve 662 bandwidth for three circuits, from source host S to destination hosts 663 D1 , D2, and D3. 665 Member Member Member 666 Network 1 Network 2 Network 3 667 +xxxxxxxxxxxxxx+ +xxxxxxxxxxxxxxxxxxxxxxxxxxxx+ +xxxxxxxxxxxxxxxxx+ 668 x x x x x x 669 x +---+ x x +---+ +---+ x x +---+ x 670 x | |100Gbps x x | | 40Gbps | | x x | | x 671 x | --------------| ----------- --------------| ---+ x 672 x | | x x | | | |100Gbps x x | | | x 673 x +|--+ x x +|--+ +---+ x x +---+ |10Gbps x 674 x | x x | x x | x 675 x |40Gbps x x | x x +-|-+ x 676 x | x x | +---+ x x | | x 677 x +|--+ x x | 10Gbps | | x x +---- -----+ x 678 x | | x x +-------------- | x x | | | | x 679 x | | x x | | x x | +---+ | x 680 x +|--+ x x +|--+ x x | 10Gbps| x 681 x | x x | x x | | x 682 x |100Gbps x x 10Gbps| x x |10Gbps | x 683 x | x x | x x | | x 684 +xx|xxxxxxxxxxx+ +xxxxxxxxxxxxxxxxx|xxxxxxxxxx+ +xx|xxxxxxxxxxxx|x+ 685 | | | | 686 +|-+ +-|+ +--+ +--+ 687 |S | |D1| |D2| |D3| 688 +--+ +--+ +--+ +--+ 690 Figure 7: A collaboration network composed of three member networks. 692 The resource abstraction captures the constraints from all networks 693 using the set of linear inequalities, as depicted in Figure 8. 694 Specifically, the variables f1, f2, f3 represent the available 695 bandwidth that can be reserved for (S, D1 ), (S, D2), and (S, D3), 696 respectively. 698 +-----------+------------------------------------+ 699 | Network | Linear Inequalities | 700 +-----------+------------------------------------+ 701 | | f1 + f2 + f3 <= 100 ....... (le11) | 702 | Member | f1 + f2 + f3 <= 40 ........ (le12) | 703 | Network 1 | f1 + f2 + f3 <= 100 ....... (le13) | 704 +-----------+------------------------------------+ 705 | Member | f2 + f3 <= 40, f1 <= 10 ... (le21) | 706 | Network 2 | f2 + f3 <= 100, f1 <= 10 .. (le21) | 707 +-----------+------------------------------------+ 708 | | f2 + f3 <= 10 ............. (le31) | 709 | Member | f2 <= 10 ............. (le32) | 710 | Network 3 | f3 <= 100 ............ (le33) | 711 +-----------+------------------------------------+ 713 Figure 8: Resource abstraction for the reservation request from 714 Figure 4. 716 Each linear inequality represents a constraint on the reservable 717 bandwidths over different shared resources by the three circuits. 718 For example, the inequality le11 indicates that all three circuits 719 share a common resource and that the sum of their bandwidths can not 720 exceed 100 Gbps. 722 After removing the redundant inequalities of each member network, the 723 resource abstraction of each member network is: 725 +-----------+------------------------------------+ 726 | Network | Linear Inequalities | 727 +-----------+------------------------------------+ 728 | Network | f1 + f2 + f3 <= 40 ........ (le12) | 729 | Member 1 | | 730 +-----------+------------------------------------+ 731 | Network | f2 + f3 <= 40, f1 <= 10 ... (le21) | 732 | Member 2 | | 733 +-----------+------------------------------------+ 734 | Network | f2 + f3 <= 10 ............. (le31) | 735 | Member 3 | | 736 +-----------+------------------------------------+ 738 Figure 9: Resource abstraction of each member network after removing 739 the redundant inequalities. 741 Although each domain may already conduct redundancy optimization, 742 there can be cross-domain redundancy. For example, the constraint 743 le31 at member network 3 (f2 + f3 <= 10) can eliminate those at 744 member network 1 (f1 + f2 + f3 <= 40) and member network 2 (f2 + f3 745 <= 40). Using a classic compression algorithm [TELGEN83], we can 746 remove this cross domain redundancy. Therefore, the compressed 747 multi-domain set of linear inequalities will contain: 749 f1 <= 10, 750 f2 + f3 <= 10 752 5.3. Multi-domain Programming Information Abstraction 754 Multi-domain SDN requires multi-domain SDN resource and programming 755 abstraction. A novel multi-domain network programming framework is 756 recently proposed to achieve programmable, end-to-end interdomain 757 route control. Specifically, in this framework, each autonomus 758 system (AS) deploys an ALTO server to provide a programming 759 abstraction. Collectively, these ALTO servers provide the client a 760 single, abstract, programmable network spanning multiple individual 761 networks. Unlike existing SDN abstractions (e.g., OpenFlow and P4), 762 it includes a built-in layer to extract and learn the interactions of 763 interdomain policies of individual networks (e.g., route selection 764 preference), providing a unified abstraction. 766 Specifically, given a destination IP prefix p specified by a client, 767 each autonomous system (AS) exposes its routing information base 768 (RIB), i.e., all available routes it has to reach p, and the 769 corresponding price for the client to use each route, by deploying an 770 ALTO server. A client queries the available routes and the 771 corresponding prices at different ASes. With the retrieved 772 information, it then itereatively selects the best route based on its 773 internal objective function and budget, and interacts with different 774 ASes to check if the selected route is policy compliant, i.e., 775 whether all ASes along this route will export the preceding segment 776 to its upstream neighbor. After finding the best policy compliant 777 route, the client then interacts with ASes of the route in a backward 778 order along the route to setup the AS path. A blackbox based 779 optimization algorithm has been developed to allow the client to 780 swiftly find the best policy compliant route, and detailsed can be 781 find in [SDI]. 783 6. IANA Considerations 785 This document includes no request to IANA. 787 7. Security Considerations 789 TBD. 791 8. References 793 8.1. Normative References 795 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 796 and D. McPherson, "Dissemination of Flow Specification 797 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 798 . 800 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 801 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 802 2014, . 804 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 805 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 806 "Application-Layer Traffic Optimization (ALTO) Protocol", 807 RFC 7285, DOI 10.17487/RFC7285, September 2014, 808 . 810 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 811 H. Song, "Application-Layer Traffic Optimization (ALTO) 812 Server Discovery", RFC 7286, DOI 10.17487/RFC7286, 813 November 2014, . 815 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 816 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 817 DOI 10.17487/RFC8189, October 2017, 818 . 820 8.2. Informative References 822 [ALTO-CDNI] 823 Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang, 824 "Content Delivery Network Interconnection (CDNI) Request 825 Routing: CDNI Footprint and Capabilities Advertisement 826 using ALTO", draft-ietf-alto-cdni-request-routing-alto-11 827 (work in progress), April 2020. 829 [ALTO-METRICS] 830 WU, Q., Yang, Y., Dhody, D., Randriamasy, S., and L. 831 Contreras, "ALTO Performance Cost Metrics", draft-ietf- 832 alto-performance-metrics-09 (work in progress), March 833 2020. 835 [ALTO-MULTIPART] 836 Zhang, J. and Y. Yang, "Multiple ALTO Resources Query 837 Using Multipart Message", draft-zhang-alto-multipart-03 838 (work in progress), March 2020. 840 [ALTO-PATH] 841 Gao, K., Randriamasy, S., Yang, Y., and J. Zhang, "ALTO 842 Extension: Path Vector", draft-ietf-alto-path-vector-10 843 (work in progress), March 2020. 845 [ALTO-PROP] 846 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 847 Gao, "Unified Properties for the ALTO Protocol", draft- 848 ietf-alto-unified-props-new-11 (work in progress), March 849 2020. 851 [ALTO-SSE] 852 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 853 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 854 sse-22 (work in progress), March 2020. 856 [ALTO-XDOM] 857 Kiesel, S. and M. Stiemerling, "Application Layer Traffic 858 Optimization (ALTO) Cross-Domain Server Discovery", draft- 859 ietf-alto-xdom-disc-06 (work in progress), August 2019. 861 [BOXOPT] Xiang, Q., Zhang, J., Wang, T., Liu, J., Guok, C., Le, F., 862 MacAuley, J., Newman, H., and R. Yang, "Optimizing in the 863 Dark: Learning an Optimal Solution Through a Simple 864 Interface", Conference AAAI 2019, 2019. 866 [BROKER-MDO] 867 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 868 Multi-domain Orchestration", draft-lachosrothenberg-alto- 869 brokermdo-02 (work in progress), March 2019. 871 [CMS] The CMS Collaboration, "The CMS experiment at the CERN 872 LHC", 2008, 873 . 875 [DRAFT-CONTEXT] 876 Randriamasy, S., "ALTO Contextual Cost Values", draft- 877 randriamasy-alto-cost-context-02 (work in progress), July 878 2017. 880 [DRAFT-FCS] 881 Zhang, J., Gao, K., Wang, J., Xiang, Q., and Y. Yang, 882 "ALTO Extension: Flow-based Cost Query", draft-gao-alto- 883 fcs-06 (work in progress), July 2018. 885 [DRAFT-RSA] 886 Gao, K., xinwang2014@hotmail.com, x., Xiang, Q., Gu, C., 887 Yang, Y., and G. Chen, "Compressing ALTO Path Vectors", 888 draft-gao-alto-routing-state-abstraction-08 (work in 889 progress), March 2018. 891 [DRAFT-UNICORN-INFO] 892 Xiang, Q., Newman, H., Bernstein, G., duhaizhou@gmail.com, 893 d., Gao, K., Mughal, A., Balcas, J., Zhang, J., and Y. 894 Yang, "Resource Orchestration for Multi-Domain Data 895 Analytics", draft-xiang-alto-exascale-network- 896 optimization-03 (work in progress), July 2017. 898 [ETSI-ZSM] 899 ETSI, "Zero Touch Network and Service Management", 2020, 900 . 903 [HEPCLOUD] 904 Holzman, B., Bauerdick, L., Bockelman, B., Dykstra, D., 905 Fisk, I., Fuess, S., Garzoglio, G., Girone, M., Gutsche, 906 O., and D. Hufnagel, "Hepcloud, a new paradigm for hep 907 facilities: Cms amazon web services investigation", 908 Journal Computing and Software for Big Science, Volume 1, 909 Number 1, Pages 1, Publisher Springer, 2017. 911 [HH-MDSFC] 912 Li, G., Li, G., Xu, Q., Zhou, H., Feng, B., Feng, X., and 913 Z. Yu, "Hybrid Hierarchical Multi-Domain Service Function 914 chaining", draft-li-sfc-hhsfc-07 (work in progress), 915 September 2019. 917 [KARMARKAR84] 918 Karmarkar, N., "A new polynomial-time algorithm for linear 919 programming", Book Title Proceedings of the sixteenth 920 annual ACM symposium on Theory of computing, Pages 302-- 921 311, 1984. 923 [LCLS] SLAC National Accelerator Laboratory, "The Linac Coherent 924 Light Source", 2020, . 926 [LHC] CERN: European Council for Nuclear Research, "The Large 927 Hadron Collider (LHC) Experiment", 2020, 928 . 930 [MD-ANALYTICS] 931 Xiang, Q., Le, F., Yang, Y., Newman, H., and H. Du, 932 "Unicorn: Resource Orchestration for Multi-Domain, Geo- 933 Distributed Data Analytics", draft-xiang-alto-multidomain- 934 analytics-02 (work in progress), July 2018. 936 [MD-E2E-NS] 937 Perez, D. and C. Rothenberg, "Multi-domain E2E Network 938 Services", draft-lachosrothenberg-alto-md-e2e-ns-00 (work 939 in progress), March 2019. 941 [MD-ORCH-NFV] 942 Katsalis, K., Nikaein, N., and A. Edmonds, "Multi-domain 943 orchestration for NFV: Challenges and research 944 directions", focus 189--195, 2016. 946 [MD-SFC-ALTO] 947 Perez, D., Xiang, Q., Rothenberg, C., and Y. Yang, "Multi- 948 domain Service Function Chaining with ALTO", draft-lachos- 949 multi-domain-sfc-alto-00 (work in progress), July 2018. 951 [MD-USE-CASES] 952 Xiang, Q., Le, F., and Y. Yang, "ALTO for Multi-Domain 953 Applications: A Review of Use Cases and Design 954 Requirements", draft-xiang-alto-multidomain-usecases-00 955 (work in progress), March 2019. 957 [MERCATOR] 958 Xiang, Q., Zhang, J., Wang, T., Liu, J., Guok, C., Le, F., 959 MacAuley, J., Newman, H., and R. Yang, "Fine-grained, 960 multi-domain network resource abstraction as a fundamental 961 primitive to enable high-performance, collaborative data 962 sciences", focus 58--70, 2018. 964 [NGMN-5G] Alliance, NGMN, "5G White Paper", 2015, 965 . 967 [PAULRAJ10COMP] 968 Paulraj, S. and P. Sumathi, "A comparative study of 969 redundant constraints identification methods in linear 970 programming problems", Journal Mathematical Problems in 971 Engineering, Volume 2010, Publisher Hindawi Limited, 2010. 973 [SDI] Xiang, Q., Zhang, J., Gao, K., Lim, Y., Le, F., Li, G., 974 and R. Yang, "Toward Optimal Software-Defined Interdomain 975 Routing", Conference 39th Annual IEEE International 976 Conference on Computer Communications (INFOCOM'20), 2020. 978 [SDX] Gupta, A., Vanbever, L., Shahbaz, M., Donovan, S., 979 Schlinker, B., Feamster, N., Rexford, J., Shenker, S., 980 Clark, R., and E. Katz-Bassett, "Sdx: A software defined 981 internet exchange", focus 551--562, 2015. 983 [SFC-MD] Sun, G., Li, Y., Liao, D., and V. Chang, "Service function 984 chain orchestration across multiple domains: A full mesh 985 aggregation approach", Journal IEEE Transactions on 986 Network and Service Management, Volumen 15, Number 3, 987 Pages 1175--1191, Publisher IEEE, 2018. 989 [SFP] Xiang, Q., Guok, C., Le, F., MacAuley, J., Newman, H., and 990 R. Yang, "SFP: Toward Interdomain Routing for SDN 991 Networks", focus 87--89, 2018. 993 [SKA] SKA Organisation, "The Square Kilometre Array", 2020, 994 . 996 [TELGEN83] 997 Telgen, J., "Identifying redundant constraints and 998 implicit equalities in systems of linear constraints", 999 Journal Management Science, Volume 29, Number 10, Pages 1000 1209--1222, Publisher INFORMS, 1983. 1002 [UNIF-REPR] 1003 Xiang, Q., Le, F., and Y. Yang, "ALTO Extension: Unified 1004 Resource Representation", draft-xiang-alto-unified- 1005 representation-01 (work in progress), March 2019. 1007 Authors' Addresses 1009 Danny Alex Lachos Perez 1010 University of Campinas 1011 Av. Albert Einstein 400 1012 Campinas, Sao Paulo 13083-970 1013 Brazil 1015 Email: dlachosp@dca.fee.unicamp.br 1016 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 1017 Christian Esteve Rothenberg 1018 University of Campinas 1019 Av. Albert Einstein 400 1020 Campinas, Sao Paulo 13083-970 1021 Brazil 1023 Email: chesteve@dca.fee.unicamp.br 1024 URI: https://intrig.dca.fee.unicamp.br/christian/ 1026 Qiao Xiang 1027 Yale University 1028 51 Prospect Street 1029 New Haven, CT 1030 USA 1032 Email: qiao.xiang@cs.yale.edu 1034 Y. Richard Yang 1035 Yale University 1036 51 Prospect St 1037 New Haven, CT 1038 USA 1040 Email: yang.r.yang@gmail.com 1042 Borje Ohlman 1043 Ericsson Research 1044 S-16480 Stockholm 1045 Sweden 1047 Email: Borje.Ohlman@ericsson.com 1049 Sabine Randriamasy 1050 Nokia Bell Labs 1051 Route de Villejust 1052 NOZAY 91460 1053 FRANCE 1055 Email: Sabine.Randriamasy@nokia-bell-labs.com 1056 Farni Boten 1057 Sprint 1058 USA 1060 Email: farni.weaver@sprint.com 1062 Luis M. Contreras 1063 Telefonica 1064 Ronda de la Comunicacion, s/n 1065 Madrid 28050 1066 Spain 1068 Email: luismiguel.contrerasmurillo@telefonica.com 1069 URI: http://lmcontreras.com/ 1071 Jingxuan Jensen Zhang 1072 Tongji University 1073 4800 Caoan Road 1074 Shanghai 201804 1075 China 1077 Email: jingxuan.n.zhang@gmail.com 1079 Kai Gao 1080 Sichuan University 1081 Chengdu 610000 1082 China 1084 Email: kaigao@scu.edu.cn