idnits 2.17.1 draft-ietf-cdni-problem-statement-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 9, 2011) is 4612 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-experiments-01 == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-use-cases-00 -- Duplicate reference: draft-bertrand-cdni-use-cases, mentioned in 'I-D.bertrand-cdni-use-cases-00', was also mentioned in 'I-D.bertrand-cdni-use-cases'. -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) -- Obsolete informational reference (is this intentional?): RFC 3570 (Obsoleted by RFC 6770) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft Velocix (Alcatel-Lucent) 4 Intended status: Informational F. Le Faucheur 5 Expires: March 12, 2012 Cisco 6 N. Bitar 7 Verizon 8 September 9, 2011 10 Content Distribution Network Interconnection (CDNI) Problem Statement 11 draft-ietf-cdni-problem-statement-00 13 Abstract 15 Content Delivery Networks (CDNs) provide numerous benefits: reduced 16 delivery cost for cacheable content, improved quality of experience 17 for End Users and increased robustness of delivery. For these 18 reasons they are frequently used for large-scale content delivery. 19 As a result, existing CDN providers are scaling up their 20 infrastructure and many Network Service Providers (NSPs) are 21 deploying their own CDNs. It is generally desirable that a given 22 content item can be delivered to an End User regardless of that End 23 User's location or attachment network. This creates a requirement 24 for interconnecting standalone CDNs so they can interoperate as an 25 open content delivery infrastructure for the end-to-end delivery of 26 content from Content Service Providers (CSPs) to End Users. However, 27 no standards or open specifications currently exist to facilitate 28 such CDN interconnection. 30 The goal of this document is to outline the problem area of CDN 31 interconnection (CDNI) for the IETF. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on March 12, 2012. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 9 76 2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 9 77 3. CDN Interconnect Model & Problem Area for IETF . . . . . . . . 11 78 3.1. Candidate CDNI Problem Area for IETF . . . . . . . . . . . 13 79 4. Design Approach for Realizing the CDNI APIs . . . . . . . . . 15 80 4.1. Relationship to the OSI network model . . . . . . . . . . 15 81 4.2. "Reuse Instead of Reinvent" Principle . . . . . . . . . . 16 82 4.3. CDNI Request Routing Interface . . . . . . . . . . . . . . 16 83 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 18 84 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 19 85 4.6. CDNI Control Interface . . . . . . . . . . . . . . . . . . 20 86 5. Gap Analysis of relevant Standardization and Research 87 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 5.1. Content Acquisition across CDNs and Delivery to End 89 User (Data plane) . . . . . . . . . . . . . . . . . . . . 21 90 5.2. CDNI Metadata . . . . . . . . . . . . . . . . . . . . . . 22 91 6. Relationship to relevant IETF Working Groups . . . . . . . . . 23 92 6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 6.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 6.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 101 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 29 102 A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 29 103 A.2. Prioritizing the CDNI Work . . . . . . . . . . . . . . . . 30 104 A.3. Related standardization activities . . . . . . . . . . . . 31 105 A.3.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 31 106 A.3.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 A.3.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 32 108 A.3.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 33 109 A.3.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 33 110 A.3.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 33 111 A.3.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 34 112 A.3.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 34 113 A.3.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 34 114 A.3.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 35 115 A.3.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 A.4. Related Research Projects . . . . . . . . . . . . . . . . 35 117 A.4.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 35 118 A.4.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 35 119 A.4.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 36 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 122 1. Introduction 124 The volume of video and multimedia content delivered over the 125 Internet is rapidly increasing and expected to continue doing so in 126 the future. In the face of this growth, Content Delivery Networks 127 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 128 content, improved quality of experience for End Users and increased 129 robustness of delivery. For these reasons CDNs are frequently used 130 for large-scale content delivery. As a result, existing CDN 131 providers are scaling up their infrastructure and many Network 132 Service Providers (NSPs) are deploying their own CDNs. It is 133 generally desirable that a given content item can be delivered to an 134 End User regardless of that End User's location or attachment 135 network. However, the footprint of a given CDN in charge of 136 delivering a given content may not expand close enough to the End 137 User's current location or attachment network to realize the cost 138 benefit and user experience that a more distributed CDN would 139 provide. This creates a requirement for interconnecting standalone 140 CDNs so that their collective CDN footprint can be leveraged for the 141 end-to-end delivery of content from Content Service Providers (CSPs) 142 to End Users. However, no standards or open specifications currently 143 exist to facilitate such CDN interconnection. 145 The goal of this document is to outline the problem area of CDN 146 interconnection (CDNI) for the IETF. 148 Section 2 discusses the use cases for CDN interconnection. Section 3 149 presents the CDNI model and problem area to be considered by the 150 IETF. Section 4 discusses how existing protocols can be reused to 151 define the CDNI interfaces while Appendix A.2 proposes to focus the 152 scope for the initial charter of a CDNI Working Group to the minimum 153 functional elements necessary for basic CDN interconnection. 154 Appendix A.2 provides a gap analysis of the work of other standards 155 organizations and finally Appendix A.2 discusses the relationship 156 with relevant IETF Working Groups. 158 1.1. Terminology 160 This document uses the following terms: 162 Content: Any form of digital data. One important form of Content 163 with additional constraints on Distribution and Delivery is 164 continuous media (i.e. where there is a timing relationship between 165 source and sink). 167 Metadata: Metadata in general is data about data. 169 Content Metadata: This is metadata about Content. Content Metadata 170 comprises: 172 1. Metadata that is relevant to the distribution of the content (and 173 therefore relevant to a CDN involved in the delivery of that 174 content). We refer to this type of metadata as "Content 175 Distribution Metadata". See also the definition of Content 176 Distribution Metadata. 177 2. Metadata that is associated with the actual Content (and not 178 directly relevant to the distribution of that Content) or content 179 representation. For example, such metadata may include 180 information pertaining to the Content's genre, cast, rating, etc 181 as well as information pertaining to the Content representation's 182 resolution, aspect ratio, etc. 184 Content Distribution Metadata: The subset of Content Metadata that is 185 relevant to the distribution of the content. This is the metadata 186 required by a CDN in order to enable and control content distribution 187 and delivery by the CDN. In a CDN Interconnection environment, some 188 of the Content Distribution Metadata may have an intra-CDN scope (and 189 therefore need not be communicated between CDNs), while some of the 190 Content Distribution Metadata have an inter-CDN scope (and therefore 191 needs to be communicated between CDNs). 193 CDNI Metadata: Content Distribution Metadata with inter-CDN scope. 194 For example, CDNI Metadata may include geo-blocking information (i.e. 195 information defining geographical areas where the content is to be 196 made available or blocked), availability windows (i.e. information 197 defining time windows during which the content is to be made 198 available or blocked) and access control mechanisms to be enforced 199 (e.g. URI signature validation). CDNI Metadata may also include 200 information about desired distribution policy (e.g. prepositioned vs 201 dynamic acquisition) and about where/how a CDN can acquire the 202 content. CDNI Metadata may also include content management 203 information (e.g. request for deletion of Content from Surrogates) 204 across interconnected CDNs. 206 Dynamic content acquisition: Dynamic content acquisition is where a 207 CDN acquires content from the content source in response to an End 208 User requesting that content from the CDN. In the context of CDN 209 Interconnection, dynamic acquisition means that a downstream CDN does 210 not acquire the content from content sources (including upstream 211 CDNs) until a request for that content has been delegated to the 212 downstream CDN by an Upstream CDN. 214 Dynamic CDNI metadata acquisition: In the context of CDN 215 Interconnection, dynamic CDNI metadata acquisition means that a 216 downstream CDN does not acquire CDNI metadata for content from the 217 upstream CDN until a request for that content has been delegated to 218 the downstream CDN by an Upstream CDN. 220 Pre-positioned content acquisition: Content Pre-positioning is where 221 a CDN acquires content from the content source prior to or 222 independent of any End User requesting that content from the CDN. In 223 the context of CDN interconnection the Upstream CDN instructs the 224 Downstream CDN to acquire the content from content sources (including 225 upstream CDNs) in advance of or independent of any End User 226 requesting it. 228 Pre-positioned CDNI Metadata acquisition: In the context of CDN 229 Interconnection, Metadata pre-positioning is where the Downstream CDN 230 acquires CDNI metadata for content prior to or independent of any End 231 User requesting that content from the Downstream CDN. 233 End User (EU): The 'real' user of the system, typically a human but 234 maybe some combination of hardware and/or software emulating a human 235 (e.g. for automated quality monitoring etc.) 237 User Agent (UA): Software (or a combination of hardware and software) 238 through which the End User interacts with the Content Service. The 239 User Agent will communicate with the CSP's service for the selection 240 of content and one or more CDNs for the delivery of the Content. 241 Such communication is not restricted to HTTP and may be via a variety 242 of protocols. Examples of User Agents (non-exhaustive) are: 243 Browsers, Set Top Boxes (STB), dedicated content applications (e.g. 244 media players), etc. 246 Network Service Provider (NSP): Provides network-based connectivity/ 247 services to End Users. 249 Content Service Provider (CSP): Provides a Content Service to End 250 Users (which they access via a User Agent). A CSP may own the 251 Content made available as part of the Content Service, or may license 252 content rights from another party. 254 Content Service: The service offered by a Content Service Provider. 255 The Content Service encompasses the complete service which may be 256 wider than just the delivery of items of Content, e.g. the Content 257 Service also includes any middleware, key distribution, program 258 guide, etc. which may not require any direct interaction with the 259 CDN. 261 Content Distribution Network (CDN) / Content Delivery Network (CDN): 262 Network infrastructure in which the network elements cooperate at 263 layers 4 through layer 7 for more effective delivery of Content to 264 User Agents. Typically a CDN consists of a Request Routing system, a 265 Distribution System (that includes a set of Surrogates), a Logging 266 System and a CDN control system. 268 CDN Provider: The service provider who operates a CDN. Note that a 269 given entity may operate in more than one role. For example, a 270 company may simultaneously operate as a Content Service Provider, a 271 Network Service Provider and a CDN Provider. 273 CDN Interconnection (CDNI): The set of interfaces over which two or 274 more CDNs communicate with each other in order to achieve the 275 delivery of content to User Agents by Surrogates in one CDN (the 276 downstream CDN) on behalf of another CDN (the upstream CDN). 278 Authoritative CDN: A CDN which has a direct relationship with a CSP 279 for the distribution & delivery of that CSP's content. 281 Upstream CDN: For a given user request, the CDN (within a pair of 282 directly interconnected CDNs) that redirects the request to the other 283 CDN. 285 Downstream CDN: For a given user request, the CDN (within a pair of 286 directly interconnected CDNs) to which the request is redirected by 287 the other CDN (the Upstream CDN). Note that in the case of 288 successive redirections (e.g. CDN1-->CDN2-->CDN3) a given CDN (e.g. 289 CDN2) may act as the Downstream CDN for a redirection (e.g. 290 CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection 291 of the same request (e.g. CDN2-->CDN3). 293 Over-the-top (OTT): A service, e.g. a CDN, operated by a different 294 operator than the NSP to which the users of that service are 295 attached. 297 Surrogate: A device/function that interacts with other elements of 298 the CDN for the control and distribution of Content within the CDN 299 and interacts with User Agents for the delivery of the Content. 301 Request Routing System: The function within a CDN responsible for 302 receiving a content request from a User Agent, obtaining and 303 maintaining necessary information about a set of candidate surrogates 304 or candidate CDNs, and for selecting and redirecting the user to the 305 appropriate surrogate or CDN. To enable CDN Interconnection, the 306 Request Routing System must also be capable of handling User Agent 307 content requests passed to it by another CDN. 309 Distribution System: the function within a CDN responsible for 310 distributing Content Distribution Metadata as well as content inside 311 the CDN (e.g. down to the surrogates) 313 Delivery: the function within CDN surrogates responsible for 314 delivering a piece of content to the User Agent. For example, 315 delivery may be based on HTTP progressive download or HTTP adaptive 316 streaming. 318 Logging System: the function within a CDN responsible for collecting 319 measurement and recording of distribution and delivery activities. 320 The information recorded by the logging system may be used for 321 various purposes including charging (e.g. of the CSP), analytics and 322 monitoring. 324 1.2. CDN Background 326 Readers are assumed to be familiar with the architecture, features 327 and operation of CDNs. For readers less familiar with the operation 328 of CDNs, the following resources may be useful: 330 o RFC 3040 [RFC3040] describes many of the component technologies 331 that are used in the construction of a CDN 332 o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs 333 o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the 334 IETF Content Delivery Internetworking (CDI) working group which 335 was closed in 2003. 337 Note: Some of the terms used in this document are similar to terms 338 used the above referenced documents. When reading this document 339 terms should be interpreted as having the definitions provided in 340 Section 1.1. 342 2. CDN Interconnect Use Cases 344 An increasing number of NSPs are deploying CDNs in order to deal 345 cost-effectively with the growing usage of on-demand video services 346 and other content delivery applications. 348 CDNs allow caching of content closer to the edge so that a given item 349 of content can be delivered by a CDN Surrogate (i.e. a cache) to 350 multiple User Agents (and their End Users) without transiting 351 multiple times through the network core (i.e from the content origin 352 to the surrogate). This contributes to bandwidth cost reductions for 353 the NSP and to improved quality of experience for the End Users. 354 CDNs also enable replication of popular content across many 355 surrogates, which enables content to be served to large numbers of 356 User Agents concurrently. This also helps dealing with situations 357 such as flash crowds and denial of service attacks. 359 The CDNs deployed by NSPs are not just restricted to the delivery of 360 content to support the Network Service Provider's own 'walled garden' 361 services, such as IP delivery of television services to Set Top 362 Boxes, but are also used for delivery of content to other devices 363 including PCs, tablets, mobile phones etc. 365 Some service providers operate over multiple geographies and federate 366 multiple affiliate NSPs. These NSPs typically operate independent 367 CDNs. As they evolve their services (e.g. for seamless support of 368 content services to nomadic users across affiliate NSPs) there is a 369 need for interconnection of these CDNs. However there are no open 370 specifications, nor common best practices, defining how to achieve 371 such CDN interconnection. 373 CSPs have a desire to be able to get (some of) their content to very 374 large number of End Users and/or over many/all geographies and/or 375 with a high quality of experience, all without having to maintain 376 direct business relationships with many different CDN providers (or 377 having to extend their own CDN to a large number of locations). Some 378 NSPs are considering interconnecting their respective CDNs (as well 379 as possibly over-the-top CDNs) so that this collective infrastructure 380 can address the requirements of CSPs in a cost effective manner. In 381 particular, this would enable the CSPs to benefit from on-net 382 delivery (i.e. within the Network Service Provider's own network/CDN 383 footprint) whenever possible and off-net delivery otherwise, without 384 requiring the CSPs to maintain direct business relationships with all 385 the CDNs involved in the delivery. Again, for this requirement, CDN 386 operators (NSPs or over-the-top CDN operators) are faced with a lack 387 of open specifications and best practices. 389 NSPs have often deployed CDNs as specialized cost-reduction projects 390 within the context of a particular service or environment, some NSPs 391 operate separate CDNs for separate services. For example, there may 392 be a CDN for managed IPTV service delivery, a CDN for web-TV delivery 393 and a CDN for video delivery to Mobile terminals. As NSPs integrate 394 their service portfolio, there is a need for interconnecting these 395 CDNs. Again, NSPs face the problem of lack of open interfaces for 396 CDN interconnection. 398 For operational reasons (e.g. disaster, flash crowd) or commercial 399 reasons, an over-the-top CDN may elect to make use of another CDN 400 (e.g. an NSP CDN with on-net Surrogates for a given footprint) for 401 serving a subset of the user requests (e.g. requests from users 402 attached to that NSP). Again, for this requirement, CDN operators 403 (over-the-top CDN operators or NSPs) are faced with a lack of open 404 specifications and best practices. 406 Use cases for CDN Interconnection are further discussed in 407 [I-D.bertrand-cdni-use-cases] (which contains a merged set of use 408 cases previously presented in [I-D.watson-cdni-use-cases] and 410 [I-D.bertrand-cdni-use-cases-00]). 412 3. CDN Interconnect Model & Problem Area for IETF 414 Interconnecting CDNs involves interactions among multiple different 415 functions and components that form each CDN. Only some of those 416 require standardization. The CDNI model and problem area proposed 417 for IETF work is illustrated in Figure 1. The candidate problem area 418 (and respectively the non-goals) for IETF work on CDN Interconnection 419 are discussed in Section 3.1 (and respectively Appendix A.1 ). 421 -------- 422 / \ 423 | CSP | 424 \ / 425 -------- 426 * 427 * 428 * /\ 429 * / \ 430 ---------------------- |CDNI| ---------------------- 431 / Upstream CDN \ | | / Downstream CDN \ 432 | +-------------+ | Control Interface| +-------------+ | 433 |******* Control |<======|====|========>| Control *******| 434 |* +------*----*-+ | | | | +-*----*------+ *| 435 |* * * | | | | * * *| 436 |* +------*------+ | Logging Interface| +------*------+ *| 437 |* ***** Logging |<======|====|========>| Logging ***** *| 438 |* * +-*-----------+ | | | | +-----------*-+ * *| 439 |* * * * | Request Routing | * * * *| 440 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 441 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 442 . |* * * +-------------+.| | | | +-------------+ * * *| . 443 . |* * * . CDNI Metadata | * * *| . 444 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 445 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 446 . |* * * | | | . \ / | | | * * *| . 447 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 448 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 449 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 450 . |******* +---------+| | Acquisition | |+----------+ *******| . 451 . | +-------------+ | | +-------*-----+ | . 452 . \ / \ * / . 453 . ---------------------- ---------*------------ . 454 . * . 455 . * Delivery . 456 . * . 457 . +--*---+ . 458 ...............Request.............................| User |..Request.. 459 | Agent| 460 +------+ 462 <==> interfaces inside the scope of CDNI 464 **** interfaces outside the scope of CDNI 465 .... interfaces outside the scope of CDNI 467 Figure 1: CDNI Problem Area 469 3.1. Candidate CDNI Problem Area for IETF 471 Listed below are the four interfaces required to interconnect a pair 472 of CDNs and that constitute the problem space that is proposed to be 473 addressed by a potential CDNI working group in the IETF. The use of 474 the term "interface" is meant to encompass the protocol over which 475 CDNI data representations (e.g. CDNI Metadata records) are exchanged 476 as well as the specification of the data representations themselves 477 (i.e. what properties/fields each record contains, its structure, 478 etc.). 480 o CDNI Control interface: This interface allows the "CDNI Control" 481 system in interconnected CDNs to communicate. This interface may 482 support the following: 483 * Allow bootstrapping of the other CDNI interfaces (e.g. 484 interface address/URL discovery and establishment of security 485 associations). 486 * Allow configuration of the other CDNI interfaces (e.g. 487 Upstream CDN specifies information to be reported through the 488 CDNI Logging interface). 489 * Allow the downstream CDN to communicate static (or fairly 490 static) information about its delivery capabilities and 491 policies. 492 * Allow bootstrapping of the interface between CDNs for content 493 acquisition (even if that interface itself is outside the scope 494 of the CDNI work). 495 * Allow upstream CDN to initiate or request specific actions to 496 be undertaken in the downstream CDN. For example, this may 497 include the following capabilities: 498 + Allow an upstream CDN to request that content files and/or 499 CDNI Metadata that it shared, be purged from, or invalidated 500 in, a downstream CDN. Support for content deletion or 501 invalidation from a CDN is a key requirement for some 502 Content Service Providers in order, amongst other use cases 503 for content deletion, to support the content rights 504 agreements they have negotiated. Today's CDNs use 505 proprietary control interfaces to enable CSPs to remove 506 content cached in the CDN and therefore there is a need to 507 have a similar but standardized content deletion capability 508 between interconnected CDNs. 509 + Allow an upstream CDN to initiate Pre-positioned content 510 acquisition and/or Pre-positioned CDN Metadata acquisition 511 in a downstream CDN. 512 o CDNI Request Routing interface: This interface allows the Request 513 Routing system in interconnected CDNs to communicate to ensure 514 that an End User request can be (re)directed from an upstream CDN 515 to a surrogate in the downstream CDN, in particular where 516 selection responsibilities may be split across CDNs (for example 517 the upstream CDN may be responsible for selecting the downstream 518 CDN while the downstream CDN may be responsible for selecting the 519 actual surrogate within that CDN). In particular, the CDN Request 520 Routing interface, may support the following: 521 * allow the upstream CDN to query the downstream CDN at request- 522 routing time before redirecting the request to the downstream 523 CDN 524 * allow the downstream CDN to provide to the upstream CDN (static 525 or dynamic) information (e.g. resources, footprint, load) to 526 facilitate selection of the downstream CDN by the upstream CDN 527 request routing system when processing subsequent content 528 requests from User Agents. 529 o CDNI Metadata distribution interface: This interface allows the 530 Distribution system in interconnected CDNs to communicate to 531 ensure CDNI Metadata can be exchanged across CDNs. See 532 Section 1.1 for definition and examples of CDNI Metadata. 533 o CDNI Logging interface: This interface allows the Logging system 534 in interconnected CDNs to communicate the relevant activity logs 535 in order to allow log consuming applications to operate in a 536 multi-CDN environments. For example, an upstream CDN may collect 537 delivery logs from a downstream CDN in order to perform 538 consolidated charging of the CSP or for settlement purposes across 539 CDNs. Similarly, an upstream CDN may collect delivery logs from a 540 downstream CDN in order to provide consolidated reporting and 541 monitoring to the CSP. 543 Note that the actual grouping of functionalities under these four 544 interfaces is considered tentative at this stage and may be changed 545 after further study (e.g. some subset of functionality be moved from 546 one interface into another). 548 The above list covers a significant potential problem space, in part 549 because in order to interconnect two CDNs there are several 'touch 550 points' that require standardization. However, it is expected that 551 the CDNI interfaces need not be defined from scratch and instead can 552 very significantly reuse or leverage existing protocols: this is 553 discussed further in Section 4. Also, it is expected that the items 554 above will be prioritized so that the CDNI Working Group can focus 555 (at least initially) on the most essential and urgent work: this is 556 discussed further in Appendix A.2. 558 As part of the development of the CDNI interfaces and solutions it 559 will also be necessary to agree on common mechanisms for how to 560 identify and name the data objects that are to be interchanged 561 between interconnected CDNs, as well as how to describe which policy 562 should be used when doing so. [I-D.jenkins-cdni-names] presents one 563 view on how CDN data types/objects could be classified such that the 564 problem space of their naming and referencing is not as large as it 565 might at first appear because there is significant commonality 566 between the different data types/objects required for CDNI. 568 Some NSPs have started to perform experiments to explore whether 569 their CDN use cases can already be addressed with existing CDN 570 implementations. One set of such experiments is documented in 571 [I-D.bertrand-cdni-experiments]. The conclusions of those 572 experiments are that while some basic limited CDN Interconnection 573 functionality can be achieved with existing CDN technology, the 574 current lack of any standardized CDNI interfaces/protocols such as 575 those discussed in this document is preventing the deployment of 576 production CDN Interconnection solutions with the necessary level of 577 functionality. 579 The acquisition of content between interconnected CDNs is out of 580 scope for CDNI and deserves some additional explanation. The 581 consequence of such a decision is that the CDNI WG is focussed on 582 only defining the control plane for CDNI; and the CDNI data plane 583 (i.e. the acquisition & distribution of the actual content objects) 584 will not be addressed by a CDNI WG. The rationale for such a 585 decision is that CDNs today typically already use standardized 586 protocols such as HTTP, FTP, rsync, etc. to acquire content from 587 their CSP customers and it is expected that the same protocols could 588 be used for acquisition between interconnected CDNs. Therefore the 589 problem of content acquisition is considered already solved and all 590 that is required from specifications developed by the CDNI WG is to 591 describe within the CDNI Metadata where to go and which protocol to 592 use to retrieve the content. 594 4. Design Approach for Realizing the CDNI APIs 596 This section expands on how CDNI interfaces can reuse and leverage 597 existing protocols. First the "reuse instead of reinvent" design 598 principle is restated, then each inetrface is discussed individually 599 with example candidate protocols that can be considered for reuse or 600 leverage. This discussion is not intended to pre-empt any WG 601 decision as to the most appropriate protocols, technologies and 602 solutions to select to solve CDNI but is intended as an illustration 603 of the fact that the CDNI interfaces need not be created in a vacuum 604 and that reuse or leverage of existing protocols is likely possible. 606 4.1. Relationship to the OSI network model 608 The four CDNI interfaces (CDNI Control interface, CDNI Request 609 Routing interface, CDNI Metadata interface, CDNI Logging interface) 610 described in Section 3.1 within the CDNI problem area are all control 611 plane interfaces operating at the application layer (Layer 7 in the 612 OSI network model). Since it is not expected that these interfaces 613 would exhibit unique session, transport or network requirements as 614 compared to the many other existing applications in the Internet, it 615 is expected that the CDNI interfaces will be defined on top of 616 existing session, transport and network protocols. 618 4.2. "Reuse Instead of Reinvent" Principle 620 Although a new application protocol could be designed specifically 621 for CDNI we assume that this is unnecessary and it is recommended 622 that existing application protocols be reused or leveraged (HTTP 623 [RFC2616], Atom Publishing Protocol [RFC5023], XMPP [RFC6120], for 624 example) to realize the CDNI interfaces. 626 4.3. CDNI Request Routing Interface 628 The CDNI Request Routing interface enables a Request Routing function 629 in an upstream CDN to query a Request Routing function in a 630 downstream CDN to determine if the downstream CDN is able (and 631 willing) to accept the delegated content request and to allow the 632 downstream CDN to control what the upstream Request Routing function 633 should return to the User Agent in the redirection message. 635 The CDNI Request Routing interface needs to offer a mechanism for an 636 upstream CDN to issue a "Redirection Request" to a downstream CDN. 637 The Request Routing interface needs to be able to support scenarios 638 where the initial User Agent request to the upstream CDN is received 639 over DNS as well as over a content specific application protocol 640 (e.g. HTTP, RTSP, RTMP, etc.). 642 Therefore a Redirection Request needs to contain information such as: 644 o The protocol (e.g. DNS, HTTP) over which the upstream CDN 645 received the initial User Agent request 646 o Additional details of the User Agent request that are required to 647 perform effective Request Routing by the Downstream CDN. For DNS 648 this would typically be the IP address of the DNS resolver making 649 the request on behalf of the User Agent. For requests received 650 over content specific application protocols the Redirection 651 Request could contain significantly more information related to 652 the original User Agent request but at a minimum would need to 653 contain the User Agent's IP address, the equivalent of the HTTP 654 Host header and the equivalent of the HTTP abs_path defined in 655 [RFC2616]. 657 It should be noted that, the CDNI architecture needs to consider that 658 a downstream CDN may receive requests from User Agents without first 659 receiving a Redirection Request from an upstream CDN, for example 660 because: 662 o User Agents (or DNS resolvers) may cache DNS or application 663 responses from Request Routers. 664 o Responses to Redirection Requests over the Request Routing 665 interface may be cacheable. 666 o Some CDNs may want broader policies, e.g. CDN B agrees to always 667 take CDN A's delegated redirection requests, in which case the 668 necessary redirection details are exchanged out of band (of the 669 CDNI interfaces), e.g. configured. 671 On receiving a Redirection Request, the downstream CDN will use the 672 information provided in the request to determine if it is able (and 673 willing) to accept the delegated content request and needs to return 674 the result of its decision to the upstream CDN. 676 Thus, a Redirection Response from the downstream CDN needs to contain 677 information such as: 679 o Status code indicating acceptance or rejection (possibly with 680 accompanying reasons). 681 o Information to allow redirection by the Upstream CDN. In the case 682 of DNS-based request routing, this is expected to include the 683 equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN 684 should return to the requesting DNS resolver. In the case of 685 application based request routing, this is expected to include the 686 application specific redirection response(s) to return to the 687 requesting User Agent. For HTTP requests from User Agents this 688 could be in the form of a URI that the upstream CDN could return 689 in a HTTP 302 response. 691 The CDNI Request Routing interface is therefore a fairly 692 straightforward request/response interface and could be implemented 693 over any number of request/response protocols. For example, it may 694 be implemented as a WebService using one of the common WebServices 695 methodologies (XML-RPC, HTTP query to a known URI, etc.). This 696 removes the need for a CDNI WG to define a new protocol for the 697 request/response element of the CDNI Request Routing interface. 698 Thus, a CDNI WG would be left only with the task of specifying: 700 o The recommended request/response protocol to use along with any 701 additional semantics and procedures that are specific to the CDNI 702 Request Routing interface (e.g. handling of malformed requests/ 703 responses). 704 o The syntax (i.e representation/encoding) of the redirection 705 requests and responses. 707 o The semantics (i.e. meaning and expected contents) of the 708 redirection requests and responses. 710 4.4. CDNI Metadata Interface 712 The CDNI Metadata interface enables the Metadata function in a 713 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 714 the downstream CDN can properly process and respond to: 716 o Redirection Requests received over the CDNI Request Routing 717 interface. 718 o Content Requests received directly from User Agents. 720 The CDNI Metadata interface needs to offer a mechanism for an 721 Upstream CDN to: 722 o distribute/update/remove CDNI Metadata to a Downstream CDN 724 and/or to allow a downstream CDN to: 726 o Make direct requests for CDNI Metadata records where the 727 downstream CDN knows the identity of the Metadata record(s) it 728 requires. 729 o Search for CDNI Metadata records where the downstream CDN does not 730 know the specific Metadata record(s) it requires but does know 731 some property of the record it is searching for. For example, it 732 may know the value of the HTTP Host header received in a HTTP 733 request and it wants to obtain the CDNI Metadata for that host so 734 that it can determine how to further process the received HTTP 735 request. 737 The CDNI Metadata interface is therefore similar to the CDNI Request 738 Routing interface because it is a request/response interface with the 739 potential addition that CDNI Metadata search may have more complex 740 semantics than a straightforward Request Routing redirection request. 741 Therefore, like the CDNI Request Routing interface, the CDNI Metadata 742 interface may be implemented as a WebService using one of the common 743 WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 744 or possibly using other existing protocols such as XMPP [RFC6120]. 745 This removes the need for a CDNI WG to define a new protocol for the 746 request/response element of the CDNI Metadata interface. 748 Thus, a CDNI WG would be left only with the task of specifying: 750 o The recommended request/response protocol to use along with any 751 additional semantics that are specific to the CDNI Metadata 752 interface (e.g. handling of malformed requests/responses). 754 o The syntax (i.e representation/encoding) of the CDNI Metadata 755 records that will be exchanged over the interface. 756 o The semantics (i.e. meaning and expected contents) of the 757 individual properties of a Metadata record. 758 o How the relationships between different CDNI Metadata records are 759 represented. 761 4.5. CDNI Logging Interface 763 The CDNI Logging interface enables details of logs or events to be 764 exchanged between interconnected CDNs, where events could be: 766 o Log lines related to the delivery of content (similar to the log 767 lines recorded in a web server's access log). 768 o Real-time or near-real time events before, during or after content 769 delivery, e.g. content Start/Pause/Stop events, etc. 770 o Operations and diagnostic messages. 772 Within CDNs today, logs and events are used for a variety of purposes 773 in addition to real-time and non real-time diagnostics and auditing 774 by the CDN Operator and its customers. Specifically CDNs use logs to 775 generate Call Data Records (CDRs) for passing to billing and payment 776 systems and to real-time (and near real-time) analytics systems. 777 Such use cases place requirements on the CDNI Logging interface to 778 support guaranteed and timely delivery of log messages between 779 interconnected CDNs. It may also be necessary to be able to prove 780 the integrity of received log messages. 782 Several protocols already exist that could potentially be used to 783 exchange CDNI logs between interconnected CDNs including SNMP Traps, 784 syslog, ftp, HTTP POST, etc. although it is likely that some of the 785 candidate protocols may not be well suited to meet all the 786 requirements of CDNI. For example SNMP traps pose scalability 787 concerns and SNMP does not support guaranteed delivery of Traps and 788 therefore could result in log records being lost and the consequent 789 CDRs and billing records for that content delivery not being produced 790 as well as that content delivery being invisible to any analytics 791 platforms. 793 Although it is not necessary to define a new protocol for exchanging 794 logs across the CDNI Logging interface, a CDNI WG would still need to 795 specify: 797 o The recommended protocol to use. 798 o A default set of log fields and their syntax & semantics. Today 799 there is no standard set of common log fields across different 800 content delivery protocols and in some cases there is not even a 801 standard set of log field names and values for different 802 implementations of the same delivery protocol. 803 o A default set of events that trigger logs to be generated. 805 4.6. CDNI Control Interface 807 The CDNI Control interface allows the "CDNI Control" system in 808 interconnected CDNs to communicate. The exact inter-CDN control 809 functionality required to be supported by the CDNI Control interface 810 is less well defined than the other three CDNI interfaces at this 811 time. 813 However, as discussed in Section 3.1, the CDNI Control interface may 814 be required to support functionality similar to the following: 815 o Allow an upstream CDN and downstream CDN to establish, update or 816 terminate their CDNI interconnection. 817 o Allow bootstrapping of the other CDNI interfaces (e.g. protocol 818 address discovery and establishment of security associations). 819 o Allow configuration of the other CDNI interfaces (e.g. Upstream 820 CDN specifies information to be reported through the CDNI Logging 821 interface). 822 o Allow the downstream CDN to communicate static information about 823 its delivery capabilities, resources and policies. 824 o Allow bootstrapping of the interface between CDNs for content 825 acquisition (even if that interface itself is outside the scope of 826 the CDNI work). 827 It is expected that for the Control inetrface also, existing 828 protocols can be reused or leveraged. Those will be considered once 829 the requirements for the Control interface have been refined. 831 5. Gap Analysis of relevant Standardization and Research Activities 833 There are a number of other standards bodies and industry forums that 834 are working in areas related to CDNs, and in some cases related to 835 CDNI. This section outlines any potential overlap with the work of 836 the CDNI WG and any component that could potentially be reused by 837 CDNI. 839 A number of standards bodies have produced specifications related to 840 CDNs, namely: 842 o TISPAN has a dedicated specification for CDN. 843 o OIPF and ATIS specify the architecture and the protocols of an 844 IPTV solution. Although OIPF and ATIS specifications include the 845 interaction with a CDN, the CDN specifications are coupled with 846 their IPTV specifications. 848 o 849 o IETF CDN WG (now concluded) touched on the same problem space as 850 the present document. However, in accordance with its initial 851 charter, the CDI WG did not define any protocols or interfaces to 852 actually enable CDN Interconnection and at that time (2003) there 853 was not enough industry interest and real life requirements to 854 justify rechartering the WG to conduct the corresponding protocol 855 work. 857 Although some of the specifications describe multi-CDN cooperation or 858 include reference points for interconnecting CDNs, none of them 859 specify in sufficient detail all the CDNI interfaces and CDNI 860 Metadata representations required to enable even a base level of CDN 861 Interconnection functionality to be implemented. 863 The following sections will summarize the existing work of the 864 standard bodies above against the CDNI problem space. 866 5.1. Content Acquisition across CDNs and Delivery to End User (Data 867 plane) 869 A number of standards bodies have completed work in the areas of 870 content acquisition interface between a CSP and a CDN, as well as as 871 on the delivery interface between the surrogate and the User Agent. 872 Some of this work is summarized below. 874 TISPAN, OIPF and ATIS have specified IPTV and/or CoD services, 875 including the data plane aspects (typically different flavors of RTP/ 876 RTCP and HTTP) to obtain content and deliver it to User Agents. For 877 example, : 878 o The OIPF data plane includes both RTP and HTTP flavors (HTTP 879 progressive download, HTTP Adaptive streaming [_3GP-DASH],...). 880 o ATIS specification "IPTV Content on Demand (CoD) Service" 881 [ATIS-COD] defines a reference point (C2) and the corresponding 882 HTTP-based data plane protocol for content acquisition between an 883 authoritative origin server and the CDN. 884 While these protocols have not been explicitly specified for content 885 acquisition across CDNs, they are suitable (in addition to others 886 such as standard HTTP) for content acquisition between CDNs in a CDN 887 Interconnection environment. Therefore for the purpose of a CDNI WG 888 there are already multiple existing data plane protocols that can be 889 used for content acquisition across CDNs. 891 Similarly, there are multiple existing standards (e.g. OIPF data 892 plane mentioned above, HTTP adaptive streaming [_3GP-DASH]) or public 893 specifications (e.g. vendor specific HTTP Adaptive streaming 894 specification) so that content delivery is considered already solved 895 (or at least sufficiently addressed in other forums). 897 Thus, specification of the content acquisition interface between CDNs 898 and the delivery interface between the surrogate and the User Agent 899 are out of scope for CDNI. CDNI may only concern itself with the 900 negotiation/selection aspects of the acquisition protocol to be used 901 in a CDN interonnect scenario. 903 5.2. CDNI Metadata 905 CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to the 906 specification of content metadata: 908 o CableLabs has defined specifications for CoD Content Metadata as 909 part of its VOD Metadata project. "The VOD Metadata project is a 910 cable television industry and cross-industry-wide effort to 911 specify the metadata and interfaces for distribution of video-on- 912 demand (VOD) material from multiple content providers to cable 913 operators." [CableLabs-Metadata]. However, while the CableLabs 914 work specifies an interface between a content provider and a 915 service provider running a CDN, it does not include an interface 916 that could be used between CDNs. 917 o ITU Study Group 16 has started work on a number of draft 918 Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA, 919 HSTP.IPTV-UMCI) specifying metadata for content distribution in 920 IPTV services. 921 o An Open IPTV Terminal receives the technical description of the 922 content distribution from the OIPF IPTV platform before receiving 923 any content. The Content distribution metadata is sent in the 924 format of a TV-Anytime XSD including tags to describes the 925 location and program type (on demand or Live) as well as 926 describing the time availability of the on demand and live 927 content. 929 However the specifications outlined above do not include metadata 930 specific to the distribution of content within a CDN or between 931 interconnected CDNs, for example geo-blocking information, 932 availability windows, access control mechanisms to be enforced by the 933 surrogate, how to map an incoming content request to a file on the 934 origin server or acquire it from the upstream CDN etc. 936 The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can 937 be associated with data that is stored by a cloud storage provider. 938 While the metadata currently defined do not match the need of a CDN 939 Interconnection solution, it is worth considering CDMI as one of the 940 existing pieces of work that may potentially be leveraged for the 941 CDNI Metadata interface (e.g by extending the CDMI metadata to 942 address more specific CDNI needs). 944 6. Relationship to relevant IETF Working Groups 946 6.1. ALTO 948 As stated in the ALTO Working Group charter [ALTO-Charter]: 950 "The Working Group will design and specify an Application-Layer 951 Traffic Optimization (ALTO) service that will provide applications 952 with information to perform better-than-random initial peer 953 selection. ALTO services may take different approaches at balancing 954 factors such as maximum bandwidth, minimum cross-domain traffic, 955 lowest cost to the user, etc. The WG will consider the needs of 956 BitTorrent, tracker-less P2P, and other applications, such as content 957 delivery networks (CDN) and mirror selection." 959 In particular, the ALTO service can be used by a CDN Request Routing 960 system to improve its selection of a CDN surrogate to serve a 961 particular User Agent request (or to serve a request from another 962 surrogate). See [I-D.penno-alto-cdn] for a detailed discussion on 963 how CDN Request Routing can be used as an integration point of ALTO 964 into CDNs. It is possible that the ALTO service could be used in the 965 same manner in a multi-CDN environment based on CDN Interconnection. 966 For example, an upstream CDN may take advantage of the ALTO service 967 in its decision for selecting a downstream CDN to which a user 968 request should be delegated. 970 However, the work of ALTO is complementary to and does not overlap 971 with the work proposed in this document because the integration 972 between ALTO and a CDN would fall under "algorithms for selection of 973 CDN or Surrogate by Request-Routing systems" in Appendix A.1 and is 974 therefore out of scope for a CDNI WG. One area for further study is 975 whether additional information should be provided by an ALTO service 976 to facilitate CDNI CDN selection. 978 6.2. DECADE 980 The DECADE Working Group [DECADE-Charter] is addressing the problem 981 of reducing traffic on the last-mile uplink, as well as backbone and 982 transit links caused by P2P streaming and file sharing applications. 983 It addresses the problem by enabling an application endpoint to make 984 content available from an in-network storage service and by enabling 985 other application endpoints to retrieve the content from there. 987 Exchanging data through the in-network storage service in this 988 manner, instead of through direct communication, provides significant 989 gain where: 991 o The network capacity/bandwidth from in-network storage service to 992 application endpoint significantly exceeds the capacity/bandwidth 993 from application endpoint to application endpoint (e.g. because of 994 an end-user uplink bottleneck); and 995 o Where the content is to be accessed by multiple instances of 996 application endpoints (e.g. as is typically the case for P2P 997 applications). 999 While, as is the case for any other data distribution application, 1000 the DECADE architecture and mechanisms could potentially be used for 1001 exchange of CDNI control plane information via an in-network-storage 1002 service (as opposed to directly between the entities terminating the 1003 CDNI interfaces in the neighbor CDNs), we observe that: 1005 o CDNI would operate as a "Content Distribution Application" from 1006 the DECADE viewpoint (i.e. would operate on top of DECADE). 1007 o There does not seem to be obvious benefits in integrating the 1008 DECADE control plane responsible for signaling information 1009 relating to control of the in-network storage service itself, and 1010 the CDNI control plane responsible for application-specific CDNI 1011 interactions (such as exchange of CDNI metadata, CDNI request 1012 redirection, transfer of CDNI logging information). 1013 o There would typically be limited benefits in making use of a 1014 DECADE in-network storage service because the CDNI interfaces are 1015 expected to be terminated by a very small number of CDNI clients 1016 (if not one) in each CDN, and the CDNI clients are expected to 1017 benefit from high bandwidth/capacity when communicating directly 1018 to each other (at least as high as if they were communicating via 1019 an in-network storage server). 1021 The DECADE in-network storage architecture and mechanisms may 1022 theoretically be used for the acquisition of the content objects 1023 themselves between interconnected CDNs. It is not expected that this 1024 would have obvious benefits in typical situations where a content 1025 object is acquired only once from an Upstream CDN to a Downstream CDN 1026 (and then distributed as needed inside the Downstream CDN). But it 1027 might have benefits in some particular situations. Since the 1028 acquisition protocol between CDNs is outside the scope of the CDNI 1029 work, this question is left for further study. 1031 The DECADE in-network storage architecture and mechanisms may 1032 potentially also be used within a given CDN for the distribution of 1033 the content objects themselves among surrogates of that CDN. Since 1034 the CDNI work does not concern itself with operation within a CDN, 1035 this question is left for further study. 1037 Therefore, the work of DECADE may be complementary to but does not 1038 overlap with the CDNI work proposed in this document. 1040 6.3. PPSP 1042 As stated in the PPSP Working Group charter [PPSP-Charter]: 1044 "The Peer-to-Peer Streaming Protocol (PPSP) working group develops 1045 two signaling and control protocols for a peer-to-peer (P2P) 1046 streaming system for transmitting live and time-shifted media content 1047 with near real-time delivery requirements." and "The PPSP WG designs 1048 a protocol for signaling and control between trackers and peers (the 1049 PPSP "tracker protocol") and a signaling and control protocol for 1050 communication among the peers (the PPSP "peer protocol"). The two 1051 protocols enable peers to receive streaming data within the time 1052 constraints required by specific content items." 1054 Therefore PPSP is concerned with the distribution of the streamed 1055 content itself along with the necessary signaling and control 1056 required to distribute the content. As such, it could potentially be 1057 used for the acquisition of streamed content across interconnected 1058 CDNs. But since the acquisition protocol is outside the scope of the 1059 work proposed for CDNI, we leave this for further study. Also, 1060 because of its streaming nature, PPSP is not seen as applicable to 1061 the distribution and control of the CDNI control plane and CDNI data 1062 representations. 1064 Therefore, the work of PPSP may be complementary to but does not 1065 overlap with the work proposed in this document for CDNI. 1067 7. IANA Considerations 1069 This document makes no request of IANA. 1071 Note to RFC Editor: this section may be removed on publication as an 1072 RFC. 1074 8. Security Considerations 1076 Distribution of content by a CDN comes with a range of security 1077 considerations such as how to enforce control of access to the 1078 content by users in line with the CSP policy. These security aspects 1079 are already dealt with by CDN Providers and CSPs today in the context 1080 of standalone CDNs. However, interconnection of CDNs introduces a 1081 new set of security considerations by extending the trust model (i.e. 1082 the CSP "trusts" a CDN that "trusts" another CDN). 1084 Maintaining the security of the content itself, its associated 1085 metadata (including distribution and delivery policies) and the CDNs 1086 distributing and delivering it, are critical requirements for both 1087 CDN Providers and CSPs and any work on CDN Interconnection must 1088 provide sufficient mechanisms to maintain the security of the overall 1089 system of interconnected CDNs as well as the information (content, 1090 metadata, logs, etc) distributed and delivered through any CDN 1091 interconnects. 1093 9. Acknowledgements 1095 The authors would like to thank Andre Beck, Mark Carlson, Bruce 1096 Davie, David Ferguson, Yiu Lee, Kent Leung, Kevin Ma, Julien 1097 Maisonneuve, Guy Meador, Emile Stephan, Oskar van Deventer and Mahesh 1098 Viveganandhan for their review comments and contributions to the 1099 text. 1101 10. References 1103 10.1. Normative References 1105 [I-D.bertrand-cdni-experiments] 1106 Bertrand, G., Faucheur, F., and L. Peterson, "Content 1107 Distribution Network Interconnection (CDNI) Experiments", 1108 draft-bertrand-cdni-experiments-01 (work in progress), 1109 August 2011. 1111 [I-D.bertrand-cdni-use-cases] 1112 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., 1113 Eardley, P., and K. Ma, "Use Cases for Content Delivery 1114 Network Interconnection", draft-bertrand-cdni-use-cases-02 1115 (work in progress), July 2011. 1117 [I-D.bertrand-cdni-use-cases-00] 1118 Bertrand, G. and E. Stephan, "Use Cases for Content 1119 Distribution Network Interconnection - 1120 draft-bertrand-cdni-use-cases-00 (superseded)", 1121 January 2011. 1123 [I-D.jenkins-cdni-names] 1124 Niven-Jenkins, B., "Thoughts on Naming and Referencing of 1125 Data Objects within Content Distribution Network 1126 Interconnection (CDNI) solutions", 1127 draft-jenkins-cdni-names-00 (work in progress), 1128 February 2011. 1130 [I-D.watson-cdni-use-cases] 1131 Watson, G., "CDN Interconnect Use Cases", 1132 draft-watson-cdni-use-cases-00 (work in progress), 1133 January 2011. 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 10.2. Informative References 1140 [ALTO-Charter] 1141 "IETF ALTO WG Charter 1142 (http://datatracker.ietf.org/wg/alto/charter/)". 1144 [ATIS] "ATIS (http://www.atis.org/)". 1146 [ATIS-COD] 1147 "ATIS IIF: IPTV Content on Demand Service, January 2011 (h 1148 ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/ 1149 ATIS-0800042.pdf)". 1151 [CDI-Charter] 1152 "IETF CDI WG Charter 1153 (http://www.ietf.org/wg/concluded/cdi)". 1155 [CableLabs] 1156 "CableLabs (http://www.cablelabs.com/about/)". 1158 [CableLabs-Metadata] 1159 "CableLabs VoD Metadata Project Primer 1160 (http://www.cablelabs.com/projects/metadata/primer/)". 1162 [DECADE-Charter] 1163 "IETF DECADE WG Charter 1164 (http://datatracker.ietf.org/wg/decade/charter/)". 1166 [I-D.penno-alto-cdn] 1167 Penno, R., Medved, J., Alimi, R., Yang, R., and S. 1168 Previdi, "ALTO and Content Delivery Networks", 1169 draft-penno-alto-cdn-03 (work in progress), March 2011. 1171 [MPEG-DASH] 1172 "Information technology - MPEG systems technologies - Part 1173 6: Dynamic adaptive streaming over HTTP (DASH), (DIS 1174 version), February 2011 1175 http://mpeg.chiariglione.org/ 1176 working_documents.htm#MPEG-B". 1178 [OIPF-Overview] 1179 "OIPF Release 2 Specification Volume 1 - Overview", 1180 September 2010. 1182 [P2PRG-CDNI] 1183 Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 1184 "Peering Peer-to-Peer" 1185 (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)", 1186 March 2010. 1188 [PPSP-Charter] 1189 "IETF PPSP WG Charter 1190 (http://datatracker.ietf.org/wg/ppsp/charter/)". 1192 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1193 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1194 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1196 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1197 Replication and Caching Taxonomy", RFC 3040, January 2001. 1199 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 1200 for Content Internetworking (CDI)", RFC 3466, 1201 February 2003. 1203 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 1204 Content Network (CN) Request-Routing Mechanisms", 1205 RFC 3568, July 2003. 1207 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 1208 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 1210 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 1211 Protocol", RFC 5023, October 2007. 1213 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1214 Protocol (XMPP): Core", RFC 6120, March 2011. 1216 [SNIA-CDMI] 1217 "SNIA CDMI (http://www.snia.org/tech_activities/standards/ 1218 curr_standards/cdmi)". 1220 [TAXONOMY] 1221 Pathan, A., "A Taxonomy and Survey of Content Delivery 1222 Networks 1223 (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. 1225 [Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional 1226 architecture"", September 2008. 1228 [Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional 1229 architecture in NGN"", September 2010. 1231 [_3GP-DASH] 1232 "Transparent end-to-end Packet-switched Streaming Service 1233 (PSS); Progressive Download and Dynamic Adaptive Streaming 1234 over HTTP (3GP-DASH) 1235 http://www.3gpp.org/ftp/Specs/html-info/26247.htm". 1237 Appendix A. Additional Material 1239 Note to RFC Editor: This appendix is to be removed on publication as 1240 an RFC. 1242 A.1. Non-Goals for IETF 1244 Listed below are aspects of content delivery that the authors propose 1245 be kept outside of the scope of a potential CDNI working group: 1246 o The interface between Content Service Provider and the 1247 Authoritative CDN (i.e. the upstream CDN contracted by the CSP for 1248 delivery by this CDN or by its downstream CDNs). 1249 o The delivery interface between the delivering CDN surrogate and 1250 the User Agent, such as streaming protocols. 1251 o The request interface between the User Agent and the request- 1252 routing system of a given CDN. Existing IETF protocols (e.g. 1253 HTTP, RTSP, DNS) are commonly used by User Agents to request 1254 content from a CDN and by CDN request routing systems to redirect 1255 the User Agent requests. The CDNI working group need not define 1256 new protocols for this purpose. Note however, that the CDNI 1257 control plane interface may indirectly affect some of the 1258 information exchanged through the request interface (e.g. URI). 1259 o The content acquisition interface between CDNs (i.e. the data 1260 plane interface for actual delivery of a piece of content from one 1261 CDN to the other). This is expected to use existing protocols 1262 such as HTTP or protocols defined in other forums for content 1263 acquisition between an origin server and a CDN (e.g. HTTP-based 1264 C2 reference point of ATIS IIF CoD). The CDN Interconnection 1265 solution may only concern itself with the agreement/negotiation 1266 aspects of which content acquisition protocol is to be used 1267 between two interconnected CDNs in view of facilitating 1268 interoperability. 1269 o End User/User Agent Authentication. End User/User Agent 1270 authentication and authorization are the responsibility of the 1271 Content Service Provider. 1272 o Content preparation, including encoding and transcoding. The CDNI 1273 architecture aims at allowing distribution across interconnected 1274 CDNs of content treated as opaque objects. Interpretation and 1275 processing of the objects, as well as optimized delivery of these 1276 objects by the surrogate to the End User are outside the scope of 1277 CDNI. 1278 o Digital Rights Management (DRM). DRM is an end-to-end issue 1279 between a content protection system and the User Agent. 1280 o Applications consuming CDNI logs (e.g. charging, analytics, 1281 reporting,...). 1282 o Internal CDN interfaces & protocols (i.e. interfaces & protocols 1283 within one CDN). 1284 o Scalability of individual CDNs. While scalability of the CDNI 1285 interfaces/approach is in scope, how an individual CDN scales is 1286 out of scope. 1287 o Actual algorithms for selection of CDNs or Surrogates by Request 1288 Routing systems (however, some specific parameters required as 1289 input to these algorithms may be in scope when they need to be 1290 communicated across CDNs). 1291 o Surrogate algorithms. For example caching algorithms and content 1292 acquisition methods are outside the scope of the CDNI work. 1293 Content management (e.g. Content Deletion) as it relates to CDNI 1294 content management policies, is in scope but the internal 1295 algorithms used by a cache to determine when to no longer cache an 1296 item of Content (in the absence of any specific metadata to the 1297 contrary) is out of scope. 1298 o Element management interfaces. 1299 o Commercial, business and legal aspects related to the 1300 interconnections of CDNs. 1302 A.2. Prioritizing the CDNI Work 1304 In order to manage the potential workload of a CDNI WG, it is 1305 recommended that the work be prioritized in a "walk before you run" 1306 approach. 1308 The CDNI problem area can be categorized into different solution 1309 scopes as follows: 1310 o "Base CDNI" Scope: This solution scope comprises the solution 1311 elements that can be considered as the 'minimum' needed to 1312 actually deliver any content using interconnected CDNs. For 1313 example, a base CDNI Request Routing interface and a base CDNI 1314 Metadata interface belong to this scope because without them the 1315 upstream CDN is unable to redirect User Agents to the downstream 1316 CDN and the downstream CDN is unable to obtain the delivery 1317 policies and other CDNI Metadata required to ingest and deliver 1318 the content. 1319 o "Operationalized CDNI" Scope: This solution scope comprises the 1320 solution elements that can be considered as the 'minimum' needed 1321 to 'operationalize' CDN Interconnection. For example, the CDNI 1322 Logging interface and the base capabilities of the CDNI Control 1323 interface (e.g. content file/metadata deletion) belong to this 1324 scope because without them CDN operators are required to 1325 substitute for them either with manual processes or proprietary 1326 interfaces. 1327 o "Enhanced CDNI" Scope: This solution scope comprises the solution 1328 elements that can be classed as 'enhanced features'. For example, 1329 the aspects of the CDNI Control interface related to automatic 1330 bootstrapping and configuration belong to this scope. 1332 It is proposed that these solution scopes be addressed primarily 1333 sequentially by a CDNI WG and that the initial charter be centered 1334 around the "Base CDNI" scope. However there is obvious benefit from 1335 having a solution for the "Base CDNI" scope that is amenable to 1336 extension for support of the "Operational" scope and "Enhanced" 1337 scope. Therefore it is proposed that the initial CDNI WG charter 1338 also includes definition of (at least) the main requirements for the 1339 "Operationalized CDNI" scope and "Enhanced CDNI" Scope, so those can 1340 be kept in mind when defining the solution for the "Base CDNI" scope. 1342 A.3. Related standardization activities 1344 A.3.1. IETF CDI Working Group (Concluded) 1346 The Content Distribution Internetworking (CDI) Working Group was 1347 formed in the IETF following a BoF in December 2000 and closed in mid 1348 2003. 1350 For convenience, here is an extract from the CDI WG charter 1351 [CDI-Charter]: 1353 " 1355 o The goal of this working group is to define protocols to allow the 1356 interoperation of separately-administered content networks. 1357 o A content network is an architecture of network elements, arranged 1358 for efficient delivery of digital content. Such content includes, 1359 but is not limited to, web pages and images delivered via HTTP, 1360 and streaming or continuous media which are controlled by RTSP. 1361 o The working group will first define requirements for three modes 1362 of content internetworking: interoperation of request-routing 1363 systems, interoperation of distribution systems, and 1364 interoperation of accounting systems. These requirements are 1365 intended to lead to a follow-on effort to define protocols for 1366 interoperation of these systems. 1367 o In its initial form, the working group is not chartered to deliver 1368 those protocols [...] 1370 " 1371 Thus, the CDI WG touched on the same problem space as the present 1372 document. 1374 The CDI WG published 3 Informational RFCs: 1376 o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)". 1377 o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing 1378 Mechanisms". 1379 o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios". 1381 A.3.2. 3GPP 1383 3GPP was the first organization that released a specification related 1384 to adaptive streaming over HTTP. 3GPP Release 9 specification on 1385 adaptive HTTP streaming was published in March 2010, and there have 1386 been some bug fixes on this specification since the publication. In 1387 addition, 3GPP is preparing an extended version for Release 10, which 1388 is scheduled to be published later in 2011. This release will 1389 include a number of clarifications, improvements and new features. 1391 [_3GP-DASH] is defined as a general framework independent of the data 1392 encapsulation format. It has support for fast initial startup and 1393 seeking, adaptive bitrate switching, re-use of HTTP origin and cache 1394 servers, re-use of existing media playout engines, on-demand, live 1395 and time-shifted delivery. It specifies syntax and semantics of 1396 Media Presentation Description (MPD), format of segments and delivery 1397 protocol for segments. It does not specify content provisioning, 1398 client behavior or transport of MPD. 1400 The content retrieved by a client using [_3GP-DASH] adaptive 1401 streaming could be obtained from a CDN but this is not discussed or 1402 specified in the 3GPP specifications as it is transparent to 1403 [_3GP-DASH] operations. Similarly, it is expected that [_3GP-DASH] 1404 can be used transparently from the CDNs as a delivery protocol 1405 (between the delivering CDN surrogate and the User Agent) in a CDN 1406 Interconnection environment. [_3GP-DASH] could also be a candidate 1407 for content acquisition between CDNs in a CDN Interconnection 1408 environment. 1410 A.3.3. ISO MPEG 1412 Within ISO MPEG, the Dynamic Adaptive Streaming over HTTP (DASH) ad- 1413 hoc group adopted the 3GPP Release 9 [_3GP-DASH] specification as a 1414 starting point and has made some improvements and extensions. 1415 Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on 1416 standardizing the manifest file and the delivery format. 1417 Additionally, the MPEG DASH ad-hoc group has also been working on the 1418 use of MPEG-2 Transport Streams as a media format, conversion from/to 1419 existing file formats, common encryption, and so on. The MPEG DASH 1420 specification could also be a candidate for delivery to the User 1421 Agent and for content acquisition between CDNs in a CDN 1422 Interconnection environment. The Draft International Standard (DIS) 1423 version [MPEG-DASH] is currently publicly available since early 1424 February 2011. 1426 In the 95th MPEG meeting in January 2011, the DASH ad-hoc group 1427 decided to start a new evaluation experiment called "CDN-EE". The 1428 goals are to understand the requirements for MPEG DASH to better 1429 support CDN-based delivery, and to provide a guidelines document for 1430 CDN operators to better support MPEG DASH streaming services. The 1431 ongoing work is still very preliminary and does not currently target 1432 looking into CDN Interconnection use cases. 1434 A.3.4. ATIS IIF 1436 ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS) 1437 that develops requirements, standards, and specifications for IPTV. 1439 ATIS IIF is developing the "IPTV Content on Demand (CoD) Service" 1440 specification. This includes use of a CDN (referred to in ATIS IIF 1441 CoD as the "Content Distribution and Delivery Functions") for support 1442 of a Content on Demand (CoD) Service as part of a broader IPTV 1443 service. However, this only covers the case of a managed IPTV 1444 service (in particular where the CDN is administered by the service 1445 provider) and does not cover the use, or interconnection, of multiple 1446 CDNs. 1448 A.3.5. CableLabs 1450 "Founded in 1988 by cable operating companies, Cable Television 1451 Laboratories, Inc. (CableLabs) is a non-profit research and 1452 development consortium that is dedicated to pursuing new cable 1453 telecommunications technologies and to helping its cable operator 1454 members integrate those technical advancements into their business 1455 objectives." [CableLabs] 1457 CableLabs has defined specifications for CoD Content Metadata as part 1458 of its VOD Metadata project. 1460 A.3.6. ETSI MCD 1462 ETSI MCD (Media Content Distribution) is the ETSI technical committee 1463 "in charge of guiding and coordinating standardization work aiming at 1464 the successful overall development of multimedia systems (television 1465 and communication) responding to the present and future market 1466 requests on media content distribution". 1468 MCD created a specific work item on interconnection of heterogeneous 1469 CDNs ("CDN Interconnection, use cases and requirements") in March 1470 2010. MCD very recently created a working group to progress this 1471 work item. However, no protocol level work has yet started in MCD 1472 for CDN Interconnection. 1474 A.3.7. ETSI TISPAN 1476 ETSI TISPAN has published two sets of IPTV specifications, one of 1477 which is based on IMS. In addition, TISPAN is about to complete the 1478 specifications of a CDN architecture supporting delivery of various 1479 content services such as time-shifted TV and VoD to TISPAN devices 1480 (UEs) or regular PCs. The use cases allow for hierarchically and 1481 geographically distributed CDN scenarios, along with multi-CDN 1482 cooperation. As a result, the architecture contains reference points 1483 to support interconnection of other TISPAN CDNs. The protocol 1484 definition phase for the corresponding CDN architecture was kicked- 1485 off at the end of 2010. In line with its long history of leveraging 1486 IETF protocols, ETSI could potentially leverage CDNI interfaces 1487 developed in the IETF for their related protocol level work on 1488 interconnections of CDNs. 1490 A.3.8. ITU-T 1492 SG13 is developing standards related to the support of IPTV services 1493 (i.e.. multimedia services such as television/VoD/audio/text/ 1494 graphics/data delivered over IP-based managed networks). 1496 ITU-T Recommendation Y.1910 [Y.1910] provides the description of the 1497 IPTV functional architecture. This architecture includes functions 1498 and interfaces for the distribution and delivery of content. This 1499 architecture is aligned with the ATIS IIF architecture. 1501 Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in 1502 more detail the content delivery functional architecture. This 1503 architecture allows CDN Interconnection: some interfaces (such as D3, 1504 D4) at the control level allow relationships between different CDNs, 1505 in the same domain or in different domains. Generic procedures are 1506 described, but the choice of the protocols is open. 1508 A.3.9. Open IPTV Forum (OIPF) 1510 The Open IPTV Forum has developed an end-to-end solution to allow any 1511 OIPF terminal to access enriched and personalized IPTV services 1512 either in a managed or a non-managed network[OIPF-Overview]. Some 1513 OIPF services (such as Network PVR) may be hosted in a CDN. 1515 To that end, the Open IPTV Forum specification is made of 5 parts: 1517 o Media Formats including HTTP Adaptive Streaming 1518 o Content Metadata 1519 o Protocols 1520 o Terminal (Declarative or Procedural Application Environment) 1521 o Authentication, Content Protection and Service Protection 1523 A.3.10. TV-Anytime Forum 1525 Version 1 of the TV-Anytime Forum specifications were published as 1526 ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line 1527 Services: Search, select, and rightful use of content on personal 1528 storage systems ("TV-Anytime")". It includes the specification of 1529 content metadata in XML schemas (ETSI TS 102 822-3) which define 1530 technical parameters for the description of CoD and Live contents. 1531 The specification is referenced by DVB and OIPF. 1533 The TV-anytime Forum was closed in 2005. 1535 A.3.11. SNIA 1537 The Storage Networking Industry Association (SNIA) is an association 1538 of producers and consumers of storage networking products whose goal 1539 is to further storage networking technology and applications. 1541 SNIA has published the Cloud Data Management Interface (CDMI) 1542 standard ([SNIA-CDMI]). 1544 "The Cloud Data Management Interface defines the functional interface 1545 that applications will use to create, retrieve, update and delete 1546 data elements from the Cloud. As part of this interface the client 1547 will be able to discover the capabilities of the cloud storage 1548 offering and use this interface to manage containers and the data 1549 that is placed in them. In addition, metadata can be set on 1550 containers and their contained data elements through this interface." 1552 A.4. Related Research Projects 1554 A.4.1. IRTF P2P Research Group 1556 Some information on CDN interconnection motivations and technical 1557 issues were presented in the P2P RG at IETF 77. The presentation can 1558 be found in [P2PRG-CDNI]. 1560 A.4.2. OCEAN 1562 OCEAN (http://www.ict-ocean.eu/) is an EU funded research project 1563 that started in February 2010 for 3 years. Some of its objectives 1564 are relevant to CDNI. It aims, among other things, at designing a 1565 new architectural framework for audiovisual content delivery over the 1566 Internet, defining public interfaces between its major building 1567 blocks in order to foster multi-vendor solutions and interconnection 1568 between Content Networks (the term "Content Networks" corresponds 1569 here to the definition introduced in [RFC3466], which encompasses 1570 CDNs). 1572 OCEAN has not yet published any open specifications, nor common best 1573 practices, defining how to achieve such CDN interconnection. 1575 A.4.3. Eurescom P1955 1577 Eurescom P1955 was a 2010 research project involving a four European 1578 Network operators, which studied the interests and feasibility of 1579 interconnecting CDNs by firstly elaborating the main service models 1580 around CDN interconnection, as well as analyzing an adequate CDN 1581 interconnection technical architecture and framework, and finally by 1582 providing recommendations for telcos to implement CDN 1583 interconnection. The Eurescom P1955 project ended in July 2010. 1585 The authors are not aware of material discussing CDN interconnection 1586 protocols or interfaces made publically available as a deliverable of 1587 this project. 1589 Authors' Addresses 1591 Ben Niven-Jenkins 1592 Velocix (Alcatel-Lucent) 1593 326 Cambridge Science Park 1594 Milton Road, Cambridge CB4 0WG 1595 UK 1597 Email: ben@velocix.com 1599 Francois Le Faucheur 1600 Cisco Systems 1601 Greenside, 400 Avenue de Roumanille 1602 Sophia Antipolis 06410 1603 France 1605 Phone: +33 4 97 23 26 19 1606 Email: flefauch@cisco.com 1607 Nabil Bitar 1608 Verizon 1609 40 Sylvan Road 1610 Waltham, MA 02145 1611 USA 1613 Email: nabil.bitar@verizon.com