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