idnits 2.17.1 draft-ietf-cdni-footprint-capabilities-semantics-17.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 date (April 22, 2016) is 2918 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-25 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-15 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI J. Seedorf 3 Internet-Draft NEC 4 Intended status: Standards Track J. Peterson 5 Expires: October 24, 2016 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Ericsson 12 April 22, 2016 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-ietf-cdni-footprint-capabilities-semantics-17 17 Abstract 19 This document captures the semantics of the "Footprint and 20 Capabilities Advertisement" part of the CDNI Request Routing 21 interface, i.e., the desired meaning of "Footprint" and 22 "Capabilities" in the CDNI context, and what the "Footprint and 23 Capabilities Advertisement Interface (FCI)" offers within CDNI. The 24 document also provides guidelines for the CDNI FCI protocol. It 25 further defines a Base Advertisement Object, the necessary registries 26 for capabilities and footprints, and guidelines on how these 27 registries can be extended in the future. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on October 24, 2016. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Design Decisions for Footprint and Capabilities . . . . . . . 5 71 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5 72 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6 73 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7 74 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 75 2.5. Focusing on Capabilities with Footprint Restrictions . . 8 76 3. Footprint and Capabilities Extension . . . . . . . . . . . . 8 77 4. Capability Advertisement Object . . . . . . . . . . . . . . . 10 78 4.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10 79 4.2. Delivery Protocol Capability Object . . . . . . . . . . . 11 80 4.2.1. Delivery Protocol Capability Object Serialization . . 11 81 4.3. Acquisition Protocol Capability Object . . . . . . . . . 12 82 4.3.1. Acquisition Protocol Capability Object Serialization 12 83 4.4. Redirection Mode Capability Object . . . . . . . . . . . 13 84 4.4.1. Redirection Mode Capability Object Serialization . . 13 85 4.5. CDNI Logging Capability Object . . . . . . . . . . . . . 14 86 4.5.1. CDNI Logging Capability Object Serialization . . . . 15 87 4.6. CDNI Metadata Capability Object . . . . . . . . . . . . . 15 88 4.6.1. CDNI Metadata Capability Object Serialization . . . . 16 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 5.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 91 5.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 92 5.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 93 5.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 94 5.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18 95 5.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18 96 5.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 7.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21 103 Appendix B. Semantics for Footprint Advertisement . . . . . . . 22 104 Appendix C. Semantics for Capabilities Advertisement . . . . . . 24 105 Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 108 1. Introduction and Scope 110 The CDNI working group is working on a set of protocols to enable the 111 interconnection of multiple CDNs. This CDN interconnection (CDNI) 112 can serve multiple purposes, as discussed in [RFC6770], for instance, 113 to extend the reach of a given CDN to areas in the network which are 114 not covered by this particular CDN. 116 The goal of this document is to achieve a clear understanding about 117 the semantics associated with the CDNI Request Routing Footprint & 118 Capabilities Advertisement Interface (from now on referred to as 119 FCI), in particular the type of information a downstream CDN (dCDN) 120 'advertises' regarding its footprint and capabilities. To narrow 121 down undecided aspects of these semantics, this document tries to 122 establish a common understanding of what the FCI needs to offer and 123 accomplish in the context of CDNI. 125 It is explicitly outside the scope of this document to decide on 126 specific protocols to use for the FCI. However, guidelines for such 127 FCI protocols are provided. 129 General assumptions in this document: 131 o The CDNs participating in the interconnected CDN have already 132 performed a boot strap process, i.e., they have connected to each 133 other, either directly or indirectly, and can exchange information 134 amongst each other. 136 o The upstream CDN (uCDN) receives footprint and/or capability 137 advertisements from a set of dCDNs. Footprint advertisement and 138 capability advertisement need not use the same underlying 139 protocol. 141 o The uCDN receives the initial request-routing request from the 142 endpoint requesting the resource. 144 The CDNI Problem Statement [RFC6707] describes the Request Routing 145 Interface as: "[enabling] a Request Routing function in a uCDN to 146 query a Request Routing function in a dCDN to determine if the dCDN 147 is able (and willing) to accept the delegated Content Request". In 148 addition, RFC6707 says "the CDNI Request Routing interface is also 149 expected to enable a dCDN to provide to the uCDN (static or dynamic) 150 information (e.g., resources, footprint, load) to facilitate 151 selection of the dCDN by the uCDN request routing system when 152 processing subsequent content requests from User Agents". It thus 153 considers "resources" and "load" as capabilities to be advertised by 154 the dCDN. 156 The range of different footprint definitions and possible 157 capabilities is very broad. Attempting to define a comprehensive 158 advertisement solution quickly becomes intractable. The CDNI 159 requirements draft [RFC7337] lists the specific requirements for the 160 CDNI Footprint & Capabilities Advertisement Interface in order to 161 disambiguate footprints and capabilities with respect to CDNI. This 162 document defines a common understanding of what the terms 'footprint' 163 and 'capabilities' mean in the context of CDNI, and details the 164 semantics of the footprint advertisement mechanism and the capability 165 advertisement mechanism. 167 1.1. Terminology 169 This document reuses the terminology defined in [RFC6707]. 171 Additionally, the following terms are used throughout this document 172 and are defined as follows: 174 o Footprint: a description of a CDN's coverage area, i.e., the area 175 from which client requests may originate for, and to which the CDN 176 is willing to deliver, content. Note: There are many ways to 177 describe a footprint, for example, by address range (e.g., IPv4/ 178 IPv6 CIDR), by network ID (e.g., ASN), by nation boundaries (e.g., 179 country code), by GPS coordinates, etc. This document does not 180 define or endorse the quality or suitability of any particular 181 footprint description method; this document only defines a method 182 for transporting known footprint descriptions in Footprint and 183 Capabilities Advertisement messages. 185 o Capability: a feature of a dCDN, upon which a uCDN relies on the 186 dCDN supporting, when making delegation decisions. Support for a 187 given feature can change over time and can be restricted to a 188 limited portion of a dCDN's footprint. Note: There are many 189 possible dCDN features that could be of interest to a uCDN. This 190 document does not presume to define them all; this document 191 describes a scheme for defining new capabilities and how to 192 transport them in Footprint and Capabilities Advertisement 193 messages. 195 2. Design Decisions for Footprint and Capabilities 197 A large part of the difficulty in discussing the FCI lies in 198 understanding what exactly is meant when trying to define footprint 199 in terms of "coverage" or "reachability." While the operators of 200 CDNs pick strategic locations to situate caches, a cache with a 201 public IPv4 address is reachable by any endpoint on the Internet 202 unless some policy enforcement precludes the use of the cache. 204 Some CDNs aspire to cover the entire world; we refer to these as 205 global CDNs. The footprint advertised by such a CDN in the CDNI 206 environment would, from a coverage or reachability perspective, 207 presumably cover all prefixes. Potentially more interesting for CDNI 208 use cases, however, are CDNs that claim a more limited coverage, but 209 seek to interconnect with other CDNs in order to create a single CDN 210 fabric which shares resources. 212 Furthermore, not all capabilities need to be footprint restricted. 213 Depending upon the use case, the optimal semantics of "footprints 214 with capability attributes" vs. "capabilities with footprint 215 restrictions" are not clear. 217 The key to understanding the semantics of footprint and capability 218 advertisement lies in understanding why a dCDN would advertise a 219 limited coverage area, and how a uCDN would use such advertisements 220 to decide among one of several dCDNs. The following section will 221 discuss some of the trade-offs and design decisions that need to be 222 decided upon for the CDNI FCI. 224 2.1. Advertising Limited Coverage 226 The basic use case that would motivate a dCDN to advertise a limited 227 coverage is that the CDN was built to cover only a particular portion 228 of the Internet. For example, an ISP could purpose-build a CDN to 229 serve only their own customers by situating caches in close 230 topological proximity to high concentrations of their subscribers. 231 The ISP knows the prefixes it has allocated to end users and thus can 232 easily construct a list of prefixes that its caches were positioned 233 to serve. 235 When such a purpose-built CDN interconnects with other CDNs and 236 advertises its footprint to a uCDN, however, the original intended 237 coverage of the CDN might not represent its actual value to the 238 interconnection of CDNs. Consider an ISP-A and ISP-B that both field 239 their own CDNs, which they interconnect via CDNI. A given user E, 240 who is a customer of ISP-B, might happen to be topologically closer 241 to a cache fielded by ISP-A, if E happens to live in a region where 242 ISP-B has few customers and ISP-A has many. In this case, is it ISP- 243 A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is 244 it up to the uCDN to understand that ISP-A's caches are potentially 245 available as back-ups - and if so, how does ISP-A advertise itself as 246 a "standby" for E? What about the case where CDNs advertising to the 247 same uCDN express overlapping coverage (for example, mixing global 248 and limited CDNs)? 250 The answers to these questions greatly depend on how much information 251 the uCDN wants to use to make a selection of a dCDN. If a uCDN has 252 three dCDNs to choose from that "cover" the IP address of user E, 253 obviously the uCDN might be interested to know how optimal the 254 coverage is from each of the dCDNs - coverage need not be binary, 255 either provided or not provided. dCDNs could advertise a coverage 256 "score," for example, and provided that they all reported scores 257 fairly on the same scale, uCDNs could use that to make their 258 topological optimality decision. Alternately, dCDNs could advertise 259 the IP addresses of their caches rather than prefix "coverage," and 260 let the uCDN decide for itself (based on its own topological 261 intelligence) which dCDN has better resources to serve a given user. 263 In summary, the semantics of advertising footprint depend on whether 264 such qualitative metrics for expressing footprint (such as the 265 coverage 'score' mentioned above) are included as part of the CDNI 266 FCI, or if the focus is just on 'binary' footprint. 268 2.2. Capabilities and Dynamic Data 270 In cases where the apparent footprints of dCDNs overlap, uCDNs might 271 also want to rely on other factors to evaluate the respective merits 272 of dCDNs. These include facts related to the caches themselves, to 273 the network where the cache is deployed, to the nature of the 274 resource sought, and to the administrative policies of the respective 275 networks. 277 In the absence of network-layer impediments to reaching caches, the 278 choice to limit coverage is necessarily an administrative policy. 279 Much policy needs to be agreed upon before CDNs can interconnect, 280 including questions of membership, compensation, volumes, and so on. 281 A uCDN certainly will factor these sorts of considerations into its 282 decision to select a dCDN, but there is probably little need for 283 dCDNs to actually advertise them through an interface - they will be 284 settled out-of-band as a precondition for interconnection. 286 Other facts about the dCDN would be expressed through the interface 287 to the uCDN. Some capabilities of a dCDN are static, and some are 288 highly dynamic. Expressing the total storage built into its caches, 289 for example, changes relatively rarely, whereas the amount of storage 290 in use at any given moment is highly volatile. Network bandwidth 291 similarly could be expressed as either total bandwidth available to a 292 cache, or based on the current state of the network. A cache can at 293 one moment lack a particular resource in storage, but have it the 294 next. 296 The semantics of the capabilities interface will depend on how much 297 of the dCDN state needs to be pushed to the uCDN and qualitatively 298 how often that information needs to be updated. 300 2.3. Advertisement versus Queries 302 In a CDNI environment, each dCDN shares some of its state with the 303 uCDN. The uCDN uses this information to build a unified picture of 304 all of the dCDNs available to it. In architectures that share 305 detailed capability information, the uCDN could perform the entire 306 request-routing operation down to selecting a particular cache in the 307 dCDN. However, when the uCDN needs to deal with many potential 308 dCDNs, this approach does not scale, especially for dCDNs with 309 thousands or tens of thousands of caches; the volume of updates to 310 footprint and capability becomes onerous. 312 Were the volume of FCI updates from dCDNs to exceed the volume of 313 requests to the uCDN, it might make more sense for the uCDN to query 314 dCDNs upon receiving requests (as is the case in the recursive 315 redirection mode described in [RFC7336]), instead of receiving 316 advertisements and tracking the state of dCDNs. The advantage of 317 querying dCDNs would be that much of the dynamic data that dCDNs 318 cannot share with the uCDN would now be factored into the uCDN's 319 decision. dCDNs need not replicate any state to the uCDN - uCDNs 320 could effectively operate in a stateless mode. 322 The semantics of both footprint and capability advertisement depend 323 on the service model here: are there cases where a synchronous query/ 324 response model would work better for the uCDN decision than a state 325 replication model? 327 2.4. Avoiding or Handling 'cheating' dCDNs 329 In a situation where more than one dCDN is willing to serve a given 330 end user request, it might be attractive for a dCDN to 'cheat' in the 331 sense that the dCDN provides inaccurate information to the uCDN in 332 order to convince the uCDN to select it over 'competing' dCDNs. It 333 could therefore be desirable to take away the incentive for dCDNs to 334 cheat (in information advertised) as much as possible. One option is 335 to make the information the dCDN advertises somehow verifiable for 336 the uCDN. On the other hand, a cheating dCDN might be avoided or 337 handled by the fact that there will be strong contractual agreements 338 between a uCDN and a dCDN, so that a dCDN would risk severe penalties 339 or legal consequences when caught cheating. 341 Overall, the information a dCDN advertises (in the long run) needs to 342 be somehow qualitatively verifiable by the uCDN, though possibly 343 through non-real-time out-of-band audits. It is probably an overly 344 strict requirement to mandate that such verification be possible 345 "immediately", i.e., during the request routing process itself. If 346 the uCDN can detect a cheating dCDN at a later stage, it might 347 suffice for the uCDN to "de-incentivize" cheating because it would 348 negatively affect the long-term business relationship with a 349 particular dCDN. 351 2.5. Focusing on Capabilities with Footprint Restrictions 353 It seems reasonable to assume that in most use cases it is the uCDN 354 that makes the decision on selecting a certain dCDN for request 355 routing based on information the uCDN has received from this 356 particular dCDN. It can be assumed that 'cheating' CDNs will be 357 dealt with via means outside the scope of CDNI and that the 358 information advertised between CDNs is accurate. In addition, 359 excluding the use of qualitative information (e.g., cache proximity, 360 delivery latency, cache load) to predict the quality of delivery 361 would further simplify the use case allowing it to better focus on 362 the basic functionality of the FCI. 364 Further understanding that in most cases contractual agreements will 365 define the basic coverage used in delegation decisions, the primary 366 focus of FCI is on providing updates to the basic capabilities and 367 coverage by the dCDNs. As such, FCI has choosen the semantics of 368 "capabilities with footprint restrictions". 370 3. Footprint and Capabilities Extension 372 Other optional "coverage/reachability" types of footprint or 373 "resource" types of footprint may be defined by future 374 specifications. To facilitate this, a clear process for specifying 375 optional footprint types in an IANA registry is specified in the CDNI 376 Metadata Footprint Types registry (defined in the CDNI Metadata 377 Interface document [I-D.ietf-cdni-metadata]). 379 This document also registers CDNI Payload Types [RFC7736] for the 380 initial capability types (see Section 5): 382 o Delivery Protocol (for delivering content to the end user) 384 o Acquisition Protocol (for acquiring content from the uCDN or 385 origin server) 387 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 388 discussed in [RFC7336]) 390 o CDNI Logging (i.e., supported logging fields) 392 o CDNI Metadata (i.e., supported Generic Metadata types) 394 Each payload type is prefaced with "FCI.". Updates to capability 395 objects MUST indicate the version of the capability object in a newly 396 registered payload type, e.g., by appending ".v2". Each capability 397 type MAY have a list of valid values. Future specifications which 398 define a given capability MUST define any necessary registries (and 399 the rules for adding new entries to the registry) for the values 400 advertised for a given capability type. 402 The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging] 403 defines all known record types, including mandatory-to-implement 404 record-types Advertising support for mandatory-to-implement record- 405 types would be redundant. CDNs SHOULD NOT advertise support for 406 mandatory-to-implement record-types. 408 The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging] 409 defines all known logging fields. Logging fields may be reused by 410 different record-types and be mandatory-to-implement in some record- 411 types, but optional in other record-types. CDNs MUST advertise 412 support for optional logging fields within the context of a specific 413 record-type. CDNs SHOULD NOT advertise support for mandatory-to- 414 implement logging fields, for a given record-type. The following 415 logging fields are defined as optional for the "cdni_http_request_v1" 416 record-type in the CDNI Logging Interface document 417 [I-D.ietf-cdni-logging]: 419 o s-ccid 421 o s-sid 423 The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] 424 requires that CDNs be able to parse all the defined metadata objects, 425 but does not require dCDNs to support enforcement of non-structural 426 GenericMetadata objects. Advertising support for mandatory-to- 427 enforce GenericMetadata types MUST be supported. Advertising support 428 for non-mandatory-to-enforce GenericMetadata types SHOULD be 429 supported. Advertisement of non-mandatory-to-enforce GenericMetadata 430 MAY be necessary, e.g., to signal temporary outages and subsequent 431 recovery. It is expected that structural metadata will be supported 432 at all times. 434 The notion of optional types of footprint and capabilities implies 435 that certain implementations might not support all kinds of footprint 436 and capabilities. Therefore, any FCI solution protocol MUST define 437 how the support for optional types of footprint/capabilities will be 438 negotiated between a uCDN and a dCDN that use the particular FCI 439 protocol. In particular, any FCI solution protocol MUST specify how 440 to handle failure cases or non-supported types of footprint/ 441 capabilities. 443 In general, a uCDN MAY ignore capabilities or types of footprints it 444 does not understand; in this case it only selects a suitable dCDN 445 based on the types of capabilities and footprint it understands. 446 Similarly, if a dCDN does not use an optional capability or footprint 447 which is, however, supported by a uCDN, this causes no problem for 448 the FCI functionality because the uCDN decides on the remaining 449 capabilities/footprint information that is being conveyed by the 450 dCDN. 452 4. Capability Advertisement Object 454 To support extensibility, the FCI defines a generic base object 455 (similar to the CDNI Metadata interface GenericMetadata object) 456 [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory 457 parsing requirements for all future FCI objects. 459 Future object definitions (e.g. regarding CDNI Metadata or Logging) 460 will build off the base object defined here, but will be specified in 461 separate documents. 463 4.1. Base Advertisement Object 465 The FCIBase object is an abstraction for managing individual CDNI 466 capabilities in an opaque manner. 468 Property: capability-type 470 Description: CDNI Capability object type. 472 Type: FCI specific CDNI Payload type (from the CDNI Payload 473 Types registry [RFC7736]) 475 Mandatory-to-Specify: Yes. 477 Property: capability-value 479 Description: CDNI Capability object. 481 Type: Format/Type is defined by the value of capability-type 482 property above. 484 Mandatory-to-Specify: Yes. 486 Property: footprints 488 Description: CDNI Capability Footprint. 490 Type: List of CDNI Footprint objects (as defined in 491 [I-D.ietf-cdni-metadata]). 493 Mandatory-to-Specify: No. 495 4.2. Delivery Protocol Capability Object 497 The Delivery Protocol capability object is used to indicate support 498 for one or more of the protocols listed in the CDNI Metadata Protocol 499 Types registry (defined in the CDNI Metadata Interface document 500 [I-D.ietf-cdni-metadata]). 502 Property: delivery-protocols 504 Description: List of supported CDNI Delivery Protocols. 506 Type: List of Protocol Types (from the CDNI Metadata Protocol 507 Types registry [I-D.ietf-cdni-metadata]) 509 Mandatory-to-Specify: Yes. 511 4.2.1. Delivery Protocol Capability Object Serialization 513 The following shows an example of Delivery Protocol Capability Object 514 Serialization, for a CDN that supports only HTTP/1.1 without TLS for 515 content delivery. 517 { 518 "capabilities": [ 519 { 520 "capability-type": "FCI.DeliveryProtocol", 521 "capability-value": { 522 "delivery-protocols": [ 523 "http1.1", 524 ] 525 }, 526 "footprints": [ 527 528 ] 529 } 530 ] 531 } 533 4.3. Acquisition Protocol Capability Object 535 The Acquisition Protocol capability object is used to indicate 536 support for one or more of the protocols listed in the CDNI Metadata 537 Protocol Types registry (defined in the CDNI Metadata Interface 538 document [I-D.ietf-cdni-metadata]). 540 Property: acquisition-protocols 542 Description: List of supported CDNI Acquisition Protocols. 544 Type: List of Protocol Types (from the CDNI Metadata Protocol 545 Types registry [I-D.ietf-cdni-metadata]) 547 Mandatory-to-Specify: Yes. 549 4.3.1. Acquisition Protocol Capability Object Serialization 551 The following shows an example of Acquisition Protocol Capability 552 Object Serialization, for a CDN that supports HTTP/1.1 with or 553 without TLS for content acquisition. 555 { 556 "capabilities": [ 557 { 558 "capability-type": "FCI.AcquisitionProtocol", 559 "capability-value": { 560 "acquisition-protocols": [ 561 "http1.1", 562 "https1.1" 563 ] 564 }, 565 "footprints": [ 566 567 ] 568 } 569 ] 570 } 572 4.4. Redirection Mode Capability Object 574 The Redirection Mode capability object is used to indicate support 575 for one or more of the modes listed in the CDNI Capabilities 576 Redirection Modes registry (see Section 5.2). 578 Property: redirection-modes 580 Description: List of supported CDNI Redirection Modes. 582 Type: List of Redirection Modes (from Section 5.2) 584 Mandatory-to-Specify: Yes. 586 4.4.1. Redirection Mode Capability Object Serialization 588 The following shows an example of Redirection Mode Capability Object 589 Serialization, for a CDN that supports only iterative (but not 590 recursive) redirection with HTTP and DNS. 592 { 593 "capabilities": [ 594 { 595 "capability-type": "FCI.RedirectionMode", 596 "capability-value": { 597 "redirection-modes": [ 598 "DNS-I", 599 "HTTP-I" 600 ] 601 } 602 "footprints": [ 603 604 ] 605 } 606 ] 607 } 609 4.5. CDNI Logging Capability Object 611 The CDNI Logging capability object is used to indicate support for 612 CDNI Logging record-types, as well as CDNI Logging fields which are 613 marked as optional for the specified record-types 614 [I-D.ietf-cdni-logging]. 616 Property: record-type 618 Description: Supported CDNI Logging record-type. 620 Type: String corresponding to an entry from the CDNI Logging 621 record-types registry [I-D.ietf-cdni-logging]) 623 Mandatory-to-Specify: Yes. 625 Property: fields 627 Description: List of supported CDNI Logging fields that are 628 optional for the specified record-type. 630 Type: List of Strings corresponding to entries from the CDNI 631 Logging Field Names registry [I-D.ietf-cdni-logging]. 633 Mandatory-to-Specify: No. Default is that all optional fields 634 are supported. Inclusion of an empty list SHALL be understood 635 to mean that none of the optional fields are supported. 636 Otherwise, only those optional fields that are listed SHALL be 637 understood to be supported. 639 4.5.1. CDNI Logging Capability Object Serialization 641 The following shows an example of CDNI Logging Capability Object 642 Serialization, for a CDN that supports the optional Content 643 Collection ID logging field (but not the optional Session ID logging 644 field) for the "cdni_http_request_v1" record type. 646 { 647 "capabilities": [ 648 { 649 "capability-type": "FCI.Logging", 650 "capability-value": { 651 "record-type": "cdni_http_request_v1", 652 "fields": [ "s-ccid" ] 653 }, 654 "footprints": [ 655 656 ] 657 } 658 ] 659 } 661 The next example shows the CDNI Logging Capability Object 662 Serialization, for a CDN that supports all optional fields for the 663 "cdni_http_request_v1" record type. 665 { 666 "capabilities": [ 667 { 668 "capability-type": "FCI.Logging", 669 "capability-value": { 670 "record-type": "cdni_http_request_v1" 671 }, 672 "footprints": [ 673 674 ] 675 } 676 ] 677 } 679 4.6. CDNI Metadata Capability Object 681 The CDNI Metadata capability object is used to indicate support for 682 CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. 684 Property: metadata 686 Description: List of supported CDNI GenericMetadata types. 688 Type: List of Strings corresponding to entries from the CDNI 689 Payload Type registry [RFC7736]) that correspond to CDNI 690 GenericMetadata objects. 692 Mandatory-to-Specify: Yes. It SHALL be understood that only 693 those GenericMetadata types listed are supported; an empty list 694 SHALL be understood to mean that only structural metadata and 695 simple types are supported [I-D.ietf-cdni-metadata]. 697 4.6.1. CDNI Metadata Capability Object Serialization 699 The following shows an example of CDNI Metadata Capability Object 700 Serialization, for a CDN that supports only the SourceMetadata 701 GenericMetadata type (i.e., it can acquire and deliver content, but 702 cannot enforce and security policies, e.g., time, location, or 703 protocol ACLs). 705 { 706 "capabilities": [ 707 { 708 "capability-type": "FCI.Metadata", 709 "capability-value": { 710 "metadata": ["MI.SourceMetadata"] 711 }, 712 "footprints": [ 713 714 ] 715 } 716 ] 717 } 719 The next example shows the CDNI Metadata Capability Object 720 Serialization, for a CDN that supports only structural metadata 721 (i.e., it can parse metadata as a transit CDN, but cannot enforce 722 security policies or deliver content). 724 { 725 "capabilities": [ 726 { 727 "capability-type": "FCI.Metadata", 728 "capability-value": { 729 "metadata": [] 730 }, 731 "footprints": [ 732 733 ] 734 } 735 ] 736 } 738 5. IANA Considerations 740 5.1. CDNI Payload Types 742 This document requests the registration of the following CDNI Payload 743 Types under the IANA CDNI Payload Type registry: 745 +-------------------------+---------------+ 746 | Payload Type | Specification | 747 +-------------------------+---------------+ 748 | FCI.DeliveryProtocol | RFCthis | 749 | | | 750 | FCI.AcquisitionProtocol | RFCthis | 751 | | | 752 | FCI.RedirectionMode | RFCthis | 753 | | | 754 | FCI.Logging | RFCthis | 755 | | | 756 | FCI.Metadata | RFCthis | 757 +-------------------------+---------------+ 759 [RFC Editor: Please replace RFCthis with the published RFC number for 760 this document.] 762 5.1.1. CDNI FCI DeliveryProtocol Payload Type 764 Purpose: The purpose of this payload type is to distinguish FCI 765 advertisement objects for supported delivery protocols 767 Interface: FCI 769 Encoding: see Section 4.2 771 5.1.2. CDNI FCI AcquisitionProtocol Payload Type 773 Purpose: The purpose of this payload type is to distinguish FCI 774 advertisement objects for supported acquisition protocols 776 Interface: FCI 778 Encoding: see Section 4.3 780 5.1.3. CDNI FCI RedirectionMode Payload Type 782 Purpose: The purpose of this payload type is to distinguish FCI 783 advertisement objects for supported redirection modes 785 Interface: FCI 787 Encoding: see Section 4.4 789 5.1.4. CDNI FCI Logging Payload Type 791 Purpose: The purpose of this payload type is to distinguish FCI 792 advertisement objects for supported CDNI Logging record-types and 793 optional CDNI Logging Field Names. 795 Interface: FCI 797 Encoding: see Section 4.5 799 5.1.5. CDNI FCI Metadata Payload Type 801 Purpose: The purpose of this payload type is to distinguish FCI 802 advertisement objects for supported CDNI GenericMetadata types. 804 Interface: FCI 806 Encoding: see Section 4.6 808 5.2. Redirection Mode Registry 810 The IANA is requested to create a new "CDNI Capabilities Redirection 811 Modes" registry in the "Content Delivery Networks Interconnection 812 (CDNI) Parameters" category. The "CDNI Capabilities Redirection 813 Modes" namespace defines the valid redirection modes that can be 814 advertised as supported by a CDN. Additions to the Redirection Mode 815 namespace conform to the "IETF Review" policy as defined in 816 [RFC5226]. 818 The following table defines the initial Redirection Modes: 820 +------------------+----------------------------------+---------+ 821 | Redirection Mode | Description | RFC | 822 +------------------+----------------------------------+---------+ 823 | DNS-I | Iterative DNS-based Redirection | RFCthis | 824 | | | | 825 | DNS-R | Recursive DNS-based Redirection | RFCthis | 826 | | | | 827 | HTTP-I | Iterative HTTP-based Redirection | RFCthis | 828 | | | | 829 | HTTP-R | Recursive HTTP-based Redirection | RFCthis | 830 +------------------+----------------------------------+---------+ 832 [RFC Editor: Please replace RFCthis with the published RFC number for 833 this document.] 835 6. Security Considerations 837 This specification describes the semantics for capabilities and 838 footprint advertisement objects across interconnected CDNs. It does 839 not, however, specify a concrete protocol for transporting those 840 objects. Specific security mechanisms can only be selected for 841 concrete protocols that instantiate these semantics. This document 842 does, however, place some high-level security constraints on such 843 protocols. 845 All protocols that implement these semantics are REQUIRED to provide 846 integrity and authentication services. Without authentication and 847 integrity, an attacker could trivially deny service by forging a 848 footprint advertisement from a dCDN which claims the network has no 849 footprint or capability. This would prevent the uCDN from delegating 850 any requests to the dCDN. Since a pre-existing relationship between 851 all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary 852 credentials could be conducted before the FCI interface is brought 853 online. The authorization decision to accept advertisements would 854 also follow this pre-existing relationship and any contractual 855 obligations that it stipulates. 857 All protocols that implement these semantics are REQUIRED to provide 858 confidentiality services. Some dCDNs are willing to share 859 information about their footprint or capabilities with a uCDN but not 860 with other, competing dCDNs. For example, if a dCDN incurs an outage 861 that reduces footprint coverage temporarily, that could be 862 information the dCDN would want to share confidentially with the 863 uCDN. 865 As specified in this document, the security requirements of the FCI 866 could be met by hop-by-hop transport-layer security mechanisms 867 coupled with domain certificates as credentials (e.g., TLS transport 868 for HTTP as per [RFC2818] and [RFC7230], with usage guidance from 869 [RFC7525]). There is no apparent need for further object-level 870 security in this framework, as the trust relationships it defines are 871 bilateral relationships between uCDNs and dCDNs rather than 872 transitive relationships. 874 7. References 876 7.1. Normative References 878 [I-D.ietf-cdni-logging] 879 Faucheur, F., Bertrand, G., Oprescu, I., and R. 880 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 881 logging-25 (work in progress), April 2016. 883 [I-D.ietf-cdni-metadata] 884 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 885 "CDN Interconnection Metadata", draft-ietf-cdni- 886 metadata-15 (work in progress), April 2016. 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, 891 . 893 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 894 DOI 10.17487/RFC2818, May 2000, 895 . 897 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 898 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 899 DOI 10.17487/RFC5226, May 2008, 900 . 902 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 903 Protocol (HTTP/1.1): Message Syntax and Routing", 904 RFC 7230, DOI 10.17487/RFC7230, June 2014, 905 . 907 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 908 "Recommendations for Secure Use of Transport Layer 909 Security (TLS) and Datagram Transport Layer Security 910 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 911 2015, . 913 7.2. Informative References 915 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 916 Distribution Network Interconnection (CDNI) Problem 917 Statement", RFC 6707, DOI 10.17487/RFC6707, September 918 2012, . 920 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 921 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 922 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 923 November 2012, . 925 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 926 "Framework for Content Distribution Network 927 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 928 August 2014, . 930 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 931 Network Interconnection (CDNI) Requirements", RFC 7337, 932 DOI 10.17487/RFC7337, August 2014, 933 . 935 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 936 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 937 December 2015, . 939 Appendix A. Main Use Case to Consider 941 Focusing on a main use case that contains a simple (yet somewhat 942 challenging), realistic, and generally imaginable scenario can help 943 in narrowing down the requirements for the CDNI FCI. To this end, 944 the following (simplified) use case can help in clarifying the 945 semantics of footprint and capabilities for CDNI. In particular, the 946 intention of the use case is to clarify what information needs to be 947 exchanged on the CDNI FCI, what types of information need to be 948 supported in a mandatory fashion (and which can be considered 949 optional), and what types of information need to be updated with 950 respect to a priori established CDNI contracts. 952 Use case: A given uCDN has several dCDNs. It selects one dCDN for 953 delivery protocol A and footprint 1 and another dCDN for delivery 954 protocol B and footprint 1. The dCDN that serves delivery protocol B 955 has a further, transitive (level-2) dCDN, that serves delivery 956 protocol B in a subset of footprint 1 where the first-level dCDN 957 cannot serve delivery protocol B itself. What happens if 958 capabilities change in the transitive level-2 dCDN that might affect 959 how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN 960 cannot serve delivery protocol B anymore)? How will these changes be 961 conveyed to the uCDN? In particular, what information does the uCDN 962 need to be able to select a new first-level dCDN, either for all of 963 footprint 1 or only for the subset of footprint 1 that the transitive 964 level-2 dCDN served on behalf of the first-level dCDN? 966 Appendix B. Semantics for Footprint Advertisement 968 Roughly speaking, "footprint" can be defined as "ability and 969 willingness to serve" by a dCDN. However, in addition to simple 970 "ability and willingness to serve", the uCDN could want additional 971 information to make a dCDN selection decision, e.g., "how well" a 972 given dCDN can actually serve a given end user request. The "ability 973 and willingness" to serve SHOULD be distinguished from the subjective 974 qualitative measurement of "how well" it was served. One can imagine 975 that such additional information is implicitly associated with a 976 given footprint, due to contractual agreements, SLAs, business 977 relationships, or past perceptions of dCDN quality. As an 978 alternative, such additional information could also be explicitly 979 tagged along with the footprint. 981 It is reasonable to assume that a significant part of the actual 982 footprint advertisement will happen in contractual agreements between 983 participating CDNs, prior to the advertisement phase using the CDNI 984 FCI. The reason for this assumption is that any contractual 985 agreement is likely to contain specifics about the dCDN coverage 986 (footprint) to which the contractual agreement applies. In 987 particular, additional information to judge the delivery quality 988 associated with a given dCDN footprint might be defined in 989 contractual agreements, outside of the CDNI FCI. Further, one can 990 assume that dCDN contractual agreements about the delivery quality 991 associated with a given footprint will probably be based on high- 992 level aggregated statistics and not too detailed. 994 Given that a large part of footprint advertisement will actually 995 happen in contractual agreements, the semantics of CDNI footprint 996 advertisement refer to answering the following question: what exactly 997 still needs to be advertised by the CDNI FCI? For instance, updates 998 about temporal failures of part of a footprint can be useful 999 information to convey via the CDNI request routing interface. Such 1000 information would provide updates on information previously agreed in 1001 contracts between the participating CDNs. In other words, the CDNI 1002 FCI is a means for a dCDN to provide changes/updates regarding a 1003 footprint it has prior agreed to serve in a contract with a uCDN. 1005 Generally speaking, one can imagine two categories of footprint to be 1006 advertised by a dCDN: 1008 o Footprint could be defined based on "coverage/reachability", where 1009 coverage/reachability refers to a set of prefixes, a geographic 1010 region, or similar boundary. The dCDN claims that it can cover/ 1011 reach 'end user requests coming from this footprint'. 1013 o Footprint could be defined based on "resources", where resources 1014 refers to surrogates/caches a dCDN claims to have (e.g., the 1015 location of surrogates/resources). The dCDN claims that 'from 1016 this footprint' it can serve incoming end user requests. 1018 For each of these footprint types, there are capabilities associated 1019 with a given footprint: 1021 o capabilities such as delivery protocol, redirection mode, and 1022 metadata, which are supported in the coverage area for a 1023 "coverage/reachability" defined footprint, or 1025 o capabilities of resources, such as delivery protocol, redirection 1026 mode, and metadata, which apply to a "resource" defined footprint. 1028 "Resource" types of footprints are more specific than "coverage/ 1029 reachability" types of footprints, where the actual coverage/ 1030 reachability are extrapolated from the resource location (e.g., 1031 netmask applied to resource IP address to derive IP-prefix). The 1032 specific methods for extrapolating coverage/reachability from 1033 resource location are beyond the scope of this document. In the 1034 degenerate case, the resource address could be specified as a 1035 coverage/reachability type of footprint, in which case no 1036 extrapolation is necessary. Resource types of footprints could 1037 expose the internal structure of a CDN network which could be 1038 undesirable. As such, the resource types of footprints are not 1039 considered mandatory to support for CDNI. 1041 Footprints can be viewed as constraints for delegating requests to a 1042 dCDN: A dCDN footprint advertisement tells the uCDN the limitations 1043 for delegating a request to the dCDN. For IP prefixes or ASN(s), the 1044 footprint signals to the uCDN that it should consider the dCDN a 1045 candidate only if the IP address of the request routing source falls 1046 within the prefix set (or ASN, respectively). The CDNI 1047 specifications do not define how a given uCDN determines what address 1048 ranges are in a particular ASN. Similarly, for country codes a uCDN 1049 should only consider the dCDN a candidate if it covers the country of 1050 the request routing source. The CDNI specifications do not define 1051 how a given uCDN determines the country of the request routing 1052 source. Multiple footprint constraints are additive: the 1053 advertisement of different types of footprint narrows the dCDN 1054 candidacy cumulatively. 1056 Independent of the exact type of a footprint, a footprint might also 1057 include the connectivity of a given dCDN to other CDNs that are able 1058 to serve content to users on behalf of that dCDN, to cover cases with 1059 cascaded CDNs. Further, the dCDN needs to be able to express its 1060 footprint to an interested uCDN in a comprehensive form, e.g., as a 1061 data set containing the complete footprint. Making incremental 1062 updates, however, to express dynamic changes in state is also 1063 desirable. 1065 Appendix C. Semantics for Capabilities Advertisement 1067 In general, the dCDN needs to be able to express its general 1068 capabilities to the uCDN. These general capabilities could express 1069 if the dCDN supports a given service, for instance, HTTP vs HTTPS 1070 delivery. Furthermore, the dCDN needs to be able to express 1071 particular capabilities for the delivery in a particular footprint 1072 area. For example, the dCDN might in general offer HTTPS but not in 1073 some specific areas, either for maintenance reasons or because the 1074 caches covering this particular area cannot deliver this type of 1075 service. Hence, in certain cases footprint and capabilities are tied 1076 together and cannot be interpreted independently from each other. In 1077 such cases, i.e., where capabilities need to be expressed on a per 1078 footprint basis, it could be beneficial to combine footprint and 1079 capabilities advertisement. 1081 A high-level and very rough semantic for capabilities is thus the 1082 following: Capabilities are types of information that allow a uCDN to 1083 determine if a dCDN is able (and willing) to accept (and properly 1084 handle) a delegated content request. In addition, Capabilities are 1085 characterized by the fact that this information can change over time 1086 based on the state of the network or caches. 1088 At a first glance, several broad categories of capabilities seem 1089 useful to convey via an advertisement interface, however, advertising 1090 capabilities that change highly dynamically (e.g., real-time delivery 1091 performance metrics, CDN resource load, or other highly dynamically 1092 changing QoS information) is beyond the scope for CDNI FCI. First, 1093 out of the multitude of possible metrics and capabilities, it is hard 1094 to agree on a subset and the precise metrics to be used. Second, it 1095 seems infeasible to specify such highly dynamically changing 1096 capabilities and the corresponding metrics within a reasonable time- 1097 frame. 1099 Useful capabilities refer to information that does not change highly 1100 dynamically and which in many cases is absolutely necessary to decide 1101 on a particular dCDN for a given end user request. For instance, if 1102 an end user request concerns the delivery of a video file with a 1103 certain protocol, the uCDN needs to know if a given dCDN has the 1104 capability of supporting this delivery protocol. 1106 Similar to footprint advertisement, it is reasonable to assume that a 1107 significant part of the actual (resource) capabilities advertisement 1108 will happen in contractual agreements between participating CDNs, 1109 i.e., prior to the advertisement phase using the CDNI FCI. The role 1110 of capability advertisement is hence rather to enable the dCDN to 1111 update a uCDN on changes since a contract has been set up (e.g., in 1112 case a new delivery protocol is suddenly being added to the list of 1113 supported delivery protocols of a given dCDN, or in case a certain 1114 delivery protocol is suddenly not being supported anymore due to 1115 failures). Capabilities advertisement thus refers to conveying 1116 information to a uCDN about changes/updates of certain capabilities 1117 with respect to a given contract. 1119 Given these semantics, it needs to be decided what exact capabilities 1120 are useful and how these can be expressed. Since the details of CDNI 1121 contracts are not known at the time of this writing (and the CDNI 1122 interface are better off being agnostic to these contracts anyway), 1123 it remains to be seen what capabilities will be used to define 1124 agreements between CDNs in practice. One implication for 1125 standardization could be to initially only specify a very limited set 1126 of mandatory capabilities for advertisement and have on top of that a 1127 flexible data model that allows exchanging additional capabilities 1128 when needed. Still, agreement needs to be found on which 1129 capabilities (if any) will be mandatory among CDNs. 1131 It is not feasible to enumerate all the possible options for the 1132 mandatory capabilities listed above (e.g., all the potential delivery 1133 protocols or metadata options) or anticipate all the future needs for 1134 additional capabilities. It would be unreasonable to burden the CDNI 1135 FCI specification with defining each supported capability. Instead, 1136 the CDNI FCI specification should define a generic protocol for 1137 conveying any capability information (e.g. with common encoding, 1138 error handling, and security mechanism; further requirements for the 1139 CDNI FCI Advertisement Interface are listed in [RFC7337]). 1141 Appendix D. Acknowledgment 1143 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 1144 Architecture and Applications of Green Information Centric 1145 Networking), a research project supported jointly by the European 1146 Commission under its 7th Framework Program (contract no. 608518) and 1147 the National Institute of Information and Communications Technology 1148 (NICT) in Japan (contract no. 167). The views and conclusions 1149 contained herein are those of the authors and should not be 1150 interpreted as necessarily representing the official policies or 1151 endorsements, either expressed or implied, of the GreenICN project, 1152 the European Commission, or NICT. 1154 Martin Stiemerling provided initial input to this document and 1155 valuable comments to the ongoing discussions among the authors of 1156 this document. Thanks to Francois Le Faucheur and Scott Wainner for 1157 providing valuable comments and suggestions to the text. 1159 Authors' Addresses 1161 Jan Seedorf 1162 NEC 1163 Kurfuerstenanlage 36 1164 Heidelberg 69115 1165 Germany 1167 Phone: +49 6221 4342 221 1168 Fax: +49 6221 4342 155 1169 Email: seedorf@neclab.eu 1171 Jon Peterson 1172 NeuStar 1173 1800 Sutter St Suite 570 1174 Concord CA 94520 1175 USA 1177 Email: jon.peterson@neustar.biz 1179 Stefano Previdi 1180 Cisco Systems 1181 Via Del Serafico 200 1182 Rome 0144 1183 Italy 1185 Email: sprevidi@cisco.com 1187 Ray van Brandenburg 1188 TNO 1189 Brassersplein 2 1190 Delft 2612CT 1191 The Netherlands 1193 Phone: +31-88-866-7000 1194 Email: ray.vanbrandenburg@tno.nl 1195 Kevin J. Ma 1196 Ericsson 1197 43 Nagog Park 1198 Acton, MA 01720 1199 USA 1201 Phone: +1 978-844-5100 1202 Email: kevin.j.ma@ericsson.com