idnits 2.17.1 draft-yang-alto-path-vector-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3217 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: 'I-D.amante-i2rs-topology-use-cases' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-i2rs-yang-network-topo' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'I-D.lee-alto-app-net-info-exchange' is defined on line 310, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-clemm-i2rs-yang-network-topo-01 == Outdated reference: A later version (-04) exists of draft-lee-alto-app-net-info-exchange-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG G. Bernstein 3 Internet-Draft Grotto Networking 4 Intended status: Standards Track Y. Lee 5 Expires: January 7, 2016 Huawei 6 W. Roome 7 M. Scharf 8 Alcatel-Lucent 9 Y. Yang 10 Yale University 11 July 6, 2015 13 ALTO Extension: Abstract Path Vector as a Cost Mode 14 draft-yang-alto-path-vector-01.txt 16 Abstract 18 The Application-Layer Traffic Optimization (ALTO) Service has defined 19 network and cost maps to provide basic network information, where the 20 cost maps allow only scalar (numerical or ordinal) cost mode values. 21 This document introduces a new cost mode called path-vector to allow 22 ALTO clients to better distinguish cost information. This document 23 starts with a non-normative use case called multi-flow scheduling to 24 illustrate that ALTO cost maps without path vectors cannot provide 25 sufficient information. This document then defines path-vector as a 26 new cost mode. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 7, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. The Multi-flow Scheduling Use Case . . . . . . . . . . . . . 3 69 3. Path-Vector as a new Cost Mode . . . . . . . . . . . . . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 7.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Appendix A. Network Element Properties Map . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 The ALTO base protocol [RFC7285] is designed for a setting of 82 exposing network topology using the extreme "my-Internet-view" 83 representation, which abstracts a whole network as a single node that 84 has a set of access ports, with each port connects to a set of 85 endhosts. The base protocol refers to each access port as a PID. 86 This "single-node" abstraction is simple and can support a wide range 87 of applications already. 89 A problem of this abstraction, however, is that it does not provide 90 sufficient information for use cases (e.g., multi-flow scheduling; 91 see Section 3) that require exposure of topology information beyond 92 the single-node abstraction, to detect sharing of the resources in 93 the underlying topology. 95 This document goes beyond the single-node topology by introducing 96 path vector as a new ALTO cost mode, where each path vector specifies 97 abstracted network elements on the routing path from a set of source 98 endhosts to a set of destination endhosts. Since the network 99 elements on a path vector are abstract network elements defined by 100 ALTO servers, the new path-vector cost mode provides a mechanism to 101 allow a network to control the level of topology exposure, and at the 102 same time better support application traffic optimization. The 103 design of path vector is based on the ALTO WG discussions at IETF 89, 104 with summary slides at http://tools.ietf.org/agenda/89/slides/slides- 105 89-alto-2.pdf. 107 The organization of this document is organized as follows. Section 2 108 gives a non-normative use case called multi-flow scheduling to 109 illustrate the need to introduce path vectors. Section 3 formally 110 specifies the path vector cost mode. Section 4 gives the Sections 4 111 and 5 discuss security and IANA considerations. 113 2. The Multi-flow Scheduling Use Case 115 ALTO uses a simple single-node network abstraction. Specifically, 116 each network map in ALTO defines an abstract, single node network. 117 Endhosts are partitioned to a set of access ports, with each access 118 port called a PID. For a given network map, a cost map of a given 119 cost metric provides a scalar (numerical or ranking) cost value for 120 each pair of source and destination PIDs. 122 Although simple, the single-node, simple scalar cost maps may not 123 convey enough information to the applications about pair-wise 124 connection properties between one PID and another PID. See [I- 125 D.bernstein-alto-topo] for a survey of use-cases where extended 126 network topology information is needed. 128 This document uses a simple use case to illustrate the issue. 129 Consider a network as shown in Figure 1. The network has 7 switches 130 (sw1 to sw7) forming a dumb-bell topology. Switches sw1/sw3 provide 131 access on one side, s2/s4 provide access on the other side, and 132 sw5-sw7 form the backbone. Endhosts eh1 to eh4 are connected to 133 access switches sw1 to sw4 respectively. Assume that the bandwidth 134 of each link is 100 Mbps. Assume that the network is abstracted with 135 4 PIDs, with each representing the hosts at one access switch. 137 +------+ 138 | | 139 --+ sw6 +-- 140 / | | \ 141 PID1 +-----+ / +------+ \ +-----+ PID2 142 eh1__| |_ / \ ____| |__eh2 143 | sw1 | \ +--+---+ +---+--+ / | sw2 | 144 +-----+ \ | | | |/ +-----+ 145 \_| sw5 +---------+ sw7 | 146 PID3 +-----+ / | | | |\ +-----+ PID4 147 eh3__| |__/ +------+ +------+ \____| |__eh4 148 | sw3 | | sw4 | 149 +-----+ +-----+ 151 Figure 1: Raw Network Topology. 153 The single-node ALTO topology abstraction of the network is shown in 154 Figure 2. 156 +----------------------+ 157 {eh1} | | {eh2} 158 PID1 | | PID2 159 +------+ +------+ 160 | | 161 | | 162 {eh3} | | {eh4} 163 PID3 | | PID4 164 +------+ +------+ 165 | | 166 +----------------------+ 168 Figure 2: Base Single-Node Topology Abstraction. 170 Consider an application overlay (e.g., a large data analysis system) 171 which needs to schedule the traffic among a set of endhost source- 172 destination pairs, say eh1 -> eh2, and eh3 -> eh4. The application 173 can request a cost map providing end-to-end available bandwidth, 174 using 'available bw' as cost-metric and 'numerical' as cost-mode, 175 where the 'available bw' between two PIDs represents available 176 bandwidth for PIDi -> PIDj, if no other applications use shared 177 resources. 179 Assume that the application receives from the cost map that both PID1 180 -> PID2 and PID3 -> PID4 have bandwidth 100 Mbps. It cannot 181 determine that if it schedules the two flows together, whether it 182 will obtain a total of 100 Mbps or 200 Mbps. This depends on whether 183 the routing of the two flows shares a bottleneck in the underlying 184 topology: 186 o Case 1: If PID1 -> PID2 and PID3 -> PID4 use different paths, for 187 example, when the first uses sw1 -> sw5 -> sw7 -> sw2, and the 188 second uses sw3 -> sw5 -> sw6 -> sw7 -> sw4. Then the application 189 will obtain 200 Mbps. 191 o Case 2: If PID1 -> PID2 and PID3 -> PID4 share the bottleneck, for 192 example, when both use the direct link sw5 -> sw7, then the 193 application will obtain only 100 Mbps. 195 To allow applications to distinguish the two aforementioned cases, 196 the network needs to provide more details. This document introduces 197 path vector to resolve the issue. 199 3. Path-Vector as a new Cost Mode 201 An extension supporting the path-vector cost-mode MUST support the 202 following extension of Section 11.2.3.6 of [RFC7285]: 204 object { 205 cost-map.DstCosts.JSONValue -> JSONString<0,*>; 206 meta.cost-mode = "path-vector"; 207 } InfoResourcePVCostMap : InfoResourceCostMap; 209 Specifically, the preceding specifies that InfoResourcePVCostMap 210 extends InfoResourceCostMap. The body specifies that the first 211 extension is achieved by changing the type of JSONValue defined in 212 DstCosts of cost-map to be an array of JSONString; the second 213 extension is that the cost-mode of meta MUST be "path-vector". 215 An example cost map using path-vector is the following: 217 GET /costmap/pv HTTP/1.1 218 Host: alto.example.com 219 Accept: application/alto-costmap+json,application/alto-error+json 220 HTTP/1.1 200 OK 221 Content-Length: TDB 222 Content-Type: application/alto-costmap+json 224 { 225 "meta" : { 226 "dependent-vtags" : [ 227 { "resource-id": "my-default-network-map", 228 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 229 }, 230 {"resource-id": "my-topology-map", // See below 231 "tag": "4xee2cb7e8d63d9fab71b9b34cbf76443631554de" 232 } 233 ], 234 "cost-type" : { // removed: "cost-metric": "routingcost", 235 "cost-mode" : "path-vector" 236 } 237 }, 239 "cost-map" : { 240 "PID1": { "PID1":[], 241 "PID2":["ne56", "ne67"], 242 "PID3":[], 243 "PID4":["ne57"] 244 }, 245 "PID2": { "PID1":["ne75"], 246 "PID2":[], 247 "PID3":["ne75"], 248 "PID4":[] 249 }, 250 "PID3": { "PID1":[], 251 "PID2":["ne57"], 252 "PID3":[], 253 "PID4":["ne57"] 254 }, 255 "PID4": { "PID1":["ne75"], 256 "PID2":[], 257 "PID3":["ne75"], 258 "PID4":[]} 259 } 260 } 262 To interpret the path vectors in a cost map that provides path 263 vectors, an ALTO client will need access to the properties of the 264 abstract network elements named in the path vectors. Such properties 265 should be provided from a network element property service (e.g., the 266 unified properties draft). Hence, the "dependent-tags" of a cost map 267 supporting path vectors MUST include two dependent resources: one for 268 a network map, which defines the grouping of endhosts, and the other 269 for an element property service. The network element property 270 service (map) MUST provide a key-value service, where the key is a 271 JSON string, and the value is the a map by itself, which has the 272 property/metric name as key. This document does not define the 273 property service. The appendix gives one definition, but it can be a 274 different one. 276 4. Security Considerations 278 This document has not conducted its security analysis. 280 5. IANA Considerations 282 This document requires the definition of a new cost-mode named path- 283 vector. 285 6. Acknowledgments 287 The author thanks discussions with Xiao Shi, Xin Wang, Erran Li, 288 Tianyuan Liu, Andreas Voellmy, Haibin Song, and Yan Luo. 290 7. References 292 7.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 7.2. Informative References 299 [I-D.amante-i2rs-topology-use-cases] 300 Medved, J., Previdi, S., Lopez, V., and S. Amante, 301 "Topology API Use Cases", draft-amante-i2rs-topology-use- 302 cases-01 (work in progress), October 2013. 304 [I-D.clemm-i2rs-yang-network-topo] 305 Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N., 306 and H. Ananthakrishnan, "A YANG Data Model for Network 307 Topologies", draft-clemm-i2rs-yang-network-topo-01 (work 308 in progress), October 2014. 310 [I-D.lee-alto-app-net-info-exchange] 311 Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO 312 Extensions to Support Application and Network Resource 313 Information Exchange for High Bandwidth Applications", 314 draft-lee-alto-app-net-info-exchange-02 (work in 315 progress), July 2013. 317 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 318 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 319 Traffic Optimization (ALTO) Protocol", RFC 7285, September 320 2014. 322 Appendix A. Network Element Properties Map 324 A missing piece to complete the path-vector design to resolve the 325 ambiguity in the use case is how to provide information on the 326 elements of the path vectors. A minimal approach is to introduce 327 network element properties (NEP) maps, where each NEP map provides a 328 mapping from a network element to its properties such as bandwidth or 329 shared risk link group (srlg). 331 A schema of an NEP map is: 333 object-map { 334 JSONString -> NetworkElementProperties; // name to properties 335 } NetworkElementMapData; 337 object-map { 338 JSONString bw; 339 JSONString srlg<0,*>; 340 [JSONString type;] // should be from an enumeration only 341 } NetworkElementProperties; 343 An example network element property map: 345 GET /nepmap HTTP/1.1 346 Host: alto.example.com 347 Accept: application/alto-nepmap+json,application/alto-error+json 348 HTTP/1.1 200 OK 349 Content-Length: TBD 350 Content-Type: application/alto-nepmap+json 352 { 353 "meta" : { 354 "vtag": { 355 "resource-id": "my-topology-map", 356 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 357 } 358 }, 359 "nep-map" : { 360 "ne57" : {"bw" : 100, "srlg" : [1, 3]}, // link sw5->sw7 361 "ne75" : {"bw" : 100, "srlg" : [1, 3]}, // link sw7->sw5 362 "ne56" : {"bw" : 100, "srlg" : [1]}, // link sw5->sw6 363 "ne65" : {"bw" : 100, "srlg" : [1]}, // link sw6->sw5 364 "ne67" : {"bw" : 100, "srlg" : [3]}, // link sw6->sw7 365 "ne76" : {"bw" : 100, "srlg" : [3]}, // link sw7->sw6 366 } 367 } 369 Authors' Addresses 371 Greg Bernstein 372 Grotto Networking 373 Fremont, CA 374 USA 376 Email: gregb@grotto-networking.com 378 Young Lee 379 Huawei 380 TX 381 USA 383 Email: leeyoung@huawei.com 385 Wendy Roome 386 Alcatel-Lucent Technologies/Bell Labs 387 600 Mountain Ave, Rm 3B-324 388 Murray Hill, NJ 07974 389 USA 391 Phone: +1-908-582-7974 392 Email: w.roome@alcatel-lucent.com 393 Michael Scharf 394 Alcatel-Lucent Technologies 395 Germany 397 Email: michael.scharf@alcatel-lucent.com 399 Y. Richard Yang 400 Yale University 401 51 Prospect St 402 New Haven CT 403 USA 405 Email: yry@cs.yale.edu