idnits 2.17.1 draft-choi-cdni-req-routing-redir-loop-prevention-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 : ---------------------------------------------------------------------------- == There are 17 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2012) is 4199 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: 'RFC2119' is mentioned on line 97, but not defined == Missing Reference: 'I-D.ietf-cdni-framework' is mentioned on line 737, but not defined == Unused Reference: 'KEYWORDS' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'I-D.davie-cdni-framework' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-problem-statement' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 804, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-davie-cdni-framework (ref. 'I-D.davie-cdni-framework') ** Downref: Normative reference to an Informational draft: draft-ietf-cdni-requirements (ref. 'I-D.ietf-cdni-requirements') Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT TS Choi 3 Intended Status: Standards Track ETRI 4 Expires: April 24, 2013 YI Seo 5 DJ Kim 6 KT 7 JM Lee 8 SKT 9 JR Koo 10 LGU+ 11 JDH Shinn 12 Solbox Inc. 13 KS Park 14 KAIST 15 October 21, 2012 17 CDNi Request Routing Redirection with Loop Prevention 18 draft-choi-cdni-req-routing-redir-loop-prevention-01 20 Abstract 22 This document describes request routing redirection procedures, loop 23 prevention mechanisms, and other operational considerations which are 24 associated with redirection. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 29, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Redirection Procedures . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Iterative Redirection Procedures . . . . . . . . . . . . . 4 65 2.2.1. HTTP-based Redirection . . . . . . . . . . . . . . . . 4 66 2.2.2. DNS-based Redirection . . . . . . . . . . . . . . . . 8 67 2.3. Recursive Redirection Procedures . . . . . . . . . . . . . 10 68 2.3.1. HTTP-based Redirection . . . . . . . . . . . . . . . . 10 69 2.3.2. DNS-based Redirection . . . . . . . . . . . . . . . . 14 70 3. Redirection Loop Prevention . . . . . . . . . . . . . . . . . 17 71 4. Redirection Operational Considerations . . . . . . . . . . . . 18 72 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 73 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 74 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 7.1 Normative References . . . . . . . . . . . . . . . . . . . 19 76 7.2 Informative References . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 79 1 Introduction 81 According to the CDNi generic and request routing interface 82 requirements[I-D.ietf-cdni-requirements], the CDNi solution shall 83 support iterative and recursive CDNi request routing, efficient 84 request routing for small and large objects, arbitrary number of 85 levels of cascaded CDN redirection, looping prevention of any CDN 86 request routing redirection, and subsequently allowing the request 87 routing redirection. To meet such requirements, this document 88 describes request routing redirection procedures, loop prevention 89 mechanisms, and other operational considerations that are associated 90 with redirection. 92 1.1 Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Redirection Procedures 100 2.1. Preliminaries 102 To meet the requirements of request routing redirection, we define 103 the term "CDN-Provider-ID". It uniquely identifies each CDN provider 104 during the course of request routing redirection. It consists of 105 "CDN provider name" and "MaxNumRedHops". A pair of an AS number and 106 an additional qualifier is used for CDN provider name. Since more 107 than one CDN providers can belong to the same AS, an additional 108 qualifier is used to guarantee the uniqueness. MaxNumRedHops 109 represents a maximum allowed redirections. The value is decreased 110 once every redirection occurs until it reaches 0. To avoid its usage 111 abuse (e.g., end user or CDN operator can set huge number like 100 or 112 above), a reasonable upper bound has to be agreed among CDN 113 providers. Security aspect of it is for further study. 115 A few examples of the CDN provider names are 100:0 and 200:1. The 116 former means that a CDN provider belong to AS 100 and it is the only 117 CDN provider within that AS. The latter represents the first CDN 118 provider in the AS 200. There are other CDN providers in the same 119 AS. 121 One example of CDN-Provider-ID is "CDN-Provider-Name=100:0 & 122 MaxNumRedHops=10", which means that a CDN provider that belong to AS 123 number 100 and it is the only CDN provider and a maximum allowed 124 redirection is 10. An example how a list of CDN-Provider-IDs can be 125 carried in the URI query string when a certain cascaded request 126 routing redirection occurs is the following. We assume that 127 redirection is cascaded three times: uCDN -> dCDN1 -> dCDN2. dCDN1, 128 then, carries the following URL, "http://cdn.csp.com?uCDN-Provider- 129 ID=100:0&dCDN1-Provider-ID=200:1&MaxNumRedHops=9". Note that 130 MaxNumbRedHops carries the latest number instead of adding in every 131 CDN-Provider-ID to save the space in URI query string. 133 It is applicable for both HTTP-based and DNS redirections. For HTTP- 134 based redirection, we define a HTTP request routing redirection 135 header "CDN-Provider-ID". For each step of redirection, it is 136 attached to the beginning of the provider domain URL. For example, 137 uCDN initiates a redirection with its URL, 138 http://100:0:10.cdn.csp.com. dCDN further attaches its own CDN- 139 Provider-ID in the front when another level of redirection is 140 required. For DNS-based redirection, the CDN-Provider-ID can be 141 attached in the DNS CNAME. 143 Since there is a CDNi requirement to support of arbitrary topology of 144 interconnected CDNs, this document assumes that the redirection 145 procedures and loop prevention mechanisms must also support arbitrary 146 topology. 148 2.2. Iterative Redirection Procedures 150 2.2.1. HTTP-based Redirection 152 In this section, we describe an iterative procedure of HTTP-based 153 request routing redirection with loop prevention. 155 End-User dCDNn dCDNn-1 dCDN1 uCDN 156 |DNS cdn.csp.com | | | | 157 |------------------------------------------------------->| 158 | | | | |(1) 159 |IPaddr of uCDN's Request Router | | | 160 |<-------------------------------------------------------| 161 |HTTP cdn.csp.com | | } | 162 |------------------------------------------------------->| 163 | | | | |(2) 164 |302 peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | 165 |<-------------------------------------------------------| 166 |DNS peer-uCDN.dCDN1.net | | | 167 |-------------------------------------------->| | 168 | | | |(3) | 169 |IPaddr of dCDN1's Request Router| | | 170 |<--------------------------------------------| | 171 | | | | | 172 |HTTP peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | 173 |-------------------------------------------->| | 174 | | | |(4) | 175 |302 peer-dCDN1.dCDN2.net/cdn.csp.com?dCDN1-Provider-ID | 176 |<--------------------------------------------| | 177 | | | | | 178 | | ....... |(5) | 179 | | | | | 180 |302 peer-dCDNn-1.dCDNn.net/cdn.csp.com?dCDNn-1-Provider-ID 181 |<-------------------------------| | | 182 | | | | | 183 |DNS peer-dCDNn-1.dCDNn.net | | | 184 |------------------------------->| | | 185 | | |(6) | | 186 |IPaddr of dCDNn's Request Router| | | 187 |<-------------------------------| | | 188 | | | | | 189 |HTTP peer-dCDNn-1.dCDNn.net/cdn.csp.com | | 190 |------------------------------->| | | 191 | | |(7) | | 192 |302 node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com | | 193 |<-------------------------------| | | 194 | | | | | 195 |DNS node1.peer-dCDNn-1.dCDNn.net| | | 196 |------------------>| | | | 197 | | |(8) | | 198 |IPaddr of dCDNn's Delivery Node } | | 199 |<------------------| | | | 200 | | | | | 201 |HTTP node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com| | 202 |------------------>| | | | 203 | |(9) | | | 204 | |DNS dCDNn-acq.dCDNn-1.net| | 205 | |----------->| | | 206 | | |(10) | | 207 | |IPaddr of dCDNn-1's Request Router | 208 | |<-----------| | | 209 | |HTTP dCDNn-acq.dCDNn-1.net?dCDNn-Provider-ID 210 | |----------->| | | 211 | | |(11) | | 212 | | | ....... | | 213 | | | | | 214 | |HTTP dCDN1-acq.uCDN.net?dCDN1-Provider-ID 215 | | | |--------->| 216 | | | | |(12) 217 | | |302 node2.dCDN1.acq.uCDN.net 218 | | | |<---------| 219 | | |DNS node2.dCDN1-acq.uCDN.net 220 | | | |--------->| 221 | | | | |(13) 222 | | |IPaddr of uCDN's Delivery Node 223 | | | |<---------| 224 | | | | |(14) 225 | | | | Data | 226 | | | |<---------| 227 | | | ....... | | 228 |Data | | | | 229 |<------------------| | | | 231 Figure 1: HTTP-based request routing redirection iterative procedure 233 The steps illustrated in the figure are as follows: 235 1. A DNS resolver for uCDN provider processes the DNS request for 236 its customer based on CDN-domain cdn.csp.com. It returns the IP 237 address of a request router in uCDN provider. 239 2. A Request Router for uCDN provider processes the HTTP request 240 and recognizes that the end-user is best served by dCDN1. So it 241 returns a 302 redirect message for a new URL constructed by 242 "stacking" dCDN1's distinguished CDN-domain (peer- 243 uCDN.dCDN1.net) on the front of the original URL. It also adds 244 uCDN's CDN-Provider-ID in the URI query string of the HTTP 245 request message. (e.g., uCDN-Provider-ID=100:0 & 246 MaxNumRedHops=10). This information is not processed by the 247 customer but conveyed in the HTTP message without any 248 modification of the step 4. The details on how it is used for 249 loop prevention is described in the step 4. 251 3. The end-user does a DNS lookup using dCDN1's distinguished 252 CDN-domain (peer-uCDN.dCDN1.net). dCDN1's DNS resolver returns 253 the IP address of a request router for dCDN1. 255 4. The request router for dCDN1 processes the HTTP request. There 256 are two options: redirect further to another dCDN (i.e., 257 cascading the request) or process it by itself. In either 258 cases, it performs loop prevention step first. It checks a list 259 of CDN-provider-IDs in the URI query string: it contains a list 260 of CDN providers which requested redirections so far. If either 261 it contains own CDN provider name or MaxNumRedHops becomes 0, it 262 means that the redirection loop has occurred or the number of 263 redirection hops has reached the maximum. Once loop is 264 detected, details on the next steps is described in the section 265 3. If it is loop free, it either redirects further or processes 266 based on the local policy. For the former, it selects another 267 dCDN provider and and sends an HTTP redirect message with its 268 own CDN-Provider-ID included in its URI query string (e.g., 269 uCDN-Provider-ID=100:0 & dCDN1-Provider-ID=200:1 & 270 MaxNumRedHops=9) attached. For the latter, it selects a 271 suitable delivery node to serve the end-user request, and 272 returns a 302 redirect message for a new URL constructed by 273 replacing the hostname by a subdomain of the dCDN1's 274 distinguished CDN-domain that points to the selected delivery 275 node. Then it goes to the step 6. 277 5. If further redirection is decided, it repeats steps 2 - 4 until 278 it either selects dCDN provider to serve the request or 279 MaxNumRedHops expires. If the former occurs, it resumes the 280 step 6. If the latter occurs, it follows the processes 281 described in the section 3. 283 6. Assuming that dCDNn is selected as a serving dCDN provider, the 284 end-user does a DNS lookup using dCDNn's distinguished 285 CDN-domain (peer-dCDNn-1.dCDNn.net). dCDNn-1's DNS resolver 286 returns the IP address of a request router for dCDNn. 288 7. The request router for dCDN1 processes the HTTP request and 289 selects a suitable delivery node to serve the end-user request, 290 and returns a 302 redirect message for a new URL constructed by 291 replacing the hostname by a subdomain of the dCDNn's 292 distinguished CDN-domain that points to the selected delivery 293 node. 295 8. The end-user does a DNS lookup using dCDNn's delivery node 296 subdomain (node1.peer-dCDNn-1.dCDNn.net). dCDNn's DNS resolver 297 returns the IP address of the delivery node. 299 9. The end-user requests the content from dCDNn's delivery node. 300 In the case of a cache hit, steps 10 ~ 14 below do not happen, 301 and the content data is directly returned by the delivery node 302 to the end-user. In the case of a cache miss, the content needs 303 to be acquired by dCDN from either parent dCDN or uCDN (not the 304 CSP). The distinguished CDN-domain peer-dCDNn-1.dCDNn.net 305 indicates that this content is to be acquired from dCDNn-1; 306 stripping the CDN-domain reveals the original CDN-domain 307 cdn.csp.com and dCDNn may verify that this CDN-domain belongs to 308 a known peer (so as to avoid being tricked into serving as an 309 open proxy). It then does a DNS request for an inter-CDN 310 acquisition CDN-domain as agreed above (in this case, dCDNn- 311 acq.dCDNn-1.net). This process repeats recursively until it 312 finds a CDN provider that can serve the requested content. 314 10. dCDNn-1's DNS resolver processes the DNS request and returns 315 the IP address of a request router in dCDNn-1. 317 11. The request router for dCDNn-1 processes the HTTP request from 318 dCDNn's delivery node. dCDNn-1 request router recognizes that 319 the request is from a peer CDN rather than an end-user because 320 of the dedicated inter-CDN acquisition domain 321 (dCDNn-acq.dCDNn-1.net). It also performs loop prevention 322 process as described in step 4 based on the provided CDN- 323 Provider-ID (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider- 324 ID=200:1 & ... & dCDNn-Provider-ID=1000:0 & MaxNumRedHops=1). 325 Depending on the number of levels of redirection and 326 availability of contents, the same process repeats until either 327 content serving CDN provider is found or MaxNumRedHps expires. 329 12. Assuming that all intermediate dCDNs also have a cache miss, 330 The request router for uCDN selects a suitable delivery node to 331 serve the inter-CDN acquisition request and returns a 302 332 redirect message for a new URL constructed by replacing the 333 hostname by a subdomain of the uCDN's distinguished inter-CDN 334 acquisition domain that points to the selected delivery node. 336 13. uCDN DNS resolver processes the DNS request and returns the IP 337 address of the delivery node in uCDN. 339 14. uCDN serves content for the requested CDN-domain to dCDN and 340 finally to end-user. Although not shown, it is at this point 341 that uCDN processes the rest of the URL: it extracts information 342 identifying the origin server, validates that this server has 343 been registered, and determines the content provider that owns 344 the origin server. It may also perform its own content 345 acquisition steps if needed before returning the content to 346 dCDN. 348 2.2.2. DNS-based Redirection 350 In this section, we describe an iterative procedure of DNS-based 351 request routing redirection with loop prevention. 353 End-User dCDNn dCDNn-1 dCDN1 uCDN 354 |DNS cdn.csp.com | | | | 355 |------------------------------------------------------->| 356 | | | | | 357 |CNAME uCDNProviderID.dCDN1.cdn.csp.com | |(1) 358 |NS records for dCDN1.cdn.csp.com| | | 359 |<-------------------------------------------------------| 360 |DNS dCDN1.cdn.csp.com | | | 361 |-------------------------------------------->| | 362 | | | | | 363 | | ....... |(2) | 364 | | | | | 365 |CNAME dCDN1.cdn.csp.com | | | 366 |NS records for dCDN1.cdn.csp.com| | | 367 |<-------------------------------| | | 368 |DNS dCDNn.cdn.csp.com | | | 369 |------------------>| | | | 370 | | |(3) | | 371 |IPaddr of dCDNn's Delivery Node } | | 372 |<------------------| | | | 373 | | | | | 374 |HTTP cdn.csp.com | | | | 375 |------------------>| | | | 376 | |(4) | | | 377 | |DNS dCDNn-acq.dCDNn-1.net| | 378 | |----------->| | | 379 | | | | | 380 | | | ....... |(5) | 381 | | | | | 382 | |DNS dCDN1 ProviderID.dCDN1-acq.uCDN.net 383 | | | |--------->| 384 | | | | |(6) 385 | | |IPaddr of uCDN's Delivery Node 386 | | | |<---------| 387 | | | | |(7) 388 | | | | Data | 389 | | | |<---------| 390 | | | ....... | | 391 |Data | | | | 392 |<------------------| | | | 394 Figure 2: DNS-based request routing redirection iterative procedure 396 The steps illustrated in the figure are as follows: 398 1. Request Router for uCDN provider processes the DNS request for 399 CDN- domain cdn.csp.com and recognizes that the end-user is best 400 served by another CDN. (This may depend on the IP address of the 401 user's local DNS resolver, or other information discussed below.) 402 The Request Router returns a DNS CNAME response by "stacking" the 403 distinguished identifier for dCDN1 and uCDN's CDN-Provider-ID 404 (e.g., 100:0.10) onto the original CDN-domain (e.g., 405 dCDN1.cdn.csp.com), plus an NS record that maps dCDN1.cdn.csp.com 406 to dCDN1's Request Router. 408 2. The end-user does a DNS lookup using the modified CDN-domain 409 (i.e., dCDN1.cdn.csp.com). dCDN1 Request Router processes the 410 request and decides to serve the request or redirect further to 411 another CDN provider. It also checks redirection loop. This 412 process iterates until either serving dCDN is selected or 413 MaxNumRedHops expires. In this case, dCDNn is selected as a 414 serving dCDN. If the former occurs, it proceeds to step 3. If 415 the latter occurs, it follows the processes described in the 416 section 3. 418 3. The end-user does a DNS lookup using the modified CDN-domain 419 (i.e., dCDN1.cdn.csp.com). This causes dCDNn's request router 420 returns an IP address of a suitable delivery node. 422 4. The end-user requests the content from dCDNn's delivery node. 423 In the case of a cache hit, steps 5 ~ 7 do not happen, and the 424 content data is directly returned by the delivery node to the 425 end-user. In the case of a cache miss, the content needs to be 426 acquired by dCDNn from either parent dCDN or uCDN (not the CSP). 427 It also performs loop prevention process as described in the step 428 2 based on the provided CDN-Provider-ID (e.g., 429 100:0.200:1.....900:0.1) 431 5. Depending on the number of levels of redirection and availability 432 of contents, the same process repeats until either content 433 serving CDN provider is found or MaxNumRedHps expires. 435 6. Assuming that all intermediate dCDNs also miss cache, uCDN is 436 selected as a content delivery CDN provider. Thus, the request 437 router for uCDN selects a suitable delivery node to serve the 438 inter-CDN acquisition request and returns IP address of the 439 suitable uCDN delivery node. 441 7. uCDN serves content to dCDN1 and further down to end-user. 442 Although not shown, it is at this point that uCDN processes the 443 rest of the URL: it extracts information identifying the origin 444 server, validates that this server has been registered, and 445 determines the content provider that owns the origin server. 447 2.3. Recursive Redirection Procedures 448 2.3.1. HTTP-based Redirection 450 In this section, we describe an recursive procedure of HTTP-based 451 request routing redirection with loop prevention. 453 End-User dCDNn dCDNn-1 dCDN1 uCDN 454 |DNS cdn.csp.com | | | | 455 |------------------------------------------------------->| 456 | | | | |(1) 457 |IPaddr of uCDN's Request Router | | | 458 |<-------------------------------------------------------| 459 |HTTP cdn.csp.com | | } | 460 |------------------------------------------------------->| 461 | | | | | 462 | RRI REQ cdn.csp.com | 463 | | | |<---------| 464 | | ....... | | 465 | |<-----------| | | 466 | RRI RESP node1.dCDNn.net |(2) | 467 | |----------->| | | 468 | | ....... | | 469 | RRI RESP node1.dCDNn.net | 470 | | | |--------->| 471 | | | | | 472 |302 node1.dCDNn.net/cdn.csp.com | | | 473 |<-------------------------------------------------------|(3) 474 | | | | | 475 |DNS node1.dCDNn.net| | | | 476 |------------------>| | | | 477 | |(4) | | | 478 |IPaddr of dCDNn's Delivery Node } | | 479 |<------------------| | | | 480 | | | | | 481 |HTTP node1.dCDNn.net/cdn.csp.com| | | 482 |------------------>| | | | 483 | |(5) | | | 484 | |DNS dCDNn-acq.dCDNn-1.net| | 485 | |----------->| | | 486 | | |(6) | | 487 | |IPaddr of dCDNn-1's Request Router | 488 | |<-----------| | | 489 | |HTTP dCDNn-acq.dCDNn-1.net?dCDNn ProviderID 490 | |----------->| | | 491 | | | | | 492 | | | ....... |(7) | 493 | | | | | 494 | |HTTP dCDN1-acq.uCDN.net?dCDN1 ProviderID 495 | | | |--------->| 496 | | | | |(8) 497 | | |302 node2.dCDN1.acq.uCDN.net 498 | | | |<---------| 499 | | |DNS node2.op-b-acq.op-a.net 500 | | | |--------->| 501 | | | | |(9) 502 | | |IPaddr of uCDN's Delivery Node 503 | | | |<---------| 504 | | | | |(10) 505 | | | | Data | 506 | | | |<---------| 507 | | | ....... | | 508 |Data | | | | 509 |<------------------| | | | 511 Figure 3: HTTP-based request routing redirection recursive procedure 513 The steps illustrated in the figure are as follows: 515 1. A DNS resolver for uCDN provider processes the DNS request for 516 its customer based on CDN-domain cdn.csp.com. It returns the IP 517 address of a request router in uCDN provider. 519 2. A Request Router for uCDN provider processes the HTTP request 520 and recognizes that the end-user is best served by dCDN1. So it 521 queries the CDNI Request Routing interface of dCDN1 providing a 522 set of information about the request including the URL 523 requested. It also provides uCDN's CDN-Provider-ID (e.g., uCDN- 524 Provider-ID=100:0 & MaxNumRedHops=10) for loop prevention 525 process. It contains a list of CDN providers that have 526 requested redirections so far. If either it contains its own 527 CDN provider name or MaxNumRedHops becomes 0, it means that the 528 redirection loop has occurred or it has reached the maximum 529 number of allowed number of redirection hops. Once loop is 530 detected, details on the next steps are described in the section 531 3. If it is loop free, dCDN1 then either replies with the DNS 532 name of a delivery node or redirect to another dCDN. Such 533 cascading redirection can continue until a serving dCDN is 534 decided. The RRI RESP can be sent in the reverse order of 535 cascaded redirection or directly to the redirection origin CDN 536 provider if contact information is known. The contact 537 information can be embedded in the RRI REQ message or pre- 538 configured during bootstrapping process. The default behavior is 539 recursive RESP. 541 3. uCDN returns a 302 redirect message for a new URL obtained from 542 the Request Routing Interface. 544 4. The end-user does a DNS lookup using the host name of the URL 545 just provided (node1.dCDNn.net). dCDNn's DNS resolver returns 546 the IP address of the corresponding delivery node. Note that, 547 since the name of the delivery node was already obtained from 548 dCDNn using the CDNI Request Routing Interface, there should not 549 be any further redirection here (in contrast to the iterative 550 method described above.) 552 4. The request router for dCDN1 processes the HTTP request. There 553 are two options: redirect further to another dCDN (i.e., 554 cascading the request) or process it by itself. In either 555 cases, it performs loop prevention step first. If it is loop 556 free, it either redirect further or processes based on the local 557 policy. For the former, it selects another dCDN provider and 558 and sends HTTP redirect message with it own CDN-Provider-ID 559 (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider-ID=200:1 & 560 MaxNumRedHops=9) attached. For the latter, it selects a 561 suitable delivery node to serve the end-user request, and 562 returns a 302 redirect message for a new URL constructed by 563 replacing the hostname by a subdomain of the dCDN1's 564 distinguished CDN-domain that points to the selected delivery 565 node. Then it goes to step 6. 567 5. The end-user requests the content from dCDNn's delivery node. 568 In the case of a cache hit, steps 6 ~ 10 below do not happen, 569 and the content data is directly returned by the delivery node 570 to the end-user. In the case of a cache miss, the content needs 571 to be acquired by dCDN from either parent dCDN or uCDN (not the 572 CSP). The distinguished CDN-domain dCDNn.net indicates that this 573 content is to be acquired from dCDNn-1; stripping the CDN-domain 574 reveals the original CDN-domain cdn.csp.com and dCDNn may verify 575 that this CDN-domain belongs to a known peer (so as to avoid 576 being tricked into serving as an open proxy). It then does a 577 DNS request for an inter-CDN acquisition CDN-domain as agreed 578 above (in this case, dCDNn-acq.dCDNn-1.net). This process 579 repeats recursively until it finds CDN provider that can serve 580 the requested content. 582 6. dCDNn-1's DNS resolver processes the DNS request and returns the 583 IP address of a request router in dCDNn-1. 585 7. The request router for dCDNn-1 processes the HTTP request from 586 dCDNn's delivery node. dCDNn-1 request router recognizes that 587 the request is from a peer CDN rather than an end-user because 588 of the dedicated inter-CDN acquisition domain 589 (dCDNn-acq.dCDNn-1.net). It also performs loop prevention 590 process as described in the step 2 based on the provided CDN- 591 Provider-ID (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider- 592 ID=200:1 & ... & dCDNn-1-Provider-ID=900:0 & MaxNumRedHops=1). 593 Depending on the number of levels of redirection and 594 availability of contents, the same process repeats until either 595 content serving CDN provider is found or MaxNumRedHps expires. 597 8. Assuming that all intermediate dCDNs also have a cache miss, The 598 request router for uCDN selects a suitable delivery node to 599 serve the inter-CDN acquisition request and returns a 302 600 redirect message for a new URL constructed by replacing the 601 hostname by a subdomain of the uCDN's distinguished inter-CDN 602 acquisition domain that points to the selected delivery node. 604 9. uCDN DNS resolver processes the DNS request and returns the IP 605 address of the delivery node in uCDN. 607 10. uCDN serves content for the requested CDN-domain to dCDN and 608 finally to end-user. Although not shown, it is at this point 609 that uCDN processes the rest of the URL: it extracts information 610 identifying the origin server, validates that this server has 611 been registered, and determines the content provider that owns 612 the origin server. It may also perform its own content 613 acquisition steps if needed before returning the content to 614 dCDN. 616 2.3.2. DNS-based Redirection 618 In this section, we describe an recursive procedure of DNS-based 619 request routing redirection with loop prevention. 621 End-User dCDNn dCDNn-1 dCDN1 uCDN 622 |DNS cdn.csp.com | | | | 623 |------------------------------------------------------->| 624 | | | | |(1) 625 | RRI REQ cdn.csp.com | 626 | | | |<---------| 627 | | ....... | | 628 | |<-----------| | | 629 | RRI RESP node1.dCDNn.net | | 630 | |----------->| | | 631 | | ....... | | 632 | RRI RESP node1.dCDNn.net | 633 | | | |--------->| 634 | | | | | 635 |CNAME dCDNn.cdn.csp.com | | | 636 |NS records for dCDNn.cdn.csp.com| | |(2) 637 |<-------------------------------------------------------| 638 | | | | | 639 |DNS dCDNn.cdn.csp.com | | | 640 |------------------>| | | | 641 | |(3) | | | 642 |IPaddr of dCDNn's Delivery Node } | | 643 |<------------------| | | | 644 | | | | | 645 |HTTP cdn.csp.com | | | | 646 |------------------>| | | | 647 | |(4) | | | 648 | |DNS dCDNn-acq.dCDNn-1.net| | 649 | |----------->| | | 650 | | | | | 651 | | | ....... |(5) | 652 | | | | | 653 | |DNS dCDN1 ProviderID.dCDN1-acq.uCDN.net 654 | | | |--------->| 655 | | | | |(6) 656 | | |IPaddr of uCDN's Delivery Node 657 | | | |<---------| 658 | | | | |(7) 659 | | | | Data | 660 | | | |<---------| 661 | | | ....... | | 662 |Data | | | | 663 |<------------------| | | | 665 Figure 4: DNS-based request routing redirection recursive procedure 667 The steps illustrated in the figure are as follows: 669 1. Request Router for uCDN provider processes the DNS request for 670 CDN-domain cdn.csp.com and recognizes that the end-user is best 671 served by dCDN1. So it queries the CDNI Request Routing 672 Interface of dCDN1 providing a set of information about the 673 request including the URL requested. It also provides uCDN's 674 CDN-Provider-ID (e.g., uCDN-Provider-ID=100:0 & MaxNumRedHops=10) 675 for loop prevention process. It checks CDN-Provider-ID. If 676 either it contains own CDN provider name or MaxNumRedHops becomes 677 0, it means that the redirection loop is occurred. Once loop is 678 detected, details on the next steps are described in the section 679 3. If it is loop-free, dCDN1 then either replies with the DNS 680 name of a delivery node or redirect to another dCDN. Such 681 cascaded redirection can continue until a serving dCDN is 682 decided. The RRI RESP can be sent in the reverse order of 683 cascaded redirection or directly to the redirection origin CDN 684 provider if contact information is known. The contact 685 information can be embedded in the RRI REQ message or pre- 686 configured during bootstrapping process. The default behavior is 687 recursive RESP In this case, dCDNn is selected as a serving dCDN. 689 2. The Request Router returns a DNS CNAME response by "stacking" the 690 distinguished identifier for dCDNn and uCDN's CDN-Provider-ID 691 onto the original CDN-domain (e.g., dCDN1.cdn.csp.com), plus an 692 NS record that maps dCDN1.cdn.csp.com to dCDN1's Request Router. 694 3. The end-user does a DNS lookup using the modified CDN-domain 695 (i.e., dCDN1.cdn.csp.com). This causes dCDNn's request router 696 returns an IP address of a suitable delivery node. 698 4. The end-user requests the content from dCDNn's delivery node. 699 In the case of a cache hit, steps 5 ~ 7 do not happen, and the 700 content data is directly returned by the delivery node to the 701 end-user. In the case of a cache miss, the content needs to be 702 acquired by dCDNn from either parent dCDN or uCDN (not the CSP). 703 It also performs loop prevention process as described in the step 704 2 based on the provided CDN-Provider-ID (e.g., uCDN-Provider- 705 ID=100:0 & dCDN1-Provider-ID=200:1 & ... & dCDNn-1-Provider- 706 ID=900:1 & MaxNumRedHops=1). 708 5. Depending on the number of levels of redirection and availability 709 of contents, the same process repeats until either content 710 serving CDN provider is found or MaxNumRedHps expires. 712 6. Assuming that all intermediate dCDNs also miss cache, uCDN is 713 selected as a content delivery CDN provider. Thus, the request 714 router for uCDN selects a suitable delivery node to serve the 715 inter-CDN acquisition request and returns IP address of the 716 suitable uCDN delivery node. 718 7. uCDN serves content to dCDN1 and further down to end-user. 719 Although not shown, it is at this point that uCDN processes the 720 rest of the URL: it extracts information identifying the origin 721 server, validates that this server has been registered, and 722 determines the content provider that owns the origin server. 724 3. Redirection Loop Prevention 726 According to the CDNi generic and request routing interface 727 requirements, the CDNi solution shall support loop prevention of any 728 CDN request routing redirection and subsequently allowing the request 729 routing redirection. To meet such requirements, this section 730 describes request routing redirection loop prevention mechanisms. 731 Loop prevention mechanism should support both detection of the loop 732 and post processing after loop detection. Also loop prevention 733 should be applicable for the process of redirection CDN provider 734 selection and inter CDN content acquisition. 736 This document specifies loop prevention mechanisms based on CDN- 737 Provider-ID. Framework document [I-D.ietf-cdni-framework] recommends 738 using distinguished acquisition domain for loop detection. It has 739 some drawbacks such as overheads caused by length and processing time 740 of domain name stacking in the case of cascading redirection This 741 document defines more general solution which can be applicable in 742 both HTTP-based and DNS-based redirections. CDN-Provider-ID which is 743 described in details in the section 2.1 is our proposed solution. 744 Unlike distinguished domain name which is proposed in the framework, 745 it is simple, unique, and efficient. 747 Post-processing after loop detection is also as important as its 748 detection. The most strict option is to deny the service when the 749 loop is detected. This option should the last resort when other 750 alternatives are not available. The simplest choice is the CDN 751 provider which detected the loop provide the service by itself 752 although the service quality may not be optimal. If it is not 753 possible, it requests its parent. If the parent can provide the 754 service, it does so. If not, it further checks with other dCDN 755 providers at the peer level or downstream until it finds available 756 one. If it all fails its attempts at the its parent, peer, and 757 children, it checks with uCDN. If note is available, it finally 758 rejects the service. 760 4. Redirection Operational Considerations 762 For efficient request routing redirection, various operational 763 considerations need to be addressed. In the framework document, for 764 the redirection selection criteria, CDNi uses end-user's IP address 765 prefix. However, in real CDN service environments, there are various 766 other reasons such as service availability, QoS requirements, 767 resource faults, etc. Both Routing Request Interface and redirection 768 request should allow exchange of such information. The type and 769 details of information that can be exchanged among CDN providers for 770 the efficient redirection has to be considered together with 771 footprint/capability advertisement. The details are for further 772 study. 774 Performance feasibility of request routing redirection and loop 775 prevention should be addressed. The requirements may vary depending 776 on the CDN service types (e.g., CDN for small and/or large object). 777 Also granularity of redirection within or between contents should be 778 considered. It is for further study, too. 780 5 Security Considerations 782 6 IANA Considerations 784 7 References 786 7.1 Normative References 788 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, March 1997. 791 [I-D.davie-cdni-framework] Peterson, L. and B. Davie, "Framework for 792 CDN Interconnection", April 2012. 794 [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content 795 Distribution Network Interconnection (CDNI) Requirements", 796 December 2011. 798 7.2 Informative References 800 [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., 801 and N. Bitar, "Content Distribution Network 802 Interconnection (CDNI) Problem Statement", May 2012. 804 [I-D.ietf-cdni-use-cases] Bertrand, G., Stephan, E., Burbridge, T., 805 Eardley, P., Ma, K., and G. Watson, "Use Cases for Content 806 Delivery Network Interconnection", June 2012. 808 Authors' Addresses 810 Taesang Choi 811 ETRI 812 161 Gajong-Dong 813 Yusong-Gu, Daejeon 814 Republic of Korea 816 Phone: +82-42-860-5628 817 Email: choits@etri.re.kr 819 Young-IL Seo 820 KT Network R&D Laboratory 821 463-1, Jeonmoin-dong, 822 Yuseong-gu, Daejeon 823 Republic of Korea 825 Phone: 82-10-3235-0135 826 Email: yohan.seo@kt.com 828 Dong-Ju Kim 829 KT Network R&D Laboratory 830 463-1, Jeonmoin-dong, 831 Yuseong-gu, Daejeon 832 Republic of Korea 834 Phone: 82-10-2686-9605 835 Email: dj.kim@kt.com 837 Jongmin Lee 838 SK Telecom 839 11, Euljiro-2ga 840 Jung-gu, Seoul 841 Republic of Korea 843 Phone: 82-10-9429-6260 844 Email: jminlee@sk.com 846 Ja-Ryeong Koo 847 LG U plus Corporation 848 Namdaemunro 5-ga 849 Jung-gu, Seoul 850 Republic of Korea 852 Phone: 82-10-8080-6115 853 Email: wjbkoo@lguplus.co.kr 855 John Dongho Shinn 856 Solbox Inc. 857 7F, Haesung Bldg. 747-2 Yeoksam-Dong 858 Kangnam-Gu, Seoul 859 Republic of Korea 861 Phone: +82-10-3005-4785 862 Email: eastsky@solbox.com