idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8008], [RFC7336], [RFC6707]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 November 2020) is 1249 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-12 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-13 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO & CDNI WGs J. Seedorf 3 Internet-Draft HFT Stuttgart - Univ. of Applied Sciences 4 Intended status: Standards Track Y. Yang 5 Expires: 21 May 2021 Yale 6 K. Ma 7 Ericsson 8 J. Peterson 9 Neustar 10 J. Zhang 11 Tongji 12 17 November 2020 14 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 15 Footprint and Capabilities Advertisement using ALTO 16 draft-ietf-alto-cdni-request-routing-alto-14 18 Abstract 20 The Content Delivery Networks Interconnection (CDNI) framework 21 [RFC6707] defines a set of protocols to interconnect CDNs, to achieve 22 multiple goals such as extending the reach of a given CDN to areas 23 that are not covered by that particular CDN. One component that is 24 needed to achieve the goal of CDNI described in [RFC7336] is the CDNI 25 Request Routing Footprint & Capabilities Advertisement interface 26 (FCI). [RFC8008] defines precisely the semantics of FCI and provides 27 guidelines on the FCI protocol, but the exact protocol is explicitly 28 outside the scope of that document. This document defines an FCI 29 protocol using the Application-Layer Traffic Optimization (ALTO) 30 protocol, following the guidelines defined in [RFC8008]. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in BCP 37 14 [RFC2119][RFC8174] when, and only when, they appear in all 38 capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 21 May 2021. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.1. Semantics of FCI Advertisement . . . . . . . . . . . . . 5 76 2.2. ALTO Background and Benefits . . . . . . . . . . . . . . 6 77 3. CDNI Advertisement Service . . . . . . . . . . . . . . . . . 8 78 3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 9 81 3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 82 3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.7.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 12 86 3.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 15 87 3.7.3. Incremental Updates Example . . . . . . . . . . . . . 16 88 4. CDNI Advertisement Service using ALTO Network Map . . . . . . 18 89 4.1. Network Map Footprint Type: altopid . . . . . . . . . . . 18 90 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 91 4.2.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 19 92 4.2.2. ALTO Network Map for CDNI Advertisement Example . . . 19 93 4.2.3. ALTO PID Footprints in CDNI Advertisement . . . . . . 20 94 4.2.4. Incremental Updates Example . . . . . . . . . . . . . 21 95 5. Filtered CDNI Advertisement using CDNI Capabilities . . . . . 22 96 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 22 97 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 22 98 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 23 99 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 23 100 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 24 102 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 24 103 5.7.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 24 104 5.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 25 105 5.7.3. Incremental Updates Example . . . . . . . . . . . . . 26 106 6. Query Footprint Properties using ALTO Property Map Service . 27 107 6.1. Representing Footprint Objects as Property Map 108 Entities . . . . . . . . . . . . . . . . . . . . . . . . 27 109 6.1.1. ASN Domain . . . . . . . . . . . . . . . . . . . . . 28 110 6.1.2. COUNTRYCODE Domain . . . . . . . . . . . . . . . . . 29 111 6.2. Representing CDNI Capabilities as Property Map Entity 112 Properties . . . . . . . . . . . . . . . . . . . . . . . 29 113 6.2.1. Defining Information Resource Media Type for Property 114 Type cdni-capabilities . . . . . . . . . . . . . . . 29 115 6.2.2. Intended Semantics of Property Type 116 cdni-capabilities . . . . . . . . . . . . . . . . . . 30 117 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 30 118 6.3.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 30 119 6.3.2. Property Map Example . . . . . . . . . . . . . . . . 30 120 6.3.3. Filtered Property Map Example . . . . . . . . . . . . 31 121 6.3.4. Incremental Updates Example . . . . . . . . . . . . . 33 122 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 123 7.1. application/alto-* Media Types . . . . . . . . . . . . . 34 124 7.2. CDNI Metadata Footprint Type Registry . . . . . . . . . . 35 125 7.3. ALTO Entity Domain Type Registry . . . . . . . . . . . . 36 126 7.4. ALTO Entity Property Type Registry . . . . . . . . . . . 36 127 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 128 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 129 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 130 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 131 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 132 11.2. Informative References . . . . . . . . . . . . . . . . . 40 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 135 1. Introduction 137 The ability to interconnect multiple content delivery networks (CDNs) 138 has many benefits, including increased coverage, capability, and 139 reliability. The Content Delivery Networks Interconnection (CDNI) 140 framework [RFC6707] defines four interfaces to achieve the 141 interconnection of CDNs: (1) the CDNI Request Routing Interface; (2) 142 the CDNI Metadata Interface; (3) the CDNI Logging Interface; and (4) 143 the CDNI Control Interface. 145 Among the four interfaces, the CDNI Request Routing Interface 146 provides key functions, as specified in [RFC6707]: "The CDNI Request 147 Routing interface enables a Request Routing function in an Upstream 148 CDN to query a Request Routing function in a Downstream CDN to 149 determine if the Downstream CDN is able (and willing) to accept the 150 delegated Content Request. It also allows the Downstream CDN to 151 control what should be returned to the User Agent in the redirection 152 message by the upstream Request Routing function." At a high level, 153 the scope of the CDNI Request Routing Interface, therefore, contains 154 two main tasks: (1) determining if the dCDN (downstream CDN) is 155 willing to accept a delegated content request, and (2) redirecting 156 the content request coming from a uCDN (upstream CDN) to the proper 157 entry point or entity in the dCDN. 159 Correspondingly, the request routing interface is broadly divided 160 into two functionalities: (1) the CDNI Footprint & Capabilities 161 Advertisement interface (FCI) defined in [RFC8008], and (2) the CDNI 162 Request Routing Redirection interface (RI) defined in [RFC7975]. 163 Since this document focuses on the first functionality (CDNI FCI), 164 below is more details about it. 166 Specifically, CDNI FCI allows both an advertisement from a dCDN to a 167 uCDN (push) and a query from a uCDN to a dCDN (pull) so that the uCDN 168 knows whether it can redirect a particular user request to that dCDN. 170 A key component in defining CDNI FCI is defining objects describing 171 the footprints and capabilities of a dCDN. Such objects are already 172 defined in [RFC8008]. A protocol to transport and update such 173 objects between a uCDN and a dCDN, however, is not defined. Hence, 174 the scope of this document is to define such a protocol by 175 introducing a new Application-Layer Traffic Optimization (ALTO) 176 [RFC7285] service called "CDNI Advertisement Service". 178 There are multiple benefits in using ALTO as a transport protocol, as 179 discussed in Section 2.2. 181 The rest of this document is organized as follows. Section 2 182 provides non-normative background on both CDNI FCI and ALTO. 183 Section 3 introduces the most basic service, called "CDNI 184 Advertisement Service", to realize CDNI FCI using ALTO. Section 4 185 demonstrates a key benefit of using ALTO: the ability to integrate 186 CDNI FCI with ALTO network maps. Such integration provides new 187 granularity to describe footprints. Section 5 introduces "Filtered 188 CDNI Advertisement Service" to allow a uCDN to get footprints with 189 given capabilities instead of getting the full resource, which can be 190 large. Section 6 further shows another benefit of using ALTO: the 191 ability to query footprint properties using ALTO unified properties. 192 In this way, a uCDN can effectively fetch capabilities of footprints 193 in which it is interested. IANA and security considerations are 194 discussed in Section 7 and Section 8 respectively. 196 2. Background 198 The design of CDNI FCI transport using ALTO depends on the 199 understanding of both FCI semantics and ALTO. Hence, this document 200 starts with a non-normative review for both. The review uses the 201 terminologies for CDNI as defined in [RFC6707], [RFC8006] and 202 [RFC8008]; those for ALTO as defined in [RFC7285] and 203 [I-D.ietf-alto-unified-props-new]. 205 2.1. Semantics of FCI Advertisement 207 [RFC8008] (CDNI "Footprint and Capabilities Semantics") defines the 208 semantics of CDNI FCI, provides guidance on what Footprint and 209 Capabilities mean in a CDNI context, and specifies the requirements 210 on the CDNI FCI transport protocol. The definitions in [RFC8008] 211 depend on [RFC8006]. Below is a non-normative review of key related 212 points of [RFC8008] and [RFC8006]. For detailed information and 213 normative specification, the reader is referred to these two RFCs. 215 * Multiple types of mandatory-to-implement footprints (ipv4cidr, 216 ipv6cidr, asn, and countrycode) are defined in [RFC8006]. A "Set 217 of IP-prefixes" can contain both full IP addresses (i.e., a /32 218 for IPv4 or a /128 for IPv6) and IP prefixes with an arbitrary 219 prefix length. There must also be support for multiple IP address 220 versions, i.e., IPv4 and IPv6, in such a footprint. 222 * Multiple initial types of capabilities are defined in [RFC8008] 223 including (1) Delivery Protocol, (2) Acquisition Protocol, (3) 224 Redirection Mode, (4) Capabilities related to CDNI Logging, and 225 (5) Capabilities related to CDNI Metadata. They are required in 226 all cases and therefore considered as mandatory-to-implement 227 capabilities for all CDNI FCI implementations. 229 * Footprint and capabilities are defined together and cannot be 230 interpreted independently from each other. Specifically, 231 [RFC8008] integrates footprint and capabilities with an approach 232 of "capabilities with footprint restrictions", by expressing 233 capabilities on a per footprint basis. 235 * Specifically, for all mandatory-to-implement footprint types, 236 footprints can be viewed as constraints for delegating requests to 237 a dCDN: A dCDN footprint advertisement tells the uCDN the 238 limitations for delegating a request to the dCDN. For IP prefixes 239 or ASN(s), the footprint signals to the uCDN that it should 240 consider the dCDN a candidate only if the IP address of the 241 request routing source falls within the prefix set (or ASN, 242 respectively). The CDNI specifications do not define how a given 243 uCDN determines what address ranges are in a particular ASN. 244 Similarly, for country codes, a uCDN should only consider the dCDN 245 a candidate if it covers the country of the request routing 246 source. The CDNI specifications do not define how a given uCDN 247 determines the country of the request routing source. Multiple 248 footprint constraints are additive, i.e., the advertisement of 249 different types of footprint narrows the dCDN candidacy 250 cumulatively. 252 * Given that a large part of Footprint and Capabilities 253 Advertisement may actually happen in contractual agreements, the 254 semantics of CDNI Footprint and Capabilities advertisement refers 255 to answering the following question: what exactly still needs to 256 be advertised by the CDNI FCI? For instance, updates about 257 temporal failures of part of a footprint can be useful information 258 to convey via the CDNI FCI. Such information would provide 259 updates on information previously agreed in contracts between the 260 participating CDNs. In other words, the CDNI FCI is a means for a 261 dCDN (downstream CDN) to provide changes/updates regarding a 262 footprint and/or capabilities that it has prior agreed to serve in 263 a contract with a uCDN (upstream CDN). Hence, server push and 264 incremental encoding will be necessary techniques. 266 2.2. ALTO Background and Benefits 268 Application-Layer Traffic Optimization (ALTO) [RFC7285] defines an 269 approach for conveying network layer (topology) information to 270 "guide" the resource provider selection process in distributed 271 applications that can choose among several candidate resources 272 providers to retrieve a given resource. Usually, it is assumed that 273 an ALTO server conveys information that these applications cannot 274 measure or have difficulty measuring themselves [RFC5693]. 276 Originally, ALTO was motivated by optimizing cross-ISP traffic 277 generated by P2P applications [RFC5693]. However, ALTO can also be 278 used for improving the request routing in CDNs. In particular, the 279 CDNI problem statement [RFC6707] explicitly mentions ALTO as a 280 candidate protocol for "actual algorithms for selection of CDN or 281 Surrogate by Request-Routing systems". 283 The following reasons make ALTO a suitable candidate protocol for 284 dCDN (downstream CDN) selection as part of CDNI request routing and, 285 in particular, for an FCI protocol: 287 * Application Layer-oriented: ALTO is a protocol specifically 288 designed to improve application layer traffic (and application 289 layer connections among hosts on the Internet) by providing 290 additional information to applications that these applications 291 could not easily retrieve themselves. This matches the need of 292 CDNI: a uCDN wants to improve application layer CDN request 293 routing by using information (provided by a dCDN) that the uCDN 294 could not easily obtain otherwise. Hence, ALTO can help a uCDN to 295 select a proper dCDN by first providing dCDNs' capabilities as 296 well as footprints (see Section 3) and then providing costs of 297 surrogates in a dCDN by ALTO cost maps. 299 * Security: The identification between uCDNs and dCDNs is an 300 important requirement. ALTO maps can be signed and hence provide 301 inherent integrity protection. Please see Section 8. 303 * RESTful Design: The ALTO protocol has undergone extensive 304 revisions in order to provide a RESTful design regarding the 305 client-server interaction specified by the protocol. A CDNI FCI 306 interface based on ALTO would inherit this RESTful design. Please 307 see Section 3. 309 * Error-handling: The ALTO protocol provides extensive error- 310 handling in the whole request and response process (see 311 Section 8.5 of [RFC7285]). A CDNI FCI interface based on ALTO 312 would inherit this this extensive error-handling framework. 313 Please see Section 5. 315 * Map Service: The semantics of an ALTO network map is an exact 316 match for the needed information to convey a footprint by a dCDN, 317 in particular, if such a footprint is being expressed by IP-prefix 318 ranges. Please see Section 4. 320 * Filtered Map Service: The ALTO map filtering service would allow a 321 uCDN to query only for parts of an ALTO map. For example, the 322 ALTO filtered property map service can enable a uCDN to query 323 properties of a part of footprints efficiently (see Section 6). 325 * Server-initiated Notifications and Incremental Updates: When the 326 footprint or the capabilities of a dCDN change (i.e., unexpectedly 327 from the perspective of a uCDN), server-initiated notifications 328 would enable a dCDN to inform a uCDN about such changes directly. 329 Consider the case where - due to failure - part of the footprint 330 of the dCDN is not functioning, i.e., the CDN cannot serve content 331 to such clients with reasonable QoS. Without server-initiated 332 notifications, the uCDN might still use a recent network and cost 333 map from the dCDN, and therefore redirect requests to the dCDN 334 which it cannot serve. Similarly, the possibility for incremental 335 updates would enable efficient conveyance of the aforementioned 336 (or similar) status changes by the dCDN to the uCDN. The newest 337 design of ALTO supports server pushed incremental updates 338 [RFC8895]. 340 * Content Availability on Hosts: A dCDN might want to express CDN 341 capabilities in terms of certain content types (e.g., codecs/ 342 formats, or content from certain content providers). The new 343 endpoint property for ALTO would enable a dCDN to make such 344 information available to a uCDN. This would enable a uCDN to 345 determine whether a dCDN actually has the capabilities for a given 346 type of content requested. 348 * Resource Availability on Hosts or Links: The capabilities on links 349 (e.g., maximum bandwidth) or caches (e.g., average load) might be 350 useful information for a uCDN for optimized dCDN selection. For 351 instance, if a uCDN receives a streaming request for content with 352 a certain bitrate, it needs to know if it is likely that a dCDN 353 can fulfill such stringent application-level requirements (i.e., 354 can be expected to have enough consistent bandwidth) before it 355 redirects the request. In general, if ALTO could convey such 356 information via new endpoint properties, it would enable more 357 sophisticated means for dCDN selection with ALTO. ALTO Path 358 Vector Extension [I-D.ietf-alto-path-vector] is designed to allow 359 ALTO clients to query information such as capacity regions for a 360 given set of flows. 362 3. CDNI Advertisement Service 364 The ALTO protocol is based on the ALTO Information Service Framework 365 which consists of multiple services, where all ALTO services are 366 "provided through a common transport protocol, messaging structure 367 and encoding, and transaction model" [RFC7285]. The ALTO protocol 368 specification [RFC7285] defines multiple initial services, e.g., the 369 ALTO network map service and cost map service. 371 This document defines a new ALTO service called "CDNI Advertisement 372 Service" which conveys JSON objects of media type "application/alto- 373 cdni+json". These JSON objects are used to transport 374 BaseAdvertisementObject objects defined in [RFC8008]; this document 375 specifies how to transport such BaseAdvertisementObject objects via 376 the ALTO protocol with the ALTO "CDNI Advertisement Service". 377 Similar to other ALTO services, this document defines the ALTO 378 information resource for the "CDNI Advertisement Service" as follows. 380 3.1. Media Type 382 The media type of the CDNI Advertisement resource is "application/ 383 alto-cdni+json". 385 3.2. HTTP Method 387 A CDNI Advertisement resource is requested using the HTTP GET method. 389 3.3. Accept Input Parameters 391 None. 393 3.4. Capabilities 395 None. 397 3.5. Uses 399 The "uses" field SHOULD NOT appear unless the CDNI Advertisement 400 resource depends on other ALTO information resources. If the CDNI 401 Advertisement resource has dependent resources, the resource IDs of 402 its dependent resources MUST be included into the "uses" field. This 403 document only defines one potential dependent resource for the CDNI 404 Advertisement resource. See Section 4 for details of when and how to 405 use it. Future documents may extend the CDNI Advertisement resource 406 and allow other dependent resources. 408 3.6. Response 410 The "meta" field of a CDNI Advertisement response MUST include the 411 "vtag" field defined in Section 10.3 of [RFC7285]. This field 412 provides the version of the retrieved CDNI FCI resource. 414 If a CDNI Advertisement response depends on other ALTO information 415 resources, it MUST include the "dependent-vtags" field, whose value 416 is an array to indicate the version tags of the resources used, where 417 each resource is specified in "uses" of its IRD entry. 419 The data component of an ALTO CDNI Advertisement response is named 420 "cdni-advertisement", which is a JSON object of type 421 CDNIAdvertisementData: 423 object { 424 CDNIAdvertisementData cdni-advertisement; 425 } InfoResourceCDNIAdvertisement : ResponseEntityBase; 427 object { 428 BaseAdvertisementObject capabilities-with-footprints<0..*>; 429 } CDNIAdvertisementData; 431 Specifically, a CDNIAdvertisementData object is a JSON object that 432 includes only one property named "capabilities-with-footprints", 433 whose value is an array of BaseAdvertisementObject objects. 435 The syntax and semantics of BaseAdvertisementObject are well defined 436 in Section 5.1 of [RFC8008]. A BaseAdvertisementObject object 437 includes multiple properties, including capability-type, capability- 438 value, and footprints, where footprints are defined in 439 Section 4.2.2.2 of [RFC8006]. 441 To be self-contained, below is a non-normative specification of 442 BaseAdvertisementObject. As mentioned above, the normative 443 specification of BaseAdvertisementObject is in [RFC8008]. 445 object { 446 JSONString capability-type; 447 JSONValue capability-value; 448 Footprint footprints<0..*>; 449 } BaseAdvertisementObject; 451 object { 452 JSONString footprint-type; 453 JSONString footprint-value<1..*>; 454 } Footprint; 456 For each BaseAdvertisementObject, the ALTO client MUST interpret 457 footprints appearing multiple times as if they appeared only once. 458 If footprints in a BaseAdvertisementObject is null or empty or not 459 appearing, the ALTO client MUST understand that the capabilities in 460 this BaseAdvertisementObject have the "global" coverage. 462 Note: Further optimization of BaseAdvertisement objects to 463 effectively provide the advertisement of capabilities with footprint 464 restrictions is certainly possible. For example, these two examples 465 below both describe that the dCDN can provide capabilities 466 ["http/1.1", "https/1.1"] for the same footprints. However, the 467 latter one is smaller in its size. 469 EXAMPLE 1 470 { 471 "meta" : {...}, 472 "cdni-advertisement": { 473 "capabilities-with-footprints": [ 474 { 475 "capability-type": "FCI.DeliveryProtocol", 476 "capability-value": { 477 "delivery-protocols": [ 478 "http/1.1" 479 ] 480 }, 481 "footprints": [ 482 483 ] 484 }, 485 { 487 "capability-type": "FCI.DeliveryProtocol", 488 "capability-value": { 489 "delivery-protocols": [ 490 "https/1.1" 491 ] 492 }, 493 "footprints": [ 494 495 ] 496 } 497 ] 498 } 499 } 501 EXAMPLE 2 502 { 503 "meta" : {...}, 504 "cdni-advertisement": { 505 "capabilities-with-footprints": [ 506 { 507 "capability-type": "FCI.DeliveryProtocol", 508 "capability-value": { 509 "delivery-protocols": [ 510 "https/1.1", 511 "http/1.1" 512 ] 513 }, 514 "footprints": [ 515 516 ] 517 } 518 ] 519 } 520 } 522 Since such optimizations are not required for the basic 523 interconnection of CDNs, the specifics of such mechanisms are outside 524 the scope of this document. 526 This document only requires the ALTO server to provide the initial 527 FCI-specific CDNI Payload Types defined in [RFC8008] as the 528 mandatory-to-implement CDNI capabilities. There may be other 529 documents extending BaseAdvertisementObject and additional CDNI 530 capabilities. They are outside the scope of this document. To 531 support them, future documents can extend the specification defined 532 in this document. 534 3.7. Examples 536 3.7.1. IRD Example 538 Below is the information resource directory (IRD) of a simple, 539 example ALTO server. The server provides both base ALTO information 540 resources (e.g., network maps) and CDNI FCI related information 541 resources (e.g., CDNI Advertisement resources), demonstrating a 542 single, integrated environment. 544 Specifically, the IRD announces two network maps, one CDNI 545 Advertisement resource without dependency, one CDNI Advertisement 546 resource depending on a network map, one filtered CDNI Advertisement 547 resource to be defined in Section 5, one property map including 548 "cdni-capabilities" as its entity property, one filtered property map 549 including "cdni-capabilities" and "pid" as its entity properties, and 550 two update stream services (one for updating CDNI Advertisement 551 resources, and the other for updating property maps). 553 GET /directory HTTP/1.1 554 Host: alto.example.com 555 Accept: application/alto-directory+json,application/alto-error+json 557 HTTP/1.1 200 OK 558 Content-Length: 3571 559 Content-Type: application/alto-directory+json 561 { 562 "meta" : { 563 "default-alto-network-map": "my-default-network-map" 564 }, 565 "resources": { 566 "my-default-network-map": { 567 "uri" : "https://alto.example.com/networkmap", 568 "media-type" : "application/alto-networkmap+json" 569 }, 570 "my-eu-netmap" : { 571 "uri" : "https://alto.example.com/myeunetmap", 572 "media-type" : "application/alto-networkmap+json" 573 }, 574 "my-default-cdnifci": { 575 "uri" : "https://alto.example.com/cdnifci", 576 "media-type": "application/alto-cdni+json" 577 }, 578 "my-cdnifci-with-pid-footprints": { 579 "uri" : "https://alto.example.com/networkcdnifci", 580 "media-type" : "application/alto-cdni+json", 581 "uses" : [ "my-eu-netmap" ] 582 }, 583 "my-filtered-cdnifci" : { 584 "uri" : "https://alto.example.com/cdnifci/filtered", 585 "media-type" : "application/alto-cdni+json", 586 "accepts" : "application/alto-cdnifilter+json" 587 }, 588 "cdnifci-property-map" : { 589 "uri" : "https://alto.example.com/propmap/full/cdnifci", 590 "media-type" : "application/alto-propmap+json", 591 "uses": [ "my-default-cdni" ], 592 "capabilities" : { 593 "mappings": { 594 "ipv4": [ "my-default-cdni.cdni-capabilities" ], 595 "ipv6": [ "my-default-cdni.cdni-capabilities" ], 596 "countrycode": [ 597 "my-default-cdni.cdni-capabilities" ], 598 "asn": [ "my-default-cdni.cdni-capabilities" ] 599 } 600 } 602 }, 603 "filtered-cdnifci-property-map" : { 604 "uri" : "https://alto.example.com/propmap/lookup/cdnifci-pid", 605 "media-type" : "application/alto-propmap+json", 606 "accepts" : "application/alto-propmapparams+json", 607 "uses": [ "my-default-cdni", "my-default-network-map" ], 608 "capabilities" : { 609 "mappings": { 610 "ipv4": [ "my-default-cdni.cdni-capabilities", 611 "my-default-network-map.pid" ], 612 "ipv6": [ "my-default-cdni.cdni-capabilities", 613 "my-default-network-map.pid" ], 614 "countrycode": [ 615 "my-default-cdni.cdni-capabilities" ], 616 "asn": [ "my-default-cdni.cdni-capabilities" ] 617 } 618 } 619 }, 620 "update-my-cdni-fci" : { 621 "uri": "https:///alto.example.com/updates/cdnifci", 622 "media-type" : "text/event-stream", 623 "accepts" : "application/alto-updatestreamparams+json", 624 "uses" : [ 625 "my-default-network-map", 626 "my-eu-netmap", 627 "my-default-cdnifci", 628 "my-filtered-cdnifci", 629 "my-cdnifci-with-pid-footprints" 630 ], 631 "capabilities" : { 632 "incremental-change-media-types" : { 633 "my-default-network-map" : "application/json-patch+json", 634 "my-eu-netmap" : "application/json-patch+json", 635 "my-default-cdnifci" : 636 "application/merge-patch+json,application/json-patch+json", 637 "my-filtered-cdnifci" : 638 "application/merge-patch+json,application/json-patch+json", 639 "my-cdnifci-with-pid-footprints" : 640 "application/merge-patch+json,application/json-patch+json" 641 } 642 } 643 }, 644 "update-my-props": { 645 "uri" : "https://alto.example.com/updates/properties", 646 "media-type" : "text/event-stream", 647 "uses" : [ 648 "cdnifci-property-map", 649 "filtered-cdnifci-property-map" 651 ], 652 "capabilities" : { 653 "incremental-change-media-types": { 654 "cdnifci-property-map" : 655 "application/merge-patch+json,application/json-patch+json", 656 "filtered-cdnifci-property-map": 657 "application/merge-patch+json,application/json-patch+json" 658 } 659 } 660 } 661 } 662 } 664 3.7.2. Basic Example 666 This basic example demonstrates a simple CDNI Advertisement resource, 667 which does not depend on other resources. There are three 668 BaseAdvertisementObjects in this resource and these objects' 669 capabilities are http/1.1 delivery protocol, [http/1.1, https/1.1] 670 delivery protocol, and https/1.1 acquisition protocol, respectively. 672 GET /cdnifci HTTP/1.1 673 Host: alto.example.com 674 Accept: application/alto-cdni+json, 675 application/alto-error+json 677 HTTP/1.1 200 OK 678 Content-Length: 1235 679 Content-Type: application/alto-cdni+json 681 { 682 "meta" : { 683 "vtag": { 684 "resource-id": "my-default-cdnifci", 685 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 686 } 687 }, 688 "cdni-advertisement": { 689 "capabilities-with-footprints": [ 690 { 691 "capability-type": "FCI.DeliveryProtocol", 692 "capability-value": { 693 "delivery-protocols": [ 694 "http/1.1" 695 ] 696 }, 697 "footprints": [ 698 { 699 "footprint-type": "ipv4cidr", 700 "footprint-value": [ "192.0.2.0/24" ] 701 } 702 ] 703 }, 704 { 705 "capability-type": "FCI.DeliveryProtocol", 706 "capability-value": { 707 "delivery-protocols": [ 708 "https/1.1", 709 "http/1.1" 710 ] 711 }, 712 "footprints": [ 713 { 714 "footprint-type": "ipv4cidr", 715 "footprint-value": [ "198.51.100.0/24" ] 716 } 717 ] 718 }, 719 { 720 "capability-type": "FCI.AcquisitionProtocol", 721 "capability-value": { 722 "acquisition-protocols": [ 723 "https/1.1" 724 ] 725 }, 726 "footprints": [ 727 { 728 "footprint-type": "ipv4cidr", 729 "footprint-value": [ "203.0.113.0/24" ] 730 } 731 ] 732 } 733 ] 734 } 735 } 737 3.7.3. Incremental Updates Example 739 A benefit of using ALTO to provide CDNI Advertisement resources is 740 that such resources can be updated using ALTO incremental updates. 741 Below is an example that also shows the benefit of having both JSON 742 merge patch and JSON patch to encode updates. 744 At first, an ALTO client requests updates for "my-default-cdnifci", 745 and the ALTO server returns the "control-uri" followed by the full 746 CDNI Advertisement response. Then when there is a change in the 747 delivery-protocols in that http/1.1 is removed (from [http/1.1, 748 https/1.1] to only https/1.1) due to maintenance of the https/1.1 749 clusters, the ALTO server regenerates the new CDNI Advertisement 750 resource and pushes the full replacement to the ALTO client. Later 751 on, the ALTO server notifies the ALTO client that "192.0.2.0/24" is 752 added into the "ipv4" footprint object for delivery-protocol 753 https/1.1 by sending the change encoded by JSON patch to the ALTO 754 client. 756 POST /updates/cdnifci HTTP/1.1 757 Host: alto.example.com 758 Accept: text/event-stream,application/alto-error+json 759 Content-Type: application/alto-updatestreamparams+json 760 Content-Length: 92 762 { "add": { 763 "my-cdnifci-stream": { 764 "resource-id": "my-default-cdnifci" 765 } 766 } 767 } 769 HTTP/1.1 200 OK 770 Connection: keep-alive 771 Content-Type: text/event-stream 773 event: application/alto-updatestreamcontrol+json 774 data: {"control-uri": 775 data: "https://alto.example.com/updates/streams/3141592653589"} 777 event: application/alto-cdni+json,my-cdnifci-stream 778 data: { ... full CDNI Advertisement resource ... } 780 event: application/alto-cdni+json,my-cdnifci-stream 781 data: { 782 data: "meta": { 783 data: "vtag": { 784 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 785 data: } 786 data: }, 787 data: "cdni-advertisement": { 788 data: "capabilities": [ 789 data: { 790 data: "capability-type": "FCI.DeliveryProtocol", 791 data: "capability-value": { 792 data: "delivery-protocols": [ 793 data: "https/1.1" 794 data: ] 795 data: }, 796 data: "footprints": [ 797 data: { "footprint-type": "ipv4cidr", 798 data: "footprint-value": [ "203.0.113.0/24" ] 799 data: } 800 data: ] 801 data: }, 802 data: { ... other CDNI advertisement object ... } 803 data: ] 804 data: } 805 data: } 807 event: application/json-patch+json,my-cdnifci-stream 808 data: [ 809 data: { "op": "replace", 810 data: "path": "/meta/vtag/tag", 811 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 812 data: }, 813 data: { "op": "add", 814 data: "path": "/cdni-advertisement/capabilities-with-footprints 815 /0/footprints/0/footprint-value/-", 816 data: "value": "192.0.2.0/24" 817 data: } 818 data: ] 820 4. CDNI Advertisement Service using ALTO Network Map 822 4.1. Network Map Footprint Type: altopid 824 The ALTO protocol defines a concept called PID to represent a group 825 of IPv4 or IPv6 addresses which can be applied the same management 826 policy. The PID is an alternative to the pre-defined CDNI footprint 827 types (i.e., ipv4cidr, ipv6cidr, asn, and countrycode). 829 To leverage this concept, this document defines a new CDNI Footprint 830 Type called "altopid". A CDNI Advertisement resource can depend on 831 an ALTO network map resource and use "altopid" footprints to compress 832 its CDNI Footprint Payload. 834 Specifically, the "altopid" footprint type indicates that the 835 corresponding footprint value is a list of PIDNames as defined in 836 [RFC7285]. These PIDNames are references of PIDs in a network map 837 resource. Hence a CDNI Advertisement resource using "altopid" 838 footprints depends on a network map. For such a CDNI Advertisement 839 resource, the resource id of its dependent network map MUST be 840 included in the "uses" field of its IRD entry, and the "dependent- 841 vtag" field with a reference to this network map MUST be included in 842 its response (see the example in Section 4.2.3). 844 4.2. Examples 846 4.2.1. IRD Example 848 The examples below use the same IRD given in Section 3.7.1. 850 4.2.2. ALTO Network Map for CDNI Advertisement Example 852 Below is an example network map whose resource id is "my-eu-netmap", 853 and this map is referenced by the CDNI Advertisement example in 854 Section 4.2.3. 856 GET /myeunetmap HTTP/1.1 857 Host: alto.example.com 858 Accept: application/alto-networkmap+json,application/alto-error+json 860 HTTP/1.1 200 OK 861 Content-Length: 309 862 Content-Type: application/alto-networkmap+json 864 { 865 "meta": { 866 "vtag": [ 867 { "resource-id": "my-eu-netmap", 868 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 869 } 870 ] 871 }, 872 "network-map": { 873 "south-france" : { 874 "ipv4": [ "192.0.2.0/24", "198.51.100.0/25" ] 875 }, 876 "germany": { 877 "ipv4": [ "203.0.113.0/24" ] 878 } 879 } 880 } 882 4.2.3. ALTO PID Footprints in CDNI Advertisement 884 This example shows a CDNI Advertisement resource that depends on a 885 network map described in Section 4.2.2. 887 GET /networkcdnifci HTTP/1.1 888 Host: alto.example.com 889 Accept: application/alto-cdni+json,application/alto-error+json 891 HTTP/1.1 200 OK 892 Content-Length: 738 893 Content-Type: application/alto-cdni+json 895 { 896 "meta" : { 897 "dependent-vtags" : [ 898 { 899 "resource-id": "my-eu-netmap", 900 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 901 } 902 ] 903 }, 904 "cdni-advertisement": { 905 "capabilities-with-footprints": [ 906 { "capability-type": "FCI.DeliveryProtocol", 907 "capability-value": [ "https/1.1" ], 908 "footprints": [ 909 { "footprint-type": "altopid", 910 "footprint-value": [ "south-france" ] 911 } 912 ] 913 }, 914 { "capability-type": "FCI.AcquisitionProtocol", 915 "capability-value": [ "https/1.1" ], 916 "footprints": [ 917 { "footprint-type": "altopid", 918 "footprint-value": [ "germany", "south-france" ] 919 } 920 ] 921 } 922 ] 923 } 924 } 926 4.2.4. Incremental Updates Example 928 In this example, the ALTO client is interested in changes of "my- 929 cdnifci-with-pid-footprints" and its dependent network map "my-eu- 930 netmap". Considering two changes, the first one is to change 931 footprints of the https/1.1 delivery protocol capability, and the 932 second one is to remove "south-france" from the footprints of the 933 https/1.1 acquisition protocol capability. 935 POST /updates/cdnifci HTTP/1.1 936 Host: alto.example.com 937 Accept: text/event-stream,application/alto-error+json 938 Content-Type: application/alto-updatestreamparams+json 939 Content-Length: 183 941 { "add": { 942 "my-eu-netmap-stream": { 943 "resource-id": "my-eu-netmap" 944 }, 945 "my-netmap-cdnifci-stream": { 946 "resource-id": "my-cdnifci-with-pid-footprints" 947 } 948 } 949 } 951 HTTP/1.1 200 OK 952 Connection: keep-alive 953 Content-Type: text/event-stream 955 event: application/alto-updatestreamcontrol+json 956 data: {"control-uri": 957 data: "https://alto.example.com/updates/streams/3141592653590"} 959 event: application/alto-networkmap+json,my-eu-netmap-stream 960 data: { ... full Network Map of my-eu-netmap ... } 962 event: application/alto-cdnifci+json,my-netmap-cdnifci-stream 963 data: { ... full CDNI Advertisement resource ... } 965 event: application/json-patch+json,my-netmap-cdnifci-stream 966 data: [ 967 data: { "op": "replace", 968 data: "path": "/meta/vtag/tag", 969 data: "value": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 970 data: }, 971 data: { "op": "add", 972 data: "path": 974 data: "/cdni-advertisement/capabilities-with-footprints 975 /0/footprints/0/footprint-value/-", 976 data: "value": "germany" 977 data: } 978 data: ] 980 event: application/json-patch+json,my-netmap-cdnifci-stream 981 data: [ 982 data: { "op": "replace", 983 data: "path": "/meta/vtag/tag", 984 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 985 data: }, 986 data: { "op": "remove", 987 data: "path": 988 data: "/cdni-advertisement/capabilities-with-footprints 989 /1/footprints/0/footprint-value/1" 990 data: } 991 data: ] 993 5. Filtered CDNI Advertisement using CDNI Capabilities 995 Section 3 and Section 4 describe CDNI Advertisement Service which can 996 be used to enable a uCDN to get capabilities with footprint 997 restrictions from dCDNs. However, since always getting full CDNI 998 Advertisement resources from dCDNs is inefficient, this document 999 introduces a new service named "Filtered CDNI Advertisement Service", 1000 to allow a client to filter a CDNI Advertisement resource using a 1001 client-given set of CDNI capabilities. For each entry of the CDNI 1002 Advertisement response, an entry will only be returned to the client 1003 if it contains at least one of the client given CDNI capabilities. 1004 The relationship between a filtered CDNI Advertisement resource and a 1005 CDNI Advertisement resource is similar to the relationship between a 1006 filtered network/cost map and a network/cost map. 1008 5.1. Media Type 1010 A filtered CDNI Advertisement resource uses the same media type 1011 defined for the CDNI Advertisement resource in Section 3.1. 1013 5.2. HTTP Method 1015 A filtered CDNI Advertisement resource is requested using the HTTP 1016 POST method. 1018 5.3. Accept Input Parameters 1020 The input parameters for a filtered CDNI Advertisement resource are 1021 supplied in the entity body of the POST request. This document 1022 specifies the input parameters with a data format indicated by the 1023 media type "application/alto-cdnifilter+json" which is a JSON object 1024 of type ReqFilteredCDNIAdvertisement, where: 1026 object { 1027 JSONString capability-type; 1028 JSONValue capability-value; 1029 } CDNICapability; 1031 object { 1032 [CDNIFCICapability cdni-capabilities<0..*>;] 1033 } ReqFilteredCDNIAdvertisement; 1035 with fields: 1037 capability-type: The same as Base Advertisement Object's capability- 1038 type defined in Section 5.1 of [RFC8008]. 1040 capability-value: The same as Base Advertisement Object's 1041 capability-value defined in Section 5.1 of [RFC8008]. 1043 cdni-fci-capabilities: A list of CDNI capabilities defined in 1044 Section 5.1 of [RFC8008] for which footprints are to be returned. 1045 If a list is empty or not appearing, the ALTO server MUST 1046 interpret it as a request for the full CDNI Advertisement 1047 resource. The ALTO server MUST interpret entries appearing in a 1048 list multiple times as if they appeared only once. If the ALTO 1049 server does not define any footprints for a CDNI capability, it 1050 MUST omit this capability from the response. 1052 5.4. Capabilities 1054 None. 1056 5.5. Uses 1058 Same to the "uses" field of the CDNI Advertisement resource (see 1059 Section 3.5). 1061 5.6. Response 1063 The response MUST indicate an error, using ALTO protocol error 1064 handling specified in Section 8.5 of the ALTO protocol [RFC7285], if 1065 the request is invalid. 1067 Specifically, a filtered CDNI Advertisement request is invalid if: 1069 * the value of "capability-type" is null; 1071 * the value of "capability-value" is null; 1073 * the value of "capability-value" is inconsistent with "capability- 1074 type". 1076 When a request is invalid, the ALTO server MUST return an 1077 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], 1078 and the "value" field of the error message SHOULD indicate this CDNI 1079 capability. 1081 The ALTO server returns a filtered CDNI Advertisement resource for a 1082 valid request. The format of a filtered CDNI Advertisement resource 1083 is the same as a full CDNI Advertisement resource (See Section 3.6.) 1085 The returned CDNI Advertisement resource MUST contain only 1086 BaseAdvertisementObject objects whose CDNI capability object is the 1087 superset of one of CDNI capability object in "cdni-fci-capabilities". 1088 Specifically, that a CDNI capability object A is the superset of 1089 another CDNI capability object B means that these two CDNI capability 1090 objects have the same capability type and mandatory properties in 1091 capability value of A MUST include mandatory properties in capability 1092 value of B semantically. See Section 5.7.2 for a concrete example. 1094 The version tag included in the "vtag" field of the response MUST 1095 correspond to the full CDNI Advertisement resource from which the 1096 filtered CDNI Advertisement resource is provided. This ensures that 1097 a single, canonical version tag is used independently of any 1098 filtering that is requested by an ALTO client. 1100 5.7. Examples 1102 5.7.1. IRD Example 1104 The examples below use the same IRD example as in Section 3.7.1. 1106 5.7.2. Basic Example 1108 This example filters the full CDNI Advertisement resource in 1109 Section 3.7.2 by selecting only the http/1.1 delivery protocol 1110 capability. Only the second BaseAdvertisementObjects in the full 1111 resource will be returned because the second object's capability is 1112 http/1.1 and https/1.1 delivery protocols which is the superset of 1113 https/1.1 delivery protocol. 1115 POST /cdnifci/filtered HTTP/1.1 1116 HOST: alto.example.com 1117 Accept: application/alto-cdni+json 1118 Content-Type: application/cdnifilter+json 1119 Content-Length: 176 1121 { 1122 "cdni-capabilities": [ 1123 { 1124 "capability-type": "FCI.DeliveryProtocol", 1125 "capability-value": { 1126 "delivery-protocols": [ "https/1.1" ] 1127 } 1128 } 1129 ] 1130 } 1132 HTTP/1.1 200 OK 1133 Content-Length: 571 1134 Content-Type: application/alto-cdni+json 1136 { 1137 "meta" : { 1138 "vtag": { 1139 "resource-id": "my-filtered-cdnifci", 1140 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 1141 } 1142 }, 1143 "cdni-advertisement": { 1144 "capabilities-with-footprints": [ 1145 { 1146 "capability-type": "FCI.DeliveryProtocol", 1147 "capability-value": { 1148 "delivery-protocols": [ 1149 "https/1.1", 1150 "http/1.1" 1151 ] 1152 }, 1153 "footprints": [ 1154 { 1155 "footprint-type": "ipv4cidr", 1156 "footprint-value": [ "198.51.100.0/24" ] 1157 } 1158 ] 1159 } 1160 ] 1161 } 1162 } 1164 5.7.3. Incremental Updates Example 1166 In this example, the ALTO client only cares about the updates of one 1167 advertisement object for delivery protocol capability whose value 1168 includes "https/1.1". So it adds its limitation of capabilities in 1169 "input" field of the POST request. 1171 POST /updates/cdnifci HTTP/1.1 1172 Host: fcialtoupdate.example.com 1173 Accept: text/event-stream,application/alto-error+json 1174 Content-Type: application/alto-updatestreamparams+json 1175 Content-Length: 346 1177 { 1178 "add": { 1179 "my-filtered-fci-stream": { 1180 "resource-id": "my-filtered-cdnifci", 1181 "input": { 1182 "cdni-capabilities": [ 1183 { 1184 "capability-type": "FCI.DeliveryProtocol", 1185 "capability-value": { 1186 "delivery-protocols": [ "https/1.1" ] 1187 } 1188 } 1189 ] 1190 } 1191 } 1192 } 1193 } 1195 HTTP/1.1 200 OK 1196 Connection: keep-alive 1197 Content-Type: text/event-stream 1198 event: application/alto-updatestreamcontrol+json 1199 data: {"control-uri": 1200 data: "https://alto.example.com/updates/streams/3141592653590"} 1202 event: application/alto-cdni+json,my-filtered-fci-stream 1203 data: { ... filtered CDNI Advertisement resource ... } 1205 event: application/json-patch+json,my-filtered-fci-stream 1206 data: [ 1207 data: { 1208 data: "op": "replace", 1209 data: "path": "/meta/vtag/tag", 1210 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1211 data: }, 1212 data: { "op": "add", 1213 data: "/cdni-advertisement/capabilities-with-footprints 1214 /0/footprints/0/footprint-value/-", 1215 data: "value": "192.0.2.0/24" 1216 data: } 1217 data: ] 1219 6. Query Footprint Properties using ALTO Property Map Service 1221 Besides the requirement of retrieving footprints of given 1222 capabilities, another common requirement for uCDN is to query CDNI 1223 capabilities of given footprints. 1225 Considering each footprint as an entity with properties including 1226 CDNI capabilities, a natural way to satisfy this requirement is to 1227 use the ALTO property map as defined in 1228 [I-D.ietf-alto-unified-props-new]. This section describes how ALTO 1229 clients look up properties for individual footprints. First, it 1230 describes how to represent footprint objects as entities in the ALTO 1231 property map. Then it describes how to represent footprint 1232 capabilities as entity properties in the ALTO property map. Finally, 1233 it provides examples of the full property map and the filtered 1234 property map supporting CDNI capabilities, and their incremental 1235 updates. 1237 6.1. Representing Footprint Objects as Property Map Entities 1239 A footprint object has two properties: footprint-type and footprint- 1240 value. A footprint-value is an array of footprint values conforming 1241 to the specification associated with the registered footprint type 1242 ("ipv4cidr", "ipv6cidr", "asn", "countrycode", and "altopid"). 1243 Considering each ALTO entity defined in 1244 [I-D.ietf-alto-unified-props-new] also has two properties: entity 1245 domain type and domain-specific identifier, a straightforward 1246 approach to represent a footprint as an ALTO entity is to represent 1247 its footprint-type as an entity domain type, and its footprint value 1248 as a domain-specific identifier. 1250 Each existing footprint type can be represented as an entity domain 1251 type as follows: 1253 * According to [I-D.ietf-alto-unified-props-new], "ipv4" and "ipv6" 1254 are two predefined entity domain types, which can be used to 1255 represent "ipv4cidr" and "ipv6cidr" footprints respectively. 1257 * "pid" is also a predefined entity domain type, which can be used 1258 to represent "altopid" footprints. Note that "pid" is a resource- 1259 specific entity domain. To represent an "altopid" footprint, the 1260 specifying information resource of the corresponding "pid" entity 1261 domain MUST be the dependent network map used by the CDNI 1262 Advertisement resource providing this "altopid" footprint. 1264 * However, no existing entity domain type can represent "asn" and 1265 "countrycode" footprints. To represent footprint-type "asn" and 1266 "countrycode", this document registers two new domains in 1267 Section 7 in addition to the ones in 1268 [I-D.ietf-alto-unified-props-new]. 1270 Here is an example of representing a footprint object of "ipv4cidr" 1271 type as a set of "ipv4" entities in the ALTO property map. The 1272 representation of the footprint object of "ipv6cidr" type is similar. 1274 { "footprint-type": "ipv4cidr", 1275 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 1276 } --> "ipv4:192.0.2.0/24", "ipv4:198.51.100.0/24" 1278 6.1.1. ASN Domain 1280 The ASN domain associates property values with Autonomous Systems in 1281 the Internet. 1283 6.1.1.1. Entity Domain Type 1285 asn 1287 6.1.1.2. Domain-Specific Entity Identifiers 1289 The entity identifier of an entity in an asn domain is encoded as a 1290 string consisting of the characters "as" (in lowercase) followed by 1291 the Autonomous System Number [RFC6793]. 1293 6.1.1.3. Hierarchy and Inheritance 1295 There is no hierarchy or inheritance for properties associated with 1296 ASN. 1298 6.1.2. COUNTRYCODE Domain 1300 The COUNTRYCODE domain associates property values with countries. 1302 6.1.2.1. Entity Domain Type 1304 countrycode 1306 6.1.2.2. Domain-Specific Entity Identifiers 1308 The entity identifier of an entity in a countrycode domain is encoded 1309 as an ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1311 6.1.2.3. Hierarchy and Inheritance 1313 There is no hierarchy or inheritance for properties associated with 1314 country codes. 1316 6.2. Representing CDNI Capabilities as Property Map Entity Properties 1318 This document defines a new entity property type called "cdni- 1319 capabilities". An ALTO server can provide a property map resource 1320 mapping the "cdni-capablities" entity property type for a CDNI 1321 Advertisement resource that it provides to an "ipv4", "ipv6", "asn" 1322 or "countrycode" entity domain. 1324 6.2.1. Defining Information Resource Media Type for Property Type cdni- 1325 capabilities 1327 The entity property type "cdni-capabilities" allows to define 1328 resource-specific entity properties. When resource-specific entity 1329 properties are defined with entity property type "cdni-capabilities", 1330 the defining information resource for a "cdni-capabilities" property 1331 MUST be a CDNI Advertisement resource provided by the ALTO server. 1332 The media type of the defining information resource for a "cdni- 1333 capabilities" property is therefore: 1335 application/alto-cdni+json 1337 6.2.2. Intended Semantics of Property Type cdni-capabilities 1339 A "cdni-capabilities" property for an entity is to indicate all the 1340 CDNI capabilities that a corresponding CDNI Advertisement resource 1341 provides for the footprint represented by this entity. Thus, the 1342 value of a "cdni-capabilities" property MUST be a JSON array. Each 1343 element in a "cdni-capabilities" property MUST be an JSON object as 1344 format of CDNICapability (see Section 5.3). The value of a "cdni- 1345 capabilities" property for an "ipv4", "ipv6", "asn", "countrycode" or 1346 "altopid" entity MUST include all the CDNICapability objects that are 1347 provided by the defining CDNI Advertisement resource and the 1348 represented footprint object of this entity are in their footprint 1349 restrictions. 1351 6.3. Examples 1353 6.3.1. IRD Example 1355 The examples use the same IRD example given by Section 3.7.1. 1357 6.3.2. Property Map Example 1359 This example shows a full property map in which entities are 1360 footprints and entities' property is "cdni-capabilities". 1362 GET /propmap/full/cdnifci HTTP/1.1 1363 HOST: alto.example.com 1364 Accept: application/alto-propmap+json,application/alto-error+json 1366 HTTP/1.1 200 OK 1367 Content-Length: 1522 1368 Content-Type: application/alto-propmap+json 1370 { 1371 "property-map": { 1372 "meta": { 1373 "dependent-vtags": [ 1374 { "resource-id": "my-default-cdnifci", 1375 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1376 ] 1377 }, 1378 "countrycode:us": { 1379 "my-default-cdnifci.cdni-capabilities": [ 1380 { "capability-type": "FCI.DeliveryProtocol", 1381 "capability-value": { 1382 "delivery-protocols": ["http/1.1"]}}] 1383 }, 1384 "ipv4:192.0.2.0/24": { 1385 "my-default-cdnifci.cdni-capabilities": [ 1386 { "capability-type": "FCI.DeliveryProtocol", 1387 "capability-value": { 1388 "delivery-protocols": ["http/1.1"]}}] 1389 }, 1390 "ipv4:198.51.100.0/24": { 1391 "my-default-cdnifci.cdni-capabilities": [ 1392 { "capability-type": "FCI.DeliveryProtocol", 1393 "capability-value": { 1394 "delivery-protocols": ["https/1.1", "http/1.1"]}}] 1395 }, 1396 "ipv4:203.0.113.0/24": { 1397 "my-default-cdnifci.cdni-capabilities": [ 1398 { "capability-type": "FCI.AcquisitionProtocol", 1399 "capability-value": { 1400 "acquisition-protocols": ["http/1.1"]}}] 1401 }, 1402 "ipv6:2001:db8::/32": { 1403 "my-default-cdnifci.cdni-capabilities": [ 1404 { "capability-type": "FCI.DeliveryProtocol", 1405 "capability-value": { 1406 "delivery-protocols": ["http/1.1"]}}] 1407 }, 1408 "asn:as64496": { 1409 "my-default-cdnifci.cdni-capabilities": [ 1410 { "capability-type": "FCI.DeliveryProtocol", 1411 "capability-value": { 1412 "delivery-protocols": ["https/1.1", "http/1.1"]}}] 1413 } 1414 } 1415 } 1417 6.3.3. Filtered Property Map Example 1419 This example uses the filtered property map service to get "pid" and 1420 "cdni-capabilities" properties for two footprints "ipv4:192.0.2.0/24" 1421 and "ipv6:2001:db8::/32". 1423 POST /propmap/lookup/cdnifci-pid HTTP/1.1 1424 HOST: alto.example.com 1425 Content-Type: application/alto-propmapparams+json 1426 Accept: application/alto-propmap+json,application/alto-error+json 1427 Content-Length: 181 1429 { 1430 "entities": [ 1431 "ipv4:192.0.2.0/24", 1432 "ipv6:2001:db8::/32" 1433 ], 1434 "properties": [ "my-default-cdnifci.cdni-capabilities", 1435 "my-default-networkmap.pid" ] 1436 } 1438 HTTP/1.1 200 OK 1439 Content-Length: 796 1440 Content-Type: application/alto-propmap+json 1442 { 1443 "property-map": { 1444 "meta": { 1445 "dependent-vtags": [ 1446 {"resource-id": "my-default-cdnifci", 1447 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}, 1448 {"resource-id": "my-default-networkmap", 1449 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1450 ] 1451 }, 1452 "ipv4:192.0.2.0/24": { 1453 "my-default-cdnifci.cdni-capabilities": [ 1454 {"capability-type": "FCI.DeliveryProtocol", 1455 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1456 "my-default-networkmap.pid": "pid1" 1457 }, 1458 "ipv6:2001:db8::/32": { 1459 "my-default-cdnifci.cdni-capabilities": [ 1460 {"capability-type": "FCI.DeliveryProtocol", 1461 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1462 "my-default-networkmap.pid": "pid3" 1463 } 1464 } 1465 } 1467 6.3.4. Incremental Updates Example 1469 In this example, the client is interested in updates for the 1470 properties "cdni-capabilities" and "pid" of two footprints 1471 "ipv4:192.0.2.0/24" and "countrycode:fr". 1473 POST /updates/properties HTTP/1.1 1474 Host: alto.example.com 1475 Accept: text/event-stream,application/alto-error+json 1476 Content-Type: application/alto-updatestreamparams+json 1477 Content-Length: 337 1479 { "add": { 1480 "fci-propmap-stream": { 1481 "resource-id": "filtered-cdnifci-property-map", 1482 "input": { 1483 "properties": [ "my-default-cdnifci.cdni-capabilities", 1484 "my-default-networkmap.pid" ], 1485 "entities": [ "ipv4:192.0.2.0/24", 1486 "ipv6:2001:db8::/32" ] 1487 } 1488 } 1489 } 1490 } 1492 HTTP/1.1 200 OK 1493 Connection: keep-alive 1494 Content-Type: text/event-stream 1496 event: application/alto-updatestreamcontrol+json 1497 data: {"control-uri": 1498 data: "https://alto.example.com/updates/streams/1414213562373"} 1500 event: application/alto-cdni+json,fci-propmap-stream 1501 data: { ... filtered property map ... } 1503 event: application/merge-patch+json,fci-propmap-stream 1504 data: { 1505 data: "property-map": { 1506 data: "meta": { 1507 data: "dependent-vtags": [ 1508 data: { "resource-id": "my-default-cdnifci", 1509 data: "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"}, 1510 data: { "resource-id": "my-default-networkmap", 1511 data: "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1512 data: ] 1513 data: }, 1514 data: "ipv4:192.0.2.0/24": { 1515 data: "my-default-cdnifci.cdni-capabilities": [ 1516 data: { "capability-type": "FCI.DeliveryProtocol", 1517 data: "capability-value": { 1518 data: "delivery-protocols": ["http/1.1", "https/1.1"]}}] 1519 data: } 1520 data: } 1521 data: } 1523 event: application/json-patch+json,fci-propmap-stream 1524 data: [ 1525 data: { "op": "replace", 1526 data: "path": "/meta/dependent-vtags/0/tag", 1527 data: "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4" 1528 data: }, 1529 data: { "op": "replace", 1530 data: "path": 1531 data: "/property-map/countrycode:fr/my-default-networkmap.pid", 1532 data: "value": "pid5" 1533 data: } 1534 data: ] 1536 7. IANA Considerations 1538 7.1. application/alto-* Media Types 1540 This document registers two additional ALTO media types, listed in 1541 Table 1. 1543 +=============+======================+===============+ 1544 | Type | Subtype | Specification | 1545 +=============+======================+===============+ 1546 | application | alto-cdni+json | Section 3 | 1547 +-------------+----------------------+---------------+ 1548 | application | alto-cdnifilter+json | Section 5 | 1549 +-------------+----------------------+---------------+ 1551 Table 1: Additional ALTO Media Types. 1553 Type name: application 1555 Subtype name: This document registers multiple subtypes, as listed 1556 in Table 1. 1558 Required parameters: n/a 1560 Optional parameters: n/a 1561 Encoding considerations: Encoding considerations are identical to 1562 those specified for the "application/json" media type. See 1563 [RFC7159]. 1565 Security considerations: Security considerations related to the 1566 generation and consumption of ALTO Protocol messages are discussed 1567 in Section 15 of [RFC7285]. 1569 Interoperability considerations: This document specifies formats of 1570 conforming messages and the interpretation thereof. 1572 Published specification: This document is the specification for 1573 these media types; see Table 1 for the section documenting each 1574 media type. 1576 Applications that use this media type: ALTO servers and ALTO clients 1577 either stand alone or are embedded within other applications. 1579 Additional information: Magic number(s): n/a 1581 File extension(s): This document uses the 1582 mime type to refer to protocol messages and thus does not 1583 require a file extension. 1585 Macintosh file type code(s): n/a 1587 Person & email address to contact for further information: See 1588 Authors' Addresses section. 1590 Intended usage: COMMON 1592 Restrictions on usage: n/a 1594 Author: See Authors' Addresses section. 1596 Change controller: Internet Engineering Task Force 1597 (mailto:iesg@ietf.org). 1599 7.2. CDNI Metadata Footprint Type Registry 1601 As proposed in Section 7.2 of [RFC8006], "CDNI Metadata Footprint 1602 Types" registry is requested. A new footprint type is to be 1603 registered, listed in Table 2. 1605 +================+=====================+======================+ 1606 | Footprint Type | Description | Specification | 1607 +================+=====================+======================+ 1608 | altopid | A list of PID names | Section 4 of RFCthis | 1609 +----------------+---------------------+----------------------+ 1611 Table 2: CDNI Metadata Footprint Type 1613 [RFC Editor: Please replace RFCthis with the published RFC number for 1614 this document.] 1616 7.3. ALTO Entity Domain Type Registry 1618 As proposed in Section 11.2 of [I-D.ietf-alto-unified-props-new], 1619 "ALTO Entity Domain Type Registry" is requested. Two new entity 1620 domain types are to be registered, listed in Table 3. 1622 +=============+================+=============+===================+ 1623 | Identifier | Entity Address | Hierarchy & | Media Type of | 1624 | | Encoding | Inheritance | Defining Resource | 1625 +=============+================+=============+===================+ 1626 | asn | See Section | None | None | 1627 | | 6.1.1.2 of | | | 1628 | | RFCthis | | | 1629 +-------------+----------------+-------------+-------------------+ 1630 | countrycode | See Section | None | None | 1631 | | 6.1.2.2 of | | | 1632 | | RFCthis | | | 1633 +-------------+----------------+-------------+-------------------+ 1635 Table 3: Additional ALTO Entity Domain Types 1637 [RFC Editor: Please replace RFCthis with the published RFC number for 1638 this document.] 1640 7.4. ALTO Entity Property Type Registry 1642 As proposed in Section 11.3 of [I-D.ietf-alto-unified-props-new], 1643 "ALTO Entity Property Type Registry" is required. A new entity 1644 property type is to be registered, listed in Table 4. 1646 +===================+====================+===================+ 1647 | Identifier | Intended Semantics | Media Type of | 1648 | | | Defining Resource | 1649 +===================+====================+===================+ 1650 | cdni-capabilities | Section 6.2 of | application/alto- | 1651 | | RFCthis | cdni+json | 1652 +-------------------+--------------------+-------------------+ 1654 Table 4: Additional ALTO Entity Property Type 1656 [RFC Editor: Please replace RFCthis with the published RFC number for 1657 this document.] 1659 8. Security Considerations 1661 As an extension of the base ALTO protocol ([RFC7285]), this document 1662 fits into the architecture of the base protocol. And hence Security 1663 Considerations of the base protocol (Section 15 of [RFC7285]) fully 1664 apply when this extension is provided by an ALTO server. 1666 In the context of CDNI Advertisement, additional security 1667 considerations should be included as follows: 1669 * For authenticity and integrity of ALTO information, an attacker 1670 may disguise itself as an ALTO server for a dCDN, and provide 1671 false capabilities and footprints to a uCDN using the CDNI 1672 Advertisement service. Such false information may lead a uCDN to 1673 (1) select an incorrect dCDN to serve user requests, or (2) skip 1674 uCDNs in good conditions. 1676 * For potential undesirable guidance from authenticated ALTO 1677 information, a dCDN can provide a uCDN with limited capabilities 1678 and smaller footprint coverage so that the dCDN can avoid 1679 transferring traffic for a uCDN which they should have to 1680 transfer. 1682 * For confidentiality and privacy of ALTO information, footprint 1683 properties integrated with ALTO unified property may expose 1684 network location identifiers (e.g., IP addresses or fine-grained 1685 PIDs). 1687 * For availability of ALTO services, an attacker may conduct service 1688 degradation attacks using services defined in this document to 1689 disable ALTO services of a network. It may request potentially 1690 large, full CDNI Advertisement resources from an ALTO server in a 1691 dCDN continuously, to consume the bandwidth resources of that ALTO 1692 server. It may also query filtered property map services with 1693 many smaller individual footprints, to consume the computation 1694 resources of the ALTO server. 1696 Although protection strategies as described in Section 15 of 1697 [RFC7285] should be applied to address aforementioned security 1698 considerations, one additional information leakage risk introduced by 1699 this document could not be addressed by these strategies. In 1700 particular, if a dCDN signs agreements with multiple uCDNs without 1701 any isolation, this dCDN may disclose extra information of one uCDN 1702 to another one. In that case, one uCDN may redirect requests which 1703 should not have to be served by this dCDN to it. 1705 To reduce the risk, a dCDN should isolate full/filtered CDNI 1706 Advertisement resources for different uCDNs. It could consider 1707 generating URIs of different full/filtered CDNI Advertisement 1708 resources by hashing its company ID, a uCDN's company ID as well as 1709 their agreements. A dCDN should avoid exposing all full/filtered 1710 CDNI Advertisement resources in one of its IRDs. 1712 9. Acknowledgments 1714 The authors thank Matt Caulfield, Danny Alex Lachos Perez, Daryl 1715 Malas and Sanjay Mishra for their timely reviews and invaluable 1716 comments. 1718 Jan Seedorf has been partially supported by the GreenICN project 1719 (GreenICN: Architecture and Applications of Green Information Centric 1720 Networking), a research project supported jointly by the European 1721 Commission under its 7th Framework Program (contract no. 608518) and 1722 the National Institute of Information and Communications Technology 1723 (NICT) in Japan (contract no. 167). The views and conclusions 1724 contained herein are those of the authors and should not be 1725 interpreted as necessarily representing the official policies or 1726 endorsements, either expressed or implied, of the GreenICN project, 1727 the European Commission, or NICT. 1729 This document has also been supported by the Coordination Support 1730 Action entitled 'Supporting European Experts Presence in 1731 lnternational Standardisation Activities in ICT' ("StandlCT.eu") 1732 funded by the European Commission under the Horizon 2020 Programme 1733 with Grant Agreement no. 780439. The views and conclusions contained 1734 herein are those of the authors and should not be interpreted as 1735 necessarily representing the official policies or endorsements, 1736 either expressed or implied, of the European Commission. 1738 10. Contributors 1740 Mr. Xiao Shawn Lin is an author of an early version of this document, 1741 with many contributions. 1743 11. References 1745 11.1. Normative References 1747 [ISO3166-1] 1748 The International Organization for Standardization, "Codes 1749 for the representation of names of countries and their 1750 subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 1751 2013. 1753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1754 Requirement Levels", BCP 14, RFC 2119, 1755 DOI 10.17487/RFC2119, March 1997, 1756 . 1758 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1759 Autonomous System (AS) Number Space", RFC 6793, 1760 DOI 10.17487/RFC6793, December 2012, 1761 . 1763 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1764 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1765 2014, . 1767 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1768 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1769 "Application-Layer Traffic Optimization (ALTO) Protocol", 1770 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1771 . 1773 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1774 "Content Delivery Network Interconnection (CDNI) 1775 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1776 . 1778 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1779 R., and K. Ma, "Content Delivery Network Interconnection 1780 (CDNI) Request Routing: Footprint and Capabilities 1781 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1782 . 1784 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1785 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1786 May 2017, . 1788 11.2. Informative References 1790 [I-D.ietf-alto-path-vector] 1791 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 1792 "ALTO Extension: Path Vector", Work in Progress, Internet- 1793 Draft, draft-ietf-alto-path-vector-12, 2 November 2020, 1794 . 1797 [I-D.ietf-alto-unified-props-new] 1798 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 1799 Gao, "Unified properties for the ALTO protocol", Work in 1800 Progress, Internet-Draft, draft-ietf-alto-unified-props- 1801 new-13, 2 November 2020, . 1804 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1805 Optimization (ALTO) Problem Statement", RFC 5693, 1806 DOI 10.17487/RFC5693, October 2009, 1807 . 1809 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1810 Distribution Network Interconnection (CDNI) Problem 1811 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1812 2012, . 1814 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1815 "Framework for Content Distribution Network 1816 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1817 August 2014, . 1819 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1820 "Request Routing Redirection Interface for Content 1821 Delivery Network (CDN) Interconnection", RFC 7975, 1822 DOI 10.17487/RFC7975, October 2016, 1823 . 1825 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 1826 Optimization (ALTO) Incremental Updates Using Server-Sent 1827 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 1828 2020, . 1830 Authors' Addresses 1832 Jan Seedorf 1833 HFT Stuttgart - Univ. of Applied Sciences 1834 Schellingstrasse 24 1835 Stuttgart 70174 1836 Germany 1838 Phone: +49-0711-8926-2801 1839 Email: jan.seedorf@hft-stuttgart.de 1841 Y.R. Yang 1842 Yale University 1843 51 Prospect Street 1844 New Haven, CT 06511 1845 United States of America 1847 Email: yry@cs.yale.edu 1848 URI: http://www.cs.yale.edu/~yry/ 1850 Kevin J. Ma 1851 Ericsson 1852 43 Nagog Park 1853 Acton, MA 01720 1854 United States of America 1856 Phone: +1-978-844-5100 1857 Email: kevin.j.ma.ietf@gmail.com 1859 Jon Peterson 1860 NeuStar 1861 1800 Sutter St Suite 570 1862 Concord, CA 94520 1863 United States of America 1865 Email: jon.peterson@neustar.biz 1866 Jingxuan Jensen Zhang 1867 Tongji University 1868 4800 Cao'an Hwy 1869 Shanghai 201804 1870 China 1872 Email: jingxuan.zhang@tongji.edu.cn