idnits 2.17.1 draft-randriamasy-alto-multi-cost-07.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. ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1009 has weird spacing: '...ostType cos...' == Line 1010 has weird spacing: '...ostMode cos...' == Line 1011 has weird spacing: '...NString map-v...' == Line 1120 has weird spacing: '...ostType cos...' == Line 1121 has weird spacing: '...ostMode cos...' == (10 more instances...) -- The document date (October 19, 2012) is 4200 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'O' is mentioned on line 551, but not defined -- Looks like a reference, but probably isn't: '2' on line 1457 -- Looks like a reference, but probably isn't: '5' on line 1299 -- Looks like a reference, but probably isn't: '4' on line 1456 -- Looks like a reference, but probably isn't: '1' on line 1455 -- Looks like a reference, but probably isn't: '21' on line 744 -- Looks like a reference, but probably isn't: '9' on line 744 -- Looks like a reference, but probably isn't: '12' on line 744 -- Looks like a reference, but probably isn't: '100' on line 796 -- Looks like a reference, but probably isn't: '200' on line 792 -- Looks like a reference, but probably isn't: '6' on line 1261 -- Looks like a reference, but probably isn't: '20' on line 795 -- Looks like a reference, but probably isn't: '50' on line 795 -- Looks like a reference, but probably isn't: '30' on line 796 == Missing Reference: 'TODO' is mentioned on line 1445, but not defined == Missing Reference: 'PIDName' is mentioned on line 1038, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 1351, but not defined == Missing Reference: 'IEEE.754.2008' is mentioned on line 1163, but not defined -- Looks like a reference, but probably isn't: '23' on line 1299 -- Looks like a reference, but probably isn't: '10' on line 1299 -- Looks like a reference, but probably isn't: '0' on line 1300 == Missing Reference: 'TypedEndpointAddr' is mentioned on line 1389, but not defined -- Looks like a reference, but probably isn't: '7' on line 1455 -- Looks like a reference, but probably isn't: '3' on line 1457 == Unused Reference: 'RFC5693' is defined on line 1512, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-10 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-11 -- Duplicate reference: draft-ietf-alto-protocol, mentioned in 'ID-alto-protocol-11', was also mentioned in 'ID-alto-protocol'. Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Randriamasy, Ed. 3 Internet-Draft W. Roome 4 Intended status: Experimental Alcatel-Lucent Bell Labs 5 Expires: April 22, 2013 N. Schwan 6 October 19, 2012 8 Multi-Cost ALTO 9 draft-randriamasy-alto-multi-cost-07 11 Abstract 13 IETF is designing a new service called ALTO (Application Layer 14 traffic Optimization) that includes a "Network Map Service", an 15 "Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and 16 thus incentives for application clients to connect to ISP preferred 17 Endpoints. These services provide a view of the Network Provider 18 (NP) topology to overlay clients. 20 The present draft proposes a light way to extend the information 21 provided by the current ALTO protocol in two ways. First, including 22 information on multiple Cost Types in a single ALTO transaction 23 provides a better mapping of the Selected Endpoints to needs of the 24 growing diversity of Content and Resources Networking Applications 25 and to the network conditions. Second, one ALTO query and response 26 exchange on N Cost Types is faster and lighter than N single cost 27 transactions. All this also helps producing a faster and more robust 28 choice when multiple Endpoints need to be selected. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 22, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Application scope and terminology . . . . . . . . . . . . . . 6 72 3. Uses cases for using multiple costs . . . . . . . . . . . . . 7 73 3.1. Use cases for using additional costs . . . . . . . . . . . 7 74 3.1.1. Delay Sensitive Overlay Applications . . . . . . . . . 8 75 3.1.2. Selection of physical servers involved in 76 virtualized applications . . . . . . . . . . . . . . . 8 77 3.1.3. CDN Surrogate Selection . . . . . . . . . . . . . . . 9 78 3.1.4. Some proposed additional properties and costs . . . . 9 79 3.2. Use cases for Multi-Cost ALTO transactions . . . . . . . . 10 80 3.2.1. Optimized Endpoint Cost Service . . . . . . . . . . . 11 81 3.2.2. Optimized Filtered Cost Map Service . . . . . . . . . 11 82 3.2.3. Cases of unpredicable Endpoint cost value changes . . 12 83 3.2.3.1. Case of a Multi-Cost ALTO query upon a route 84 change . . . . . . . . . . . . . . . . . . . . . . 12 85 3.2.3.2. Case of a Multi-Cost ALTO query upon a cost 86 value change . . . . . . . . . . . . . . . . . . . 13 87 4. ALTO Protocol updates needed to support multi-cost 88 transactions . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.1. List of ALTO protocol updates required and recommended . . 15 90 4.2. Updates required in the member format of objects . . . . . 16 91 4.2.1. Cost value encoded in JSONArray . . . . . . . . . . . 16 92 4.2.2. Format update on CostMode and CostType . . . . . . . . 16 93 4.3. Rules required on object member description . . . . . . . 17 94 4.3.1. Rule on cost value order in ALTO reponses . . . . . . 17 95 4.3.2. Rule on mapping for cost-type and cost-mode array 96 members . . . . . . . . . . . . . . . . . . . . . . . 17 97 4.4. Updates recommended in the object structure . . . . . . . 17 98 4.5. Rule recommended on the cost value mode . . . . . . . . . 17 99 4.6. Extended constraints on multi-cost values . . . . . . . . 18 100 4.6.1. Use cases for mutli-cost multi-operator constraints . 18 101 4.6.2. Extended constraints in Multi-Cost ALTO . . . . . . . 19 102 5. Protocol extensions for multi-cost ALTO transactions . . . . . 19 103 5.1. Information Resources Directory . . . . . . . . . . . . . 20 104 5.1.1. Example of Multi-Cost specific resources in the IRD . 20 105 5.2. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 22 106 5.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 22 107 5.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 22 108 5.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 22 109 5.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 22 110 5.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 23 111 5.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 25 112 5.3. Filtered Multi-Cost Map . . . . . . . . . . . . . . . . . 25 113 5.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 26 114 5.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 26 115 5.3.3. Input Parameters . . . . . . . . . . . . . . . . . . . 26 116 5.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 28 117 5.3.5. Response . . . . . . . . . . . . . . . . . . . . . . . 28 118 5.3.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . 29 119 5.3.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . 29 120 5.4. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 30 121 5.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 31 122 5.4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 31 123 5.4.3. Input Parameters . . . . . . . . . . . . . . . . . . . 31 124 5.4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 32 125 5.4.5. Response . . . . . . . . . . . . . . . . . . . . . . . 32 126 5.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 33 127 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 128 6.1. Information for IANA on proposed Cost Types . . . . . . . 35 129 6.2. Information for IANA on proposed Endpoint Propeeries . . . 35 130 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 131 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 132 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 133 8.2. Informative References . . . . . . . . . . . . . . . . . . 36 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 136 1. Introduction 138 IETF is designing a new service called ALTO that provides guidance to 139 overlay applications, which have to select one or several hosts from 140 a set of candidates that are able to provide a desired resource. 141 This guidance is based on parameters that affect performance and 142 efficiency of the data transmission between the hosts, e.g., the 143 topological distance. The purpose of ALTO is to improve Quality of 144 Experience (QoE) in the application while reducing resource 145 consumption in the underlying network infrastructure. The ALTO 146 protocol conveys the Internet View from the perspective of a Provider 147 Network region that spans from a region to one or more Autonomous 148 System (AS). Together with this Network Map, it provides the 149 Provider determined Cost Map between locations of the Network Map. 150 Last, it provides the Ranking of Endpoints w.r.t. their routing cost. 152 Current ALTO Costs and their modes provide values that are seen to be 153 stable over a longer period of time, such as hopcount and 154 administrative routing cost to reflect ISP routing preferences. 155 Recently, new use cases have extended the usage scope of ALTO to 156 Content Delivery Networks, Data centers and applications that need 157 additional information to select their Endpoints or handle their 158 PIDs. 160 Thus a multitude of new Cost Types that better reflect the 161 requirements of these applications are expected to be specified, in 162 particular cost values that change more frequently than previously 163 assumed. 165 The current ALTO protocol draft [ID-alto-protocol-11] restricts ALTO 166 Cost Maps and Endpoint Cost services to only one Cost Type and Cost 167 Mode per ALTO request. To retrieve information for several Cost 168 Types, an ALTO client must send several separate requests to the 169 server. 171 It would be far more efficient, in terms of RTT, traffic, and 172 processing load on the ALTO client and server, to get all costs with 173 a single query/response transaction. Vector costs provide a robust 174 and natural input to multi-variate path computation as well as robust 175 multi-variate selection of multiple Endpoints. In particular, one 176 Cost Map reporting on N Cost Types is less bulky than N Cost Maps 177 containing one Cost Type each. This is valuable for both the storage 178 of these maps and their transmission. Additionally, for many 179 emerging applications that need information on several Cost Types, 180 having them gathered in one map will save time. 182 There are three parts in this draft. The first part exposes use 183 cases motivating the introduction of new Cost Types and why multi- 184 cost transactions are useful. The second part specifies the core 185 ALTO protocol extensions that are required or recommended to support 186 requests and responses on multiple Cost Types in one single 187 transaction. These extensions also integrate the discussions within 188 the ALTO Working Group. The third part lists the Multi-Cost ALTO 189 services that can be supported by these extensions. 191 2. Application scope and terminology 193 This draft generalizes the case of a P2P client to include the case 194 of a CDN client, a client of an application running on a virtual 195 server, a GRID application client and any Client having the choice in 196 several connection points for data or resource exchange. To do so, 197 it uses the term "Application Client" (AC). 199 This draft focuses on the use case where the ALTO client is embedded 200 in the Application Client or in some Application Endpoint tracker in 201 the network, such as a P2P tracker, a CDN request router or a cloud 202 computing orchestration system implemented in a logically centralized 203 management system. 205 It is assumed that Applications likely to use the ALTO service have a 206 choice in connection endpoints as it is the case for most of them. 207 The ALTO service is managed by the Network Provider (NP) and reflects 208 its preferences for the choice of endpoints. The NP defines in 209 particular the network map, the routing cost among Network Locations, 210 the cost types used to reflect it, and which ALTO services are 211 available at a given ALTO server. 213 The draft uses terms defined as follows: 215 o Endpoint (EP): can be a Peer, a CDN storage location, a physical 216 server involved in a virtual server-supported application, a Party 217 in a resource sharing swarm such as a computation Grid or an 218 online multi-party game. 220 o Endpoint Discovery (EP Discovery) : this term covers the different 221 types of processes used to discover the eligible endpoints. 223 o Network Service Provider (NSP): includes both ISPs, who provide 224 means to transport the data, and Content Delivery Networks (CDNs) 225 who care for the dissemination, persistent storage and possibly 226 identification of the best/closest content copy. 228 o ALTO transaction: a request/response exchange between an ALTO 229 Client and an ALTO Server. 231 o Application Client (AC): this term generalizes the case of a P2P 232 client to include the case of a CDN client, a client of an 233 application running on a virtual server, a GRID application client 234 and any Client having the choice in several connection points for 235 data or resource exchange. 237 3. Uses cases for using multiple costs 239 The ALTO protocol specification in [ID-alto-protocol-11] focuses on 240 the basic use case of optimizing routing costs in NSP networks. 241 Upcoming use cases however will require both new Cost Types and new 242 Endpoint Properties. Recent ALTO use cases now extend to CDNs, Data 243 centers and other applications that need additional information to 244 select their Endpoints or handle their PIDs. The needed Cost Types 245 depend on the QoE requirements that are specific to the applications. 246 Moreover, the cost values that they may use may change more rapidly 247 than assumed up to now. 249 The goal of this section is to describe forward looking use case 250 scenarios that are likely to benefit from ALTO, in order to motivate 251 the introduction of new Cost Types and Endpoint Properties as well as 252 the ALTO Multi-Cost extension. 254 3.1. Use cases for using additional costs 256 ALTO Cost Types and Endpoint Properties are registered in two 257 registries maintained by IANA. The ALTO Cost Type registry ensures 258 that the Cost Types that are represented by an ALTO Cost Map are 259 unique identifiers, and it further contains references to the 260 semantics of the Cost Type. The current specification registers 261 'routingcost' as a generic measure for routing traffic from a source 262 to a destination. In a similar way the ALTO Endpoint Property 263 Registry ensures uniqueness of ALTO Endpoint Property identifiers and 264 provides references to particular semantics of the allocated Endpoint 265 Properties. Currently the 'pid' identifier is registered, which 266 serves as an identifier that allows aggregation of network endpoints 267 into network regions. Both registries accept new entries after 268 Expert Review. New entries should conform to the respective 269 syntactical requirements, and must include information about the new 270 identifier, the intended semantics, and the security considerations. 271 One basic example advocating for multiple Cost Type transactions is 272 an Application Client looking for destination Endpoints or Source/ 273 Destination PID pairs yielding jointly the lowest 'routingcost' and 274 path delay. We hereby assume that 'routingcost' values report some 275 monetary cost and that the Application Client chooses to rely on the 276 hopcount to reflect the path delay. 278 3.1.1. Delay Sensitive Overlay Applications 280 The ALTO working group has been created to allow P2P applications and 281 NSPs a mutual cooperation, in particular because P2P bulk file- 282 transfer applications have created a huge amount of intra-domain and 283 congestion on low-speed uplink traffic. By aligning overlay 284 topologies according to the 'routingcost' of the underlying network, 285 both layers are expected to benefit in terms of reduced costs and 286 improved Quality-of-Experience. 288 Other types of overlay applications might benefit from a different 289 set of path metrics. In particular for real-time sensitive 290 applications, such as gaming, interactive video conferencing or 291 medical services, creating an overlay topology with respect to a 292 minimized delay is preferable. However it is very hard for an NSP to 293 give accurate guidance for this kind of realtime information, instead 294 probing through end-to-end measurements on the application layer has 295 proven to be the superior mechanism. Still, a NSP might give some 296 guidance to the overlay application, for example by providing 297 statistically preferable paths, possibly with respect to the time of 298 day. Also static information like hopcount can serve as an indicator 299 for the delay that can be expected. Thus a Cost Type that can 300 indicate latency, without the need for end-to-end measurements 301 between endpoints, is likely to be useful. 303 3.1.2. Selection of physical servers involved in virtualized 304 applications 306 Virtualized applications in large Datacenters are supported by 307 virtualized servers that actually gather resources distributed on 308 several physical servers. The federation of these resources is often 309 orchestrated by a centralized entity that needs to select the 310 physical servers from or to which it will take resources. This 311 entity can be co-located with an ALTO Client that will request and 312 get the ALTO information on the network formed by the physical 313 servers. The physical servers can be assimilated to endpoints with 314 which the orchestration entity trades application resources or 315 content. These resources include computation resources, storage 316 capacity and path bandwidth between the physical servers. 318 Here too, the applications that are ran are diverse and may have 319 different and specific QoE requirements. The Endpoint selection 320 typically needs to consider both the computational resources at the 321 Endpoints and the resources e.g. in bandwidth on the transmission 322 paths to or among Endpoints. Thus the application QoE requirements 323 drive the Endpoint selection with more or less weight on QoE specific 324 metrics such as hopcount/delay, bandwidth and other resources, that 325 are typically combined with the routing cost and need to jointly 326 integrate the Endpoint and transmission path perspective in the 327 decision process, which is difficult to do with one single Cost Type. 329 3.1.3. CDN Surrogate Selection 331 Another use case is motivated through draft 332 [draft-jenkins-alto-cdn-use-cases-01]. The request router in today's 333 CDNs makes a decision about the surrogate or cache node to which a 334 content request should be forwarded. Typically this decision is 335 based on locality aspects, i.e. the request router tries to select 336 the surrogate node losest to the client. By using the 'routingcost' 337 Cost Type, an ALTO server allows an NSP to guide the CDN in selecting 338 the best cache node. This is particularly important as CDNs place 339 cache nodes deeper into the network (i.e., closer to the end user), 340 which requires finer grained information. Finally the provisioning 341 of abstracted network topology information across administrative 342 boundaries gains importance for cache federations. 344 While distance today is the predominant metric used for routing 345 decisions, other metrics might allow sophisticated request routing 346 strategies. For example the load a cache node sees in terms of CPU 347 utilization, memory usage or bandwidth utilization might influence 348 routing decisions for load-balancing reasons. There exist numerous 349 ways of gathering and feeding this kind of information into the 350 request routing mechanism. 352 For example, information reporting on the occupation level of a cache 353 could be based on a cost reflecting: its remaining computation 354 resources, its remaining storage capacity w.r.t its capacity in 355 storage or computation resources. 357 As ALTO is likely to become a standardized interface to provide 358 network topology information, the ALTO server could also provide 359 other information that a request router needs. In the next 360 iterations of this draft we will analyse which of these metrics is 361 suitable as a Cost Type or Endpoint Property for CDN Surrogate 362 Selection, and propose to register them in the respective registries. 364 3.1.4. Some proposed additional properties and costs 366 In addition to CDN caches, Endpoint Properties and Costs can be 367 useful to report an Endpoint's load, given that an Endpoint can as 368 well be a physical server in a datacenter or any entity as defined in 369 Section 2 of this draft. 371 Proposed new Endpoint properties and costs include: 373 o an Endpoint Property called "EPCapacity", reflecting the nominal 374 capacity of this endpoint. This capacity could be split into: 376 * EP Nominal Memory: the storage capacity of the Endpoint. 378 * EP Nominal Bandwidth: the capacity of the computation resources 379 of the Endpoint. 381 o an Endpoint Cost called "EP occupied Capacity", reflecting the 382 currently available resources w.r.t. their nominal capacity. As 383 with EP Capacity, this can be split into: 385 * EP Occupied Memory: the remaining storage capacity, 387 * EP Occupied Bandwidth: the remaining computation resources. 389 Likewise, new Cost Types are needed to describe the resources of the 390 network paths needed for content transport, in particular the 391 utilized network path bandwidth. 393 o A Cost Type named 'pathoccupationcost' (POC) can be used to 394 reflect the NP view of the utilized path bandwidth. Such an ALTO 395 Cost Type is likely to have values that change frequently. By no 396 means, as stated in the ALTO requirements, are ALTO Cost types 397 expected to reflect real-time values, as these can be gathered by 398 other mechanisms. Instead, a Cost Type such as 399 'pathoccupationcost' should be used as an abstraction that may be 400 represented by a statistical value, or be updated regularly at a 401 frequency lower than 'real-time', or be provided according to 402 different time periods or other parameters. A provision mode for 403 time dependent cost values is proposed in 404 [draft-randriamasy-alto-cost-schedule-01] 406 3.2. Use cases for Multi-Cost ALTO transactions 408 Different Cost Types are suitable for different applications. For 409 example, delay sensitive applications look for both low routing cost 410 and low delay, where as other applications, such as non real time 411 content download, look for moderate delay and minimal losses. On the 412 other hand, applications or entities managing application input 413 information may want, for various reasons to update their ALTO 414 information on several Cost Types. So an ALTO Client may want to mix 415 Cost Types in either 'numerical' and 'ordinal' mode, for Cost Types 416 values that can be represented by numerical values. 418 The Multi-Cost ALTO Services propose to: 420 o include several Cost Types (and/or Cost Modes) in an ALTO client's 421 Cost Map and Endpoint Cost request, 423 o provide several Cost Type values (and/or Cost Mode) in an ALTO 424 server's response, instead of one. 426 The primary reasons to use Multi-Cost ALTO are: 428 o Optimizing time and bandwidth: a single ALTO response with a 429 Multi-Cost cost map with three separate Cost Type values takes 430 much less network bandwidth, and fewer CPU cycles, than three 431 separate ALTO requests for three complete single-cost cost maps. 432 The motivation also holds for the Endpoint Cost Service. Multi- 433 Cost ALTO services can straightforwardly provide a more complete 434 set of cost information. 436 o Facing unpredictable and/or rapid value changes: an ALTO client 437 can get a consistent snapshot of several different rapidly-varying 438 Cost Type values. 440 3.2.1. Optimized Endpoint Cost Service 442 The Endpoint Cost Service (ECS) provides cost information about both 443 the application Endpoint resources and the networking resources used 444 to access those Endpoints. In addition, the ECS may be invoked in 445 "short term" situations, that is for frequent requests and/or 446 requests requiring fast responses. For the ECS, the server's 447 response is restricted to the requested Endpoints, and so is much 448 smaller than a complete Cost Map. Therefore the ECS can be invoked 449 for 'nearly-instant' information requests, and is particularly well 450 suited for multi-cost ALTO transactions, supporting requests and 451 responses on several Cost Type values simultaneously. 453 3.2.2. Optimized Filtered Cost Map Service 455 The set of ALTO Cost Types is not restricted to 'routingcost': ALTO 456 Servers may provide a broader set of metrics. One thing to consider 457 is that the frequency of updates can vary from a Cost Type to another 458 one. Additionally the volume of an entire cost map with values of 459 all available Cost Types, may get rapidly prohibitive for frequent 460 downloads. Given these considerations the Application Client may 461 take better advantage when: 463 o requesting multi-cost maps filtered w.r.t. Cost Types of 464 compatible update frequencies or dates, which is the 465 responsibility of the Application Client, 467 o requesting multi-cost maps filtered w.r.t. a restricted set of PID 468 pairs. 470 In such a case, as with the Endpoint Cost Service, the purpose of a 471 Multi-Cost transaction is to gain time with whatever future use of 472 the received ALTO information. In this case, the Client may mix Cost 473 Types in either 'numerical' and 'ordinal' mode, for Cost Type values 474 that can be represented by numerical values. 476 3.2.3. Cases of unpredicable Endpoint cost value changes 478 Querying all Endpoint cost values simultaneously is always more time 479 and resources efficient than doing it sequentially. 481 It becomes a necessity in case of unpredictable and/or rapid value 482 changes on at least one of the ALTO Cost Types. The term 'rapid' 483 here means "Typical update intervals [that] may be several orders of 484 magnitude longer than the typical network-layer packet round-trip 485 time (RTT)", as described in [ID-ALTO-Requirements13], up to a couple 486 of minutes. 488 This section provides two examples of a delay sensitive application 489 using 'routingcost' and 'hopcount' to select an Endpoint. The 490 application can choose between two candidate Endpoints, EP1 and EP2. 491 The initial choice at T=1 is EP1. It is assumed that at T=2 events 492 in the network occur that impact both 'routingcost' and 'hopcount'. 494 These examples illustrate the need to query 'hopcount' and 495 'routingcost' values at the same time in order to re-evaluate the EP 496 costs w.r.t. the QoE needs of the application. It is assumed that 497 the application triggers regular ALTO requests to get the latest cost 498 values for a list of candidate Endpoints. 500 In some cases the Application client wants to use the ALTO 501 information to perform multi-variate optimization on several Cost 502 Type values. In order for the optimization to be reliable, it is 503 recommended that the Cost Type values are provided in 'numerical' 504 Cost Mode. Therefore the requested Cost Mode for the applicable Cost 505 Types SHOULD be 'numerical'. 507 3.2.3.1. Case of a Multi-Cost ALTO query upon a route change 509 In Figure 1, initially at time T=1, the application has chosen EP1 510 rather than EP2, despite the higher routing cost, because EP1 has a 511 "better" (lower) 'hopcount' value and despite the higher routing cost 512 and possibly because the application has set a higher weight to 513 'hopcount'. 515 At a time T=2, the route to EP1 changes. The ALTO Server information 516 is accordingly updated. The ALTO client makes its next request to 517 update the cost values for 'routingcost' and 'hopcount' on EP1 and 518 EP2. It appears that EP1 has now a hopcount value of 3, the same 519 than for EP2 while its routing cost is higher. 521 The application realizes that there is no more benefit in keeping 522 interacting with EP1 and therefore switches to EP2, that now has the 523 same hopcount but a lower routing cost. 525 T = 1 : EP1: routingcost = 40, hopcount = 2 526 EP2: routingcost = 30, hopcount = 3 528 EP1 is selected because application is time-sensitive and 529 metric 'hopcount' has a higher weight 531 .-----. 532 O ---------- O ------------- | EP2 | 533 / `-----' 534 / 535 / .-----. 536 Source ----------------------- O ---- | EP1 | 537 `-----' 539 T = 2 : EP1: routingcost = 40, hopcount = 3 540 EP2: routingcost = 30, hopcount = 3 542 - Route to EP1 has changed. Hopcount is now 3 544 ==> EP2 is selected because routingcost is lower than for 545 EP1, with the same hopcount value 546 .-----. 547 O ---------- O -------------| EP2 | 548 / \ `-----' 549 / `-----. 550 / `------. .-----. 551 Source ---------- X --------- [O] ---- | EP1 | 552 `-----' 554 Figure 1: Endpoint re-selection using Multi-Cost ALTO request on 555 updated cost values, upon a chnage in the route. 557 3.2.3.2. Case of a Multi-Cost ALTO query upon a cost value change 558 T = 1 : EP1: routingcost = 30, hopcount = 2 559 EP2: routingcost = 30, hopcount = 3 560 ==> EP1 is selected because application is time-sensitive and 561 hopcount metrics has higher weight 563 .-----. 564 O ---------- O ------------- | EP2 | 565 / `-----' 566 / 567 / .-----. 568 O ------------------------ O ---- | EP1 | 569 `-----' 571 T = 2 : EP1: routingcost = 40, hopcount = 2 572 EP2: routingcost = 30, hopcount = 3 573 Routingcost to EP1 has increased. Hopcount is the same. 574 ==> Delay sensitive applications willing to minimize hopcount 575 remain with EP1 while other applications may remain 576 with EP2, that now has a lower routingcost. 578 .-----. 579 O ---------- O -------------| EP2 | 580 / `-----' 581 / 582 / .-----. 583 O ------------------------ O ---- | EP1 | 584 `-----' 585 Figure 2: Endpoint selection using 2 Cost Types with joint request on 586 updated cost values and for delay sensitive applications. 588 4. ALTO Protocol updates needed to support multi-cost transactions 590 To allow running Multi-Cost ALTO Services some minor changes in the 591 base protocol are needed. A set of multi-cost specific media-types 592 is introduced and the main updates consist into changing the JSON 593 type of the value taken by a few members of the objects describing 594 the information resources. 596 As written in the introduction, this section relies on the previous 597 version of the ALTO protocol draft, see [ID-alto-protocol]. It 598 partially integrates an update of the current version issued 599 recently, see [ID-alto-protocol-11], that proposes a generic encoding 600 of cost values in the 'JSONValue' data type. The proposed Multi-Cost 601 specifications will be updated according to the outcome of WG 602 discussions. 604 This section lists and details the proposed changes according to the 605 previous ALTO protocol draft, [ID-alto-protocol] . 607 If members 'cost-type' and 'cost-mode' of objects 608 InfoResourceCostMap, InfoResourceEndpointCostMap, ReqFilteredCostMap, 609 ReqEndpointCostMap remain specified as single values in the base ALTO 610 protocol, then Multi-Cost specific media types need to be used 611 similarly to those specified in the previous version of this draft, 612 see [draft-randriamasy-alto-multi-cost-05]. 614 4.1. List of ALTO protocol updates required and recommended 616 The following updates to the current ALTO protocol, see 617 [ID-alto-protocol], are required or recommended to support multi-cost 618 ALTO transactions. The new resulting JSON formats are specified in 619 the next sections. 621 o Updates required in the format of objects member(s): 623 * Objects DstCosts (to destination PIDs) and EndpointDstCosts (to 624 destination Endpoints): JSON type of cost value member evolves 625 from JSONNumber to JSONArray. 627 * Objects InfoResourceCostMap, ReqFilteredCostMap, 628 ReqEndpointCostMap, InfoResourceEndpointCostMap: members 'cost- 629 mode' and 'cost-type' have now an array of values rather than a 630 single value. 632 o Updates recommended in the object structure: 634 * Objects CostMapCapability and FilteredCostMapCapability: new 635 member giving the maximum number of Cost Types in a response. 637 o Rules required on object member description: 639 * Order in which the multiple cost values are provided in the 640 responses, 642 * Number of values in member 'cost-types' of objects 643 InfoResourceCostMap, InfoResourceEndpointCostMap, 644 ReqFilteredCostMap, ReqEndpointCostMap. 646 o Rule recommended on the cost value mode: 648 * when the mode 'numerical' is available or applicable. 650 4.2. Updates required in the member format of objects 652 This section specifies the changes in the object member format that 653 are required to enable multi-cost ALTO transactions. 655 The term Single Cost qualifies the items as they are specified in the 656 current ALTO protocol draft, up to version 10 658 4.2.1. Cost value encoded in JSONArray 660 The fundamental change to support multi-cost is to encode the cost 661 values with the type JSONArray. This way, the cost between 2 PIDs or 662 to an Endpoint can be represented in a generic way: 664 o with several Cost Types, 666 o with Cost Types whose value can each be encoded with any type of 667 JSON value. 669 For example, a multi-cost value represented with Cost Types (assuming 670 they are supported by the ALTO Server): 671 ["routingcost", "hopcount", "quarterlyvaluexxx", "statustring"] 673 will be encoded in the following JSON Array in a Multi Cost ALTO 674 response: 676 [23, 6, [2, 5, 4, 1], "medium"] 678 The objects impacted by the encoding of ALTO Multi-Cost values in a 679 JSONArray are: DstCosts and EndpointDstCosts. Full specification 680 will be provided in later sections of this draft. 682 4.2.2. Format update on CostMode and CostType 684 In the base protocol, Objects InfoResourceCostMap, 685 ReqFilteredCostMap, ReqEndpointCostMap, InfoResourceEndpointCostMap 686 have members 'cost-mode' and 'cost-type' that list which Cost Type is 687 reported and in which mode this Cost Type is represented. 689 In Multi-Cost ALTO several Cost Types are used per destination PID or 690 Endpoint, so the member 'cost-type' of these objects must now be an 691 array of values rather than a single value. Likewise, the member 692 'cost-mode' must now be an array, where each value reports the 693 representation mode of the corresponding index in the 'cost-type' 694 list. 696 The change on members 'cost-mode' and 'cost-type' from a single value 697 to an array of values are specified in later sections. 699 4.3. Rules required on object member description 701 When several cost values are provided, it is necessary to 702 unambiguously specify to which Cost Type each value corresponds and 703 in which mode each value is provided. 705 4.3.1. Rule on cost value order in ALTO reponses 707 The cost values each Source/Destination pair MUST be provided in the 708 same order as in the array of Cost Types. This way, the cost type 709 values are provided without any ambiguity on the Cost Type they 710 report on. 712 4.3.2. Rule on mapping for cost-type and cost-mode array members 714 The cost-mode array MUST be of the same size as the cost-type array. 715 Each value of this array maps to the Cost Type ID at the same place 716 in the Cost Type array and this value specifies the mode in which the 717 value for this Cost Type is provided. 719 4.4. Updates recommended in the object structure 721 Objects MultiCostMapCapability and FilteredMultiCostMapCapability: 722 new member giving the maximum number of Cost Types in a response. 724 4.5. Rule recommended on the cost value mode 726 In multi-cost transactions: when the mode 'numerical' is available 727 for a Cost Type, it MUST be the one used to represent the cost 728 values. In any case, the Cost Mode used for each Cost Type MUST be 729 exactly specified. 731 The following example illustrates how how this rule can be applied: 733 Assume the Cost Types array: 734 ["routingcost", "hopcount", "quarterlyvaluexxx", "statustring"] 736 The corresponding Cost Mode array should be (assuming that 737 these modes are supported): 738 ["numerical", "numerical", "dynamic", "string"] 740 An example of values is: 741 [23, 6, [21, 9, 4, 12], "medium"] 743 In this example, it is assumed that when the value of a Cost Type is 744 expressed by an array of numbers such as [21, 9, 4, 12], the values 745 in this array are expressed in the 'numerical' mode. 747 4.6. Extended constraints on multi-cost values 749 This draft proposes to extend the constraint tests in the base 750 protocol to allow tests on the various costs in a request, and to 751 allow more general predicates. 753 The base ALTO protocol allows optional contraints in the input 754 parameters to a request for a Filtered Cost Map or the Endpoint Cost 755 Service. The 'constraints' member is an array of expressions that 756 all apply to the (single) requested Cost Type. The encoding of 757 'constraints' member, is fully specified in Section 6.8.2.2.3 "Input 758 parameters" of the base protocol as follows: 760 A constraint contains two entities separated by whitespace: 761 (1) an operator,'gt' for greater than, 'lt' for less than, 762 'ge' for greater than or equal to, 'le' for less than or equal to, 763 or 'eq' for equal to 764 (2) a target cost value. The cost value is a number that MUST be 765 defined in the same units as the Cost Type indicated by the costtype 766 parameter 767 ... 768 If multiple 'constraint' parameters are specified, they are 769 interpreted as being related to each other with a logical AND. 771 Such a specification covers multiple predicates on one metric such 772 as: 773 'routingcost' values belong to [6, 20) 775 However, an application 777 4.6.1. Use cases for mutli-cost multi-operator constraints 779 Suppose that an application uses information on the ALTO Cost Types 780 'hopcount' and 'routingcost'. This application may want to select 781 paths or Endpoints with bounds on values for both 'hopcount' and 782 'routingcost'. For instance solutions meeting a constraint like: 784 'hopcount' values in [6,20) OR 'routingcost' values in [100,200] 786 Moreover, this application may be ready to make compromises and to 787 select paths or Endpoints by bounding their cost values according to 788 two options: 790 1. either solutions with moderate 'hopcount' and high 'routingcost', 791 for instance: 'hopcount' values in [6,20] AND 'routingcost' 792 values in [100,200], 794 2. or solutions with higher 'hopcount' and moderate 'routingcost', 795 for instance: 'hopcount' values in [20,50] AND 'routingcost' 796 values in [30,100]. 798 4.6.2. Extended constraints in Multi-Cost ALTO 800 This draft proposes to support the two above mentioned use cases by 801 extending the scope of constraints in two ways: 803 o allow the 'constraint' member to be applicable to multiple Cost 804 Types, 806 o allow the multiple constraints to be related to each other by both 807 logical AND and logical OR. 809 The two options would be covered by a logical expression like: 811 [('hopcount' ge 6) AND ('hopcount' lt 20) AND 812 ('routingcost' ge 100) AND ('routingcost' le 200)] 813 OR 814 [('hopcount' ge 20) AND ('hopcount' le 50) AND 815 ('routingcost' ge 30) AND ('routingcost' le 100)] 817 A simple encoding of multi-cost constraints for such expressions is 818 specified in Section 5.3.3 of this draft, describing the input 819 parameters to request for Filtered Cost Map. This specification is 820 applicable to the EP Cost service as well. 822 5. Protocol extensions for multi-cost ALTO transactions 824 This section proposes extensions of the ALTO protocol to support 825 Multi Cost ALTO Services or provide additional ALTO information. It 826 integrates discussions on the ALTO mailing list. 828 If an ALTO client desires information on several Cost Types, then 829 instead of placing as many requests as costs, it may request and 830 receive all the desired Cost Types in one single transaction. 832 The ALTO server then, provided it supports the requested Cost Types, 833 and provided it supports multi-cost ALTO transactions, sends one 834 single response where for each {source, destination} pair, the cost 835 values are arranged in an array, where each component corresponds to 836 a specified Cost Type. The correspondence between the components and 837 the Cost Types is implicitly indicated in the ALTO response. Indeed, 838 the values in the Cost values MUST be provided in the same order as 839 in the array of cost types indicated in the response. 841 The following ALTO services have corresponding Multi-Cost extensions: 843 o Information Resources Directory: extended with multi-cost related 844 URIs and associated capabilities. 846 o Cost Map Service: extended with the Multi-Cost Map Service, 848 o Cost Map Filtering Service: extended with the Multi-Cost Map 849 Filtering Service, 851 o Endpoint Cost Lookup Service: extended with the Endpoint Multi- 852 Cost Lookup Service. 854 5.1. Information Resources Directory 856 When the ALTO server supports the provision of information on 857 multiple costs in a single transaction, the Information Resources 858 Directory will list the corresponding resources. The media type 859 remains the same as in the current ALTO protocol. 861 5.1.1. Example of Multi-Cost specific resources in the IRD 863 The following is an example Information Resource Directory returned 864 by an ALTO Server and containing Multi-Cost specific services: the 865 Multi-Cost Map Service, Filtered Multi-Cost Map and the Endpoint 866 Multi-Cost Service. It is assumed that the IRD contains usual ALTO 867 Services as described in the example IRD of the current ALTO 868 protocol. In this example, the ALTO Server additionally provides 869 Multi-Cost Services in a specific folder of "alto.example.com" called 870 "multi". This folder contains the Multi-Cost Maps, Filtered Multi- 871 Cost Maps as well as the Endpoint Multi-Cost Service. 873 In this example, the ALTO IRD exposes Multi-Cost capabilities on cosy 874 types "routingcost", "hopcount", "pathoccupationcost", that can be 875 combined in a request. The values on these metrics are provided in 876 numerical mode. Values provided for cost-type string are in "string" 877 mode. 879 GET /directory HTTP/1.1 880 Host: alto.example.com 881 Accept: application/alto-directory+json,application/alto-error+json 882 HTTP/1.1 200 OK 883 Content-Length: [TODO] 884 Content-Type: application/alto-directory+json 886 { 887 "resources" : [ 888 { 890 ..... 891 Usual ALTO "single-cost" Services as described in current ALTO Protocol 892 ..... 894 }, { 895 "uri" : "http://alto.example.com/multi/costmap", 896 "media-types" : ["application/alto-multicostmap+json"], 897 "capabilities" : { 898 "cost-types" : [ "routingcost", "hopcount" ], 899 "cost-modes" : [ "numerical", "numerical" ] 900 } 901 }, { 902 "uri" : "http://alto.example.com/multi/costmap/filtered", 903 "media-types" : ["application/alto-multicostmap+json" ], 904 "accepts" : ["application/alto-multicostmapfilter+json" ], 905 "capabilities" : { 906 "cost-constraints" : true, 907 "max-cost-types" : 3, 908 "cost-types" : [ "routingcost", "hopcount", "pathoccupationcost" ], 909 "cost-modes" : [ "numerical", "numerical", "numerical" ] 910 } 911 }, { 912 "uri" : "http://alto.example.com/multi/endpointmulticost/lookup", 913 "media-types" : [ "application/alto-endpointmulticost+json" ], 914 "accepts" : [ "application/alto-endpointmulticostparams+json" ], 915 "capabilities" : { 916 "cost-constraints" : true, 917 "max-cost-types" : 2, 918 "cost-types" : [ "routingcost", "hopcount", "status" ], 919 "cost-modes" : [ "numerical", "numerical", "string" ] 920 } 921 } 922 ] 923 } 925 5.2. Multi-Cost Map Service 927 This section introduces a new media-type for the Multi-Cost map. For 928 each source/destination pair of PIDs, it provides the values of the 929 different Cost Types supported for the Multi-Cost map, in the same 930 order as in the list of Cost Types specified in the capabilities. 932 A Multi-Cost Map MAY be provided by an ALTO Server. 934 Note that the capabilities specify implicitly the order in which the 935 different Cost Type values will be listed in the Cost Map. 937 The Cost Type values in the responses are encoded as a JSONArray of 938 cost values for the different Cost Types. 940 Note that values in a Multi-Cost map are arrays of values of the 941 various Cost Types. If the ALTO server does not have the value for a 942 particular Cost Type for a source/destination PID pair, the server 943 MUST use 'null' (a reserved JSON symbol) for that location in the 944 array. If the ALTO server does not have a value for any of the Cost 945 Types for a given source/destination pair -- that is, the array is a 946 list of nulls -- then the ALTO server MAY omit the entry for that 947 source/destination pair. 949 5.2.1. Media Type 951 The media type is "application/alto-multicostmap+json". 953 5.2.2. HTTP Method 955 This resource is requested using the HTTP GET method. 957 5.2.3. Input Parameters 959 None. 961 5.2.4. Capabilities 963 This resource may be defined for multiple Cost Types and Cost Modes. 964 The capabilities of an ALTO Server URI providing this resource are 965 defined by a JSON Object of type CostMapCapability: 967 object { 968 CostType cost-types<0..*>; 969 CostMode cost-modes<0..*>; 970 } MultiCostMapCapability; 972 with members 974 cost-types The Cost Types (Section 5.XX) supported by the 975 corresponding URI. If not present, this member MUST be 976 interpreted as an empty array. 978 cost-modes The Cost Modes (Section 5.XX) supported for each of 979 the supported Cost Types listed in the array 'cost-types'. 980 This array MUST have the same size as the array 'cost-types', 981 and each member of this array MUST give the mode of the 982 Cost Type at that index. 984 An ALTO Server MUST support all of the Cost Types listed here for 985 each of the listed Cost Modes. Note that an ALTO Server may provide 986 multiple Cost Map Information Resources, each with different 987 capabilities. 989 An ALTO Server supporting the Multi-Cost Map service, MUST support 990 the Cost mode 'numerical' for all supported Cost Types encoded with 991 the 'JSONNumber' type. 993 5.2.5. Response 995 The returned InfoResourceEntity object has "data" member of type 996 InfoResourceMultiCostMap: 998 object DstMultiCosts { 999 JSONArray [PIDName]; 1000 ... 1001 }; 1003 object { 1004 DstMultiCosts [PIDName]<0..*>; 1005 ... 1006 } MultiCostMapData; 1008 object { 1009 CostType cost-type<0..*>; 1010 CostMode cost-mode<0..*>; 1011 JSONString map-vtag; 1012 MultiCostMapData map; 1013 } InfoResourceMultiCostMap; 1015 with members: 1017 cost-mode Array of Cost Modes (Section xxx) used in the Cost Map. 1018 This array MUST have the same size as the array 'cost-types'. 1019 where each member of the cost-mode array is the Cost Mode used 1020 for the Cost Type at the same place in the array. 1022 cost-type The array of Cost Types (Section xxx) used in the Cost Map. 1024 map-vtag The Version Tag (Section xx) of the Network Map used to 1025 generate the Cost Map. 1027 map The Cost Map data itself. 1029 MultiCostMapData is a JSON object with each member representing a 1030 single Source PID; the name for a member is the PIDName string 1031 identifying the corresponding Source PID. For each Source PID, a 1032 DstMultiCosts object denotes the associated costs to a set of 1033 destination PIDs each identified by a string indexed by PIDName. For 1034 each destination PID, object DstMultiCost[PIDName] provides an array 1035 of one or several values, each corresponding to the Cost Type listed 1036 at the same place in the 'cost-type' array. This array MUST have the 1037 same size as the 'cost-type' array. The values in the 1038 DstMultiCosts[PIDName] array MUST be listed in the same order as in 1039 the 'cost-type' array. 1041 The returned Cost Map MUST include the required Path Costs for each 1042 pair of Source and Destination PID for which this information is 1043 available. If a cost value is not defined, it MUST be replaced by 1044 the reserved JSON symbol 'null'. 1046 The members 'cost-mode' and 'cost-type' MUST be arrays with the same 1047 number of elements. 1049 5.2.6. Example 1051 This example illustrates a 'static' multi-cost' ALTO transaction, 1052 where the utilized Cost Types all have 'static' values. We assume 1053 here that the Cost Types available at the ALTO Server are 1054 "routingcost" and "hopcount" and the 'numerical' mode is available 1055 for both of them. The "routingcost" may be based on monetary 1056 considerations where as the "hopcount" is used to report on the path 1057 delay. We also assume that ALTO server does not know the value of 1058 the "routingcost" between PID2 and PID3, and hence uses null for 1059 those costs. 1061 GET /multicostmap/num HTTP/1.1 1062 Host: alto.example.com 1063 Accept: application/alto-multicostmap+json,application/alto-error+json 1065 HTTP/1.1 200 OK 1066 Content-Length: [TODO] 1067 Content-Type: application/alto-multicostmap+json 1069 { 1070 "meta" : {}, 1071 "data" : { 1072 "cost-mode" : ["numerical", "numerical"], 1073 "cost-type" : ["routingcost", "hopcount"], 1074 "map-vtag" : "1266506139", 1075 "map" : { 1076 "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, 1077 "PID2": { "PID1":[null,5], "PID2":[1,0], "PID3":[15,9] }, 1078 "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } 1079 } 1080 } 1081 } 1083 5.3. Filtered Multi-Cost Map 1085 A Multi-Cost Map may be very large. In addition, an Application 1086 Client assisted by the ALTO Client does not necessarily need the Cost 1087 Types for all the source/destination PID pairs. 1089 Therefore applications may more likely use Cost Map information 1090 filtered w.r.t. the Cost types as well as the source/destination 1091 pairs of PIDs. This section specifies Filtered Multi-Cost Maps. 1093 A Filtered Multi Cost Map is a Cost Map Information Resource for 1094 which an ALTO Client may supply additional parameters limiting the 1095 scope of the resulting Cost Map. A Filtered Multi Cost Map MAY be 1096 provided by an ALTO Server. 1098 5.3.1. Media Type 1100 The media type is "application/alto-multicostmap+json". 1102 5.3.2. HTTP Method 1104 This resource is requested using the HTTP POST method. 1106 5.3.3. Input Parameters 1108 Input parameters are supplied in the entity body of the POST request. 1109 This document specifies the input parameters with a data format 1110 indicated by the media type "application/ 1111 alto-multicostmapfilter+json", which is a JSON Object of type 1112 ReqFilteredMultiCostMap, where: 1114 object { 1115 PIDName srcs<0..*>; 1116 PIDName dsts<0..*>; 1117 } PIDFilter; 1119 object { 1120 CostType cost-type<0..*>; 1121 CostMode cost-mode<0..*>; 1122 JSONString constraints<0..*>; [OPTIONAL] 1123 JSONArray or-constraints<0..*>; [OPTIONAL] 1124 PIDFilter pids; [OPTIONAL] 1125 } ReqFilteredMultiCostMap; 1127 with members: 1129 cost-type The Cost Types for the returned costs. 1130 Each listed Cost Type MUST be one of the supported Cost Types 1131 indicated in this resource's capabilities. 1133 cost-mode The Cost Mode for each of the returned Cost Types. 1134 As for the choice of Cost Modes, the ALTO Clients SHOULD be 1135 cognizant of operations applicable to different Cost Modes. 1136 For Cost types values encoded with the 'JSONNumber' type, the 1137 Cost Mode SHOULD be numerical when the purpose is to perform 1138 multi-variate optimization. 1140 constraints 1141 Defines an array of additional constraints. The ALTO 1142 server MUST return the costs for all source/destination pair 1143 that satisfy all constraints in this list, and no other 1144 costs. This parameter MUST NOT be specified if this 1145 resource's capabilities (Section XXXX?) indicate that 1146 constraint support is not available. Each string in the 1147 'constraint' array MUST contain three entities separated by 1148 whitespace, in the following format: 1149 [index] op value 1150 'Index' is a number between 0 and the number of Cost 1151 Types minus 1, and indicates the Cost Type to which this 1152 constraint applies. (The square brackets ([]) surrounding 1153 'index' are required syntactic sugar. They serve as a 1154 reminder that 'index' is an array index, not a value to test, 1155 and they avoid unusual-looking constraints such as "1 ge 5".) 1156 'Op' is an operator: 'gt' for greater than, 'lt' for less 1157 than, 'ge' for greater than or equal to, 'le' for less than 1158 or equal to, 'eq' for equal to, or 'ne' for not equal to. 1159 'Value' is a target cost value to compare against the 1160 indicated Cost Type. For numeric Cost Types, 'value' MUST be 1161 a number defined in the same units as the Cost Type indicated 1162 by 'index'. ALTO servers SHOULD use at least IEEE 754 1163 doubleprecision floating point [IEEE.754.2008] to store the 1164 cost value, and SHOULD perform internal computations using 1165 double-precision floating-point arithmetic. For string Cost 1166 Types, 'value' MUST be a string enclosed in single quotes ('). 1167 For array-valued Cost Types, 'eq' is true iff one of the 1168 Cost Type values is equal to 'value', and 'ne' is true iff 1169 none of the Cost Type values are equal to 'value'. The other 1170 operators are not defined for array-valued Cost Types. 1172 or-constraints 1173 Defines an array of arrays of constraint strings. The 1174 individual constraint strings MUST be in the same format as 1175 strings in the 'constraints' parameter. The ALSO server MUST 1176 return costs that satisfy all constraints in one or more of 1177 the inner lists, and no other costs. That is, 1178 'or-constraints' is the logical OR of ANDs. The client MUST 1179 NOT specify this parameter if this resource's capabilities 1180 (Section XXXX?) indicate that constraint support is not 1181 available. The client MUST NOT specify both a 1182 'or-constraints' and a 'constraints' parameter. 1184 pids A list of Source PIDs and a list of Destination PIDs for which 1185 Path Costs are to be returned. If a list is empty, the ALTO 1186 Server MUST interpret it as the full set of currently-defined 1187 PIDs. The ALTO Server MUST interpret entries appearing in a list 1188 multiple times as if they appeared only once. If the "pids" 1189 member is not present, both lists MUST be interpreted by the ALTO 1190 Server as containing the full set of currently-defined PIDs. 1192 5.3.4. Capabilities 1194 The URI providing this resource supports all capabilities documented 1195 in Section 7.7.2.2.4 (with identical semantics), plus additional 1196 capabilities. In particular, the capabilities are defined by a JSON 1197 object of type FilteredMultiCostMapCapability: 1199 object { 1200 CostMode cost-modes<0..*>; 1201 CostType cost-types<0..*>; 1202 JSONBool cost-constraints; 1203 JSONNumber max-cost-types; [OPTIONAL] 1204 } FilteredMultiCostMapCapability; 1206 with members: 1208 cost-modes See Section 4.2.5 of this MC draft 1210 cost-types See Section 4.2.5 of this MC draft 1212 max-cost-types Indicates the maximum number of cost values 1213 the ALTO Server can provide in a multi-cost array of a 1214 Multi-Cost Map. 1216 cost-constraints If true, then the ALTO Server allows cost 1217 constraints to be included in requests to the corresponding URI. 1218 If not present, this member MUST be interpreted as if it specified 1219 false. 1221 5.3.5. Response 1223 See Section on Multi Cost Map Service of this draft for the format. 1224 The returned Cost Map MUST NOT contain any source/destination pair 1225 that was not indicated (implicitly or explicitly) in the input 1226 parameters. If the input parameters contain a PID name that is not 1227 currently defined by the ALTO Server, the ALTO Server MUST behave as 1228 if the PID did not appear in the input parameters. If any 1229 constraints are specified, Source/Destination pairs for which the 1230 Path Costs do not meet the constraints MUST NOT be included in the 1231 returned Cost Map. If no constraints were specified, then all Path 1232 Costs are assumed to meet the constraints. 1234 5.3.6. Example 1 1236 POST multi/multicostmap/filtered HTTP/1.1 1237 Host: alto.example.com 1238 Content-Type: application/alto-multicostmapfilter+json 1239 Accept: application/alto-multicostmap+json,application/alto-error+json 1241 { 1242 "cost-mode" : ["numerical", "numerical"], 1243 "cost-type" : ["routingcost", "hopcount"], 1244 "pids" : { 1245 "srcs" : [ "PID1" ], 1246 "dsts" : [ "PID1", "PID2", "PID3" ] 1247 } 1248 } 1250 HTTP/1.1 200 OK 1251 Content-Length: [TODO] 1252 Content-Type: application/alto-multicostmap+json 1254 { 1255 "meta" : {}, 1256 "data" : { 1257 "cost-mode" : ["numerical", "numerical"], 1258 "cost-type" : ["routingcost", "hopcount"], 1259 "map-vtag" : "1266506139", 1260 "map" : { 1261 "PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] } 1262 } 1263 } 1264 } 1266 5.3.7. Example 2 1268 This is an example of using constraints to restrict returned source/ 1269 destination PID pairs to those with 'routingcost' between 5 and 10, 1270 or 'hopcount' equal to 0. 1272 POST multi/multicostmap/filtered HTTP/1.1 1273 Host: alto.example.com 1274 Content-Type: application/alto-multicostmapfilter+json 1275 Accept: application/alto-multicostmap+json,application/alto-error+json 1277 { 1278 "cost-mode" : ["numerical", "numerical"], 1279 "cost-type" : ["routingcost", "hopcount"], 1280 "or-constraints" : [ ["[0] ge 5", "[0] le 10"], 1281 ["[1] eq 0"] ] 1282 "pids" : { 1283 "srcs" : [ "PID1", "PID2" ], 1284 "dsts" : [ "PID1", "PID2", "PID3" ] 1285 } 1286 } 1288 HTTP/1.1 200 OK 1289 Content-Length: [TODO] 1290 Content-Type: application/alto-multicostmap+json 1292 { 1293 "meta" : {}, 1294 "data" : { 1295 "cost-mode" : ["numerical", "numerical"], 1296 "cost-type" : ["routingcost", "hopcount"], 1297 "map-vtag" : "1266506139", 1298 "map" : { 1299 "PID1": { "PID2": [5,23], "PID3": [10,5] } 1300 "PID2": { "PID2": [1,0] }, 1301 } 1302 } 1303 } 1305 5.4. Endpoint Multi-Cost Service 1307 The Endpoint Multi-Cost Service provides information on several Cost 1308 Types between individual Endpoints. 1310 This service MAY be provided by an ALTO Server. It is important to 1311 note that although this resource allows an ALTO Server to reveal 1312 costs between individual endpoints, an ALTO Server is not required to 1313 do so. A simple alternative would be to compute the cost between two 1314 endpoints as the costs between the PIDs corresponding to the 1315 endpoints if these values are available for the requested Cost Types. 1317 When the cost values are requested to perform multi-variate numerical 1318 optimization and are each available in the 'numerical' mode, then the 1319 ALTO Client SHOULD request the 'numerical' mode in order to get a 1320 reliable result. Note that this consideration is outside the scope 1321 of the ALTO protocol as it relates to the responsibility of the ALTO 1322 Client and related entries. However common sense lead to warn that a 1323 necessary condition for vector ranking method to be reliable is that 1324 the components of the processed vectors are numerical and not ordinal 1325 values. 1327 5.4.1. Media Type 1329 The media type is "application/alto-endpointmulticost+json". 1331 5.4.2. HTTP Method 1333 This resource is requested using the HTTP POST method 1335 5.4.3. Input Parameters 1337 Input parameters are supplied in the entity body of the POST request. 1338 This document specifies input parameters with a data format indicated 1339 by media type "application/alto-endpointmulticostparams+json", which 1340 is a JSON Object of type ReqEndpointMultiCostMap: 1342 object { 1343 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 1344 TypedEndpointAddr dsts<1..*>; 1345 } EndpointFilter; 1347 object{ 1348 CostType cost-type<0..*>; 1349 CostMode cost-mode<0..*>; 1350 JSONString constraints<0..*>; [OPTIONAL] 1351 JSONArray or-constraints<0..*>; [OPTIONAL] 1352 EndpointFilter endpoints; 1353 } ReqEndpointMultiCostMap; 1355 with members: 1357 cost-mode Defined equivalently to the "cost-mode" 1358 input parameter of a Filtered Multi Cost Map. 1360 cost-type Defined equivalently to the "cost-type" 1361 input parameter of a Filtered Multi Cost Map. 1363 constraints Defined equivalently to the "constraints" 1364 input parameter of a Filtered Multi Cost Map. 1366 or-constraints Defined equivalently to the "or-constraints" 1367 input parameter of a Filtered Multi Cost Map. 1369 endpoints A list of Source Endpoints and Destination Endpoints for 1370 which Path multiple Costs are to be returned. If the list 1371 of Source Endpoints is empty (or not included), the ALTO Server 1372 MUST interpret it as if it contained the Endpoint Address 1373 corresponding to the client IP address from the incoming 1374 connection (see Section 10.3 for discussion and considerations 1375 regarding this mode). The list of destination Endpoints 1376 MUST NOT be empty. The ALTO Server MUST interpret entries 1377 appearing multiple times in a list as if they appeared only once. 1379 5.4.4. Capabilities 1381 See section on Filtered Multi Cost Map capabities in this draft. 1383 5.4.5. Response 1385 The returned InfoResourceEntity object has "data" member equal to 1386 InfoResourceEndpointMultiCostMap, where: 1388 object EndpointDstMultiCosts { 1389 JSONArray [TypedEndpointAddr]; 1390 ... 1391 }; 1393 object { 1394 EndpointDstMultiCosts [TypedEndpointAddr]<0..*>; 1395 ... 1396 } EndpointMultiCostMapData; 1398 object { 1399 CostMode cost-mode<0..*>; 1400 CostType cost-type<0..*>; 1401 EndpointMultiCostMapData map; 1402 } InfoResourceEndpointMultiCostMap; 1404 InfoResourceEndpointMultiCostMap has members: 1406 cost-type<0..*> The Cost Types used in the returned Cost Map. 1408 cost-mode<0..*> The Cost Mode for each of the Cost Types used 1409 in the returned Cost Map. 1411 map The Endpoint Multi-Cost Map data itself. 1413 EndpointMultiCostMapData is a JSON object with each member 1414 representing a single Source Endpoint specified in the 1415 input parameters; the name for a member is the 1416 TypedEndpointAddr string identifying the corresponding 1417 Source Endpoint. For each Source Endpoint, a 1418 EndpointDstMultiCosts object denotes the cost vector 1419 associated to each Destination Endpoint specified in the 1420 input parameters; the name for each member in the object is 1421 the TypedEndpointAddr string identifying the corresponding 1422 Destination Endpoint. 1424 5.4.6. Example 1425 POST multi/endpointmulticost/lookup HTTP/1.1 1426 Host: alto.example.com 1427 Content-Length: [TODO] 1428 Content-Type: application/alto-endpointmulticostparams+json 1429 Accept: application/alto-endpointmulticost+json,application/alto-error+json 1431 { 1432 "cost-type" : ["routingcost", "hopcount"], 1433 "cost-mode" : ["numerical", "numerical"], 1434 "endpoints" : { 1435 "srcs": [ "ipv4:192.0.2.2" ], 1436 "dsts": [ 1437 "ipv4:192.0.2.89", 1438 "ipv4:198.51.100.34", 1439 "ipv4:203.0.113.45" 1440 ] 1441 } 1442 } 1444 HTTP/1.1 200 OK 1445 Content-Length: [TODO] 1446 Content-Type: application/alto-endpointmulticost+json 1448 { 1449 "meta" : {}, 1450 "data" : { 1451 "cost-type" : ["routingcost", "hopcount"], 1452 "cost-mode" : ["numerical", "numerical"], 1453 "map" : { 1454 "ipv4:192.0.2.2": { 1455 "ipv4:192.0.2.89" : [1, 7], 1456 "ipv4:198.51.100.34" : [2, 4], 1457 "ipv4:203.0.113.45" : [3, 2] 1458 } 1459 } 1460 } 1461 } 1463 6. IANA Considerations 1465 Information for the ALTO Endpoint property registry maintained by the 1466 IANA and related to the new Endpoints supported by the acting ALTO 1467 server. These definitions will be formulated according to the syntax 1468 defined in Section on "ALTO Endpoint Property Registry" of 1470 [ID-alto-protocol], 1472 Information for the ALTO Cost Type Registry maintained by the IANA 1473 and related to the new Cost Types supported by the acting ALTO 1474 server. These definitions will be formulated according to the syntax 1475 defined in Section on "ALTO Cost Type Registry" of 1476 [ID-alto-protocol], 1478 6.1. Information for IANA on proposed Cost Types 1480 When a new ALTO Cost Type is defined, accepted by the ALTO working 1481 group and requests for IANA registration MUST include the following 1482 information, detailed in Section 11.2: Identifier, Intended 1483 Semantics, Security Considerations. 1485 6.2. Information for IANA on proposed Endpoint Propeeries 1487 Likewise, an ALTO Endpoint Property Registry could serve the same 1488 purposes as the ALTO Cost Type registry. Application to IANA 1489 registration for Endpoint Properties would follow a similar process. 1491 7. Acknowledgements 1493 The authors would like to thank Dave Mac Dysan and Vijay Gurbani for 1494 fruitful discussions and comments on this draft and previous 1495 versions. 1497 Sabine Randriamasy is partially supported by the MEDIEVAL project 1498 (http://www.ict-medieval.eu/), a research project supported by the 1499 European Commission under its 7th Framework Program (contract no. 1500 248565). The views and conclusions contained herein are those of the 1501 authors and should not be interpreted as necessarily representing the 1502 official policies or endorsements, either expressed or implied, of 1503 the MEDIEVAL project or the European Commission. 1505 8. References 1507 8.1. Normative References 1509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1510 Requirement Levels", BCP 14, RFC 2119, March 1997. 1512 [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem 1513 Statement", October 2009. 1515 8.2. Informative References 1517 [ID-ALTO-Requirements13] 1518 "draft-ietf-alto-reqs-13.txt", January 2012. 1520 [ID-alto-protocol] 1521 , Eds., ""ALTO Protocol" draft-ietf-alto-protocol-10.txt", 1522 October 2011. 1524 [ID-alto-protocol-11] 1525 , Eds., ""ALTO Protocol" draft-ietf-alto-protocol-11.txt", 1526 March 2012. 1528 [draft-jenkins-alto-cdn-use-cases-01] 1529 ""Use Cases for ALTO within CDNs" 1530 draft-jenkins-alto-cdn-use-cases-01", June 2011. 1532 [draft-randriamasy-alto-cost-schedule-01] 1533 "ALTO Cost Schedule", July 2012. 1535 [draft-randriamasy-alto-multi-cost-05] 1536 "Multi-Cost ALTO", October 2011. 1538 Authors' Addresses 1540 Sabine Randriamasy (editor) 1541 Alcatel-Lucent Bell Labs 1542 Route de Villejust 1543 NOZAY 91460 1544 FRANCE 1546 Email: Sabine.Randriamasy@alcatel-lucent.com 1548 W. D. Roome 1549 Alcatel-Lucent Bell Labs 1550 600 Mountain Ave. 1551 Murray Hill, NJ 07974 1552 USA 1554 Phone: 1555 Fax: 1556 Email: W.Roome@alcatel-lucent.com 1557 URI: 1559 Nico Schwan 1561 Email: ietf@nico-schwan.de