idnits 2.17.1 draft-lachos-alto-md-info-exposure-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 (July 13, 2020) is 1376 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'A' is mentioned on line 292, but not defined == Missing Reference: 'C' is mentioned on line 292, but not defined == Missing Reference: 'B' is mentioned on line 292, but not defined ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-22) exists of draft-ietf-alto-cdni-request-routing-alto-11 == 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-10 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-17 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-01 == Outdated reference: A later version (-06) exists of draft-xiang-alto-multidomain-analytics-03 == Outdated reference: A later version (-04) exists of draft-lachosrothenberg-alto-brokermdo-03 == Outdated reference: A later version (-01) exists of draft-lachos-sfc-multi-domain-alto-00 == Outdated reference: A later version (-03) exists of draft-xiang-alto-unified-representation-02 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 2 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: 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 Multi-domainn Information Exposure using ALTO 23 draft-lachos-alto-md-info-exposure-00 25 Abstract 27 A common setting in emerging applications (e.g., data-intensive 28 science applications, flexible inter-domain routing, multi-domain 29 service function chaining) is that the traffic from a source to a 30 destination traverses multiple networks domains. Such multi-domain 31 applications can benefit from network information exposure using 32 ALTO. This document summarizes the benefits of using such multi- 33 domain information and discusses the ALTO design issues for gathering 34 it. Besides, it also presents key design requirements to be 35 addressed in order to realize the proposal of providing multi-domain 36 information by ALTO services. Finally, another important objective 37 of this document is to begin discussions into the ALTO WG concerning 38 potential new items to be considered for the re-charter. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 14, 2021. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. What does "multi-domain information exposure" mean? . . . . . 3 76 3. What Information do Multi-domain applications need? . . . . . 5 77 3.1. Basic Formulation . . . . . . . . . . . . . . . . . . . . 6 78 4. What are the ALTO issues of gathering multi-domain 79 information? . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.1. Communication Mechanisms . . . . . . . . . . . . . . . . 8 81 4.1.1. Server-to-Client ALTO communication . . . . . . . . . 8 82 4.1.2. Domain connectivity discovery . . . . . . . . . . . . 8 83 4.1.3. ALTO server discovery . . . . . . . . . . . . . . . . 8 84 4.2. Conceptual Query Interfaces and Data Representation . . . 8 85 4.2.1. Single-domain composition . . . . . . . . . . . . . . 8 86 4.2.2. Simple resource query language . . . . . . . . . . . 9 87 4.3. Computation Model . . . . . . . . . . . . . . . . . . . . 9 88 4.3.1. Scalability . . . . . . . . . . . . . . . . . . . . . 9 89 4.3.2. Security and Privacy . . . . . . . . . . . . . . . . 9 90 5. How to design a whole ALTO framework? . . . . . . . . . . . . 9 91 5.1. ALTO servers communication . . . . . . . . . . . . . . . 10 92 5.2. Multi-domain Connectivity discovery . . . . . . . . . . . 10 93 5.3. Multi-domain ALTO Server discovery . . . . . . . . . . . 11 94 5.4. Unified resource representation . . . . . . . . . . . . . 11 95 5.5. Flexible/Generic query language . . . . . . . . . . . . . 11 96 5.6. Computation complexity optimization . . . . . . . . . . . 12 97 5.7. Security/Privacy Preserving . . . . . . . . . . . . . . . 12 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 103 8.2. Informative References . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 106 1. Introduction 108 Many multi-domain applications are emerging with the development of 109 new technologies, such as SDN, NFV, and 5G. Examples of such 110 applications include data-intensive science 111 applications [CMS][LCLS][LHC][SKA], multi-domain service function 112 chaining [NGMN-5G][SFC-MD][MD-ORCH-NFV][ETSI-ZSM], and flexible 113 inter-domain routing [SFP][SDX][RFC5575]. Such cross-domain 114 applications can benefit substantially from exposure of network 115 information to improve both applications performance and resource 116 consumption. 118 The Application-Layer Optimization Protocol (ALTO) [RFC7285] already 119 introduces basic mechanisms (e.g., modularity, dependency) and 120 abstractions (e.g., map services) for applications to take optimized 121 actions based on network information. However, exposing network 122 information to support multi-domain use cases introduces issues to be 123 considered in the current ALTO design. 125 This document provides a definition of multi-domain information 126 exposure (Section 2) and identifies the benefits of using it in 127 applications traversing multiple domains (Section 3). Next, it 128 elaborates key design requirements of ALTO for exposing multi-domain 129 information (Section 4). It then lists a set of mechanisms to design 130 a multi-domain ALTO framework (Section 5). 132 The overall rationale of this document is to arouse a discussion 133 about potential rechartering topics to handle multi-domain with ALTO. 135 2. What does "multi-domain information exposure" mean? 137 For the purposes of this document, a domain is considered to be a 138 separate administrative environment. Specifically, the multi-domain 139 approach involves multiple networks managed by different 140 administrative domains. Examples of such domains include, among 141 others, science networks, mobile operators, cloud service providers, 142 and transport network providers. 144 In multi-domain information exposure, multiple networks perform 145 exchange of information to handle applications traversing multiple 146 domains. For example, consider a collaboration network composed of 147 three-member domains, as shown in Figure 1. An application (e.g., a 148 large data analysis system) wants to reserve bandwidth for two flows 149 f1: (S1, D1) and f2: (S2, D2). In this example, the traffic from a 150 source to a destination traverses multiple domains (A, B, and C), and 151 hence the application needs to retrieve multi-domain information 152 about topology and resources to take optimized allocation/placement 153 decisions. 155 .------------. 156 | Domain B | 157 .-------------. | 30 Gbps | 158 | Domain A | _____o............o---D1 159 S1 | | / '------------' 160 \ | 100 Gbps | / 161 \ o*************o/ .------------. 162 / | | \ | Domain C | 163 / | | \ | 30 Gbps | 164 S2 | | \____o............|---D2 165 '-------------' '------------' 167 ---- 1 Tbps link 169 Figure 1: A collaboration network composed of three member domains. 171 The current ALTO base protocol is not designed for a multi-domain 172 setting of exposing network information. For example, consider P2P 173 applications (the first and main use case for the development of 174 ALTO [RFC7971]). Figure 2 depicts a tracker-based P2P application 175 with a global tracker (ALTO client) in domain A accessing ALTO 176 servers at two ISPs (domains B and C). The ALTO server in each 177 domain will provide only local information to ALTO clients, i.e., the 178 tracker will receive topology-/policy-related information of a single 179 domain (domain B or domain C). Due to the lack of information 180 exchange between different domains, ALTO servers will not be able to 181 expose information across multiple domains, i.e., the tracker will 182 not receive merged topology-/policy-related information from domain B 183 and domain C. 185 ,-------. 186 ,---. ,-' `-. +-----------+ 187 ,-' `-. / domain B \ | Peer 1 |******** 188 / \ / +-------------+ \ | | * 189 / domain A \ ++====>| ALTO Server | )+-----------+ * 190 / \ || \ +------^------+ / +-----------+ * 191 ; +-----------+ : || \ # / | Peer 2 | * 192 | | Tracker |<====++ `-. # ,-' | |****** * 193 | |ALTO Client| | `---#---' +-----------+ * * 194 | +-----------+<====++ ,---#---. * * 195 : * ; || ,-' # `-. +-----------+ * * 196 \ * / || / # \ | Peer 3 | * * 197 \ * / || / +------v------+ \ | |**** * * 198 \ * / ++====>| ALTO Server | )+-----------+ * * * 199 `-. * ,-' \ +-------------+ / +-----------+ * * * 200 `-*-' \ / | Peer 4 |** * * * 201 * `-. domain C,-' | | * * * * 202 * `-------' +-----------+ * * * * 203 * * * * * 204 * * * * * 205 ********************************************************* 206 Legend: 207 *** Application protocol 208 === ALTO protocol 209 ### Multi-domain ALTO protocol (NOT EXISTS) 211 Figure 2: Global Tracker Accessing ALTO Server at Various Domains 212 (Adapted from [RFC7971]). 214 3. What Information do Multi-domain applications need? 216 Many types of network information are needed by cross-domain 217 applications to improve their performances, including network state 218 (e.g., loss, delay, ECN bit [RFC3168], INT [INT]), performance 219 metrics (e.g., throughput, max reservable Bandwidth), capability 220 information (e.g., delivery/acquisition protocol), locality (e.g., 221 servers/domains location and paths), among others. 223 In our previous example (See Figure 1), before the application can 224 run a resource allocation algorithm to execute such submitted flows, 225 it needs to gather some information from the network domains: 227 o End-to-End cost across multiple domains 229 This cost may be expressed in terms of resource availability and 230 sharing (e.g., network bandwidth) for the set of requested flows 231 to be reserved. In our presented scenario, for example, both 232 flows f1 and f2 are sharing the same network path in domain A. It 233 means that they share a common resource, the network bandwidth. 235 o Sequence of domains and candidate paths 237 In multi-domain use cases, each flow will consume networking 238 resources of multiple domains (if source node and destination node 239 are located in different domains). Therefore, the application 240 needs to discover a sequence of domains and candidate paths 241 between source nodes and destination nodes, i.e., which domains 242 are involved for the different traffic flows. In our example, the 243 multi-domain network paths for f1 and f2 are [A , B], and [A, C], 244 respectively. 246 3.1. Basic Formulation 248 Consider different services, for each domain, providing previous 249 information. Each service is defined as an object fi with a set of 250 network properties, such as: 252 o Path (fi.path): representing the sequence of network devices that 253 packets of flow fi will traverse. 255 o Available bandwidth (fi.abw): representing the bandwidth that flow 256 fi can request. 258 o Delay (fi.delay): representing the average delay of packets of 259 flow fi. 261 In our example, consider each ALTO server providing the bandwidth 262 property using a set of linear inequalities (See Figure 3). Where x1 263 and x2 represent the available bandwidth that can be reserved for 264 (S1, D1 ), and (S2, D2), respectively. 266 +-----------+---------------------- --------+ 267 | DOMAIN | LINEAR INEQUALITIES | 268 +-----------+-------------------------------+ 269 | Domain A | x1 + x2 <= 100 ....... (le11) | 270 +-----------+-------------------------------+ 271 | Domain B | x1 <= 30 ....... (le21) | 272 +-----------+-------------------------------+ 273 | Domain C | x2 <= 30 ........ (le31) | 274 +-----------+-------------------------------+ 276 Figure 3: Bandwidth properties for the reservation request from 277 Figure 1. 279 Each linear inequality represents a constraint on the reservable 280 bandwidths over different shared resources by the two flows. For 281 example, the inequality le11 indicates that both flows share a common 282 resource and that the sum of their bandwidths can not exceed 100 283 Gbps. 285 In a multi-domain setting, a network property to a flow fi may 286 involve properties of multiple networks, e.g.,: 288 o fi.md-abw: min(fi.abw[A] + fi.abw[B] + fi.abw[C]) 290 o fi.md-path: fi.path[A] . fi.path[B] . fi.path[C] 292 o fi.md-delay: fi.delay[A] + fi.delay[B] + fi.delay[C] 294 The involved domains may exchange such multi-domain properties. They 295 also may apply composition mechanisms to create a unified 296 representation to reveal a compact multi-domain network resource 297 information. For example, taking a look at the set of previous 298 linear inequalities (See Figure 3), one can conclude that the 299 constraint le21 at domain B (x1 <= 30) and the constraint le31 at 300 domain C (x2 <= 30) can eliminate that at domain A (X1 + x2 <= 100). 301 ALTO servers may compose this information and remove the cross-domain 302 redundancy (e.g., using a classic compression algorithm [TELGEN83]). 303 Therefore, the compressed multi-domain set of linear inequalities is 304 reduced to two linear inequalities (i.e., le21 and le31). 306 4. What are the ALTO issues of gathering multi-domain information? 308 ALTO provides a generic framework to expose network information for 309 applications to improve their performance. In particular, ALTO 310 introduces generic mechanisms such as: (i) information resource 311 directory (IRD), (ii) information consistency (tag, dependency, 312 multi-info resources [ALTO-MULTIPART]), and (iii) information update 313 model (e.g., incremental update with server-sent events [ALTO-SSE]). 314 ALTO also introduces abstractions exposing network information to the 315 applications: (i) network and cost maps, (ii) a multi-cost 316 map [RFC8189], (iii) the path vector abstraction [ALTO-PATH], and 317 (iv) capability maps (e.g., CDNI [ALTO-CDNI] and unified property 318 Map [ALTO-PROP]). Another generic concept introduced is "filter", so 319 that information resources can be filtered (e.g., filtered network/ 320 cost map). Besides, each individual information resource is provided 321 as a RESTful service with a very simple, but well-working grammar 322 (essentially JSON grammar [RFC7159]). 324 However, the multi-domain settings of exposing network information 325 arise key issues to be considered in the current ALTO design. Next, 326 we list several design issues of using ALTO to provide multi-domain 327 information. Such issues can be roughly categorized in three 328 aspects: (i) communication mechanisms, (ii) conceptual query 329 interfaces and data representation, and (iii) computation model. 331 4.1. Communication Mechanisms 333 4.1.1. Server-to-Client ALTO communication 335 In multi-domain scenarios is not possible to optimize the traffic 336 with only locally available network information (i.e., server-to- 337 client ALTO communication). For example, compute costs for source/ 338 destination pairs correctly if a source and/or a destination is 339 outside the domain it belongs to. Therefore, it also necessary 340 multi-ALTO server communication to allow exchanging detailed network 341 information from multiple domains. The ALTO protocol specification 342 states (See Section 3.1 of [RFC7285]) that "It may also be possible 343 for an ALTO server to exchange network information with other ALTO 344 servers (either within the same administrative domain or another 345 administrative domain with the consent of both parties) in order to 346 adjust exported ALTO". However, such a protocol is outside the scope 347 of the specification. 349 4.1.2. Domain connectivity discovery 351 The connectivity information is the reachability between source nodes 352 and the destination nodes. In order to find the resources sharing 353 between different source/destination pair, an application needs to 354 know which domains are involved in the data movement of each node 355 pair. Besides, a set of candidate paths needs to be computed in 356 order to know how to reach a remote destination node. The current 357 ALTO extensions do not have this feature. 359 4.1.3. ALTO server discovery 361 Once the multi-domain connectivity discovery is performed, an 362 application (as an ALTO client) needs to be aware of the presence and 363 the location of ALTO servers in order to get appropriate guidance. 364 These ALTO servers will be located in different network domains, so 365 that multi-domain ALTO server discovery mechanisms are needed. 367 4.2. Conceptual Query Interfaces and Data Representation 369 4.2.1. Single-domain composition 371 In the current ALTO framework, each domain can have its own 372 representation of the same network information. For example, suppose 373 that the path cost for member domain B (See Figure 1) is utilization 374 charge instead of available bandwidth. In this case, both values are 375 not comparable together. Even, if all the member domains have the 376 same utilization charge property, there would not necessarily a 377 uniform form of billing because each member domain is autonomous. 378 Member domain A may charge using dollar, member domain B may charge 379 using euros, while member domain C may use some form of local units. 381 4.2.2. Simple resource query language 383 Applications need to express their objectives and requirements in a 384 query. For example, find the bandwidth the network can provide for 385 flow f1 (S1, D1) subject to reachability requirements (e.g., from S1 386 to D1), bi-direction symmetry (e.g., data traffic from S1 to D1 and 387 from D1 to S1), waypoint traversal (e.g., f2 must traverse one 388 middlebox m1), blacklist of devices (e.g., f1 should not pass a 389 certain device m2), link/node disjointness (e.g., f1 and f2 flows 390 being transmitted along two link-disjoint paths), and QoS metrics 391 (e.g., the bandwidth of the flow f1 needs to be at least 30 Gbps). 392 The current query interface in ALTO (e.g., filtered network/cost map) 393 can not express such flexible queries. 395 4.3. Computation Model 397 4.3.1. Scalability 399 The optimization problems specified by the applications can be 400 computationally expensive and time-consuming. For example, the 401 number of available paths for each flow is increased exponentially 402 with the number of domains involved. As such, the number of 403 available configurations for a set of flows would also increase 404 exponentially with both the network size and the number of flows. 406 4.3.2. Security and Privacy 408 The information provided by the ALTO base protocol is considered 409 coarse-grained in several recent multi-domain use cases. New ALTO 410 extensions have been designed to provide fine-grained network 411 information to the application. Using these ALTO extension services 412 for multi-domain scenarios would raise new security and privacy 413 concerns. 415 5. How to design a whole ALTO framework? 417 In order to address the aforementioned issues, this section 418 summarizes envisioned solutions and on-going efforts to allow ALTO to 419 expose network information across multiple domains. See Table 1 to 420 identify the relationship between the key design issues and their 421 corresponding mechanisms to consider in a multi-domain ALTO 422 framework. 424 +---------------------------------+---------------------------------+ 425 | FROM | TO | 426 +---------------------------------+---------------------------------+ 427 | Server-to-Client ALTO | ALTO servers communication | 428 | communication | | 429 | ------------------------------- | ------------------------------- | 430 | Domain connectivity discovery | Multi-domain connectivity | 431 | | discovery | 432 | ------------------------------- | ------------------------------- | 433 | ALTO server discovery | Multi-domain ALTO server | 434 | | discovery | 435 | ------------------------------- | ------------------------------- | 436 | Single-domain composition | Unified Resource Representation | 437 | ------------------------------- | ------------------------------- | 438 | Simple resource query language | Generic/Flexible query language | 439 | ------------------------------- | ------------------------------- | 440 | Scalability | Computation complexity | 441 | | optimization | 442 | ------------------------------- | ------------------------------- | 443 | Security & Privacy | Security/Privacy preserving | 444 +---------------------------------+---------------------------------+ 446 Table 1: Issues of applying the current ALTO framework in the multi- 447 domain setting & solutions. 449 5.1. ALTO servers communication 451 ALTO servers may consider either a hierarchical or mesh architectural 452 deployment design [INTER-ALTO][MD-ANALY][MD-BROKER][MD-SFC]. When a 453 hierarchical architecture is used, ALTO servers in domain partitions 454 gather locally-available network information and send it to central 455 server, which in turn merges data and distributes ALTO services. In 456 a mesh deployment, ALTO servers may be set up in each domain 457 independently, connected to each other, and gathering the network 458 information from other domains. 460 5.2. Multi-domain Connectivity discovery 462 Multi-domain mechanisms combining domains sequence computation and 463 paths computation need to be defined, or standardized computation 464 protocols could be re-used. In the latter case, the IETF has a set 465 of well defined protocols, such as BGP [RFC4271], PCE ([RFC5441] 466 , [RFC6805]), or BGP-LS [RFC7752]. The BGP protocol, for instance, 467 provides multi-domain sequence computation to know how to reach a 468 destination just identifying the next hop for IP traffic delivery; 469 however, it does not advertise multiple alternative routes. BGP-LS 470 allows visibility of the network topology (real physical or 471 abstracted) and export traffic engineering information with external 472 domains using the BGP routing protocol. Following the PCE-based 473 architecture [RFC4655] for computing optimal multi-domain end-to-end 474 paths, [RFC5441], [RFC6805] define mechanisms where a PCE entity 475 cooperates either with other PCE entities in adjacent domains or with 476 a parent PCE entity, respectively. A mix between BGP-LP and PCE may 477 also be considered, with the first one providing topology/link-state 478 network information, and with the second one making the necessary 479 path computations between domains. 481 5.3. Multi-domain ALTO Server discovery 483 The ALTO cross-domain server discovery document [RFC8686] specifies a 484 procedure for identifying ALTO servers outside of the ALTO client's 485 own network domain. Other mechanisms could also be leveraged, such 486 as those based on PCE or BGP architectures. For example, [RFC4674] 487 proposes a set of functional requirements to allow a path computation 488 client (PCC) to automatically and dynamically discover the location 489 of PCEs entities (including additional information about supported 490 capabilities) for each controller domain. Inline with those 491 requirements, [PROTO-BGP] is defining extensions to BGP to also carry 492 PCE discovery information. Specifically, this document extends BGP 493 to allow a PCE entities to advertise their location and some useful 494 information to a PCC for the PCE selection. 496 5.4. Unified resource representation 498 Therefore, multi-domain composition mechanisms are necessaries so 499 that network information from ALTO servers in multiple domains can 500 fit into a single and consistent "virtual" domain abstraction. ALTO 501 information services such as network maps, cost maps, unified entity 502 properties, network capabilities, and routing path abstractions (path 503 vectors) of individual domains need to follow a common semantic as 504 well as be consistently integrated to provide the abstraction of a 505 single, coherent network to the applications. ... design options of 506 multi-domain composition 507 mechanisms [UNI-REPRES][UNICORN][MERCATOR][MERCATOR-2]. 509 5.5. Flexible/Generic query language 511 With a flexible/generic query language, the network can filter out a 512 large number of unqualified domains. The language specification 513 could be inspired by standard [GSM][NFV-NSD] or pre- 514 standard [SOCKET-INTENTS][IBN] mechanisms, implemented with a user- 515 friendly grammar (e.g., SQL-style query). 517 5.6. Computation complexity optimization 519 Therefore, ALTO servers need to support mechanisms to improve the 520 scalability and performance (e.g., pre-computation and projection). 521 For example, the ALTO Routing State Abstraction extension 522 document [DRAFT-RSA] describes equivalent transformation algorithms 523 that can effectively reduce the redundancy in the network view as 524 much as possible while still providing the same information. Such 525 algorithms may be integrated with any ALTO service (e.g., path vector 526 extension) as a post-processing step. 528 5.7. Security/Privacy Preserving 530 ALTO needs mechanisms (with little overhead) that provide accurate 531 sharing network information, and at the same time, protects each 532 member domain. This privacy-preserving interdomain information 533 process may consider, for instance, a secure multi-party computation 534 (SMPC) protocol [MD-ANALY][MERCATOR]. 536 6. IANA Considerations 538 This document includes no request to IANA. 540 7. Security Considerations 542 TBD. 544 8. References 546 8.1. Normative References 548 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 549 of Explicit Congestion Notification (ECN) to IP", 550 RFC 3168, DOI 10.17487/RFC3168, September 2001, 551 . 553 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 554 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 555 DOI 10.17487/RFC4271, January 2006, 556 . 558 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 559 Element (PCE)-Based Architecture", RFC 4655, 560 DOI 10.17487/RFC4655, August 2006, 561 . 563 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 564 Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, 565 October 2006, . 567 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 568 "A Backward-Recursive PCE-Based Computation (BRPC) 569 Procedure to Compute Shortest Constrained Inter-Domain 570 Traffic Engineering Label Switched Paths", RFC 5441, 571 DOI 10.17487/RFC5441, April 2009, 572 . 574 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 575 and D. McPherson, "Dissemination of Flow Specification 576 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 577 . 579 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 580 Path Computation Element Architecture to the Determination 581 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 582 DOI 10.17487/RFC6805, November 2012, 583 . 585 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 586 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 587 2014, . 589 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 590 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 591 "Application-Layer Traffic Optimization (ALTO) Protocol", 592 RFC 7285, DOI 10.17487/RFC7285, September 2014, 593 . 595 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 596 S. Ray, "North-Bound Distribution of Link-State and 597 Traffic Engineering (TE) Information Using BGP", RFC 7752, 598 DOI 10.17487/RFC7752, March 2016, 599 . 601 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 602 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 603 Deployment Considerations", RFC 7971, 604 DOI 10.17487/RFC7971, October 2016, 605 . 607 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 608 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 609 DOI 10.17487/RFC8189, October 2017, 610 . 612 [RFC8686] Kiesel, S. and M. Stiemerling, "Application-Layer Traffic 613 Optimization (ALTO) Cross-Domain Server Discovery", 614 RFC 8686, DOI 10.17487/RFC8686, February 2020, 615 . 617 8.2. Informative References 619 [ALTO-CDNI] 620 Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang, 621 "Content Delivery Network Interconnection (CDNI) Request 622 Routing: CDNI Footprint and Capabilities Advertisement 623 using ALTO", draft-ietf-alto-cdni-request-routing-alto-11 624 (work in progress), April 2020. 626 [ALTO-MULTIPART] 627 Zhang, J. and Y. Yang, "Multiple ALTO Resources Query 628 Using Multipart Message", draft-zhang-alto-multipart-03 629 (work in progress), March 2020. 631 [ALTO-PATH] 632 Gao, K., Randriamasy, S., Yang, Y., and J. Zhang, "ALTO 633 Extension: Path Vector", draft-ietf-alto-path-vector-10 634 (work in progress), March 2020. 636 [ALTO-PROP] 637 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 638 Gao, "Unified Properties for the ALTO Protocol", draft- 639 ietf-alto-unified-props-new-10 (work in progress), 640 November 2019. 642 [ALTO-SSE] 643 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 644 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 645 sse-17 (work in progress), July 2019. 647 [CMS] The CMS Collaboration, "The CMS experiment at the CERN 648 LHC", 2008, 649 . 651 [DRAFT-RSA] 652 Gao, K., xinwang2014@hotmail.com, x., Xiang, Q., Gu, C., 653 Yang, Y., and G. Chen, "Compressing ALTO Path Vectors", 654 draft-gao-alto-routing-state-abstraction-08 (work in 655 progress), March 2018. 657 [ETSI-ZSM] 658 ETSI, "Zero Touch Network and Service Management", 2020, 659 . 662 [GSM] GSM Association, "Generic Network Slice Template", 2019, 663 . 666 [IBN] Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, 667 "Intent-Based Networking - Concepts and Definitions", 668 draft-irtf-nmrg-ibn-concepts-definitions-01 (work in 669 progress), March 2020. 671 [INT] Kim, C., Sivaraman, A., Katta, N., Bas, A., Dixit, A., and 672 L. Wobker, "In-band network telemetry via programmable 673 dataplanes", Book Title ACM SIGCOMM, 2015. 675 [INTER-ALTO] 676 Dulinski, Z., Wydrych, P., and R. Stankiewicz, "Inter-ALTO 677 Communication Problem Statement", draft-dulinski-alto- 678 inter-problem-statement-02 (work in progress), July 2015. 680 [LCLS] SLAC National Accelerator Laboratory, "The Linac Coherent 681 Light Source", 2020, . 683 [LHC] CERN: European Council for Nuclear Research, "The Large 684 Hadron Collider (LHC) Experiment", 2020, 685 . 687 [MD-ANALY] 688 Xiang, Q., Zhang, J., Le, F., Yang, Y., and H. Newman, 689 "Resource Orchestration for Multi-Domain, Exascale, Geo- 690 Distributed Data Analytics", draft-xiang-alto-multidomain- 691 analytics-03 (work in progress), March 2020. 693 [MD-BROKER] 694 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 695 Multi-domain Orchestration", draft-lachosrothenberg-alto- 696 brokermdo-03 (work in progress), March 2020. 698 [MD-ORCH-NFV] 699 Katsalis, K., Nikaein, N., and A. Edmonds, "Multi-domain 700 orchestration for NFV: Challenges and research 701 directions", focus 189--195, 2016. 703 [MD-SFC] Perez, D., Xiang, Q., Rothenberg, C., and Y. Yang, "Multi- 704 domain Service Function Chaining with ALTO", draft-lachos- 705 sfc-multi-domain-alto-00 (work in progress), March 2020. 707 [MERCATOR] 708 Xiang, Q., Zhang, J., Wang, T., Liu, J., Guok, C., Le, F., 709 MacAuley, J., Newman, H., and R. Yang, "Fine-Grained, 710 Multi-Domain Network Resource Abstraction as a Fundamental 711 Primitive to Enable High-Performance, Collaborative Data 712 Sciences", Publisher IEEE, BookTitle SC18: International 713 Conference for High Performance Computing, Networking, 714 Storage and Analysis, Pages 58-70, 2018. 716 [MERCATOR-2] 717 Xiang, Q., Zhang, J., Wang, T., Liu, J., Guok, C., Le, F., 718 MacAuley, J., Newman, H., and R. Yang, "Toward Fine- 719 Grained, Privacy-Preserving, Efficient Multi-Domain 720 Network Resource Discovery", Publisher IEEE, Journal IEEE 721 Journal on Selected Areas in Communications, Volume 37, 722 Number 8, Pages 1924-1940, 2019. 724 [NFV-NSD] ETSI ISG, "Network functions virtualisation (NFV); 725 management and orchestration; network service templates 726 specification", 2019, 727 . 731 [NGMN-5G] Alliance, NGMN, "5G White Paper", 2015, 732 . 734 [PROTO-BGP] 735 Dong, J., Chen, M., Dhody, D., Tantsura, J., Kumaki, K., 736 and T. Murai, "BGP Extensions for Path Computation Element 737 (PCE) Discovery", draft-dong-pce-discovery-proto-bgp-07 738 (work in progress), July 2017. 740 [SDX] Gupta, A., Vanbever, L., Shahbaz, M., Donovan, S., 741 Schlinker, B., Feamster, N., Rexford, J., Shenker, S., 742 Clark, R., and E. Katz-Bassett, "Sdx: A software defined 743 internet exchange", focus 551--562, 2015. 745 [SFC-MD] Sun, G., Li, Y., Liao, D., and V. Chang, "Service function 746 chain orchestration across multiple domains: A full mesh 747 aggregation approach", Journal IEEE Transactions on 748 Network and Service Management, Volumen 15, Number 3, 749 Pages 1175--1191, Publisher IEEE, 2018. 751 [SFP] Xiang, Q., Guok, C., Le, F., MacAuley, J., Newman, H., and 752 R. Yang, "SFP: Toward Interdomain Routing for SDN 753 Networks", focus 87--89, 2018. 755 [SKA] SKA Organisation, "The Square Kilometre Array", 2020, 756 . 758 [SOCKET-INTENTS] 759 Schmidt, P., Enghardt, T., Khalili, R., and A. Feldmann, 760 "Socket Intents: Leveraging Application Awareness for 761 Multi-Access Connectivity", Publisher ACM, Series CoNEXT 762 '13, Pages 295-300, 2013. 764 [TELGEN83] 765 Telgen, J., "Identifying redundant constraints and 766 implicit equalities in systems of linear constraints", 767 Journal Management Science, Volume 29, Number 10, Pages 768 1209--1222, Publisher INFORMS, 1983. 770 [UNI-REPRES] 771 Xiang, Q., Zhang, J., Le, F., and Y. Yang, "ALTO 772 Extension: Unified Resource Representation", draft-xiang- 773 alto-unified-representation-02 (work in progress), March 774 2020. 776 [UNICORN] Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang, R., and 777 J. Liu, "Unicorn: Unified resource orchestration for 778 multi-domain, geo-distributed data analytics", 779 Journal Future Generation Computer Systems, Volumen 93, 780 Pages 188-197, 2019. 782 Authors' Addresses 784 Danny Alex Lachos Perez 785 University of Campinas 786 Av. Albert Einstein 400 787 Campinas, Sao Paulo 13083-970 788 Brazil 790 Email: dlachosp@dca.fee.unicamp.br 791 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 792 Christian Esteve Rothenberg 793 University of Campinas 794 Av. Albert Einstein 400 795 Campinas, Sao Paulo 13083-970 796 Brazil 798 Email: chesteve@dca.fee.unicamp.br 799 URI: https://intrig.dca.fee.unicamp.br/christian/ 801 Qiao Xiang 802 Yale University 803 51 Prospect Street 804 New Haven, CT 805 USA 807 Email: qiao.xiang@cs.yale.edu 809 Y. Richard Yang 810 Yale University 811 51 Prospect St 812 New Haven, CT 813 USA 815 Email: yang.r.yang@gmail.com 817 Borje Ohlman 818 Ericsson Research 819 S-16480 Stockholm 820 Sweden 822 Email: Borje.Ohlman@ericsson.com 824 Sabine Randriamasy 825 Nokia Bell Labs 826 Route de Villejust 827 NOZAY 91460 828 FRANCE 830 Email: Sabine.Randriamasy@nokia-bell-labs.com 831 Farni Boten 832 Sprint 833 USA 835 Email: farni.weaver@sprint.com 837 Luis M. Contreras 838 Telefonica 839 Ronda de la Comunicacion, s/n 840 Madrid 28050 841 Spain 843 Email: luismiguel.contrerasmurillo@telefonica.com 844 URI: http://lmcontreras.com/ 846 Jingxuan Jensen Zhang 847 Tongji University 848 4800 Caoan Road 849 Shanghai 201804 850 China 852 Email: jingxuan.n.zhang@gmail.com 854 Kai Gao 855 Sichuan University 856 Chengdu 610000 857 China 859 Email: kaigao@scu.edu.cn