idnits 2.17.1 draft-bertrand-cdni-footprint-discovery-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2012) is 4252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 304, but not defined == Missing Reference: 'HIGH' is mentioned on line 314, but not defined == Unused Reference: 'RFC2119' is defined on line 504, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-04 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-03 == Outdated reference: A later version (-18) exists of draft-ietf-idr-aigp-08 == Outdated reference: A later version (-02) exists of draft-previdi-cdni-footprint-advertisement-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Bertrand 3 Internet-Draft France Telecom - Orange 4 Intended status: Informational September 3, 2012 5 Expires: March 7, 2013 7 CDN Footprint Discovery 8 draft-bertrand-cdni-footprint-discovery-01 10 Abstract 12 Interconnected CDNs need to exchange information on the set of end- 13 users to which they can deliver content. This information is 14 commonly referred to as "CDN Footprint". This memo presents use 15 cases for CDN Footprint Discovery in CDNI. It provides a survey of 16 existing work on the subject and a set of additional requirements for 17 controlling the exchange of Footprint information. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 7, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Use-Cases for Footprint Discovery . . . . . . . . . . . . . . 5 69 3.1. Protocol Not Required . . . . . . . . . . . . . . . . . . 5 70 3.2. Protocol Potentially Required . . . . . . . . . . . . . . 6 71 4. Additional Requirements . . . . . . . . . . . . . . . . . . . 6 72 5. Survey of CDN Footprint Discovery . . . . . . . . . . . . . . 7 73 5.1. Legacy Protocols . . . . . . . . . . . . . . . . . . . . . 7 74 5.1.1. Legacy BGP . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1.2. Legacy BGP Community Tag . . . . . . . . . . . . . . . 8 76 5.2. New Proposals . . . . . . . . . . . . . . . . . . . . . . 8 77 5.2.1. BGP Extension for CDNI . . . . . . . . . . . . . . . . 8 78 5.2.2. ALTO Footprint . . . . . . . . . . . . . . . . . . . . 8 79 6. Survey of CDN Delivery Proximity Discovery . . . . . . . . . . 9 80 6.1. BGP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.2. BGP AIGP . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 6.3. BGP Extension for CDNI . . . . . . . . . . . . . . . . . . 9 83 6.4. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.5. Generic Capability Advertisement . . . . . . . . . . . . . 10 85 7. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Terminology 96 We adopt the terminology described in 97 [I-D.ietf-cdni-problem-statement] and [I-D.davie-cdni-framework], and 98 extend it with the additional terms defined below. 100 Aggregate CDN Footprint: a set of User-Agent reachability information 101 for which a CDN claims that it can deliver content in good 102 conditions, by itself or through one of its dCDNs. The CDN Footprint 103 aggregates information on the footprint of the dCDNs with whom a uCDN 104 is interconnected. 106 High-Level CDN Footprint: the part of the footprint information that 107 reflects rather static and business-level information. As an 108 example, the failure of a Surrogate does not change the High-level 109 CDN Footprint information but may change detailed information of an 110 element of the CDN Footprint. 112 On-Net Footprint: a set of User-Agent reachability information for 113 which a CDN claims that it can deliver content directly. For 114 instance, a given Access CDN may assert that its On-Net CDN Footprint 115 encompasses all end-users in AS 64496 and AS 64497. 117 CDN Delivery Proximity: Information on the network distance between a 118 set of end-users in the CDN Footprint and the closest Surrogates of 119 the considered CDN or of one of its dCDNs. Various metrics can be 120 considered for defining this distance; examples of such metrics 121 include the AS hop count or an accumulated Interior Gateway Protocol 122 (IGP) metric. 124 CDN Footprint Discovery: discovery of information on CDN Footprint 125 and CDN Delivery Proximity. CDN Footprint Discovery provides the 126 information that enables a uCDN's Request Routing Interface to select 127 the most appropriate dCDN for a given content request. CDN Footprint 128 Discovery encompasses two different parts: 130 1. High-Level Footprint Discovery permits discovering groups of end- 131 users/Surrogates and interconnection costs between them. 133 2. Detailed Footprint Discovery permits exchanging information that 134 is subject to more scalability and confidentiality constraints. 135 The level of information sharing must be tightly controlled. 137 CDN Footprint Discovery Interface: An interface that enables CDN 138 Footprint Discovery. Section 3 details the use cases for a CDN 139 Footprint Discovery Interface. 141 2. Introduction 143 This memo presents use cases for CDN Footprint and CDN Delivery 144 Proximity discovery in CDNI. It provides a survey of existing work 145 on the subject and a set of additional requirements for controlling 146 the exchange of Footprint information. 148 The reader should be familiar with the work of the CDNI WG: 150 o CDNI problem statement [I-D.ietf-cdni-problem-statement] defines 151 the problem area that the CDNI working group is chartered to 152 address. 154 o [I-D.ietf-cdni-use-cases] outlines real world use-cases for 155 interconnecting CDNs. These use cases (e.g., "QoE and QoS 156 Improvement") require the discovery of CDN Footprint information. 158 o [I-D.ietf-cdni-requirements] specifies a set of requirements for 159 CDN Footprint Discovery. 161 The present document describes: 163 o The use cases for CDN Footprint Discovery (Section 3), 165 o The requirements for CDN Footprint Discovery (Section 4), 167 o A survey of Footprint Discovery protocols (Section 5). 169 2.1. Abbreviations 171 o CDN: Content Delivery Network 173 o CDNP: Content Delivery Network Provider 175 o CSP: Content Service Provider 177 o dCDN: downstream CDN 179 o IGP: Interior Gateway Protocol 181 o NSP: Network Service Provider 183 o uCDN: upstream CDN 185 3. Use-Cases for Footprint Discovery 187 The present memo considers the use cases for a Footprint Discovery 188 Protocol in a multi-CDN case [I-D.ietf-cdni-use-cases]. It does not 189 consider mono-CDN issues. 191 [I-D.davie-cdni-framework] (Section 3.5.) describes "Dynamic 192 Footprint Discovery" as a situation where "being able to dynamically 193 discover the set of requests that a given dCDN is willing and able to 194 serve is beneficial. For example, a CDN might at one time be able to 195 serve a certain set of client IP prefixes, but that set might change 196 over time due to changes in the topology and routing policies of the 197 IP network." [I-D.davie-cdni-framework] provides an example where 198 footprint information exchanges occur through the request routing 199 interface and are triggered by an end-user's request (DNS resolution 200 or content request). 202 In the present memo, we seek to clarify in which cases such Footprint 203 Discovery through a protocol is required. 205 3.1. Protocol Not Required 207 In most cases, High-Level CDN Footprint Discovery does not require a 208 protocol, as in the following examples cases: 210 o High-Level CDN Footprint is Germany 212 o High-Level CDN Footprint is AS 64496 214 However, the two following special cases deserve particular 215 attention: 217 1. When the dCDNs' Footprints overlap, 219 2. When end-users outside the dCDNs' Footprints can request content. 221 In these two cases, the uCDN needs additional criteria than the 222 dCDN's Footprint to select the "best" CDN. For instance, a static 223 rule can be configured to select one of the available dCDNs. 224 Alternatively, the uCDN may use dCDN's Delivery Proximity information 225 to elect a delivering CDN. 227 The remainder of this memo focuses on cases, where either CDN 228 Footprint is defined dynamically or uCDN requires dynamic Delivery 229 Proximity information on dCDNs. 231 3.2. Protocol Potentially Required 233 In some cases, the uCDN needs dCDNs' Delivery Proximity information 234 to determine which dCDN is the "best" to serve a given set of end- 235 users. For instance, the "best" CDN can be defined as the one that 236 has deployed Surrogates topologically the closest to the end-user 237 (e.g., an Access CDN). This topological information is tightly 238 related to the underlying networks: one may consider that a Surrogate 239 is topologically far from the end-user if the path between these two 240 entities crosses high cost links or many links. While information 241 about the Surrogates location is rather confidential, abstract 242 information about the path's cost between a set of end-users and the 243 closest Surrogates in a CDN may be generic enough to avoid disclosing 244 confidential information about the network. 246 CDN federations might involve several levels of CDN interconnection. 247 In such scenarios, the CDN Footprint of a given CDN represents the 248 aggregation of the CDN Footprint of all its own dCDNs. Therefore, 249 some variations of the dCDNs' Footprint can result in variations of 250 the CDN's Footprint. This example shows that the more levels of 251 delegation we consider, the more dynamic the CDN Footprint 252 information becomes. Nevertheless, in the medium term, complex 253 deployments scenarios involving more than a few levels of delegations 254 are unlikely, because of performance issues. Consequently, we 255 consider that the High-Level CDN Footprint is rather static and 256 remains valid for at least 24 hours. 258 Depending on the considered metric, the CDN Delivery Proximity may 259 change rarely (e.g., AS hop count) or more frequently (e.g., 260 accumulated IGP metric). 262 4. Additional Requirements 264 [I-D.ietf-cdni-requirements], already specifies two requirements 265 related to Footprint Discovery: REQ-2 and REQ-3. We remind these two 266 requirements below. 268 "REQ-2 [MED] The CDNI Request-Routing interface should allow the 269 Downstream CDN to communicate to the Upstream CDN aggregate 270 information to facilitate CDN selection during request routing, such 271 as Downstream CDN capabilities, resources and affinities (i.e. 272 Preferences or cost). This information could, for example, include: 274 o supported content types and delivery protocols 276 o footprint (e.g., layer-3 coverage) 277 o a set of metrics/attributes (e.g., Streaming bandwidth, storage 278 resources, distribution and delivery priority) 280 o a set of affinities (e.g., Preferences, indication of 281 distribution/delivery fees) 283 o information to facilitate request redirection (e.g., Reachability 284 information of Downstream CDN Request Routing system)." 286 "REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- 287 Routing interface shall allow the Downstream CDN to also include in 288 the information communicated to the Upstream CDN, information on the 289 capabilities, resources and affinities of CDNs to which the 290 Downstream CDN may (in turn) redirect requests received by the 291 Upstream CDN. In that case, the CDNI Request-Routing interface shall 292 prevent looping of such information exchange." 294 We define additional requirements, specific to Footprint Discovery. 296 FPT-1 [MED] A uCDN must be able to discover CDN Footprint and CDN 297 Delivery Proximity information about dCDNs. 299 FPT-2 [HIGH] A dCDN MUST be able to control what other CDNs can 300 discover about its CDN Footprint and CDN Delivery Proximity. 302 We also clarify REQ-3: 304 FPT-3 [MED] A uCDN should not forward to any other CDN the Footprint 305 and Delivery Proximity information that it has discovered about a 306 dCDN without the explicit agreement of this dCDN. 308 Finally, the deployment of a Footprint Discovery Interface imposes 309 some operational requirements. For instance, a Footprint Discovery 310 protocol must not affect network stability and scalability. It must 311 also be simple enough to avoid increasing the networks' operation 312 complexity. 314 FPT-4 [HIGH] A Footprint Discovery protocol should not affect network 315 stability and scalability. 317 5. Survey of CDN Footprint Discovery 319 5.1. Legacy Protocols 320 5.1.1. Legacy BGP 322 Consider a dCDN that claims its CDN Footprint covers AS 64496. BGP 323 advertises AS-Path information that easily enables a uCDN to map end- 324 users to the dCDN, basing on the end-users' IP address and on a 325 mapping of IP addresses to AS numbers. 327 BGP also provides CDN Delivery Proximity information: for instance, a 328 CDN listening to BGP advertisements is able to determine the AS-path 329 length to the advertised prefixes. Note that BGP information might 330 be collected in the network and provided to the CDN through another 331 protocol rather than directly through BGP. 333 5.1.2. Legacy BGP Community Tag 335 The NSP may use part of the community tags carried by its legacy 336 internal BGP to filter and gather the prefixes in stable groups (see 337 section 5.1.7 of [I-D.ietf-alto-deployments]) that are then used by 338 its internal CDN [I-D.jenkins-alto-cdn-use-cases] for fine-grained 339 request routing based on these groups. A protocol (e.g., HTTP-based) 340 can be used to advertise aggregated information on such groups rather 341 than detailed information per prefix. This provides a simple way to 342 aggregate information for scalability and confidentiality purposes. 344 An operator may consider that the grouping of prefixes into zones 345 (the list of prefixes with a given community value) is confidential, 346 as this grouping discloses information on the network's organization. 348 5.2. New Proposals 350 5.2.1. BGP Extension for CDNI 352 [I-D.previdi-cdni-footprint-advertisement] proposes a BGP-based 353 mechanism to advertise connectivity information in the context of 354 CDNI. It is based on the introduction of a CDN sub address Family 355 (SAFI) and leverages BGP (extended) community tags. It uses 356 Multiprotocol-BGP (MP-BGP [RFC4760]) in order for CDNs and/or ISPs to 357 advertise their connectivity to footprints. A new NLRI is defined to 358 carry CDN connectivity advertisements. In summary, the draft defines 359 a "CDN-level BGP" to complement the legacy network-level BGP 360 described in Section 5.1.1 and Section 5.1.2. 362 5.2.2. ALTO Footprint 364 [I-D.jenkins-alto-cdn-use-cases] describes the use cases for a CDN to 365 be able to obtain network topology and cost information from an ALTO 366 server. These use cases include: "Exposing NSP End User Reachability 367 to a CDN, Exposing CDN End User Reachability to CSPs, CDN deployed 368 within a Broadband network, CDN delivering Over-The-Top of a NSP's 369 network, and CDN acquiring content from multiple upstream sources". 370 An additional use case may be to advertise CDN End User Reachability 371 to upstream CDNs. 373 The NSP CDN acting as a dCDN ALTO server may filter and send prefix 374 groups (see Section 5.1.2) to uCDN ALTO clients according to its 375 policies and with respect to a separate agreement it has with each 376 uCDN. A group may appear as a PID in ALTO network and cost maps. 378 6. Survey of CDN Delivery Proximity Discovery 380 6.1. BGP-TE 382 [I-D.gredler-idr-ls-distribution] proposes a BGP-based mechanism by 383 which link state and traffic engineering information can be collected 384 from networks and shared with external components. 386 6.2. BGP AIGP 388 The Accumulated IGP Metric Attribute for BGP [I-D.ietf-idr-aigp] 389 defines a new TLV attribute in BGP that allows redistribution of IGP 390 costs between ASes belonging to the same managing entity. With AIGP, 391 path selection can take into account IGP costs from other ASes for 392 reaching a certain prefix. For the interconnection of multiple CDNs 393 managed by the same entity ("Inter-Affiliates Interconnection" 394 [I-D.ietf-cdni-use-cases]), the AIGP information may enable a uCDN to 395 determine which dCDN is topologically the closest to a set of end- 396 users. However, the deployment limitations of AIGP listed in 397 [I-D.ietf-idr-aigp] (Section 2. and 3.1.) restrict the applicability 398 of AIGP for this use case. 400 6.3. BGP Extension for CDNI 402 See Section 5.2.1. 404 6.4. ALTO 406 [I-D.penno-alto-cdn] (Section 7.1.) describes how ALTO can be used by 407 CDNs in a different administrative domain than the ISP to provide the 408 cost from each CDN node to all known Subscriber PIDs. This mechanism 409 enables the CDN to determine its CDN Delivery Proximity to groups of 410 end users. 412 [I-D.ietf-alto-deployments] discusses deployment related issues of 413 ALTO for peer-to-peer and CDNs. In Section 5.1, it presents the use 414 of ALTO for a mono-CDN case. The ALTO server may leverage the BGP 415 information (e.g., BGP community attribute) to group prefixes into 416 PIDs. ALTO cost map permits providing cost information between PIDs 417 and could be used by a dCDN to communicate its CDN Delivery Proximity 418 to an uCDN. 420 [I-D.seedorf-alto-for-cdni] briefly mentions that ALTO could support 421 selection of downstream CDN but does not indicate the way the ALTO 422 server is fed. 424 6.5. Generic Capability Advertisement 426 [I-D.he-cdni-cap-info-advertising] proposes an HTTP/1.1-based 427 protocol which is used to communicate capability information (e.g., 428 resources, footprint, load) "to facilitate selection of the 429 Downstream CDN by the Upstream CDN request routing system". 431 7. Synthesis 433 The use cases section shows that in the short term, the need for a 434 Footprint Advertisement Protocol is limited to specific use cases. 435 The survey shows that multiple new proposals addressing CDN Footprint 436 Discovery are being defined, but none is mature and fulfills all the 437 requirements yet. 439 As a result, we consider that if there is enough interest for 440 developing a CDN Footprint Advertisement Protocol, more work is 441 needed to fulfill the specific requirements that arise in the context 442 of CDNI. 444 Key building blocks for a Footprint Discovery protocol are clearly 445 identified: 447 1. Information on the network-level connectivity to groups of 448 prefixes, i.e., to groups of end-users, is required. For 449 instance, BGP-level inter-domain routing data can typically be 450 the source of this type of information, which may be advertised 451 through a protocol based on HTTP, for example, or directly 452 through BGP. 454 2. A mechanism to group end-users that must be served from the same 455 set of Surrogates (e.g., representing a given CDN) is required. 456 For example, BGP extended community attribute and ALTO PIDs 457 typically provide such mechanisms. The grouping of end-users can 458 disclose confidential information on the CDN or network 459 organization, therefore, a CDN/NSP will provide the groups' 460 definitions only to its trusted partners. 462 3. A mechanism to discover generic cost information (uCDN Delivery 463 Proximity) for the delivery from a given set of Surrogates (e.g., 464 a CDN) to a given set of end-users is required. For example, 465 ALTO cost maps, legacy BGP, BGP AIGP, and Previdi's MP-BGP 466 extension typically provide such information, which may be 467 advertised through the aforementioned protocols directly or 468 through another protocol (e.g., HTTP based). To fulfill the 469 topology hiding requirements (identified in [RFC5693] (Section 470 5.5.) and [I-D.penno-alto-cdn] (Section 6.1.)), the advertised 471 information must not disclose confidential information on the 472 CDN's and underlying networks' topology (i.e., it must not permit 473 to derive a detailed network map). 475 IETF may design a Footprint Discovery mechanism basing on these 476 building blocks. To increase the chances for this mechanism to be 477 deployed by operators, such a mechanism should give enough control on 478 information advertisement and respect operational requirements such 479 as not being too tightly bound to the network. 481 8. IANA Considerations 483 This memo includes no request to IANA. 485 9. Security Considerations 487 Footprint Discovery exposes information about the internals of CDNs. 488 Therefore, it is subject to confidentiality issues. 490 10. Acknowledgments 492 The authors would like to thank Christian Jacquenet, Yannick Le 493 Louedec, Sophie Nachman-Ghnassia, Iuniana Oprescu, Marcin Pilarski, 494 and Emile Stephan for discussions about early versions of this 495 document. 497 They also thank the contributors of the EU FP7 OCEAN project for 498 valuable inputs. 500 11. References 502 11.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 508 "Multiprotocol Extensions for BGP-4", RFC 4760, 509 January 2007. 511 11.2. Informative References 513 [I-D.davie-cdni-framework] 514 Davie, B. and L. Peterson, "Framework for CDN 515 Interconnection", draft-davie-cdni-framework-01 (work in 516 progress), October 2011. 518 [I-D.gredler-idr-ls-distribution] 519 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 520 "North-Bound Distribution of Link-State and TE Information 521 using BGP", draft-gredler-idr-ls-distribution-02 (work in 522 progress), July 2012. 524 [I-D.he-cdni-cap-info-advertising] 525 He, X., Dawkins, S., Chen, G., Zhang, Y., and W. Ni, 526 "Capability Information Advertising for CDN 527 Interconnection", draft-he-cdni-cap-info-advertising-01 528 (work in progress), March 2012. 530 [I-D.ietf-alto-deployments] 531 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO 532 Deployment Considerations", draft-ietf-alto-deployments-04 533 (work in progress), March 2012. 535 [I-D.ietf-cdni-problem-statement] 536 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 537 Distribution Network Interconnection (CDNI) Problem 538 Statement", draft-ietf-cdni-problem-statement-08 (work in 539 progress), June 2012. 541 [I-D.ietf-cdni-requirements] 542 Leung, K. and Y. Lee, "Content Distribution Network 543 Interconnection (CDNI) Requirements", 544 draft-ietf-cdni-requirements-03 (work in progress), 545 June 2012. 547 [I-D.ietf-cdni-use-cases] 548 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 549 K., and G. Watson, "Use Cases for Content Delivery Network 550 Interconnection", draft-ietf-cdni-use-cases-10 (work in 551 progress), August 2012. 553 [I-D.ietf-idr-aigp] 554 Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 555 "The Accumulated IGP Metric Attribute for BGP", 556 draft-ietf-idr-aigp-08 (work in progress), June 2012. 558 [I-D.jenkins-alto-cdn-use-cases] 559 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 560 S. Previdi, "Use Cases for ALTO within CDNs", 561 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 562 June 2012. 564 [I-D.penno-alto-cdn] 565 Penno, R., Medved, J., Alimi, R., Yang, R., and S. 566 Previdi, "ALTO and Content Delivery Networks", 567 draft-penno-alto-cdn-03 (work in progress), March 2011. 569 [I-D.previdi-cdni-footprint-advertisement] 570 Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and 571 L. Faucheur, "CDNI Footprint Advertisement", 572 draft-previdi-cdni-footprint-advertisement-01 (work in 573 progress), March 2012. 575 [I-D.seedorf-alto-for-cdni] 576 Seedorf, J., "ALTO for CDNi Request Routing", 577 draft-seedorf-alto-for-cdni-00 (work in progress), 578 October 2011. 580 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 581 Optimization (ALTO) Problem Statement", RFC 5693, 582 October 2009. 584 Author's Address 586 Gilles Bertrand 587 France Telecom - Orange 588 38-40 rue du General Leclerc 589 Issy les Moulineaux, 92130 590 FR 592 Phone: +33 1 45 29 89 46 593 Email: gilles.bertrand@orange.com