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