idnits 2.17.1 draft-he-cdni-routing-request-redirection-05.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2013) is 4037 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-03 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Danhua. Wang, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track B. Niven-Jenkins, Ed. 5 Expires: October 02, 2013 Velocix (Alcatel-Lucent) 6 Xiaoyan. He 7 Huawei 8 Chen. Ge 9 China Telecom 10 Wei. Ni 11 China Mobile 12 March 31, 2013 14 Request Routing Redirection Interface for CDN Interconnection 15 draft-he-cdni-routing-request-redirection-05 17 Abstract 19 The Request Routing Interface comprises of (1) the asynchronous 20 advertisement of footprint and capabilities by a downstream CDN that 21 allows a upstream CDN to decide whether to redirect particular user 22 requests to that downstream CDN; and (2) the synchronous operation of 23 an upstream CDN requesting whether a downstream CDN is prepared to 24 accept a user request and of a downstream CDN responding with how to 25 actually redirect the user request. This document describes an 26 interface for the latter part, i.e. the CDNI request routing/ 27 Redirection Interface. 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 October 02, 2013. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Interface function and operation overview . . . . . . . . . . 4 65 4. HTTP based RESTful interface for the Redirection Interface . 5 66 4.1. Information passed in RI requests & responses . . . . . . 7 67 4.2. JSON encoding of RI requests & responses . . . . . . . . 9 68 4.3. DNS redirection . . . . . . . . . . . . . . . . . . . . . 10 69 4.3.1. DNS Redirection requests . . . . . . . . . . . . . . 10 70 4.3.2. DNS Redirection responses . . . . . . . . . . . . . . 12 71 4.4. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 13 72 4.4.1. HTTP Redirection requests . . . . . . . . . . . . . . 13 73 4.4.2. HTTP Redirection responses . . . . . . . . . . . . . 14 74 4.5. Indicating the cacheability and scope of responses . . . 15 75 4.6. Error responses . . . . . . . . . . . . . . . . . . . . . 17 76 4.7. Loop detection & prevention . . . . . . . . . . . . . . . 18 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 80 8. Outstanding considerations . . . . . . . . . . . . . . . . . 20 81 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 84 10.2. Informative References . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 A Content Delivery Network (CDN) is a system built on an existing IP 90 network which is used for large scale content delivery, via 91 prefetching or dynamically caching content on its distributed 92 surrogates (caching servers). [RFC6707] describes the problem area 93 of interconnecting CDNs. 95 The CDNI request routing interface outlined in 96 [I-D.ietf-cdni-framework] comprises of: 98 1. The asynchronous advertisement of footprint and capabilities by a 99 downstream CDN that allows a upstream CDN to decide whether to 100 redirect particular user requests to that downstream CDN. 102 2. The synchronous operation of an upstream CDN requesting whether a 103 downstream CDN is prepared to accept a user request and of a 104 downstream CDN responding with how to actually redirect the user 105 request. 107 This document describes an interface for the latter part, i.e. the 108 CDNI request routing/Redirection Interface (RI). 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 This document reuses the terminology defined in [RFC6707]. The term 117 "Distinguished CDN Domain" defined in [I-D.ietf-cdni-framework] is 118 also reused in this document. 120 The following additional terms are introduced by this document: 122 Application Level Redirection: The act of using an application 123 specific redirection mechanism for the request routing process of a 124 CDN. The Redirection Target (RT) is the result of the routing 125 decision of a CDN at the time it receives a content request via an 126 application specific protocol response. Examples of an application 127 level redirection are HTTP 302 Redirection and RTMP 302 Redirection. 129 DNS Redirection: The act of using DNS name resolution for the request 130 routing process of a CDN. In DNS Redirection, the DNS name server of 131 the CDN makes the routing decision based on a local policy and 132 selects one or more Redirection Targets (RTs) and redirects the user 133 agent to the RT(s) by returning the details of the RT(s) in response 134 to the DNS query request from the user agent's DNS resolver. 136 HTTP Redirection: The act of using an HTTP redirection response for 137 the request routing process of a CDN. The Redirection Target (RT) is 138 the result of the routing decision of a CDN at the time it receives a 139 content request via HTTP. HTTP Redirection is a particular case of 140 Application Level Redirection. 142 Redirection Target (RT): A Redirection Target is the endpoint to 143 which the user agent is redirected. In CDNI, a RT may point to a 144 number of different components, some examples include a surrogate in 145 the same CDN as the request router, a request router in a downstream 146 CDN or a surrogate in a downstream CDN, etc. 148 3. Interface function and operation overview 150 [[Editor's note: Need to factor token authorisation into a future 151 draft when that work is more stable/mature within the WG.]] 153 The CDNI request routing/Redirection Interface (RI) is one of the 154 main building blocks required in order to interconnect CDNs. The 155 main function of the Redirection Interface is to allow the Request 156 Routing systems in interconnected CDNs to communicate to facilitate 157 the redirection of User Agent requests between interconnected CDNs. 159 The detailed requirements for the Redirection Interface and their 160 relative priorities are described in section 5 of 161 [I-D.ietf-cdni-requirements]. 163 The User Agent will make a request to a request router in the uCDN 164 using one of either DNS or HTTP. If the RI is used between the uCDN 165 and one or more dCDNs. The dCDN's RI response may contain a 166 Redirection Target with a type that is compatible with the protocol 167 used between User Agent and uCDN request router. The dCDN has 168 control over the Redirection Target it provides and depending on the 169 returned Redirection Target, the User Agent's request may be 170 redirected to: 172 o The final Surrogate, which may be in the dCDN or another dCDN (if 173 dCDN delegates the delivery to another CDN). 175 o A request router (in dCDN or another CDN) that will be using a 176 redirection protocol (DNS or HTTP) which may or may not be the 177 same as original redirection protocol. 179 The Redirection Interface operates between the Request Routing 180 systems of a pair of interconnected CDNs. To enable communication 181 over the Redirection Interface, the two interconnected CDNs need to 182 know the end point (URI) in the other CDN to query. For example, an 183 Upstream CDN needs to know the URI (end point) in a Downstream CDN to 184 send its CDNI request routing queries to. 186 The Redirection Interface URI may be statically pre-configured, 187 dynamically discovered via the CDNI control interface, or discovered 188 via other means. However, such discovery mechanisms are not 189 specified in this document, as they are considered out of the scope 190 of the Redirection Interface specification. 192 CDNI solutions must support both of the request routing mechanisms 193 illustrated in section 2.1 of [I-D.ietf-cdni-framework], namely 194 Iterative Request Redirection and Recursive Request Redirection. 195 However, the Iterative Request Redirection method does not invoke any 196 interaction over the Redirection Interface between interconnected 197 CDNs. Therefore, the Redirection Interface is only relevant in the 198 case of Recursive Request Redirection and so this document will not 199 discuss Iterative Request Redirection further. 201 In the case of Recursive Request Redirection, in order to perform 202 redirection of a request received from a User Agent, the Upstream CDN 203 queries the Downstream CDN so that the Downstream CDN can select and 204 provide a Redirection Target. In cases where a uCDN has a choice of 205 dCDNs it is down to the uCDN to decide (for example via configured 206 policies) which dCDN(s) to query and in which order to query them. A 207 number of strategies are possible including selecting a preferred 208 dCDN based on local policy, possibly falling back to querying an 209 alternative dCDN(s) if the first dCDN does not return a Redirection 210 Target or otherwise reject the uCDN's RI request. A more complex 211 strategy could be to query multiple dCDNs in parallel before 212 selecting one and using the Redirection Target provided by that dCDN. 214 The Upstream CDN->User Agent redirection protocols addressed in this 215 draft are: DNS redirection and HTTP redirection. Other types of 216 application level redirection will not be discussed further in this 217 draft. However the Redirection Interface is designed to be 218 extensible and could be extended to support additional application 219 level redirection protocols. 221 Also, according to the CDNI generic and request routing interface 222 requirements, the CDNI solution shall support mechanisms to prevent 223 and detect RI request loops. To meet such requirements, this 224 document defines a loop prevention and detection mechanism as part of 225 the Redirection Interface. 227 4. HTTP based RESTful interface for the Redirection Interface 229 This document defines a simple RESTful interface for the Redirection 230 Interface based on HTTP [RFC2616], where the attributes of a User 231 Agent's requests are encapsulated along with any other data that can 232 aid the downstream CDN in processing the requests. The RI response 233 encapsulates the attributes of the RT(s) that the upstream CDN should 234 return to the User Agent (if it decides to utilize the Downstream CDN 235 for delivery) along with the policy for how the response can be 236 reused. 238 The same RESTful interface is used for both DNS and HTTP redirection 239 of User Agent's requests, although the contents of the RI requests/ 240 responses contain data specific to either DNS or HTTP redirection. 242 This approach has been chosen because it enables CDN operators to 243 only have to deploy a single (RESTful) interface for the RI between 244 their CDNs, regardless of the User Agent redirection method. In this 245 way, from an operational point of view there is only one interface to 246 monitor, manage, develop troubleshooting tools for, etc. 248 In addition, having a single RI where the attributes of the User 249 Agent's DNS or HTTP request are encapsulated along with the other 250 data required for the downstream CDN to make a request routing 251 decision, avoids having to try and encapsulate or proxy DNS/HTTP/RTMP 252 /etc requests and find ways to somehow embed the additional CDNI 253 request routing/Redirection Interface properties/data within those 254 End User DNS/HTTP/RTMP/etc requests. 256 Finally, the RI is easily extendable to support other User Agent 257 request redirection methods (e.g. RTMP 302 redirection). 259 The generic Recursive Request Redirection message flow between 260 Request Routing systems in a pair of interconnected CDNs is as 261 follows: 263 User Agent CDN B RR CDN A RR 264 |UA Request (DNS or HTTP) | | 265 |-------------------------------------------------->| (1) 266 | | | 267 | |HTTP POST to CDN B's RI | 268 | |URI encapsulating UA | 269 | |request attributes | 270 | |<------------------------| (2) 271 | | | 272 | |HTTP Response with body | 273 | |containing attributes of | 274 | |protocol specific | 275 | |response to return to UA | 276 | |------------------------>| (3) 277 | | | 278 | Protocol specific response (redirection)| 279 |<--------------------------------------------------| (4) 280 | | | 282 Figure 1: Generic Recursive Request Redirection message flow 284 1. The User Agent sends its request, either DNS request or HTTP 285 request, to CDN A. The Request Routing System of CDN A processes 286 the request and, through local policy, it recognizes that the 287 request is best served by another CDN, specifically CDN B (or 288 that CDN B is one of a number of candidate dCDNs it could use). 290 2. The Request Routing System of CDN A sends an HTTP POST to CDN B's 291 RI URI containing the attributes of the User Agent's request. 293 3. The Request Routing System of CDN B processes the request and 294 assuming the request is well formed, etc. responds with an HTTP 295 "200" response with a message body containing the RT(s) to return 296 to the User Agent as well as parameters that indicate the 297 properties of the response (cacheability and scope). 299 4. The Request Routing System of CDN A sends a protocol specific 300 response (containing the returned attributes) to the User Agent, 301 so that the User Agent's request will be redirected to the RT(s) 302 returned by CDN B. 304 4.1. Information passed in RI requests & responses 306 The information passed in RI requests splits into two basic 307 categories: 309 1. The attributes of the User Agent's request to the upstream CDN. 311 2. Properties/parameters that the uCDN can use to control the dCDN's 312 response or that can help the dCDN make its decision. 314 To assist the routing decision of a Downstream CDN, the Upstream CDN 315 shall convey as much information as possible to the Downstream CDN, 316 for example the URI of the requested content and the User Agent's 317 location information, when those are known by the uCDN Request 318 Routing system. 320 In order for the Downstream CDN to determine whether it is capable of 321 delivering any requested content, it requires CDNI metadata related 322 to the content the User Agent is requesting. That metadata will 323 describe the content and any policies associated with it. It is 324 expected that the RI request contains sufficient information for the 325 Request Router in the Downstream CDN to be able to retrieve the 326 require CDNI Metadata via the CDNI Metadata interface. 328 The information passed in RI responses splits into two basic 329 categories: 331 1. The attributes of the RT to return to the User Agent in the DNS 332 response or HTTP response. 334 2. Parameters/policies that indicate the properties of the response, 335 such as, whether it is cacheable, the scope of the response, etc. 337 In addition to details of how to redirect the User Agent, the 338 Downstream CDN may wish to return additional policy to the Upstream 339 CDN to help the Upstream CDN with future RI requests. For example 340 the Downstream CDN may wish to return a policy that expresses "this 341 response can be reused without requiring a RI request for 60 seconds 342 provided the User Agent's IP address is in the range 192.0.2.0 - 343 192.0.2.255". 345 These additional policies split into two basic categories: 347 o An indication of the cacheability of the response carried in the 348 HTTP response headers (to reduce the number of subsequent RI 349 requests the uCDN needs to make). 351 o The scope of the response (if it is cacheable) carried within the 352 body of the HTTP response. For example whether the response 353 applies to a wider range of IP addresses than what was included in 354 the RI request. 356 The cacheability of the response is indicated using the standard HTTP 357 Cache-Control mechanisms. 359 4.2. JSON encoding of RI requests & responses 361 The body of RI requests and responses is a JSON object containing a 362 dictionary of keys. Keys MUST always be encoded in lowercase. 363 Unknown keys MUST be ignored but the response MUST NOT be considered 364 invalid unless the syntax of the request is invalid. 366 The following keys are defined: 368 +------------+------------------+-----------------------------------+ 369 | Key | Request/Response | Description | 370 +------------+------------------+-----------------------------------+ 371 | dns | Both | The attributes of the UA's DNS | 372 | | | request or the attributes of the | 373 | | | RT(s) to return in a DNS | 374 | | | response. | 375 | http | Both | The attributes of the UA's HTTP | 376 | | | request or the attributes of the | 377 | | | RT to return in a HTTP response. | 378 | scope | Response | The scope of the response (if it | 379 | | | is cacheable). For example | 380 | | | whether the response applies to a | 381 | | | wider range of IP addresses than | 382 | | | what was included in the RI | 383 | | | request. | 384 | error | Response | Additional details if the | 385 | | | response is an error response. | 386 | cdn-path | Both | A List of Strings. Contains the | 387 | | | CDN Provider IDs of previous CDNs | 388 | | | this RI request has passed | 389 | | | through. When cascading a RI | 390 | | | request the transit CDN appends | 391 | | | its own CDN Provider ID to the | 392 | | | list in cdn-path so that | 393 | | | downstream CDNs can detect loops | 394 | | | in the RI request chain. Transit | 395 | | | CDNs should check the cdn-path | 396 | | | and not cascade the RI request to | 397 | | | downstream CDNs that are already | 398 | | | listed in cdn-path. The cdn-path | 399 | | | MUST be reflected back in RI | 400 | | | responses. | 401 | max-hops | Request | Integer specifying the Maximum | 402 | | | Number of hops (CDN Provider IDs) | 403 | | | this request is allowed to be | 404 | | | propagated along. This allows the | 405 | | | uCDN to crudely constrain the | 406 | | | latency of the request routing | 407 | | | chain. | 408 +------------+------------------+-----------------------------------+ 410 Top-Level keys in RI requests/responses 412 A single request or response MUST contain only one of the dns or http 413 keys. Requests MUST contain a cdn-path key. 415 [[Editor's note: Need some text/section specifying the Media Types 416 for RI requests/responses]] 418 [[Editor's note: Need some text on minimum attributes to be able to 419 (at least parse) - e.g. A/AAAA/CNAME, etc)]] 421 [[Editor's note: Need section detailing format/etc for scope and 422 error keys]] 424 Note: All implementations MUST support IPv4 addresses encoded as 425 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and 426 MUST support all IPv6 address formats specified in [RFC4291]. Server 427 implementations SHOULD use IPv6 address formats specified in 428 [RFC5952]. 430 4.3. DNS redirection 432 The following sections provide more detailed descriptions of the 433 information that should be passed in RI requests and responses for 434 DNS redirection. 436 4.3.1. DNS Redirection requests 438 For DNS based redirection the uCDN needs to pass the following 439 information to the dCDN in the RI request: 441 o The IP address of the DNS resolver that made the DNS request to 442 the Upstream CDN. 444 o The type of DNS query made (A, AAAA, RCODEs, etc.). 446 o The class of DNS query made (usually IN). [[Editor's Note: Do we 447 need to include class or can we always assume it is IN?]] 449 o The fully qualified domain name for which DNS redirection is being 450 requested. 452 o The IP address or prefix of the User Agent (if known to the 453 Upstream CDN, e.g. through draft-vandergaast-edns-client-subnet). 455 The information above is encoded as a set of key:value pairs within 456 the dns dictionary as follows: 458 +---------------+---------+-----------+-----------------------------+ 459 | Key | Value | Mandatory | Description | 460 +---------------+---------+-----------+-----------------------------+ 461 | resolver-ip | String | Yes | The IP address of the UA's | 462 | | | | DNS resolver. | 463 | qtype | String | Yes | The type of DNS query made | 464 | | | | by the UA's DNS resolvers | 465 | | | | in uppercase (A, AAAA, | 466 | | | | etc.). | 467 | qclass | String | Yes | The class of DNS query made | 468 | | | | in uppercase (IN, etc.). | 469 | qname | String | Yes | The fully qualified domain | 470 | | | | name being queried. | 471 | c-subnet | String | No | The IP address of the UA in | 472 | | | | CIDR format. | 473 | dns-only | Boolean | No | If True then dCDN MUST only | 474 | | | | use DNS redirection to a | 475 | | | | surrogate and MUST include | 476 | | | | the dns-only property set | 477 | | | | to True on any cascaded RI | 478 | | | | requests. Defaults to | 479 | | | | False. | 480 +---------------+---------+-----------+-----------------------------+ 482 An example RI request (uCDN->dCDN) for DNS based redirection: 484 POST /dcdn/ri HTTP/1.1 485 Host: rr1.dcdn.example.net 486 Accept: application/vnd.cdni.ri.response+json 488 { 489 "dns" : { 490 "resolver-ip" : "192.0.2.1", 491 "c-subnet" : "198.51.100.0/24", 492 "qtype" : "A", 493 "qclass" : "IN", 494 "qname" : "www.example.com" 495 }, 496 "cdn-path": ["AS65551:0"], 497 "max-hops": 3 498 } 500 4.3.2. DNS Redirection responses 502 For DNS based redirection the dCDN needs to return one of the 503 following to the uCDN in the RI response: 505 o The IP address of (or a CNAME to) the RT (if the dCDN is 506 performing DNS based redirection); or 508 o The IP address of (or a CNAME to) a RT which is a Request Router 509 (if the dCDN is performing HTTP based redirection). 511 The information above is encoded as a set of key:value pairs within 512 the dns dictionary as follows: 514 +---------+-------------+-------------+-----------------------------+ 515 | Key | Value | Mandatory | Description | 516 +---------+-------------+-------------+-----------------------------+ 517 | rcode | Integer | Yes | DNS response code. | 518 | name | String | Yes | The fully qualified domain | 519 | | | | name the response relates | 520 | | | | to. | 521 | a | List of | No | Set of IPv4 Addresses of | 522 | | String | | RT(s). | 523 | aaaa | List of | No | Set of IPv6 Addresses of | 524 | | String | | RT(s). | 525 | cname | List of | No | Set of fully qualified | 526 | | String | | domain names of RT(s). | 527 | ttl | Integer | No | TTL of DNS response. | 528 | | | | Default is 0. | 529 +---------+-------------+-------------+-----------------------------+ 531 Response must contain at least one of a, aaaa, cname. 533 An example of a successful RI response (dCDN->uCDN) for DNS based 534 redirection: 536 [[Editor's note: Currently shows both A/AAAA & CNAME in single 537 response, need to split to show the different use cases]] 539 HTTP/1.1 200 OK 540 Date: Mon, 06 Aug 2012 18:41:38 GMT 541 Content-Type: application/vnd.cdni.ri.response+json 543 { 544 "dns" : { 545 "rcode" : 0, 546 "name" : "www.example.com", 547 "a" : ["192.0.2.200", "192.0.2.201"], 548 "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"], 549 "cname" : ["rr1.dcdn.example", 550 "rr2.dcdn.example"], 551 "ttl" : 60 552 } 553 } 555 4.4. HTTP Redirection 557 The following sections provide more detailed descriptions of the 558 information that should be passed in RI requests and responses for 559 HTTP redirection. 561 4.4.1. HTTP Redirection requests 563 For HTTP based redirection the uCDN MUST pass the following 564 information to the dCDN in the RI request: 566 o The IP address of the User Agent. 568 o The URL requested by the User Agent. 570 The uCDN MAY also pass additional information to the dCDN in the RI 571 request, such as: 573 o The HTTP method or version number of the User Agent's request. 575 o Additional HTTP header included in the User Agent request. 577 The information above is encoded as a set of key:value pairs within 578 the http dictionary as follows: 580 +------------------+---------+-----------+--------------------------+ 581 | Key | Value | Mandatory | Description | 582 +------------------+---------+-----------+--------------------------+ 583 | c-ip | String | Yes | The IP address of the | 584 | | | | UA/client | 585 | cs-uri | String | Yes | The URI requested by the | 586 | | | | UA/client. | 587 | cs() | String | No | The contents of the HTTP | 588 | | | | header named | 589 | | | | as a | 590 | | | | string, for example | 591 | | | | cs(Cookie) would contain | 592 | | | | the content of the HTTP | 593 | | | | Cookie: header. Two | 594 | | | | special s | 595 | | | | are defined: cs(Method) | 596 | | | | and cs(HTTP-Version) | 597 | | | | which contain the | 598 | | | | contents of the Method & | 599 | | | | HTTP-Version parts of | 600 | | | | the Request-Line as | 601 | | | | defined in Section 5.1 | 602 | | | | of [RFC2616]. | 603 +------------------+---------+-----------+--------------------------+ 605 An example RI request (uCDN->dCDN) for HTTP based redirection: 607 POST/dcdn/rrri HTTP/1.1 608 Host: rr1.dcdn.example.net 609 Accept: application/vnd.cdni.rrri.response+json 611 { 612 "http": { 613 "c-ip": "198.51.100.1", 614 "cs-uri": "http://www.example.com" 615 }, 616 "cdn-path": ["AS65551:0"], 617 "max-hops": 3 618 } 620 4.4.2. HTTP Redirection responses 622 For HTTP based redirection the dCDN needs to return one of the 623 following to the uCDN in the RI response: 625 o A URL pointing to the selected RT (if the dCDN is redirecting the 626 User Agent directly to a surrogate); or 628 o A URL pointing to a RT which is a Request Router (if the dCDN is 629 not redirecting the User Agent directly to a surrogate). 631 The information above is encoded as a set of key:value pairs within 632 the http dictionary as follows: 634 +--------------------+----------+-----------+-----------------------+ 635 | Key | Value | Mandatory | Description | 636 +--------------------+----------+-----------+-----------------------+ 637 | sc-status | Integer | Yes | The status code of | 638 | | | | the HTTP response to | 639 | | | | return to the UA | 640 | | | | (usually 302). | 641 | cs-uri | String | Yes | The URI requested by | 642 | | | | the UA/client. | 643 | sc-location | String | Yes | The contents of the | 644 | | | | Location header to | 645 | | | | return to the UA | 646 | | | | (i.e. a URI pointing | 647 | | | | to the RT(s)). | 648 | sc-cache-control | String | No | The contents of the | 649 | | | | Cache-Control header | 650 | | | | to return to the UA. | 651 +--------------------+----------+-----------+-----------------------+ 653 [[Editor's Note: Should we change the format above to align with the 654 cs() format for headers on the RI request and allow the dCDN to 655 signal back any headers it wants in the response as sc()? 656 How to handle sc-status in that case - as a "special" header or 657 separate key? Probably need to give some advice on HTTP headers the 658 uCDN may want to override/not pass through, e.g. Server:?]] 660 An example of a successful RI response (dCDN->uCDN) for HTTP based 661 redirection: 663 HTTP/1.1 200 OK 664 Date: Mon, 06 Aug 2012 18:41:38 GMT 665 Content-Type: application/vnd.cdni.ri.response+json 667 { 668 "http": { 669 "sc-status": 302, 670 "cs-uri": "http://www.example.com" 671 "sc-location": 672 "http://sur1.dcdn.example/ucdn/example.com", 673 "sc-cache-control" : "public, max-age=30" 674 } 675 } 677 4.5. Indicating the cacheability and scope of responses 679 [[Editor's note: Need to expand text a little.]] 681 Cacheability is via the standard HTTP Cache-Control mechanisms. 683 Scope is encoded as a set of key:value pairs within the scope 684 dictionary as follows: 686 +-----------+----------+------------+-------------------------------+ 687 | Key | Value | Mandatory | Description | 688 +-----------+----------+------------+-------------------------------+ 689 | iprange | List of | No | A List of IP subnets in CIDR | 690 | | String | | notation that this RI | 691 | | | | response can be reused for, | 692 | | | | provided the RI response is | 693 | | | | still considered fresh. | 694 +-----------+----------+------------+-------------------------------+ 696 If a uCDN has multiple cached responses with overlapping scopes, 697 longest prefix matching of the User Agent's IP against the IP subnets 698 in the scope of each response SHOULD be used to select the most 699 appropriate RI response to use. [[Editor's note: is this always 700 true? What about the most recent response, should that override 701 older ones for the overlappign scope?]] 703 Example of DNS redirection response from Section 4.3.2 that is 704 cacheable by the uCDN for 60 seconds and can be returned to any User 705 Agent with an IPv4 address in 198.51.100.0/16. 707 HTTP/1.1 200 OK 708 Date: Mon, 06 Aug 2012 18:41:38 GMT 709 Content-Type: application/vnd.cdni.ri.response+json 710 Cache-Control: public, max-age=60 712 { 713 "dns" : { 714 "rcode" : 0, 715 "name" : "www.example.com", 716 "a" : ["192.0.2.200", "192.0.2.201"], 717 "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"], 718 "cname" : ["rr1.dcdn.example", 719 "rr2.dcdn.example"], 720 "ttl" : 60 721 } 722 "scope" : { 723 "iprange" : ["198.51.100.0/16"] 724 } 725 } 727 Example of HTTP redirection response from Section 4.4.2 that is 728 cacheable by the uCDN for 60 seconds and can be returned to any User 729 Agent with an IPv4 address in 198.51.100.0/16. 731 HTTP/1.1 200 OK 732 Date: Mon, 06 Aug 2012 18:41:38 GMT 733 Content-Type: application/vnd.cdni.ri.response+json 734 Cache-Control: public, max-age=60 736 { 737 "http": { 738 "sc-status": 302, 739 "cs-uri": "http://www.example.com" 740 "sc-location": 741 "http://sur1.dcdn.example/ucdn/example.com", 742 "sc-cache-control" : "public, max-age=30" 743 } 744 "scope" : { 745 "iprange" : ["198.51.100.0/16"] 746 } 747 } 749 4.6. Error responses 751 [[Editor's note: Probably need more explanation & examples of errors 752 that shouldn't be propagated to the User Agent?]] 754 RI error response examples. 756 RI error response (dCDN->uCDN) for DNS based User Agent requests: 758 HTTP/1.1 500 Server Error 759 Date: Mon, 06 Aug 2012 18:41:38 GMT 760 Content-Type: application/vnd.cdni.rrri.error+json 761 Cache-Control: private, no-cache 763 { 764 "dns" : { 765 "rcode" : 4 # DNS response code (e.g. 766 # doesn't support AAAA) 767 "name" : "www.example.com", # domain name response 768 # relates to 769 }, 770 "error" : { 771 "code" : TBD, # Give each error type its 772 # own numeric code 773 "description" : # Give more informative 774 "IPv6/AAAA queries are not supported" # description than just 775 } # protocol specific error 776 # codes 777 } 779 RI error response (dCDN->uCDN) for HTTP based User Agent requests: 781 HTTP/1.1 500 Server Error 782 Date: Mon, 06 Aug 2012 18:41:38 GMT 783 Content-Type: application/vnd.cdni.rrri.error+json 784 Cache-Control: private, no-cache 786 { 787 "http": { 788 "rcode": 400, # HTTP response code 789 "url": "http://www.example.com", # URL response 790 # relates to 791 } 792 "error" : { 793 "code" : TBD, # Give each error type its 794 # own numeric code 795 "description" : TBD # Give more informative 796 # description than just 797 } # protocol specific error 798 # codes 799 } 801 4.7. Loop detection & prevention 802 In order to prevent and detect RI request loops, each CDN MUST insert 803 its CDN Provider ID into the cdn-path key of every RI request it 804 originates or cascades. When receiving RI requests a dCDN should 805 check the cdn-path and reject any RI requests which already contain 806 the downstream CDN's Provider ID in the cdn-path. Transit CDNs 807 should check the cdn-path and not cascade the RI request to 808 downstream CDNs that are already listed in cdn-path. CDNs MUST NOT 809 propagate to any downstream CDNs if the number of CDN Provider IDs in 810 cdn-path (including the CDN's own Provider ID) is equal to or greater 811 than max-hops. 813 The CDN Provider ID uniquely identifies each CDN provider during the 814 course of request routing redirection. It consists of the the 815 characters AS followed by the CDN Provider's AS number, then a colon 816 (':') and an additional qualifier that is used to guarantee 817 uniqueness in case a particular AS has multiple independent CDNs 818 deployed. For example "AS65551:0". 820 If a downstream CDN receives a RI request whose cdn-path already 821 contains that downstream CDN's Provider ID the downstream CDN MUST 822 send a RI response with an error code of [[TBD]]. 824 It should be noted that the loop detection & prevention mechanisms 825 described above only cover preventing and detecting loops within the 826 RI itself. In the cases where the IP address(es) or URI(s) returned 827 in RI responses do not resolve directly to a surrogate in the final 828 dCDN it is also possible to have redirection loops where Request 829 Routers in different CDNs direct User Agents in a loop. 831 5. Security Considerations 833 [[Editor's note: Not sure if this current text is really security 834 considerations or whether it is better placed elsewhere in the 835 document.]] 837 In HTTP based Recursive Request Redirection, the end user's web 838 browsers will not send cookies if the content request is redirected 839 to a URL in a different domain rather than the original CP's domain, 840 e.g. the Downstream CDN's domain. If the browser is expected to 841 send any cookies associated with the original CP's domain, this will 842 cause problem that the CP's policy is not enforced by the CDN. 844 The section 5.2 of draft [I-D.peterson-cdni-strawman] has discussed a 845 similar question and given a solution. 847 6. IANA Considerations 849 This document makes no request of IANA. 851 7. Acknowledgements 853 The authors would like to thank Ray Brandenburg, Taesang Choi, 854 Francois le Faucheur and Scott Wainner for their valuable comments 855 and input to this document. 857 8. Outstanding considerations 859 Along with the various Editor's notes in the document, the following 860 items still need to be addressed: 862 o What extra properties/fields are required to cover all DNS/HTTP 863 redirection cases? 865 o Do we need Queries other than A/AAAA & response other than A/AAAA/ 866 CNAME? 868 o Response scopes other than IP address? (AS? URL match?) 870 o Better Security Considerations section. 872 o Description/specification for how to extend the protocol with 873 additional optimonal parameters/attributes. 875 9. Contributing Authors 877 [RFC Editor Note: Please move the contents of this section to the 878 Authors' Addresses section prior to publication as an RFC.] 880 Spencer Dawkins 881 Huawei 883 Email: spencer@wonderhamster.org 885 Yunfei Zhang 887 Email: hishigh@gmail.com 889 10. References 891 10.1. Normative References 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, March 1997. 896 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 897 Resource Identifier (URI): Generic Syntax", STD 66, RFC 898 3986, January 2005. 900 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 901 Architecture", RFC 4291, February 2006. 903 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 904 Address Text Representation", RFC 5952, August 2010. 906 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 907 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 908 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 910 10.2. Informative References 912 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 913 Distribution Network Interconnection (CDNI) Problem 914 Statement", RFC 6707, September 2012. 916 [I-D.ietf-cdni-framework] 917 Peterson, L. and B. Davie, "Framework for CDN 918 Interconnection", draft-ietf-cdni-framework-03 (work in 919 progress), February 2013. 921 [I-D.ietf-cdni-requirements] 922 Leung, K. and Y. Lee, "Content Distribution Network 923 Interconnection (CDNI) Requirements", draft-ietf-cdni- 924 requirements-05 (work in progress), February 2013. 926 [I-D.peterson-cdni-strawman] 927 Peterson, L. and J. Hartman, "A Simple Approach to CDN 928 Interconnection", draft-peterson-cdni-strawman-01 (work in 929 progress), May 2011. 931 Authors' Addresses 933 Wang Danhua (editor) 934 Huawei Technologies 935 No. 101 Software Avenue 936 Nanjing, Jiangsu Province 210001 937 P.R.China 939 Phone: +86-25-56624734 940 Fax: +86-25-56624702 941 Email: wangdanhua@huawei.com 942 Ben Niven-Jenkins (editor) 943 Velocix (Alcatel-Lucent) 944 3 Ely Road 945 Milton, Cambridge CB24 6DD 946 UK 948 Email: ben@velocix.com 950 He Xiaoyan 951 Huawei 952 B2, Huawei Industrial Base 953 518129 954 P.R.China 956 Email: hexiaoyan@huawei.com 958 Ge Chen 959 China Telecom 960 109 West Zhongshan Ave,Tianhe District 961 Guangzhou 962 P.R. China 964 Email: cheng@gsta.com 966 Ni Wei 967 China Mobile 968 No.32 Xuanwumen West Street Xicheng District 969 Beijing 100053 970 P.R. China 972 Email: niwei@chinamobile.com