idnits 2.17.1 draft-schwan-alto-incr-updates-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 351 has weird spacing: '...ostMode cos...' == Line 352 has weird spacing: '...ostType cos...' == Line 353 has weird spacing: '...sionTag map-v...' == Line 354 has weird spacing: '...sionTag cost-...' == Line 355 has weird spacing: '...NNumber updat...' -- The document date (March 12, 2012) is 4399 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) == Missing Reference: 'TODO' is mentioned on line 529, but not defined == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-10 == Outdated reference: A later version (-03) exists of draft-jenkins-alto-cdn-use-cases-01 ** Downref: Normative reference to an Informational draft: draft-jenkins-alto-cdn-use-cases (ref. 'I-D.jenkins-alto-cdn-use-cases') == Outdated reference: A later version (-04) exists of draft-pbryan-json-patch-02 ** Downref: Normative reference to an Informational draft: draft-pbryan-json-patch (ref. 'I-D.pbryan-json-patch') ** Downref: Normative reference to an Informational draft: draft-pbryan-zyp-json-pointer (ref. 'I-D.pbryan-zyp-json-pointer') ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 5693 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO N. Schwan 3 Internet-Draft W. Roome 4 Intended status: Standards Track Alcatel-Lucent Bell Labs 5 Expires: September 13, 2012 March 12, 2012 7 ALTO Incremental Updates 8 draft-schwan-alto-incr-updates-01 10 Abstract 12 The goal of Application-Layer Traffic Optimization (ALTO) is to 13 bridge the gap between network and applications by provisioning 14 network related information. This allows applications to make 15 informed decisions, for example when selecting a target host from a 16 set of candidates. 18 Therefore an ALTO server provides network and cost maps to its 19 clients. This draft discusses options on how to provide incremental 20 updates for these maps, with the goal of reducing the amount of data 21 needed for transmitting the maps. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 September 13, 2012. 46 Copyright Notice 48 Copyright (c) 2012 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 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Determine Client Map Version . . . . . . . . . . . . . . . . . 7 66 3.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1.1. If-Modified-Since HTTP Header . . . . . . . . . . . . 7 68 3.1.2. If-None-Match HTTP Header . . . . . . . . . . . . . . 9 69 3.2. Version-based incremental updates as ALTO extension . . . 10 70 3.2.1. CURRENT NETWORK MAP vtag . . . . . . . . . . . . . . . 10 71 3.2.2. Extensions to full cost-map response: . . . . . . . . 11 72 4. Incremental Update Options . . . . . . . . . . . . . . . . . . 12 73 4.1. Send entire map . . . . . . . . . . . . . . . . . . . . . 12 74 4.2. Patch map . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.3. Encode map . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.4. JSON patch . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.5. Send only changed values . . . . . . . . . . . . . . . . . 14 78 5. Partial Update Capability . . . . . . . . . . . . . . . . . . 15 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 The goal of Application-Layer Traffic Optimization (ALTO) is to 89 bridge the gap between network and applications by provisioning 90 network related information. This allows applications to make 91 informed decisions, for example when selecting a target host from a 92 set of candidates. Typical applications are file sharing, real-time 93 communication and live streaming peer-to-peer networks [RFC5693] as 94 well as Content Distribution Networks 95 [I-D.jenkins-alto-cdn-use-cases]. 97 The ALTO protocol [I-D.ietf-alto-protocol] is specified as a client- 98 server protocol based on the HyperText Transfer Protocol (HTTP) and 99 encoded in JavaScript Object Notation (JSON). An ALTO server 100 provides services that guide ALTO clients in their decisions. The 101 Endpoint Property Service allows ALTO clients to look up properties 102 of endpoints, for example its Netwok Location. The Endpoint Cost 103 Service allows ALTO server to rank endpoints amongst each other with 104 respect to numerical or ordinal costs. The Map Service and the Map 105 Filtering Service allows ALTO client to retrieve full or partial 106 Network Maps and the associated Cost Maps that are provisioned by an 107 ALTO server. 109 The ALTO Network Map contains groupings of endpoints as defined by 110 the ALTO server. By aggregating multiple endpoints that are close to 111 one another with respect to their network connectivity a greater 112 scalability is achieved. Each group of endpoints is associated to a 113 Network Location identifier called a PID, for example by a list of IP 114 prefixes that belong to the PID. The ALTO Server then indicates 115 preferences amongst the PIDs in the Cost Map by defining Path Costs 116 amongst sets of Netwok Locations. 118 The size of the Network and Cost Maps depend on the granularity of 119 the map an ALTO server provides for its clients. While some use 120 cases allow operators to configure their servers to support only a 121 small numbers of PIDs, other use cases are expected to require a much 122 greater accuracy in terms of network locations. In order to avoid 123 the transmission of the same information in each client request, a 124 mechanism that allows a server to send incremental updates, in 125 particular for large Network and Cost Maps, is needed. 127 The goal of this draft is to list and discuss the different options 128 that allow such incremental updates of Network and Cost Maps. The 129 draft is structured as follows: First it lists options that allow a 130 server to validate the cached version of a map a client has. Then it 131 disusses the options a server has to send incremental updates. 132 Finally it introduces an information resource capability that allows 133 servers to advertise which ALTO services are able to handle partial 134 updates. 136 Comments and discussions about this memo should be directed to the 137 ALTO working group: alto@ietf.org. 139 2. Problem Statement 141 The ALTO protocol uses Network and Cost Maps to allow ALTO servers 142 the specification of its own aggregated network view. Essentially 143 the Network Map contains information on how the endpoints are grouped 144 together, which is typically done according to their proximity. The 145 Cost Map contains Path Costs between the network regions defined in 146 the Network Map. The size of these maps strongly depends on the 147 scenario an ALTO server is configured for by its operator. While in 148 some scenarios both maps might only comprise s small number of PIDs, 149 others need much greater accuracy. For large maps partial updates 150 might become necessary. 152 Both map types have slightly different characteristics. Network Maps 153 in general are expected to be smaller than Cost Maps. As an example, 154 a Network Map with 5,000 PIDs, each having 10 cidrs will result in a 155 map with the size of roughly 1.25 megabytes. A Cost Map in contrast 156 contains a n*n matrix for cost entries where n is the number of PIDs. 157 Even for short PID names a full cost map for 5,000 PIDs takes up to 158 417 megabytes. Network Maps are also seen to be less dynamic than 159 Cost Maps. This is due to the fact that the topology an ALTO server 160 sees changes slower than the path costs of the network. Another 161 characteristic is that changes to the Network Map will impact the 162 Cost Map, whereas vice versa this is presumably not the case. A 163 final discussion on whether partial updates are useful for both map 164 types is out of the scope of this document. 166 The remainder of this document discusses options to allow partial 167 updates of Network and Cost Maps. Therefore two sections focus on 168 two seperate problems that need a solution. The first part 169 (Section 3) discusses how an ALTO client and an ALTO server can 170 synchronize their map state without transmitting the whole map. This 171 is needed to identify whether a partial update can be applied and 172 also to calculate the partial update itself. The second part 173 (Section 4) of the document discusses how partial updates can be 174 encoded and sent to the client. 176 3. Determine Client Map Version 178 To allow a server sending incremental updates to a client it first 179 needs to check the version of a cached map a client already has. In 180 this section we discuss options for this validation. We focus our 181 discussion on approaches where the client polls the ALTO server for 182 map changes and the server decides based on the client request. 183 Therefore we first disuss HTTP built-in options and follow-up with a 184 possible extension to ALTO network and cost maps themselves. 186 3.1. HTTP 188 HTTP [RFC2616] provides request-header fields to express conditional 189 requests. Typically these conditional requests are used by caches to 190 decide whether a copy of a resource they have can be served to a 191 requesting client directly or not. 193 Note that it has to be checked if partial updates as reponse on HTTP 194 conditional requests are conform with the HTTP specification. 196 3.1.1. If-Modified-Since HTTP Header 198 One possible option is to use the HTTP If-Modified-Since header in 199 the request if the client has previously contacted the ALTO service 200 and thus already has a version of the map. Therefore the server 201 includes date and time when the map was last modified into the Last- 202 Modified entity-header for a particular map, which is cached by the 203 client together with the map and sends it in new requests for the 204 same map in the If-Modified-Since header. 206 The following figure illustrates a GET request for a Network Map 207 Information Resource. Additionally the client indicates the time 208 when it retrieved the Network Map the last time in the If-Modified- 209 Since header field. 211 GET /networkmap HTTP/1.1 212 Host: alto.example.com 213 Accept: application/alto-networkmap+json,application/alto-error+json 214 If-Modified-Since: Sat, 24 Dec 2011 19:43:31 GMT 216 Figure 1: If-Modified-Since HTTP Header 218 A server retrieving this request uses the timestamp provided by the 219 client to decide whether to send a full map, only partial updates of 220 the map or no map at all in case there were no changes. 222 In case the Network Map has not been modified since the time provided 223 by the client in the request, the server SHOULD reply with a 304 HTTP 224 response. The client then caches the updated value of the Last- 225 Modified entity-header for future requests. 227 304 Not Modified 228 Last-Modified: Sun, 25 Dec 2011 09:33:31 GMT 230 Figure 2: HTTP Response 304 232 In case the server determines that the timestamp provided by the 233 client is out-of-date and cannot be reused for a partial update it 234 returns the full Network Map, as defined in the ALTO core protocol 235 specification. The following figure shows the Last-Modified entity- 236 header in the HTTP response that is used as a timestamp for the map 237 as well as the ETag header for a If-None-Match request, as explained 238 in section Section 3.1.2. 240 HTTP/1.1 200 OK 241 Content-Length: [TODO] 242 Content-Type: application/alto-networkmap+json 243 Date: Sun, 25 Dec 2011 09:33:31 GMT 244 ETag: "nm000012" 246 { 247 "meta" : {}, 248 "data" : { 249 "map-vtag" : "1266506139", 250 "map" : { 251 "PID1" : { 252 "ipv4" : [ 253 "192.0.2.0/24", 254 "198.51.100.0/25" 255 ] 256 }, 257 "PID2" : { 258 "ipv4" : [ 259 "198.51.100.128/25" 260 ] 261 }, 262 "PID3" : { 263 "ipv4" : [ 264 "0.0.0.0/0" 265 ], 266 "ipv6" : [ 267 "::/0" 268 ] 269 } 270 } 271 } 272 } 274 Figure 3: Full Network Map HTTP Response 276 In case the server determines that there was a change to the Network 277 Map the server MAY choose not to send the full map, but a partial 278 update only. Options for sending these partial updates are discussed 279 in Section 4. 281 3.1.2. If-None-Match HTTP Header 283 A second HTTP based mechanism could employ ETags in combination with 284 the If-None-Match header. Here the server creates entity tags that 285 identify the version of a map. A client that caches a map includes 286 this identifier in every future request. The server can use this 287 ETag to calculate the necessary partial update for both map versions. 289 The following example illustrates a client GET request which includes 290 an ETag, identifying a network map. The example assumes the client 291 received the Network Map response in Figure 3. 293 GET /networkmap HTTP/1.1 294 Host: alto.example.com 295 Accept: application/alto-networkmap+json,application/alto-error+json 296 If-None-Match: "nm000012" 298 Figure 4: If-None-Match HTTP Header 300 3.2. Version-based incremental updates as ALTO extension 302 With this approach, clients poll the ALTO server for changes. The 303 server provides hints as to the polling frequency. We propose two 304 different mechanisms in the ALTO message format, one for network-map 305 changes, the other for cost-map changes. 307 For network-map changes, add a new GET-mode request, "CURRENT NETWORK 308 MAP VTAG." The response is short and simple: just the current map- 309 vtag and a hint about how often the network-map might change. Once a 310 client has the full network map, the client periodically sends that 311 CURRENT VTAG request to the server. If the map-vtag changes, the 312 client re-gets the network map. For cost-map changes, add two new 313 fields to the full cost-map response: a "cost-map-vtag" and a hint 314 about the how often the server updates the cost map. 316 Using these vtags both client and server can determine if it is 317 necessary to request or to send an updated map, a full map, or if the 318 current version is still up-to-date. 320 3.2.1. CURRENT NETWORK MAP vtag 322 This is a GET-mode request. The response is a simple json structure 323 with 325 o The current map-vtag for the network map. 327 o The average number of seconds between changes to the network map. 329 It needs a new media type, say application/alto-currentmapvtag+json 331 For example, 332 HTTP/1.1 200 OK 333 Content-Length: [TODO] 334 Content-Type: application/alto-currentmapvtag+json 336 { 337 "meta" : {}, 338 "data" : { 339 "map-vtag" : "123456", 340 update-interval: 86400 341 } 342 } 344 Figure 5: CURRENT NETWORK MAP vtag 346 3.2.2. Extensions to full cost-map response: 348 Add two new fields to the costmap response, as in: 350 object { 351 CostMode cost-mode; 352 CostType cost-type; 353 VersionTag map-vtag; 354 VersionTag cost-map-vtag; // Optional 355 JSONNumber update-interval; // Optional 356 CostMapData map; 357 } InfoResourceCostMap; 359 Figure 6: Extensions to full cost-map response 361 cost-map-vtag: A string that (together with the network map-vtag) 362 uniquely identifies this version of the cost map. 364 update-interval: Average time between cost-map updates, in seconds. 365 (A hint, not a guarantee). Perhaps required if cost-map-vtag is 366 present 368 These fields would only be in the full cost map response, not in a 369 filtered cost map response. 371 4. Incremental Update Options 373 Once a server has decided to send a partial update only there are 374 several ways to do so. This section discusses these response 375 options. 377 4.1. Send entire map 379 One trivial option is always to send the entire map anyways. The 380 advantage of sending the whole map typically is that there is no 381 computational effort needed on the server side. Thus this can always 382 be a fallback in case the server is under load, or in case a partial 383 update appears to be inefficient. 385 4.2. Patch map 387 A server that knows the version of the map a client currently has can 388 use this information to calculate the contextual diff to the newest 389 version of the map. This can also be done in a batch process for all 390 previous versions once a new map is loaded on the server to avoid a 391 per request calculation. The diff output can then be sent in a 392 response to the client, which in turn can use it to patch its version 393 of the map. By doing this the newest version of the map can be 394 recreated. 396 4.3. Encode map 398 One major goal of applying partial updates is to reduce transmission 399 time by reducing the amount of data which is to be transferred to the 400 client. This goal can be achieved by applying compression 401 techniques, such as gzip, to the message content, both for partial 402 updates as well as for entire maps. 404 HTTP supports this by the Content-Encoding entity header field. The 405 advantage of using compression is that there is no need to change the 406 underlying media-type of the reponse. Typically not all ALTO clients 407 will support this optimization from the beginning, thus the server 408 will need to store two representations of the maps: One which is 409 compressed and one uncompressed. 411 4.4. JSON patch 413 JSON Patch [I-D.pbryan-json-patch] defines a JSON document structure 414 that allows partial modifications to a JSON document and defines the 415 associated media type "application/json-patch". Therefore JSON Patch 416 is a suitable option for incremental udates of the Network and Cost 417 Maps. JSON patch supports add, remove and replace operations that 418 can be used in combination with JSON Pointers 420 [I-D.pbryan-zyp-json-pointer] to modify values and arrays of the JSON 421 document members. 423 Typically JSON Patch is used in combination with the HTTP PATCH 424 method [RFC5789] to partially modify existing resources on a server. 425 As an ALTO client is not modifying a resource, but wants to be 426 updated if the resource has changed it needs to signal to the server 427 that it is able to receive and understand JSON Patch updates. This 428 can be done by including the media type "application/json-patch" in 429 the Accept header field of the HTTP request. 431 Although JSON Patch permits pointers to index individual array 432 elements, that's potentially ambiguous. "Add" and "delete" change 433 the array indexes; do subsequent updates to that array refer to the 434 original indexes or the revised indexes? And even if that's well- 435 specified, it's a potential source of error. Furthermore, some 436 clients may store the CIDRs in a PID as a set, rather than an array, 437 so they don't keep the original index numbers. 439 To avoid these problems, we recommend that when updating the CIDRs 440 for a PID, the server replaces the full array value for that PID, 441 rather than updating individual CIDRs by index. 443 This may also simplify the server, because it just has to flag the 444 PID as having changed; it doesn't have to remember the previous 445 sequence of CIDRs. 447 The following figure illustrates one example where the server decides 448 to send a partial update to the client using JSON Patch. The server 449 indicates this in the reponse Content-Type header. In the following 450 example the Network Map from the example in Figure 3 above has 451 changed. The map-vtag element has been incremented by 1, which 452 results in a replace operation for the respective element containing 453 the new value. Also two new subnets are added to the Network Map in 454 PID1 and PID2 by two replace operations on the ipv4 arrays. 456 HTTP/1.1 200 OK 457 Content-Length: [TODO] 458 Content-Type: application/json-patch 459 Date: Sun, 25 Dec 2011 09:33:31 GMT 461 { "replace": "/data/map-vtag", "value": "1266506140" }, 462 { "replace": "/data/map/PID1/ipv4", "value": 463 ["192.0.2.0/24", "198.51.200.0/25", "198.51.100.0/25"] }, 464 { "replace": "/data/map/PID2/ipv4", "value": 465 ["198.51.100.128/25", "198.51.200.128/25"] } 466 Figure 7: Partial update with JSON Patch 468 4.5. Send only changed values 470 Another option is to offer a dedicated ALTO service for partial 471 updates. A client that detemines that its current map is out-of- 472 date, for example by comparing cost-map-vtag values can then query 473 this service to retrieve the partial update. 475 This service can be implemented in a new POST-mode request, "GET 476 COST-MAP CHANGES". The POST data would have a cost-map-vtag from a 477 previous cost-map response. The response would be the same as for a 478 full costmap request, except that it only has costs that have changed 479 since the specified cost-map-vtag. The response would contain the 480 current cost-map-vtag and update-interval. 482 If the current cost-map-vtag is the same as the specified one -- that 483 is, if there are no changes -- the "map" entry in the response has no 484 cost entries. 486 If the specified cost-map-vtag is invalid, or if it's sufficiently 487 old that the server no longer knows what changed since that version, 488 the server returns a complete cost map. Thus the response MUST have 489 costs that changed since the specified version, but MAY have other 490 costs as well. 492 A possible implementation strategy for this service is to maintain at 493 the server for each cost type an "instantaneous" cost map and the 494 last N "numbered versions" of those costs. For a full-map requests 495 without a version number, the server returns the most recent 496 numbered-version map. For a COST-MAP CHANGES request, the server 497 finds the client's version number in its stack of saved versions, and 498 returns the diffs between that version and the most recent numbered 499 version. If the server doesn't have the old version any more, the 500 server returns the full latest version. 502 Then periodically the server copies the instantaneous map to the 503 last-stable map, assigns it a new version number, shuffles the list 504 down, and discards the oldest version. The server could cache diffs 505 and discard old ones. 507 For filtered cost-map requests, the server could use either the 508 "instantaneous" cost map or the most recent "versioned" cost map. 510 5. Partial Update Capability 512 An ALTO server needs to advertise its ability of providing 513 incremental updates to a client. One option of doing this is by 514 including an ALTO information resource capability indicating the 515 partial update option. This can be done per ALTO service, which 516 allows a fine grained control over which URIs handle partial 517 requests. 519 The following Information Resource Directory illustrates one example 520 where network and costmaps are available with and without partial 521 update option respectively. This is expressed by the JSONBool 522 capability element "partial-update". 524 GET /directory HTTP/1.1 525 Host: alto.example.com 526 Accept: application/alto-directory+json,application/alto-error+json 528 HTTP/1.1 200 OK 529 Content-Length: [TODO] 530 Content-Type: application/alto-directory+json 532 { 533 "resources" : [ 534 { 535 "uri" : "http://alto.example.com/serverinfo", 536 "media-types" : [ "application/alto-serverinfo+json" ] 537 }, { 538 "uri" : "http://alto.example.com/networkmap", 539 "media-types" : [ "application/alto-networkmap+json" ] 540 }, { 541 "uri" : "http://alto.example.com/costmap/rcost", 542 "media-types" : [ "application/alto-costmap+json" ], 543 "capabilities" : { 544 "cost-modes" : [ "numerical" ], 545 "cost-types" : [ "routingcost" ] 546 } 547 }, { 548 "uri" : "http://alto.example.com/partialupdate/networkmap", 549 "media-types" : [ "application/alto-networkmap+json" ] 550 "capabilities" : { 551 "partial-update" : true, 552 } 553 }, { 554 "uri" : "http://alto.example.com/partialupdate/costmap/rcost", 555 "media-types" : [ "application/alto-costmap+json" ], 556 "capabilities" : { 557 "partial-update" : true, 558 "cost-modes" : [ "numerical" ], 559 "cost-types" : [ "routingcost" ] 560 } 561 } 562 } 563 ] 564 } 566 Figure 8: IRD With Partial Update Capability 568 6. IANA Considerations 570 None. 572 7. Security Considerations 574 To be done in later versions of this document. 576 8. Conclusion 578 This document describes different options that can be applied to 579 support incremental updates of ALTO Network and Cost maps. In 580 particular it comprises option for client and server to synchronize 581 themselves about their current map state, and further includes 582 options on how to encode partial updates. Finally it proposes an new 583 parial update capability for the Information Resource Directory. 585 9. References 587 [I-D.ietf-alto-protocol] 588 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 589 draft-ietf-alto-protocol-10 (work in progress), 590 October 2011. 592 [I-D.jenkins-alto-cdn-use-cases] 593 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 594 S. Previdi, "Use Cases for ALTO within CDNs", 595 draft-jenkins-alto-cdn-use-cases-01 (work in progress), 596 June 2011. 598 [I-D.pbryan-json-patch] 599 Bryan, P., "JSON Patch", draft-pbryan-json-patch-02 (work 600 in progress), October 2011. 602 [I-D.pbryan-zyp-json-pointer] 603 Bryan, P. and K. Zyp, "JSON Pointer", 604 draft-pbryan-zyp-json-pointer-02 (work in progress), 605 October 2011. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 611 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 612 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 614 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 615 Optimization (ALTO) Problem Statement", RFC 5693, 616 October 2009. 618 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 619 RFC 5789, March 2010. 621 Appendix A. Acknowledgments 623 The authors would like to thank Vijay Gurbani for his valuable input 624 and excellent feedback to this document. 626 Nico Schwan is partially supported by the ENVISION project 627 (http://www.envision-project.org), a research project supported by 628 the European Commission under its 7th Framework Program (contract no. 629 248565). The views and conclusions contained herein are those of the 630 authors and should not be interpreted as necessarily representing the 631 official policies or endorsements, either expressed or implied, of 632 the ENVISION project or the European Commission. 634 Authors' Addresses 636 Nico Schwan 637 Alcatel-Lucent Bell Labs 638 Lorenzstrasse 10 639 Stuttgart 70435 640 Germany 642 Email: nico.schwan@alcatel-lucent.com 643 URI: www.alcatel-lucent.com/bell-labs 645 Bill Roome 646 Alcatel-Lucent Bell Labs 648 Email: w.roome@alcatel-lucent.com 649 URI: www.alcatel-lucent.com/bell-labs