idnits 2.17.1 draft-lelouedec-cdni-request-routing-00.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 abstract seems to contain references ([I-D.ietf-cdni-framework], [I-D.ietf-cdni-requirements], [I-D.ietf-cdni-problem-statement]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 35: '...powerful concept SHALL be used to simp...' RFC 2119 keyword, line 249: '...equest, the uCDN MAY redirect the cont...' RFC 2119 keyword, line 250: '...CDN and the dCDN MUST accept the conte...' RFC 2119 keyword, line 323: '...the IETF CDNI WG MUST allow to support...' RFC 2119 keyword, line 441: '...ion 3), the upstream CDN MUST generate...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-00 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-03 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Le Louedec 3 Internet-Draft A. Marrec 4 Intended status: Informational G. Bertrand 5 Expires: January 10, 2013 France Telecom - Orange 6 M. Pilarski 7 Orange Polska / WUT 8 July 9, 2012 10 CDNI Request Routing 11 draft-lelouedec-cdni-request-routing-00 13 Abstract 15 The present document proposes to clarify the CDNI Request Routing 16 interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- 17 problem-statement], as well as related terminology. 19 In particular the present document proposes to split the CDNI Request 20 Routing interface into two separate interfaces with clearer roles, 21 named respectively CDNI Routing interface and CDNI Downstream 22 Resource Identifier Signaling interface (CDNI DRIS interface). 24 This part of the CDN interconnection framework the IETF has been 25 referring to so far with the term "CDNI Request Routing" is just 26 another routing, signaling and forwarding problem in a long series of 27 the telecommunication history. For example, one can draw a direct 28 analogy between the IP/MPLS-TE framework and the CDN interconnection 29 framework. 31 In addition, this document recommends that the specification of ALL 32 CDN interconnection interfaces in the scope of the CDNI IETF WG 33 relies on the equivalent concept to IP prefix for CDN 34 interconnection, named 'contentRequestScope'. This highly useful and 35 powerful concept SHALL be used to simplify the specification of ALL 36 CDN interconnection interfaces, as well as to ensure performance and 37 scalability in CDN interconnection. 39 All these proposals can be smoothly integrated in the WG drafts, 40 especially [I-D.ietf-cdni-framework] and 41 [I-D.ietf-cdni-requirements], as they essentially propose (useful) 42 clarifications of the existing framework. 44 Status of this Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 10, 2013. 61 Copyright Notice 63 Copyright (c) 2012 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Motivations and Terminology Clarifications . . . . . . . . . . 4 80 2.1. The CDNI Request Routing interface should be split . . . . 5 81 2.2. The routing function of the CDNI Request Routing 82 interface should be clarified . . . . . . . . . . . . . . 6 83 2.3. CDNI request redirection strategies . . . . . . . . . . . 7 84 3. Overview of the CDNI Routing interface . . . . . . . . . . . . 8 85 4. The CDNI Downstream Resource Identifier Signaling (DRIS) 86 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.1. Overview of the CDNI DRIS interface . . . . . . . . . . . 11 88 4.2. Overview of CDNI DRIS operations . . . . . . . . . . . . . 15 89 4.2.1. Case of iterative CDNI request redirection . . . . . . 16 90 4.2.2. Case of recursive CDNI request redirection . . . . . . 18 91 4.3. Key points to note about the CDNI DRIS interface . . . . . 23 92 5. CDNI request routing is just another routing and signaling 93 problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 6. Conclusion and recommendations . . . . . . . . . . . . . . . . 26 95 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 98 10. Informative References . . . . . . . . . . . . . . . . . . . . 28 99 Appendix A. Proposal for Section 4.2 of CDNI framework draft . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 The present document proposes to clarify the CDNI Request Routing 105 interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- 106 problem-statement], as well as the related terminology. 108 In particular the present document proposes to split the CDNI Request 109 Routing interface into two separate interfaces with clearer roles, 110 named respectively CDNI Routing interface and CDNI Downstream 111 Resource Identifier Signaling interface (CDNI DRIS interface). 113 Section 2 presents the motivations for splitting the CDNI Request 114 Routing interface. It also proposes to review and to expand the 115 terminology about the terms iterative request routing and recursive 116 request routing. 118 Section 3 and Section 4 provide a short overview respectively of the 119 CDNI Routing interface and of the CDNI DRIS interface. The detailed 120 specifications of each of these interfaces will be made public 121 shortly by the authors in dedicated IETF drafts. 123 Section 5 provides an analogy with IP/MPLS-TE framework. This just 124 aims at helping readers to understand the proposals and 125 recommendations in this document. 127 Section 6 concludes this draft with recommendations for the IETF CDNI 128 WG. This includes recommendations about the CDNI WG charter, as well 129 as about [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-requirements]. 131 Appendix A proposes a text to replace Section 4.2 of 132 [I-D.ietf-cdni-framework]. 134 2. Motivations and Terminology Clarifications 136 Section 2.1 and Section 2.2 present the motivations for splitting and 137 clarifying the CDNI Request Routing interface. 139 This document adopts the terminology described in [I-D.ietf-cdni- 140 problem-statement] and [I-D.ietf-cdni-framework], except for the 141 terms 'iterative request routing' and 'recursive request routing'. 142 Section 2.3 proposes to review and to expand the terminology about 143 these two terms. 145 In addition this document extends this terminology with the terms 146 'CDNI routing interface', 'CDNI DRIS interface' and 147 'contentRequestScope' introduced and illustrated respectively in 148 Sections 3, 4, and 5. It also introduces the term 'delivery 149 resource'. From the perspective of the uCDN, a delivery resource is 150 a delivery node or a request routing system towards which a content 151 request may be redirected: either a delivery node inside the uCDN, or 152 the request routing system of a CDN different from the uCDN, or a 153 delivery node within a CDN different from the upstream CDN. 155 2.1. The CDNI Request Routing interface should be split 157 One key message of the present document is that the term "CDNI 158 Request Routing" is confusing as it makes a mix-up of two clearly 159 different sets of processes and interfaces. 161 As described in [I-D.ietf-cdni-problem-statement], the CDNI Request 162 Routing interface's role is twofold: 164 1. "To enable a downstream CDN to provide to the upstream CDN 165 (static or dynamic) information (e.g., resources, footprint, 166 load) to facilitate selection of the downstream CDN by the 167 upstream CDN request routing system when processing subsequent 168 content requests from User Agents." 170 2. "To allow the downstream CDN to control what the upstream Request 171 Routing function should return to the User Agent in the 172 redirection message." 174 These two functions are fundamentally different. Besides, depending 175 on the considered use cases, described in [I-D.ietf-cdni-use-cases], 176 they could be implemented differently (e.g., the first function could 177 be implemented manually while the second function would be 178 implemented with a network protocol, or vice versa, or they could 179 rely on different network protocols, etc.). 181 This idea that the request routing interface comprises two parts has 182 started to be visible in the latest version of the Section 4.2 in 183 [I-D.ietf-cdni-framework]. We think that it is a good first step 184 that requires clarifications. Indeed, [I-D.ietf-cdni-framework] 185 mentions a 'synchronous part' that makes again a mix-up between 186 operations involving communications with the user agent and 187 operations only between the CDNs. And the latter ones can be purely 188 asynchronous operations in some cases, as illustrated in Section 4 of 189 the present memo. 191 Therefore, in order to simplify and accelerate the specification of 192 the CDNI interfaces, the present document proposes to split the 193 current CDNI Request Routing interface into two separate interfaces 194 with clearer roles, further detailed in Section 3 and Section 4 195 respectively: 197 1. The CDNI Routing Interface 199 2. The CDNI Downstream Resource Identifier Signaling (DRIS) 200 Interface. 202 2.2. The routing function of the CDNI Request Routing interface should 203 be clarified 205 Quoting [I-D.ietf-cdni-problem-statement], "The CDNI Request Routing 206 interface enables a Request Routing function in an upstream CDN to 207 query a Request Routing function in a downstream CDN to determine if 208 the downstream CDN is able (and willing) to accept the delegated 209 content request". 211 The "ability" and the "willingness" of the downstream CDN to accept 212 the delegated content request match two fully different processes in 213 CDN interconnection. And the description of both these processes 214 should be reviewed and clarified for the following reasons: 216 o Regarding the former process, i.e. related to the "ability" 217 ("enables a Request Routing function in an upstream CDN to query a 218 Request Routing function in a downstream CDN to determine if the 219 downstream CDN is able (...) to accept the delegated content 220 request"), a routing protocol is used to achieve such a process, 221 called routing process, in many other technologies and networks 222 (IP, ATM, etc.). In all these technologies, it is the downstream 223 entity that provides routing information to the upstream entity. 224 The same approach should be applied to CDN interconnection. The 225 reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, 226 dCDN 3, and then it selects one of them based on their responses") 227 would suffer from latency, signaling overhead and/or lack of 228 reactivity to events that impact the ability of the downstream 229 CDNs to accept delegated content requests. 231 o Regarding the latter process, i.e. related to the "willingness" 232 ("enables a Request Routing function in an upstream CDN to query a 233 Request Routing function in a downstream CDN to determine if the 234 downstream CDN (...) is willing (...)to accept the delegated 235 content request"), it is to be noted that the relationship between 236 a uCDN and a dCDN is always in the frame of a contractual 237 agreement between the administrative entity owning the uCDN, 238 acting as the customer, and the administrative entity owning the 239 dCDN, acting as the service provider. Therefore, consider a case 240 where 242 * the uCDN has a content request to redirect which is in full 243 conformance with the terms of this contractual agreement, and 245 * the uCDN has selected this dCDN. 247 As the uCDN knows, thanks to the routing information exchanged via 248 the aforementioned routing process, that the dCDN is able to 249 accept this content request, the uCDN MAY redirect the content 250 request to the dCDN and the dCDN MUST accept the content request. 251 Exchanging over the CDNI Request Routing interface information 252 about the "willingness" of the dCDN to accept the content request 253 is not relevant. 255 2.3. CDNI request redirection strategies 257 The terms "Iterative CDNI request routing" and "Recursive CDNI 258 request routing" are defined in [I-D.ietf-cdni-framework]. As 259 explained above the term "CDNI request routing" is confusing, 260 therefore, the present document proposes to use the terms "Iterative 261 CDNI request redirection" and "Recursive CDNI request redirection" 262 instead. We consider that these new terms are more appropriate than 263 the definitions provided in [I-D.ietf-cdni-framework]. 265 The definition of "Recursive CDNI request routing" given in 266 [I-D.ietf-cdni-framework] indicates "...that the Downstream CDN may 267 elect to have the request redirected directly to a delivery node 268 inside the Downstream CDN, to the Request-Routing System of the 269 Downstream CDN, to another CDN, or to any other system that the 270 Downstream CDN sees as fit for handling the redirected request." 272 In order to clarify this point, and for the purpose of Section 3 to 273 Section 6, the present document introduces the terms "full-recursive 274 CDNI request redirection" and "semi-recursive CDNI request 275 redirection". 277 Full-recursive CDNI request redirection and semi-recursive CDNI 278 request redirection are two subtypes of recursive CDNI request 279 redirection. A recursive CDNI request redirection is either a full- 280 recursive CDNI request redirection or a semi-recursive request 281 redirection. 283 "Full-recursive CDNI request redirection" refers to the case where 284 the considered CDN redirects the content request directly to a 285 delivery node of another CDN, as illustrated in Figure 4. It means 286 the content request is redirected: 288 o either directly to a delivery node inside the Downstream CDN, 290 o or directly to a delivery node inside a downstream CDN of the 291 downstream CDN, 293 o or directly to a delivery node inside a downstream CDN of a 294 downstream CDN of the downstream CDN, 296 o etc. (anyway directly to a delivery node). 298 In contrast, "semi-recursive CDNI request redirection" refers to the 299 case, illustrated on Figure 5, where the considered CDN does not 300 directly redirect the content request to a delivery node. It means 301 the request is redirected: 303 o either to the request routing system of the Downstream CDN that 304 will deliver the content 306 o or to the request routing system of another CDN that will deliver 307 the content and that is a downstream CDN of the downstream CDN, 309 o or to the request routing system of another CDN that will deliver 310 the content and that is a downstream CDN of a downstream CDN of 311 the downstream CDN, 313 o etc. (anyway not directly to a delivery node). 315 Full-recursive redirection has the advantage over semi-recursive 316 redirection of being more transparent from the user agent's 317 perspective, but the disadvantage of the downstream CDN exposing more 318 of its internal structure (in particular, the addresses of delivery 319 nodes) to the upstream CDN (and possibly to the upstream CDN(s) of 320 its upstream CDN, etc.). By contrast, semi-recursive redirection 321 does not require dCDN to expose the addresses of its delivery nodes 322 to uCDN. The specifications for the CDNI interfaces elaborated 323 within the IETF CDNI WG MUST allow to support both these recursive 324 CDNI request redirection strategies. 326 3. Overview of the CDNI Routing interface 328 The CDNI routing interface is dedicated to the CDNI routing process. 329 The CDNI routing process consists in the advertisement of CDNI 330 routing information from the downstream CDN to the upstream CDN. 332 Note: The upstream CDN never provides the downstream CDN with any 333 CDNI routing information. 335 CDNI routing information details "capabilities" of the downstream CDN 336 that the upstream CDN must take into account in its CDN selection 337 process. The CDN selection process consists for the upstream CDN to 338 select the CDN (either the upstream CDN or one of its downstream 339 CDN(s)) that should handle the content request the upstream CDN 340 receives from the user agent. 342 Note: The term "capabilities" refer to the capacity of the downstream 343 CDN to handle correctly content requests from user agents. It does 344 not necessarily mean that the downstream CDN will satisfy (alone) all 345 these content requests by delivering the requested content to the 346 user agent. Indeed the downstream CDN may have its own downstream 347 CDN(s) and may decide that some or all of these content requests will 348 be handled by its own downstream CDN(s). 350 Figure 1 provides a short illustration of the CDNI routing interface. 351 The upstream CDN on Figure 1 has two downstream CDNs: CDN1 and CDN2. 353 Via their respective CDNI routing interfaces established with the 354 upstream CDN, CDN1 and CDN2 provide the upstream CDN with CDNI 355 routing information about the capabilities that they offer to the 356 upstream CDN in the frame of their respective CDNI agreements 357 contracted with the upstream CDN. 359 The inner architecture of the upstream CDN is beyond the scope of the 360 current charter of the IETF CDNI WG. Figure 1 provides a high level 361 representation of a possible implementation just in order to ease 362 understanding of the global picture. 364 Basically and typically, the CDNI routing information received from 365 CDN1 and CDN2 will feed a CDNI routing table controlled by a routing 366 module in the upstream CDN. And every time the upstream CDN receives 367 a content request from a user agent (either a DNS request in case of 368 DNS based request redirection, or an HTTP request in case of HTTP 369 based request redirection, etc.), its CDN selection module (in charge 370 of the CDN selection process) will consult this CDNI routing module 371 to decide about which CDN will handle this request (the upstream CDN, 372 CDN1, or CDN2). In the example on Figure 1, the upstream CDN selects 373 CDN 2 for the considered content request. 375 +-----+ +------------------------------------------------+ 376 | | | Upstream CDN | 377 | | | | 378 | | | (1) Content request +----------------------+ | 379 | |-------------------------->| | | 380 | | | | CDN selection | | 381 | | | (2) | Module | | 382 | | | +--------->| | | 383 | | | | | (Selection of CDN2) | | 384 | | | | +----------------------+ | 385 |User | | | | 386 |Agent| | | | 387 | | | | | 388 | | | V | 389 | | | +--------------------------------------------+ | 390 | | | | | | 391 | | | | CDNI Routing Module | | 392 | | | | | | 393 | | | +--------------------------------------------+ | 394 | | | ^ ^ | 395 | | | | | | 396 | | +-----------|----------------------|-------------+ 397 | | |(A) CDNI Routing (A)| 398 | | | Interfaces | 399 | | +-------+-------+ +-------+-------+ 400 | | |Downstream CDN1| |Downstream CDN2| 401 +-----+ +---------------+ +---------------+ 403 Figure 1: CDNI routing interface 405 The operations shown on Figure 1 are as follows: 407 1. A content request from a user agent (and/or from an intermediate 408 local DNS in case it is a DNS request) arrives at the upstream 409 CDN. 411 2. Within the upstream CDN, the CDN selection module consults the 412 routing module to decide which CDN will handle this content 413 request (i.e. whether it will be the upstream CDN or one of its 414 downstream CDNs). The interface between these internal modules 415 is out of standardization scope. 417 A. The operations achieved over the CDNI Routing interfaces aim at 418 providing all information about the capabilities offered by the 419 downstream CDNs to the upstream CDN in the frame of their respective 420 CDNI agreements contracted with the upstream CDN. 422 The operations referenced with numeric indexes on Figure 1 ("1", "2") 423 show a time dependency: every time the upstream CDN receives a 424 content request ("1") its CDN selection process consults the routing 425 table ("2"). 427 In contrast, Routing information is to be exchanged continuously, 428 with keep alive and update messages. There is no time dependency 429 between the content requests received by the upstream CDN and the 430 operations over the CDNI routing interfaces. By reference to the 431 terminology used in [I-D.ietf-cdni-framework], CDNI Routing 432 operations are asynchronous. The CDNI routing interfaces are 433 referenced with an alphabetic index ("A") on Figure 1 to reflect this 434 point. 436 4. The CDNI Downstream Resource Identifier Signaling (DRIS) Interface 438 4.1. Overview of the CDNI DRIS interface 440 AFTER the CDN selection process is achieved by the upstream CDN for a 441 given content request (see Section 3), the upstream CDN MUST generate 442 a response redirecting that content request towards the selected 443 delivery resource by using in this response an identifier of that 444 selected delivery resource. 446 The selected delivery resource can be: 448 1. Either a delivery node within the upstream CDN 450 This corresponds to the case where the CDN selection process of the 451 upstream CDN selects the upstream CDN for that content request. In 452 this case, the upstream CDN delivers the requested content to the 453 client through one of its delivery nodes. The selected delivery 454 resource is the upstream CDN's delivery node. 456 2. Or the request routing system of a CDN different from the 457 upstream CDN 459 This corresponds to the case where the upstream CDN did select a 460 downstream CDN for that content request, and where the CDNI request 461 redirection strategy between the upstream CDN and this downstream CDN 462 is based either on the iterative mode or on the semi-recursive mode. 463 If the CDNI request redirection strategy between the uCDN and the 464 dCDN is based on the iterative mode, the CDN to which the request 465 routing system belongs is the downstream CDN selected by the upstream 466 CDN for that content request (see Figure 3: Iterative CDNI request 467 redirection). If the CDNI request redirection strategy between the 468 uCDN and the dCDN is based on the semi-recursive mode, the CDN to 469 which that request routing system belongs can possibly be 471 o the downstream CDN selected by the upstream CDN for that content 472 request, or 474 o a downstream CDN of that downstream CDN, or 476 o a downstream CDN of a downstream CDN of that downstream CDN, 478 o etc., 480 due to the recursive nature of this mode (see Figure 5). 482 3. Or a delivery node within a CDN different from the upstream CDN 484 This corresponds to the case where the upstream CDN did select a 485 downstream CDN for that content request, and where the CDNI request 486 redirection strategy between the upstream CDN and this downstream CDN 487 is based on the full-recursive mode. 489 The CDN to which the selected delivery node belongs can possibly be a 490 delivery node within the downstream CDN selected by the upstream CDN 491 for that content request, or a delivery node within a downstream CDN 492 of that downstream CDN, or a delivery node within a downstream CDN of 493 a downstream CDN of that downstream CDN, etc., due to the recursive 494 nature of this mode (see Figure 4: Full-recursive CDNI request 495 redirection). 497 In the cases "2." and "3.", the downstream CDN MUST provide the 498 identifier of the selected delivery resource to the upstream CDN. 499 The downstream CDN uses the CDNI DRIS interface to provide the 500 upstream CDN with this identifier called "Downstream Resource 501 Identifier" (DRI). 503 Note. In the recursive modes (full-recursive and semi-recursive) the 504 upstream CDN does not need to know if the selected delivery resource 505 belongs to the downstream CDN that the uCDN selected for that content 506 request or to another CDN (i.e. to one downstream CDN of this 507 downstream CDN, or to one downstream CDN of one downstream CDN of 508 this downstream CDN, etc.). The upstream CDN just needs to get from 509 the selected downstream CDN the "Downstream Resource Identifier" 510 (DRI) of the selected delivery resource, so as to generate with this 511 identifier a response redirecting that content request towards that 512 selected delivery resource. 514 +-----+ +-------------------------------------------------+ 515 | |(1) Content | | 516 | | request | Upstream CDN | 517 | |----------------+ | 518 | | | | | 519 | | | | (5) Content request response | 520 | |<---------------|---------------------------------+ | 521 | | | | | | 522 | | | +-V--------------+ +--------+---------+ | 523 | | | | CDN selection | | Content request | | 524 | | | | Module |(3) | response | | 525 | | | | |-------->| generation | | 526 | | | | (Selection |Internal | Module | | 527 |User | | | of CDN2) |Interface| | | 528 |Agent| | +----------------+ +------------------+ | 529 | | | ^ ^ | 530 | | | (2)|Internal (4)|Internal | 531 | | | |interface |interface | 532 | | | V V | 533 | | | +-------------+ +-----------+ | 534 | | | |CDNI Routing | |DRI | | 535 | | | |Module | |Module | | 536 | | | +-------------+ +-----------+ | 537 | | | ^ ^ ^ ^ | 538 | | +----------|---|-----------------|---|------------+ 539 | | CDNI Routing|(A)+--------------+ |(B)|CDNI DRIS 540 | | Interfaces | +------------|--+ |Interfaces 541 | | | | | | 542 | | +------+-----v--+ +-+------v------+ 543 | | |Downstream CDN1| |Downstream CDN2| 544 +-----+ +---------------+ +---------------+ 546 Figure 2: CDNI DRIS interface 548 Figure 2 is an extension of Figure 1. Again, the inner architecture 549 of the CDN is beyond the scope of the IETF CDNI WG charter; Figure 2 550 provides a high level representation of a possible implementation 551 just in order to ease the understanding of the global picture. 553 The operations shown on Figure 2 are as follows: 555 1. A content request from a user agent (and/or from an intermediate 556 local DNS in case it is a DNS request) arrives at the upstream 557 CDN. 559 2. Within the upstream CDN, the CDN selection Module consults the 560 routing module to decide which CDN will handle this content 561 request (i.e. whether it will be the upstream CDN or one of its 562 downstream CDNs). The interface between these internal modules 563 is out of standardization scope. Let us consider that the CDN 564 selection module selected the downstream CDN2 for that content 565 request (so as to continue with the illustrating example 566 introduced in Section 3). 568 3. Once this CDN selection is achieved, the module in charge of 569 generating the response to the content request ('Content request 570 response generation Module' on Figure 2) is called. The 571 interface between these internal modules is out of 572 standardization scope. In order to generate the response, the 573 Content request response generation module needs to get the 574 identifier of the selected delivery resource (DRI) to where the 575 content request must be redirected. 577 4. The Content request response generation module consults the DRI 578 module to get this adequate DRI. The interface between these 579 internal modules is out of standardization scope. The DRI module 580 is in charge of getting and storing the DRI(s) provided by each 581 downstream CDN over their CDNI DRIS interfaces with the upstream 582 CDN. 584 5. Once the Content request response generation module has this 585 adequate DRI, it generates the response to the content request so 586 as to the request be redirected towards the selected delivery 587 resource. 589 A. The operations achieved over the CDNI Routing interfaces aim at 590 providing all information about the capabilities offered by the 591 downstream CDNs to the upstream CDN in the frame of their respective 592 CDNI agreements contracted with the upstream CDN. 594 B. The operations achieved over the CDNI DRIS Interface with the 595 downstream CDN2 aim at providing the upstream CDN with the DRI, i.e. 596 the identifier of the selected delivery resource. 598 The operations referenced with numeric indexes on Figure 2 ("1", "2", 599 "3", "4", "5") show a strict time dependency. In particular, it is 600 to be highlighted that the CDN selection process of the upstream CDN 601 does not take the DRI information into account. This identifier is 602 used by the content request response generation module only after the 603 CDN selection process is achieved. 605 As explained in Section 3, the CDNI routing interfaces are referenced 606 with an alphabetic index ("A") to indicate that the CDNI routing 607 information are exchanged asynchronously and continuously, with keep 608 alive and update messages. 610 The CDNI DRIS interfaces are also referenced with an alphabetic index 611 ("B") to indicate there is not always a systematic time dependency 612 between the content requests received by the upstream CDN and the 613 operations occurring over the CDNI DRIS interfaces. This depends, 614 among others, on the CDNI request redirection strategy enforced 615 between the CDNs (recursive or iterative). This means that the 616 specification of the CDNI DRIS interface MUST enable synchronous and 617 asynchronous operations, as illustrated in the next Section 4.2. 619 4.2. Overview of CDNI DRIS operations 621 This section gives an overview of operations over the CDNI DRIS 622 interfaces for each CDNI request redirection strategy (iterative, 623 full-recursive and semi-recursive). 625 All the figures present the same network topology with three cascaded 626 CDNs so as to show very clearly the difference between the full- 627 recursive and semi-recursive modes. The case where only two CDNs are 628 involved can be straightforwardly deduced. In addition, the CDNI 629 request redirection strategy applied between the first CDN and the 630 second CDN (e.g., iterative) could differ from the strategy applied 631 between the second CDN and the third CDN (e.g., semi- recursive). 632 The three figures are for illustration purpose only; they do not aim 633 at reflecting exhaustively the full flexibility that the CDN service 634 providers have when choosing their CDNI request redirection 635 strategies. 637 The same situation and content request are considered in all the 638 three figures: 640 o There is one CDNI agreement and one CDN interconnection between 641 CDN-a and CDN-b for the considered request. CDN-b is a downstream 642 CDN of CDN-a. And there is one CDNI DRIS interface between CDN-a 643 and CDN-b, bootstrapped with configuration information exchanged 644 over the CDNI control interface during the initial CDN 645 interconnection activation process (see 646 [I-D.ietf-cdni-framework]). 648 o In the same way there is one CDNI agreement, one CDN 649 interconnection and one CDNI DRIS interface between CDN-b and 650 CDN-c. CDN-c is a downstream CDN of CDN-b for the considered 651 request. 653 o CDN-a receives a content request and decides CDN-b will handle it. 654 CDN-b decides the content request will be handled by CDN-c. CDN-c 655 delivers the content to the user agent from one of its delivery 656 nodes (cache hit). 658 4.2.1. Case of iterative CDNI request redirection 660 Figure 3 presents the case where the iterative CDNI request 661 redirection mode is applied between CDN-a and CDN-b, and between 662 CDN-b and CDN-c. 664 +-----+ +------------------+ 665 | | |CDN-a | 666 | | 1 | (uCDN for CDN-b) | 667 | |-------------------------------------->| | 668 | | 2 | | 669 | |<--------------------------------------| | 670 | | +------------------+ | +--------+ | 671 | | |CDN-b | | | | | 672 | | 3 | (uCDN for CDN-c) | | |DRI | | 673 | |----->| | +------------->|Module | | 674 | | 4 | +--------+ | 0 | | | | | 675 | |<-----| | |--------+ | +--------+ | 676 | | | | | | +------------------+ 677 |User | | |DRI | | 678 |Agent| | |Module | | 679 | | | | | | 680 | | | | | | 0 681 | | | | |<-------+ 682 | | | +--------+ | | 683 | | +------------------+ | +------------------+ 684 | | | |CDN-c | 685 | | | | +--------+ | 686 | | | | | | | 687 | | +--------------|DRI | | 688 | | | |Module | | 689 | | | | | | 690 | | 5 | +--------+ | 691 | |-------------------------------------->| | 692 | | 6 | | 693 | |<--------------------------------------| | 694 | | 7 | +--------+ | 695 | |------------------------------------------->| | | 696 | | 8 | |Delivery| | 697 | |<-------------------------------------------|Node | | 698 | | | | | | 699 | | | +--------+ | 700 +-----+ +------------------+ 702 Figure 3: Iterative CDNI request redirection 704 The operations shown in Figure 3 are as follows: 706 0. CDN-a gets from CDN-b, over the CDNI DRIS interface between CDN-a 707 and CDN-b, a DRI valid for any content request within their mutual 708 CDNI agreement, and possibly before any user agent content request is 709 received by CDN-a. 711 In the iterative case, the CDNI DRIS interface may indeed provide the 712 upstream CDN with a unique DRI valid in the frame of their mutual 713 CDNI agreement for any content request received by the upstream CDN. 715 Basically, it means that the downstream CDN informs the upstream CDN 716 that, when the upstream CDN decides to redirect a content request to 717 this downstream CDN in the frame of their mutual CDNI agreement, the 718 upstream CDN just has to use systematically that DRI to forge the 719 response sent by the upstream CDN to redirect the content request to 720 that downstream CDN. 722 For example, in case the CDNI request redirection mechanism is based 723 on HTTP 302 redirect messages, this DRI includes a distinguished CDN- 724 domain, which is to be "stacked" in front of the original URL to 725 construct the new URL to redirect the content request to the request 726 routing system of the downstream CDN, as detailed in 727 [I-D.ietf-cdni-framework]. 729 This static and unique DRI for a CDNI agreement set between CDN-a and 730 CDN-b can be exchanged even before the first content request received 731 by CDN-a. This is an example of asynchronous operation over the CDNI 732 DRIS interface. And this is one case where it may be relevant to 733 implement the CDNI DRIS interface "manually"; for example the DRI can 734 be exchanged on the phone or by email simply and only once for the 735 whole duration of the CDNI agreement between CDN-a and CDN-b. 737 We describe the other operations of Figure 3 below. 739 0. The same way, CDN-b gets from CDN-c, over the CDNI DRIS interface 740 between CDN-b and CDN-c, a DRI valid for any content request within 741 their mutualCDNI agreement, and possibly before any user agent 742 content request is received by CDN-b. 744 1. The considered content request, sent by a user agent (and/or by 745 an intermediate local DNS in case it is a DNS request), arrives at 746 CDN-a. 748 2. CDN-a decides this content request is to be best handled by 749 CDN-b. Therefore, CDN-a sends a response to the content request, 750 forged with the DRI provided by CDN-b. 752 3. A request is thus sent by the user agent (and/or by an 753 intermediate local DNS in case it is a DNS request) to CDN-b. 755 4. CDN-b decides this content request is to be best handled by 756 CDN-c. Thus, CDN-b sends a response to the content request forged 757 with the DRI provided by CDN-c. 759 5. A request is sent by the user agent (and/or by an intermediate 760 local DNS in case it is a DNS request) to CDN-c. 762 6. CDN-c decides it will handle the request, i.e. it will be the one 763 to deliver the content to the user agent. CDN-c selects one of its 764 delivery nodes to handle that content request. CDN-c generates a 765 response redirecting the content request to this delivery node. 767 7. The user agent emits a content request to the selected delivery 768 node. 770 8. The selected delivery node from CDN-c delivers the requested 771 content to the user agent. 773 4.2.2. Case of recursive CDNI request redirection 775 Figure 4 presents the case where the full-recursive CDNI request 776 redirection mode is applied between CDN-a and CDN-b, and between 777 CDN-b and CDN-c. 779 +-----+ +------------------+ 780 | | |CDN-a | 781 | | 1 | (uCDN for CDN-b) | 782 | |-------------------------------------->| | 783 | | 6 | | 784 | |<--------------------------------------| | 785 | | +------------------+ | +--------+ | 786 | | |CDN-b | +--------------| | | 787 | | | (uCDN for CDN-c) | | | |DRI | | 788 | | | | | +-------->|Module | | 789 | | | +--------+ | 2 | | | | | | 790 | | | | |<-------+ | | +--------+ | 791 | | | | | | 5 | +------------------+ 792 |User | | |DRI |-------------+ 793 |Agent| | |Module | | 3 794 | | | | |-------------+ 795 | | | | | | 4 | 796 | | | | |<-------+ | 797 | | | +--------+ | | | 798 | | +------------------+ | | +------------------+ 799 | | | | |CDN-c | 800 | | | | | +--------+ | 801 | | | +-------->| | | 802 | | | | |DRI | | 803 | | +--------------|Module | | 804 | | | | | | 805 | | | +--------+ | 806 | | 7 | +--------+ | 807 | |------------------------------------------->| | | 808 | | 8 | |Delivery| | 809 | |<-------------------------------------------|Node | | 810 | | | | | | 811 | | | +--------+ | 812 +-----+ +------------------+ 814 Figure 4: Full-recursive CDNI request redirection 816 The operations shown in Figure 4 are as follows: 818 1. The considered content request, sent by a user agent (and/or by 819 an intermediate local DNS in case it is a DNS request), arrives at 820 CDN-a. 822 2. CDN-a decides this content request is to be best handled by 823 CDN-b. CDN-a sends a request to CDN-b over the CDNI DRIS interface 824 set up between CDN-a and CDN-b. The request includes all information 825 about the content request CDN-b needs in order to select the most 826 appropriate delivery resource and to response to CDN-a with the 827 corresponding adequate DRI. 829 3. CDN-b decides this content request is to be best handled by 830 CDN-c. CDN-b sends a request to CDN-c over the CDNI DRIS interface 831 set up between CDN-b and CDN-c. The request includes all information 832 about the content request CDN-c needs in order to select the most 833 appropriate delivery resource and to response to CDN-b with the 834 corresponding adequate DRI. 836 4. CDN-c decides it will handle the content request, i.e. it will be 837 the one to deliver the content to the user agent. CDN-c selects one 838 of its delivery nodes to handle that content request. CDN-c sends a 839 response to CDN-b, over the CDNI DRIS interface between CDN-b and 840 CDN-c, with a DRI corresponding to that delivery node. 842 5. CDN-b sends a response to CDN-a, over the CDNI DRIS interface 843 between CDN-a and CDN-b, with a DRI corresponding to the selected 844 delivery node from CDN-c. This DRI is based on the DRI provided by 845 CDN-c. Details about the manipulations achieved by CDN-b over the 846 DRI received from CDN-c to generate the DRI sent to CDN-a are to be 847 provided in the dedicated specification of the CDNI DRIS interface. 849 6. CDN-a sends a response to the content request, forged with the 850 DRI provided by CDN-b. 852 7. The user agent emits a content request directly to the selected 853 delivery node from CDN-c. 855 8. The selected delivery node from CDN-c delivers the requested 856 content to the user agent. 858 The Figure 5 below presents the case where the semi-recursive CDNI 859 request redirection mode is applied between CDN-a and CDN-b, and 860 between CDN-b and CDN-c. 862 +-----+ +------------------+ 863 | | |CDN-a | 864 | | 1 | (uCDN for CDN-b) | 865 | |-------------------------------------->| | 866 | | 6 | | 867 | |<--------------------------------------| | 868 | | +------------------+ | +--------+ | 869 | | |CDN-b | +--------------| | | 870 | | | (uCDN for CDN-c) | | | |DRI | | 871 | | | | | +-------->|Module | | 872 | | | +--------+ | 2 | | | | | | 873 | | | | |<-------+ | | +--------+ | 874 | | | | | | 5 | +------------------+ 875 |User | | |DRI |-------------+ 876 |Agent| | |Module | | 3 877 | | | | |-------------+ 878 | | | | | | 4 | 879 | | | | |<-------+ | 880 | | | +--------+ | | | 881 | | +------------------+ | | +------------------+ 882 | | | | |CDN-c | 883 | | | | | +--------+ | 884 | | | +-------->| | | 885 | | | | |DRI | | 886 | | +--------------|Module | | 887 | | | | | | 888 | | 7 | +--------+ | 889 | |-------------------------------------->| | 890 | | 8 | | 891 | |<--------------------------------------| | 892 | | 9 | +--------+ | 893 | |------------------------------------------->| | | 894 | | 10 | |Delivery| | 895 | |<-------------------------------------------|Node | | 896 | | | | | | 897 | | | +--------+ | 898 +-----+ +------------------+ 900 Figure 5: Semi-recursive CDNI request redirection 902 The operations shown in Figure 5 are as follows: 904 1. The considered content request, sent by a user agent (and/or by 905 an intermediate local DNS in case it is a DNS request), arrives at 906 CDN-a. 908 2. CDN-a decides this content request is to be best handled by 909 CDN-b. CDN-a sends a request to CDN-b over the CDNI DRIS interface 910 set up between CDN-a and CDN-b. The request includes all information 911 about the content request CDN-b needs in order to select the most 912 appropriate delivery resource and to response to CDN-a with the 913 corresponding adequate DRI. 915 3. CDN-b decides this content request is to be best handled by 916 CDN-c. CDN-b sends a request to CDN-c over the CDNI DRIS interface 917 set up between CDN-b and CDN-c. The request includes all information 918 about the content request CDN-c needs in order to select the most 919 appropriate delivery resource and to response to CDN-b with the 920 corresponding adequate DRI. 922 4. CDN-c decides it will handle the content request, i.e. it will be 923 the one to deliver the content to the user agent. CDN-c sends a 924 response to CDN-b, over the CDNI DRIS interface between CDN-b and 925 CDN-c, with a DRI corresponding to its request routing system. 927 5. CDN-b sends a response to CDN-a, over the CDNI DRIS interface 928 between CDN-a and CDN-b, with a DRI corresponding to the selected 929 delivery resource (i.e. to the request routing system of CDN-c). 930 This DRI is based on the DRI provided by CDN-c. Details about the 931 manipulations achieved by CDN-b over the DRI received from CDN-c to 932 generate the DRI sent to CDN-a are to be provided in the dedicated 933 specification of the CDNI DRIS interface. 935 6. CDN-a sends a response to the content request, forged with the 936 DRI provided by CDN-b. 938 7. The content request is redirected by the user agent (and/or by an 939 intermediate local DNS in case it is a DNS request) to the selected 940 delivery resource, i.e. to CDN-c. 942 8. CDN-c decides it will handle the content request, i.e. it will be 943 the one to deliver the content to the user agent. CDN-c selects one 944 of its delivery nodes to handle that content request. CDN-c 945 generates a response redirecting the content request to this delivery 946 node. 948 9. The user agent emits a content request to the selected delivery 949 node. 951 10. The selected delivery node from CDN-c delivers the requested 952 content to the user agent. 954 As shown on Figure 4 and 5, when the recursive mode is applied, the 955 upstream CDN may have to send a request over a CDNI DRIS interface 956 every time it receives a content request. This is an example of 957 synchronous operations over the CDNI DRIS interface. Having one CDNI 958 DRIS request per content request may lead to scalability issues, even 959 if the CDNI DRIS interface is implemented with a network protocol 960 rather than "manually". Yet these issues can be solved. This is to 961 be documented in the dedicated specification of the CDNI DRIS 962 interface. 964 4.3. Key points to note about the CDNI DRIS interface 966 To conclude this section, the key points to note about the CDNI DRIS 967 interface are the following: 969 o The CDNI DRIS interface MUST always exist between two 970 interconnected CDNs. Whatever the CDNI request redirection 971 strategy applied (recursive or iterative), the CDNI DRIS interface 972 exists, even if it is implemented "manually" in some cases, as 973 suggested in the example of Figure 3 above. 975 o Moreover the CDNI DRIS interface MUST be unique from a functional 976 perspective. Another way to say this is that, from a functional 977 perspective, this is the exact same CDNI DRIS interface that is 978 used, and the exact same type of information that are exchanged 979 over this interface, whatever the CDNI request redirection 980 strategy applied (recursive or iterative). 982 o The specification of the CDNI DRIS interface MUST enable 983 synchronous and asynchronous CDNI DRIS operations: operations 984 possibly triggered by the CDN selection process for a given 985 content request (as shown on Figure 4 and 5), as well as 986 operations achieved independently of any content request (as shown 987 on Figure 3). 989 o The specification of the CDNI DRIS interface MUST enable 990 operations initiated by uCDN (as shown on Figure 4 and 5) or by 991 dCDN (as shown on Figure 3). 993 o The specification of the CDNI DRIS interface MUST be compatible 994 with "automatic" (i.e. "with a specific network protocol") and 995 "manual" implementations, as discussed in Section 4.2. The 996 specification of the CDNI DRIS interface SHALL include a 997 description for each of these implementation options. 999 o The CDNI routing and CDNI DRIS interfaces MUST be independent. 1001 5. CDNI request routing is just another routing and signaling problem 1003 This part of the CDN interconnection framework the IETF has been 1004 referring to so far with the term "CDNI Request Routing" is just 1005 another routing, signaling and forwarding problem in a long series of 1006 the telecommunication history. 1008 For example one can draw an analogy with the IP/MPLS-TE framework, 1009 notably, as shown on Figure 6 and below, between: 1011 o the CDNI routing interface and any IP routing protocol/interface 1012 (such as BGP/IGP IP routing protocols), 1014 o the CDNI DRIS interface and a signaling protocol such as RSVP-TE. 1016 It is to be noted that such an analogy must be considered with care 1017 because the context and objectives of CDN interconnection are 1018 different from IP routing, signaling and forwarding. In particular, 1019 the type of information exchanged via the CDNI DRIS interface is 1020 totally different from the information exchanged by protocols like 1021 RSVP-TE in IP/MPLS networks. Anyway this analogy may ease to 1022 understand the role of the CDNI DRIS interface in the CDNI framework. 1024 Another key point to note in this analogy is that IP prefix is one of 1025 the most important concepts in IP networks. It is used in most IP 1026 processes (IP routing, packet filtering, MPLS-TE signaling, etc.). 1027 It has been a highly useful and powerful concept to simplify the 1028 specification of TCP/IP protocols as well as to ensure performance 1029 and scalability of IP networks. For example exchanging IP routing 1030 information per IP prefix has been a MUST to ensure IP routing 1031 performance and scalability. 1033 The equivalent concept to IP prefix has the same importance in the 1034 CDN interconnection framework. The concept is named 1035 "contentRequestScope" in Figure 6. A contentRequestScope designates 1036 a class of content requests sharing common properties (e.g., "all the 1037 HTTP requests", or "all HTTP requests issued by French users", or 1038 "all RTSP and HTTP requests with signed URL", etc.). 1040 In the same way as IP prefix is a key concept for specifying TCP/IP 1041 protocols, "contentRequestScope" is THE main concept for the CDN 1042 interconnection framework. This highly useful and powerful concept 1043 SHALL be used to simplify the specification of ALL CDN 1044 interconnection interfaces, as well as to ensure performance and 1045 scalability in CDN interconnection. 1047 +--------------------------------+----------------------------------+ 1048 | IP/MPLS-TE concepts | CDN Interconnection concepts | 1049 +--------------------------------+----------------------------------+ 1050 | IP packet Forwarding | Content request redirection | 1051 +--------------------------------+----------------------------------+ 1052 | IP prefix | ContentRequestScope | 1053 | (correspond to a class of IP | (correspond to a class of | 1054 | addresses sharing the same | content requests sharing | 1055 | prefix) | common properties) | 1056 +--------------------------------+----------------------------------+ 1057 | Ingress Provider Edge Router | upstream CDN (uCDN) | 1058 | (ILSR) | | 1059 +--------------------------------+----------------------------------+ 1060 | Egress Provider Edge Router | Delivery resource (delivery node | 1061 | (ELSR) | or downstream CDN) | 1062 +--------------------------------+----------------------------------+ 1063 | IP routing interfaces (running | CDNI routing interface | 1064 | IGP/BGP IP routing protocols) | | 1065 +--------------------------------+----------------------------------+ 1066 | IP routing information | CDNI routing information | 1067 | (IP prefix <-> Next Hop) | (ContentRequestScope <-> dCDN) | 1068 +--------------------------------+----------------------------------+ 1069 | IP FEC table construction | Redirection table construction | 1070 | (IP prefix <-> ELSR) | (ContentRequestScope <-> delivery| 1071 | | resource) | 1072 +--------------------------------+----------------------------------+ 1073 | Signaling information provided | Signaling information provided | 1074 | by the RSVP-TE protocol | by the CDNI DRIS interface | 1075 | (MPLS label <-> ELSR) | (DRI <-> delivery resource) | 1076 +--------------------------------+----------------------------------+ 1077 | To encapsulate an IP packet in | To generate a redirected content | 1078 | an MPLS frame (using an MPLS | request (using a DRI) | 1079 | Label) | | 1080 +--------------------------------+----------------------------------+ 1081 | To forward a packet out of the | To redirect a content request | 1082 | nominal route based on IGP | out of the authoritative CDN, | 1083 | and BGP routing information, | to another CDN, thanks to CDN | 1084 | thanks to MPLS Traffic | interconnection technologies | 1085 | Engineering technologies | | 1086 +--------------------------------+----------------------------------+ 1087 | To forward an IP packet | To redirect a content request to | 1088 | encapsulated in an MPLS frame | to the selected downstream CDN | 1089 | via - or to - the destination | - or to the selected delivery | 1090 | ELSR thanks to the MPLS | node - thanks to the | 1091 | header of the MPLS frame | Downtream Resource Identifier | 1092 | | (DRI) used to forge the response | 1093 | | to the initial content request | 1094 +--------------------------------+----------------------------------+ 1095 Figure 6: Analogy between IP/MPLS-TE and CDNI concepts 1097 CDNI Routing interfaces exchanges CDNI routing information per 1098 contentRequestScope, i.e. per class of content requests sharing 1099 common properties. 1101 Analogically: IP routing protocols like IGP/BGP exchange routing 1102 information per IP prefix, i.e. per class of IP addresses sharing 1103 common properties. 1105 The upstream CDN builds its redirection table with information 1106 provided by the CDNI Routing interface and the CDNI DRIS interface. 1108 Analogically: The Ingress Provider Edge Router (ILSR) builds its 1109 forwarding table with information provided by the IP routing and 1110 MPLS-TE signaling protocols. 1112 When receiving a content request, which has possibly been already 1113 redirected by some upstream CDNs, a CDN consults its forwarding table 1114 to generate a response using the adequate DRI, provided by the CDNI 1115 DRIS interface, which redirects the content request to the selected 1116 delivery resource (which is a CDN or a node downstream). 1118 Analogically: When receiving an IP packet, possibly encapsulated in 1119 an MPLS frame, an Ingress Provider Edge Router (ILSR) consults its 1120 forwarding table to manipulate it adequately. This manipulation may 1121 include to encapsulate it in an MPLS frame, based on the signaling 1122 information provided by the RSVP-TE protocol, which makes it being 1123 then forwarded to the right Egress Provider Edge router (ELSR). 1125 6. Conclusion and recommendations 1127 A first key message of this document is that the term "CDNI request 1128 routing" is confusing as it makes a mix-up of clearly different set 1129 of processes and interfaces. 1131 A second key message of this document is that this part of the CDN 1132 interconnection framework the IETF has been referring to so far with 1133 the term "CDNI Request Routing" is just another routing, signaling 1134 and forwarding problem in a long series of the telecommunication 1135 history. For example, one can draw a direct analogy between the IP/ 1136 MPLS-TE framework and the CDN interconnection framework. 1138 Thus one can directly be inspired by the best practices and results 1139 of the efforts invested over years, even decades, to develop 1140 technologies in the past, such as IP/MPLS-TE, to specify adequately 1141 CDN interconnection interfaces. 1143 The proposals from the current document can be smoothly integrated in 1144 the WG drafts, especially [I-D.ietf-cdni-framework] and 1145 [I-D.ietf-cdni-requirements], as they essentially propose (useful) 1146 clarifications of the existing framework. 1148 We recommend to review [I-D.ietf-cdni-framework], at least its 1149 section 4.2. Appendix A provides a proposal to replace the current 1150 Section 4.2 of [I-D.ietf-cdni-framework]. 1152 We recommend to review [I-D.ietf-cdni-requirements], to clearly 1153 distinguish the requirements specific to the CDNI routing interface 1154 from the requirements specific to the CDNI DRIS interface. 1156 We also recommend to review the charter of the CDNI WG, in particular 1157 to replace the following objective: 1159 o "WG Creation + 18 months: Submit specification of the CDNI Request 1160 Routing protocol to IESG as Proposed Standard" 1162 by the two following objectives: 1164 o "WG Creation + 18 months: Submit specification of the CDNI Routing 1165 interface to IESG as Proposed Standard" 1167 o "WG Creation + 18 months: Submit specification of the CDNI 1168 Downstream Resource Identifier Signaling (DRIS) Interface to IESG 1169 as Proposed Standard" 1171 Last but not least, we recommend that the specification of ALL CDN 1172 interconnection interfaces, including the CDNI routing interface and 1173 the CDNI DRIS interface, rely on the "contentRequestScope" concept, 1174 i.e. the equivalent concept to IP prefix for CDN interconnection. In 1175 the same way as IP prefix is a key concept for specifying TCP/IP 1176 protocols, "contentRequestScope" is THE main concept for the CDN 1177 interconnection framework. This highly useful and powerful concept 1178 SHALL be used to simplify the specification of ALL CDN 1179 interconnection interfaces, as well as to ensure performance and 1180 scalability in CDN interconnection. 1182 7. Acknowledgments 1184 The authors would like to thank Chris Hawinkel, Larry Peterson, Yvan 1185 Massot, Ali Gouta, Emile Stephan, and Patrick Fleming for their 1186 inputs and comments. 1188 They also thank the contributors of the EU FP7 OCEAN project in the 1189 frame of which these proposals have been elaborated. 1191 The work leading to these results has received funding from the 1192 European Union's Seventh Framework Programme (FP7/2007-2013) in OCEAN 1193 project (FP7-ICT-248775; http://www.ict-ocean.eu/). 1195 8. IANA Considerations 1197 This memo includes no request to IANA. 1199 9. Security Considerations 1201 Those are discussed in [I-D.ietf-cdni-problem-statement]. 1203 10. Informative References 1205 [I-D.ietf-cdni-framework] 1206 Peterson, L. and B. Davie, "Framework for CDN 1207 Interconnection", draft-ietf-cdni-framework-00 (work in 1208 progress), April 2012. 1210 [I-D.ietf-cdni-problem-statement] 1211 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 1212 Distribution Network Interconnection (CDNI) Problem 1213 Statement", draft-ietf-cdni-problem-statement-08 (work in 1214 progress), June 2012. 1216 [I-D.ietf-cdni-requirements] 1217 Leung, K. and Y. Lee, "Content Distribution Network 1218 Interconnection (CDNI) Requirements", 1219 draft-ietf-cdni-requirements-03 (work in progress), 1220 June 2012. 1222 [I-D.ietf-cdni-use-cases] 1223 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 1224 K., and G. Watson, "Use Cases for Content Delivery Network 1225 Interconnection", draft-ietf-cdni-use-cases-08 (work in 1226 progress), June 2012. 1228 Appendix A. Proposal for Section 4.2 of CDNI framework draft 1230 "4.2. Request Routing Interface 1232 The request routing interface is not a single interface, it 1233 corresponds to two separate interfaces with clear roles: 1235 1) The CDNI Routing Interface 1237 The CDNI routing interface is dedicated to the CDNI routing process. 1238 The CDNI routing process consists in the advertisement of CDNI 1239 routing information from the downstream CDN to the upstream CDN (the 1240 upstream CDN never provides the downstream CDN with any CDNI routing 1241 information). CDNI routing information details capabilities of the 1242 downstream CDN that the upstream CDN must take into account in its 1243 dCDN selection process. 1245 2) The CDNI Downstream resource Identifier Signaling (DRIS) Interface 1247 AFTER the CDN selection process is achieved by the upstream CDN for a 1248 given content request, the upstream CDN MUST generate a response 1249 redirecting that request towards the selected delivery resource by 1250 inserting in this response an identifier of that selected delivery 1251 resource. 1253 This selected delivery resource can be: 1255 1. a delivery node within the upstream CDN, 1257 2. a downstream CDN (i.e. the request routing system of that 1258 downstream CDN), or 1260 3. a delivery node within a downstream CDN. 1262 In the cases "2." and "3." , the identifier of that selected delivery 1263 resource MUST be provided by the downstream CDN to the upstream CDN. 1264 The downstream CDN uses the CDNI DRIS interface to provide the 1265 upstream CDN with this identifier called "Downstream resource 1266 Identifier" (DRI). 1268 Authors' Addresses 1270 Yannick Le Louedec 1271 France Telecom - Orange 1272 2 avenue Pierre Marzin 1273 Lannion, 22307 1274 France 1276 Phone: +33 2 96 05 17 64 1277 Email: yannick.lelouedec@orange.com 1278 Anne Marrec 1279 France Telecom - Orange 1280 2 avenue Pierre Marzin 1281 Lannion, 22307 1282 France 1284 Phone: +33 2 96 05 18 71 1285 Email: anne.marrec@orange.com 1287 Gilles Bertrand 1288 France Telecom - Orange 1289 38-40 rue du General Leclerc 1290 Issy les Moulineaux, 92130 1291 France 1293 Phone: +33 1 45 29 89 46 1294 Email: gilles.bertrand@orange.com 1296 Marcin Pilarski 1297 Orange Polska / WUT 1298 ul. Obrzezna 7 / ul. Koszykowa 75 1299 Warsaw, Mazowieckie 02-691 / 00-662 1300 Poland 1302 Email: marcin.pilarski@orange.com / marcin.pilarski@mini.pw.edu.pl