idnits 2.17.1 draft-xiang-alto-multidomain-extension-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (1 November 2020) is 1265 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8189' is defined on line 242, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG Q. Xiang 3 Internet-Draft Y. Yang 4 Intended status: Standards Track Yale University 5 Expires: 5 May 2021 1 November 2020 7 ALTO Multi-Domain Extension: Challenges, Existing Efforts and Next Steps 8 draft-xiang-alto-multidomain-extension-00.txt 10 Abstract 12 The emerging multi-domain applications, such as flexible interdomain 13 routing, distributed, federated machine learning and multi-domain 14 collaborative dataset transfer, can benefit substantially from 15 getting information from networks. The ALTO base protocol [RFC7285] 16 provides a northbound interface for applications to retrieve the 17 network information. In particular, it specifies the communication 18 between an ALTO client and an ALTO server, where the ALTO is 19 implicitly assumed to be able to answer any query from the ALTO 20 client. However, it does not specify the cases when the network 21 information are originated from multiple domains (i.e., 22 administrative entities or geographically partitions). This document 23 summarizes the discussion on the ALTO weekly meeting since IETF 108 24 on how to extend ALTO to support multi-domain applications. It 25 identifies the key challenges for retrieving network information from 26 multiple networks, reviews the existing efforts in the work group, 27 and discusses the next steps to fully address the challenges. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 5 May 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 64 3. Extending ALTO to Multi-Domain: Challenges . . . . . . . . . 3 65 4. Existing Efforts in the ALTO Working Group . . . . . . . . . 4 66 5. ALTO Multi-Domain Extension: Basic Ideas . . . . . . . . . . 4 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 6.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The ALTO protocol [RFC7285] provides network information to 75 applications so that applications can make network informed decisions 76 to improve the performance. Not only traditional applications such 77 peer-to-peer systems, many recent, novel multi-domain applications, 78 which orchestrate resources across multiple networks, can also 79 benefit substantially from ALTO. 81 Since the recharter discussion on IETF 108, there has been much 82 interest and discussion on the ALTO weekly meetings to extend the 83 ALTO base protocol to support multi-domain applications. This 84 document is a summary of the discussion on these meetings. It 85 outlines the challenges, reviews the existing efforts in the working 86 group, and discuss the next steps to design ALTO multi-domain 87 extensions. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. Extending ALTO to Multi-Domain: Challenges 97 This section uses a motivating example to outline the key challenges 98 for designing ALTO extensions to support multi-domain applications. 100 Consider the example in Figure 1, where the application wants to 101 retrieve the network information from endpoint S to endpoint D. S 102 and D are each attached to a different network. 104 * Challenge 1: the route from S to D spans multiple networks, whose 105 information is partitioned and stored at multiple ALTO servers. 106 In other words, no single ALTO server has the complete information 107 of the flow from S to D. As such, either the ALTO client needs to 108 communicate with all ALTO servers along the route to collect and 109 aggregate all the information, or the ALTO server that receives 110 the ALTO client's query at the beginning needs to acts as a 111 delegate to collect and aggregate all the information before 112 returning it to the ALTO client. 114 * Challenge 2: the route from S to D may not even be fully 115 instantiated. For example, when a network uses SDN to manage its 116 routing and performs load balancing based on the the remainder of 117 flows' source MAC addresses divided by 3, it is impossible to 118 fully instantiate the forwarding table on the limited memory in a 119 commodity OpenFlow switch. As such, the ALTO client or the 120 delegated ALTO server needs to decide which other ALTO servers to 121 contact to collect the needed information. 123 * Challenge 3: Different ALTO servers may have information about 124 different metrics. In particular, along the route from S to D, 125 two ALTO servers may provide information two segments of the route 126 with different metrics, e.g., one provides the bandwidth 127 information while the other provides the latency information. 128 Even if two ALTO servers provide information of the same metric, 129 say latency, they may provide different statistics, e.g., one 130 provide the mean latency while the other provide the median 131 latency. As such, the ALTO client or the delegated ALTO server 132 needs to figure out how to aggregate such information and return 133 to the application. 135 * Challenge 4: When the application wants to retrieve network 136 information of multiple pairs of source-destination endpoints, the 137 routes of different flows may share same link(s), leading to 138 resource sharing. As such, collecting network information of 139 different flows individually may yield inaccurate results. 141 4. Existing Efforts in the ALTO Working Group 143 Several documents in the ALTO group have made design proposals for 144 extending ALTO to multi-domain settings. This section provides a 145 review. 147 * [DRAFT-UNICORN-INFO] and [DRAFT-NFCHAIN] propose broker-based 148 architectures for collection network information from multiple 149 networks. In particular, an ALTO client act as a broker or 150 aggregator on behalf of applications to directly communicate with 151 all ALTO servers in the networks to collect and aggregate 152 information. These efforts provide initial starting point for 153 addressing challenge 1, but does not specify how different ALTO 154 servers can communicate with each other. 156 * For challenge 2, [RFC8686] specifies a cross-domain ALTO server 157 discovery mechanism for the ALTO client or the delegate ALTO 158 server to discover which ALTO server possesses the information of 159 interest. It partially address challenge 2. However, it does not 160 specify how to handle the scenario where different ALTO servers 161 possess different parts of the information of interest (i.e., 162 partial information). 164 * [DRAFT-UNICORN-INFO] provides an information aggregation mechanism 165 to aggregate information from multiple networks. It is related to 166 challenge 3, however, it assumes that all networks provide 167 information using the same metric and the same statistics. 169 * [DRAFT-PV] designs the ALTO path vector extension to support ALTO 170 servers to capture the resource sharing among multiple flows and 171 return to the ALTO client. However, it does not specify the 172 scenario where network uses more complex routing strategies, such 173 as multipath routing and on-demand routing, for source-destination 174 endpoints. 176 5. ALTO Multi-Domain Extension: Basic Ideas 178 This section describes the basic ideas to design an ALTO multi-domain 179 extension to address the aforementioned challenges. In particular, 180 to address challenge 1 and 2 to identify the full route of a source- 181 destination endpoint pair and query the corresponding ALTO servers to 182 retrieve information, we will base on the pub-sub design of the SDN 183 federation routing protocol [SFP] and go beyond to specify the inter- 184 ALTO-server communication mechanism, which allows ALTO servers to 185 exchange and aggregate information from multiple networks. 187 To address challenge 3 to aggregate the information from different 188 networks, we will extend the ALTO framework to standardize single 189 aggregation in some settings, where information are in the same 190 metric and uses the same statistics. To aggregate the information 191 from different networks in different metrics and statics, we will 192 resort to the theoretical framework of routing algebra [ROUTING-MO], 193 which aggregates routing information of different metrics as a 194 partial order of vectors, and go beyond to specify the multi-domain 195 ALTO server information aggregation mechanism, which supports the 196 more flexible aggregation of ALTO information. 198 To address challenge 4 to retrieve the resource sharing information 199 of multiple source-destination endpoints pairs when networks use more 200 complex routing strategies such as multipath routing and on-demand 201 routing, we will base on the ALTO path vector extension [DRAFT-PV], 202 but go beyond to use generic mathematical programming constraints as 203 a compact representation of the resource sharing information across 204 multiple networks. 206 6. References 208 6.1. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, 212 DOI 10.17487/RFC2119, March 1997, 213 . 215 6.2. Informative References 217 [DRAFT-NFCHAIN] 218 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 219 Multi-domain Orchestration", 2018, 220 . 223 [DRAFT-PV] Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y. R. 224 Yang, "ALTO Extension: Abstract Path Vector as a Cost 225 Mode", 2015, . 228 [DRAFT-UNICORN-INFO] 229 Xiang, Q., Newman, H., Bernstein, G., Du, H., Gao, K., 230 Mughal, A., Balcas, J., Zhang, J., and Y. R. Yang, 231 "Implementation and Deployment of A Resource Orchestration 232 System for Multi-Domain Data Analytics", 2017, 233 . 236 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 237 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 238 "Application-Layer Traffic Optimization (ALTO) Protocol", 239 RFC 7285, DOI 10.17487/RFC7285, September 2014, 240 . 242 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 243 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 244 DOI 10.17487/RFC8189, October 2017, 245 . 247 [RFC8686] Kiesel, S. and M. Stiemerling, "Application-Layer Traffic 248 Optimization (ALTO) Cross-Domain Server Discovery", 249 RFC 8686, DOI 10.17487/RFC8686, February 2020, 250 . 252 [ROUTING-MO] 253 Sobrinho, J. and M. Ferreira, "Routing on Multiple 254 Optimality Criteria", 2020, 255 . 257 [SFP] Xiang, Q., Guok, C., Le, F., MacAuley, J., Newman, H., and 258 Y. R. Yang, "SFP: Toward Interdomain Routing for SDN 259 Networks", 2018, 260 . 262 Authors' Addresses 264 Qiao Xiang 265 Yale University 266 51 Prospect Street 267 New Haven, CT 268 United States of America 270 Email: qiao.xiang@cs.yale.edu 272 Y. Richard Yang 273 Yale University 274 51 Prospect Street 275 New Haven, CT 276 United States of America 278 Email: yry@cs.yale.edu