idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-15.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2021) is 1173 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 (-24) exists of draft-ietf-alto-unified-props-new-15 -- 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-13 Summary: 2 errors (**), 0 flaws (~~), 3 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: July 15, 2021 Yale 6 K. Ma 7 Ericsson 8 J. Peterson 9 Neustar 10 J. Zhang 11 Tongji 12 January 11, 2021 14 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 15 Footprint and Capabilities Advertisement using ALTO 16 draft-ietf-alto-cdni-request-routing-alto-15 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 July 15, 2021. 57 Copyright Notice 59 Copyright (c) 2021 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 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1. Semantics of FCI Advertisement . . . . . . . . . . . . . 5 77 2.2. ALTO Background and Benefits . . . . . . . . . . . . . . 6 78 3. CDNI Advertisement Service . . . . . . . . . . . . . . . . . 8 79 3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 9 82 3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 83 3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 85 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.7.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 12 87 3.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 15 88 3.7.3. Incremental Updates Example . . . . . . . . . . . . . 16 89 4. CDNI Advertisement Service using ALTO Network Map . . . . . . 18 90 4.1. Network Map Footprint Type: altopid . . . . . . . . . . . 18 91 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 92 4.2.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 18 93 4.2.2. ALTO Network Map for CDNI Advertisement Example . . . 19 94 4.2.3. ALTO PID Footprints in CDNI Advertisement . . . . . . 19 95 4.2.4. Incremental Updates Example . . . . . . . . . . . . . 20 96 5. Filtered CDNI Advertisement using CDNI Capabilities . . . . . 22 97 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 22 98 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 22 99 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 22 100 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 23 101 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 23 103 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 24 104 5.7.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 24 105 5.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 24 106 5.7.3. Incremental Updates Example . . . . . . . . . . . . . 26 107 6. Query Footprint Properties using ALTO Property Map Service . 27 108 6.1. Representing Footprint Objects as Property Map Entities . 27 109 6.1.1. ASN Domain . . . . . . . . . . . . . . . . . . . . . 28 110 6.1.2. COUNTRYCODE Domain . . . . . . . . . . . . . . . . . 28 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 cdni-capabilities 29 116 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 30 117 6.3.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 30 118 6.3.2. Property Map Example . . . . . . . . . . . . . . . . 30 119 6.3.3. Filtered Property Map Example . . . . . . . . . . . . 31 120 6.3.4. Incremental Updates Example . . . . . . . . . . . . . 33 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 122 7.1. application/alto-* Media Types . . . . . . . . . . . . . 34 123 7.2. CDNI Metadata Footprint Type Registry . . . . . . . . . . 35 124 7.3. ALTO Entity Domain Type Registry . . . . . . . . . . . . 36 125 7.4. ALTO Entity Property Type Registry . . . . . . . . . . . 36 126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 127 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 128 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 129 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 130 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 131 11.2. Informative References . . . . . . . . . . . . . . . . . 40 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 134 1. Introduction 136 The ability to interconnect multiple content delivery networks (CDNs) 137 has many benefits, including increased coverage, capability, and 138 reliability. The Content Delivery Networks Interconnection (CDNI) 139 framework [RFC6707] defines four interfaces to achieve the 140 interconnection of CDNs: (1) the CDNI Request Routing Interface; (2) 141 the CDNI Metadata Interface; (3) the CDNI Logging Interface; and (4) 142 the CDNI Control Interface. 144 Among the four interfaces, the CDNI Request Routing Interface 145 provides key functions, as specified in [RFC6707]: "The CDNI Request 146 Routing interface enables a Request Routing function in an Upstream 147 CDN to query a Request Routing function in a Downstream CDN to 148 determine if the Downstream CDN is able (and willing) to accept the 149 delegated Content Request. It also allows the Downstream CDN to 150 control what should be returned to the User Agent in the redirection 151 message by the upstream Request Routing function." At a high level, 152 the scope of the CDNI Request Routing Interface, therefore, contains 153 two main tasks: (1) determining if the dCDN (downstream CDN) is 154 willing to accept a delegated content request, and (2) redirecting 155 the content request coming from a uCDN (upstream CDN) to the proper 156 entry point or entity in the dCDN. 158 Correspondingly, the request routing interface is broadly divided 159 into two functionalities: (1) the CDNI Footprint & Capabilities 160 Advertisement interface (FCI) defined in [RFC8008], and (2) the CDNI 161 Request Routing Redirection interface (RI) defined in [RFC7975]. 162 Since this document focuses on the first functionality (CDNI FCI), 163 below is more details about it. 165 Specifically, CDNI FCI allows both an advertisement from a dCDN to a 166 uCDN (push) and a query from a uCDN to a dCDN (pull) so that the uCDN 167 knows whether it can redirect a particular user request to that dCDN. 169 A key component in defining CDNI FCI is defining objects describing 170 the footprints and capabilities of a dCDN. Such objects are already 171 defined in [RFC8008]. A protocol to transport and update such 172 objects between a uCDN and a dCDN, however, is not defined. Hence, 173 the scope of this document is to define such a protocol by 174 introducing a new Application-Layer Traffic Optimization (ALTO) 175 [RFC7285] service called "CDNI Advertisement Service". 177 There are multiple benefits in using ALTO as a transport protocol, as 178 discussed in Section 2.2. 180 The rest of this document is organized as follows. Section 2 181 provides non-normative background on both CDNI FCI and ALTO. 182 Section 3 introduces the most basic service, called "CDNI 183 Advertisement Service", to realize CDNI FCI using ALTO. Section 4 184 demonstrates a key benefit of using ALTO: the ability to integrate 185 CDNI FCI with ALTO network maps. Such integration provides new 186 granularity to describe footprints. Section 5 introduces "Filtered 187 CDNI Advertisement Service" to allow a uCDN to get footprints with 188 given capabilities instead of getting the full resource, which can be 189 large. Section 6 further shows another benefit of using ALTO: the 190 ability to query footprint properties using ALTO entity property map 191 extension. In this way, a uCDN can effectively fetch capabilities of 192 footprints in which it is interested. IANA and security 193 considerations are discussed in Section 7 and Section 8 respectively. 195 2. Background 197 The design of CDNI FCI transport using ALTO depends on the 198 understanding of both FCI semantics and ALTO. Hence, this document 199 starts with a non-normative review for both. The review uses the 200 terminologies for CDNI as defined in [RFC6707], [RFC8006] and 201 [RFC8008]; those for ALTO as defined in [RFC7285] and 202 [I-D.ietf-alto-unified-props-new]. 204 2.1. Semantics of FCI Advertisement 206 [RFC8008] (CDNI "Footprint and Capabilities Semantics") defines the 207 semantics of CDNI FCI, provides guidance on what Footprint and 208 Capabilities mean in a CDNI context, and specifies the requirements 209 on the CDNI FCI transport protocol. The definitions in [RFC8008] 210 depend on [RFC8006]. Below is a non-normative review of key related 211 points of [RFC8008] and [RFC8006]. For detailed information and 212 normative specification, the reader is referred to these two RFCs. 214 o Multiple types of mandatory-to-implement footprints (ipv4cidr, 215 ipv6cidr, asn, and countrycode) are defined in [RFC8006]. A "Set 216 of IP-prefixes" can contain both full IP addresses (i.e., a /32 217 for IPv4 or a /128 for IPv6) and IP prefixes with an arbitrary 218 prefix length. There must also be support for multiple IP address 219 versions, i.e., IPv4 and IPv6, in such a footprint. 221 o Multiple initial types of capabilities are defined in [RFC8008] 222 including (1) Delivery Protocol, (2) Acquisition Protocol, (3) 223 Redirection Mode, (4) Capabilities related to CDNI Logging, and 224 (5) Capabilities related to CDNI Metadata. They are required in 225 all cases and therefore considered as mandatory-to-implement 226 capabilities for all CDNI FCI implementations. 228 o Footprint and capabilities are defined together and cannot be 229 interpreted independently from each other. Specifically, 230 [RFC8008] integrates footprint and capabilities with an approach 231 of "capabilities with footprint restrictions", by expressing 232 capabilities on a per footprint basis. 234 o Specifically, for all mandatory-to-implement footprint types, 235 footprints can be viewed as constraints for delegating requests to 236 a dCDN: A dCDN footprint advertisement tells the uCDN the 237 limitations for delegating a request to the dCDN. For IP prefixes 238 or ASN(s), the footprint signals to the uCDN that it should 239 consider the dCDN a candidate only if the IP address of the 240 request routing source falls within the prefix set (or ASN, 241 respectively). The CDNI specifications do not define how a given 242 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 o 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 o 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 o 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 o 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 o 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 o 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 o 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 o 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 o 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 o 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" 570 }, 571 "my-eu-netmap" : { 572 "uri" : "https://alto.example.com/myeunetmap", 573 "media-type" : "application/alto-networkmap+json" 574 }, 575 "my-default-cdnifci": { 576 "uri" : "https://alto.example.com/cdnifci", 577 "media-type": "application/alto-cdni+json" 578 }, 579 "my-cdnifci-with-pid-footprints": { 580 "uri" : "https://alto.example.com/networkcdnifci", 581 "media-type" : "application/alto-cdni+json", 582 "uses" : [ "my-eu-netmap" ] 583 }, 584 "my-filtered-cdnifci" : { 585 "uri" : "https://alto.example.com/cdnifci/filtered", 586 "media-type" : "application/alto-cdni+json", 587 "accepts" : "application/alto-cdnifilter+json" 588 }, 589 "cdnifci-property-map" : { 590 "uri" : "https://alto.example.com/propmap/full/cdnifci", 591 "media-type" : "application/alto-propmap+json", 592 "uses": [ "my-default-cdni" ], 593 "capabilities" : { 594 "mappings": { 595 "ipv4": [ "my-default-cdni.cdni-capabilities" ], 596 "ipv6": [ "my-default-cdni.cdni-capabilities" ], 597 "countrycode": [ 598 "my-default-cdni.cdni-capabilities" ], 599 "asn": [ "my-default-cdni.cdni-capabilities" ] 600 } 601 } 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 } 619 } 620 }, 621 "update-my-cdni-fci" : { 622 "uri": "https:///alto.example.com/updates/cdnifci", 623 "media-type" : "text/event-stream", 624 "accepts" : "application/alto-updatestreamparams+json", 625 "uses" : [ 626 "my-default-network-map", 627 "my-eu-netmap", 628 "my-default-cdnifci", 629 "my-filtered-cdnifci", 630 "my-cdnifci-with-pid-footprints" 631 ], 632 "capabilities" : { 633 "incremental-change-media-types" : { 634 "my-default-network-map" : "application/json-patch+json", 635 "my-eu-netmap" : "application/json-patch+json", 636 "my-default-cdnifci" : 637 "application/merge-patch+json,application/json-patch+json", 638 "my-filtered-cdnifci" : 639 "application/merge-patch+json,application/json-patch+json", 640 "my-cdnifci-with-pid-footprints" : 641 "application/merge-patch+json,application/json-patch+json" 642 } 643 } 644 }, 645 "update-my-props": { 646 "uri" : "https://alto.example.com/updates/properties", 647 "media-type" : "text/event-stream", 648 "uses" : [ 649 "cdnifci-property-map", 650 "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 ] 712 }, 713 "footprints": [ 714 { 715 "footprint-type": "ipv4cidr", 716 "footprint-value": [ "198.51.100.0/24" ] 717 } 718 ] 719 }, 720 { 721 "capability-type": "FCI.AcquisitionProtocol", 722 "capability-value": { 723 "acquisition-protocols": [ 724 "https/1.1" 725 ] 726 }, 727 "footprints": [ 728 { 729 "footprint-type": "ipv4cidr", 730 "footprint-value": [ "203.0.113.0/24" ] 731 } 732 ] 733 } 734 ] 735 } 736 } 738 3.7.3. Incremental Updates Example 740 A benefit of using ALTO to provide CDNI Advertisement resources is 741 that such resources can be updated using ALTO incremental updates. 742 Below is an example that also shows the benefit of having both JSON 743 merge patch and JSON patch to encode updates. 745 At first, an ALTO client requests updates for "my-default-cdnifci", 746 and the ALTO server returns the "control-uri" followed by the full 747 CDNI Advertisement response. Then when there is a change in the 748 delivery-protocols in that http/1.1 is removed (from [http/1.1, 749 https/1.1] to only https/1.1) due to maintenance of the https/1.1 750 clusters, the ALTO server regenerates the new CDNI Advertisement 751 resource and pushes the full replacement to the ALTO client. Later 752 on, the ALTO server notifies the ALTO client that "192.0.2.0/24" is 753 added into the "ipv4" footprint object for delivery-protocol 754 https/1.1 by sending the change encoded by JSON patch to the ALTO 755 client. 757 POST /updates/cdnifci HTTP/1.1 758 Host: alto.example.com 759 Accept: text/event-stream,application/alto-error+json 760 Content-Type: application/alto-updatestreamparams+json 761 Content-Length: 92 763 { "add": { 764 "my-cdnifci-stream": { 765 "resource-id": "my-default-cdnifci" 766 } 767 } 768 } 770 HTTP/1.1 200 OK 771 Connection: keep-alive 772 Content-Type: text/event-stream 774 event: application/alto-updatestreamcontrol+json 775 data: {"control-uri": 776 data: "https://alto.example.com/updates/streams/3141592653589"} 778 event: application/alto-cdni+json,my-cdnifci-stream 779 data: { ... full CDNI Advertisement resource ... } 781 event: application/alto-cdni+json,my-cdnifci-stream 782 data: { 783 data: "meta": { 784 data: "vtag": { 785 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 786 data: } 787 data: }, 788 data: "cdni-advertisement": { 789 data: "capabilities": [ 790 data: { 791 data: "capability-type": "FCI.DeliveryProtocol", 792 data: "capability-value": { 793 data: "delivery-protocols": [ 794 data: "https/1.1" 795 data: ] 796 data: }, 797 data: "footprints": [ 798 data: { "footprint-type": "ipv4cidr", 799 data: "footprint-value": [ "203.0.113.0/24" ] 800 data: } 801 data: ] 802 data: }, 803 data: { ... other CDNI advertisement object ... } 804 data: ] 805 data: } 806 data: } 808 event: application/json-patch+json,my-cdnifci-stream 809 data: [ 810 data: { "op": "replace", 811 data: "path": "/meta/vtag/tag", 812 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 813 data: }, 814 data: { "op": "add", 815 data: "path": "/cdni-advertisement/capabilities-with-footprints 816 /0/footprints/0/footprint-value/-", 817 data: "value": "192.0.2.0/24" 818 data: } 819 data: ] 821 4. CDNI Advertisement Service using ALTO Network Map 823 4.1. Network Map Footprint Type: altopid 825 The ALTO protocol defines a concept called PID to represent a group 826 of IPv4 or IPv6 addresses which can be applied the same management 827 policy. The PID is an alternative to the pre-defined CDNI footprint 828 types (i.e., ipv4cidr, ipv6cidr, asn, and countrycode). 830 To leverage this concept, this document defines a new CDNI Footprint 831 Type called "altopid". A CDNI Advertisement resource can depend on 832 an ALTO network map resource and use "altopid" footprints to compress 833 its CDNI Footprint Payload. 835 Specifically, the "altopid" footprint type indicates that the 836 corresponding footprint value is a list of PIDNames as defined in 837 [RFC7285]. These PIDNames are references of PIDs in a network map 838 resource. Hence a CDNI Advertisement resource using "altopid" 839 footprints depends on a network map. For such a CDNI Advertisement 840 resource, the resource id of its dependent network map MUST be 841 included in the "uses" field of its IRD entry, and the "dependent- 842 vtag" field with a reference to this network map MUST be included in 843 its response (see the example in Section 4.2.3). 845 4.2. Examples 847 4.2.1. IRD Example 849 The examples below use the same IRD given in Section 3.7.1. 851 4.2.2. ALTO Network Map for CDNI Advertisement Example 853 Below is an example network map whose resource id is "my-eu-netmap", 854 and this map is referenced by the CDNI Advertisement example in 855 Section 4.2.3. 857 GET /myeunetmap HTTP/1.1 858 Host: alto.example.com 859 Accept: application/alto-networkmap+json,application/alto-error+json 861 HTTP/1.1 200 OK 862 Content-Length: 309 863 Content-Type: application/alto-networkmap+json 865 { 866 "meta": { 867 "vtag": [ 868 { "resource-id": "my-eu-netmap", 869 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 870 } 871 ] 872 }, 873 "network-map": { 874 "south-france" : { 875 "ipv4": [ "192.0.2.0/24", "198.51.100.0/25" ] 876 }, 877 "germany": { 878 "ipv4": [ "203.0.113.0/24" ] 879 } 880 } 881 } 883 4.2.3. ALTO PID Footprints in CDNI Advertisement 885 This example shows a CDNI Advertisement resource that depends on a 886 network map described in Section 4.2.2. 888 GET /networkcdnifci HTTP/1.1 889 Host: alto.example.com 890 Accept: application/alto-cdni+json,application/alto-error+json 892 HTTP/1.1 200 OK 893 Content-Length: 738 894 Content-Type: application/alto-cdni+json 896 { 897 "meta" : { 898 "dependent-vtags" : [ 899 { 900 "resource-id": "my-eu-netmap", 901 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 902 } 903 ] 904 }, 905 "cdni-advertisement": { 906 "capabilities-with-footprints": [ 907 { "capability-type": "FCI.DeliveryProtocol", 908 "capability-value": [ "https/1.1" ], 909 "footprints": [ 910 { "footprint-type": "altopid", 911 "footprint-value": [ "south-france" ] 912 } 913 ] 914 }, 915 { "capability-type": "FCI.AcquisitionProtocol", 916 "capability-value": [ "https/1.1" ], 917 "footprints": [ 918 { "footprint-type": "altopid", 919 "footprint-value": [ "germany", "south-france" ] 920 } 921 ] 922 } 923 ] 924 } 925 } 927 4.2.4. Incremental Updates Example 929 In this example, the ALTO client is interested in changes of "my- 930 cdnifci-with-pid-footprints" and its dependent network map "my-eu- 931 netmap". Considering two changes, the first one is to change 932 footprints of the https/1.1 delivery protocol capability, and the 933 second one is to remove "south-france" from the footprints of the 934 https/1.1 acquisition protocol capability. 936 POST /updates/cdnifci HTTP/1.1 937 Host: alto.example.com 938 Accept: text/event-stream,application/alto-error+json 939 Content-Type: application/alto-updatestreamparams+json 940 Content-Length: 183 942 { "add": { 943 "my-eu-netmap-stream": { 944 "resource-id": "my-eu-netmap" 945 }, 946 "my-netmap-cdnifci-stream": { 947 "resource-id": "my-cdnifci-with-pid-footprints" 948 } 949 } 950 } 952 HTTP/1.1 200 OK 953 Connection: keep-alive 954 Content-Type: text/event-stream 956 event: application/alto-updatestreamcontrol+json 957 data: {"control-uri": 958 data: "https://alto.example.com/updates/streams/3141592653590"} 960 event: application/alto-networkmap+json,my-eu-netmap-stream 961 data: { ... full Network Map of my-eu-netmap ... } 963 event: application/alto-cdnifci+json,my-netmap-cdnifci-stream 964 data: { ... full CDNI Advertisement resource ... } 966 event: application/json-patch+json,my-netmap-cdnifci-stream 967 data: [ 968 data: { "op": "replace", 969 data: "path": "/meta/vtag/tag", 970 data: "value": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 971 data: }, 972 data: { "op": "add", 973 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 o the value of "capability-type" is null; 1071 o the value of "capability-value" is null; 1072 o the value of "capability-value" is inconsistent with "capability- 1073 type". 1075 When a request is invalid, the ALTO server MUST return an 1076 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], 1077 and the "value" field of the error message SHOULD indicate this CDNI 1078 capability. 1080 The ALTO server returns a filtered CDNI Advertisement resource for a 1081 valid request. The format of a filtered CDNI Advertisement resource 1082 is the same as a full CDNI Advertisement resource (See Section 3.6.) 1084 The returned CDNI Advertisement resource MUST contain only 1085 BaseAdvertisementObject objects whose CDNI capability object is the 1086 superset of one of CDNI capability object in "cdni-fci-capabilities". 1087 Specifically, that a CDNI capability object A is the superset of 1088 another CDNI capability object B means that these two CDNI capability 1089 objects have the same capability type and mandatory properties in 1090 capability value of A MUST include mandatory properties in capability 1091 value of B semantically. See Section 5.7.2 for a concrete example. 1093 The version tag included in the "vtag" field of the response MUST 1094 correspond to the full CDNI Advertisement resource from which the 1095 filtered CDNI Advertisement resource is provided. This ensures that 1096 a single, canonical version tag is used independently of any 1097 filtering that is requested by an ALTO client. 1099 5.7. Examples 1101 5.7.1. IRD Example 1103 The examples below use the same IRD example as in Section 3.7.1. 1105 5.7.2. Basic Example 1107 This example filters the full CDNI Advertisement resource in 1108 Section 3.7.2 by selecting only the http/1.1 delivery protocol 1109 capability. Only the second BaseAdvertisementObjects in the full 1110 resource will be returned because the second object's capability is 1111 http/1.1 and https/1.1 delivery protocols which is the superset of 1112 https/1.1 delivery protocol. 1114 POST /cdnifci/filtered HTTP/1.1 1115 HOST: alto.example.com 1116 Accept: application/alto-cdni+json 1117 Content-Type: application/cdnifilter+json 1118 Content-Length: 176 1119 { 1120 "cdni-capabilities": [ 1121 { 1122 "capability-type": "FCI.DeliveryProtocol", 1123 "capability-value": { 1124 "delivery-protocols": [ "https/1.1" ] 1125 } 1126 } 1127 ] 1128 } 1130 HTTP/1.1 200 OK 1131 Content-Length: 571 1132 Content-Type: application/alto-cdni+json 1134 { 1135 "meta" : { 1136 "vtag": { 1137 "resource-id": "my-filtered-cdnifci", 1138 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 1139 } 1140 }, 1141 "cdni-advertisement": { 1142 "capabilities-with-footprints": [ 1143 { 1144 "capability-type": "FCI.DeliveryProtocol", 1145 "capability-value": { 1146 "delivery-protocols": [ 1147 "https/1.1", 1148 "http/1.1" 1149 ] 1150 }, 1151 "footprints": [ 1152 { 1153 "footprint-type": "ipv4cidr", 1154 "footprint-value": [ "198.51.100.0/24" ] 1155 } 1156 ] 1157 } 1158 ] 1159 } 1160 } 1162 5.7.3. Incremental Updates Example 1164 In this example, the ALTO client only cares about the updates of one 1165 advertisement object for delivery protocol capability whose value 1166 includes "https/1.1". So it adds its limitation of capabilities in 1167 "input" field of the POST request. 1169 POST /updates/cdnifci HTTP/1.1 1170 Host: fcialtoupdate.example.com 1171 Accept: text/event-stream,application/alto-error+json 1172 Content-Type: application/alto-updatestreamparams+json 1173 Content-Length: 346 1175 { 1176 "add": { 1177 "my-filtered-fci-stream": { 1178 "resource-id": "my-filtered-cdnifci", 1179 "input": { 1180 "cdni-capabilities": [ 1181 { 1182 "capability-type": "FCI.DeliveryProtocol", 1183 "capability-value": { 1184 "delivery-protocols": [ "https/1.1" ] 1185 } 1186 } 1187 ] 1188 } 1189 } 1190 } 1191 } 1193 HTTP/1.1 200 OK 1194 Connection: keep-alive 1195 Content-Type: text/event-stream 1197 event: application/alto-updatestreamcontrol+json 1198 data: {"control-uri": 1199 data: "https://alto.example.com/updates/streams/3141592653590"} 1201 event: application/alto-cdni+json,my-filtered-fci-stream 1202 data: { ... filtered CDNI Advertisement resource ... } 1204 event: application/json-patch+json,my-filtered-fci-stream 1205 data: [ 1206 data: { 1207 data: "op": "replace", 1208 data: "path": "/meta/vtag/tag", 1209 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1210 data: }, 1211 data: { "op": "add", 1212 data: "/cdni-advertisement/capabilities-with-footprints 1213 /0/footprints/0/footprint-value/-", 1214 data: "value": "192.0.2.0/24" 1215 data: } 1216 data: ] 1218 6. Query Footprint Properties using ALTO Property Map Service 1220 Besides the requirement of retrieving footprints of given 1221 capabilities, another common requirement for uCDN is to query CDNI 1222 capabilities of given footprints. 1224 Considering each footprint as an entity with properties including 1225 CDNI capabilities, a natural way to satisfy this requirement is to 1226 use the ALTO property map as defined in 1227 [I-D.ietf-alto-unified-props-new]. This section describes how ALTO 1228 clients look up properties for individual footprints. First, it 1229 describes how to represent footprint objects as entities in the ALTO 1230 property map. Then it describes how to represent footprint 1231 capabilities as entity properties in the ALTO property map. Finally, 1232 it provides examples of the full property map and the filtered 1233 property map supporting CDNI capabilities, and their incremental 1234 updates. 1236 6.1. Representing Footprint Objects as Property Map Entities 1238 A footprint object has two properties: footprint-type and footprint- 1239 value. A footprint-value is an array of footprint values conforming 1240 to the specification associated with the registered footprint type 1241 ("ipv4cidr", "ipv6cidr", "asn", "countrycode", and "altopid"). 1242 Considering each ALTO entity defined in 1243 [I-D.ietf-alto-unified-props-new] also has two properties: entity 1244 domain type and domain-specific identifier, a straightforward 1245 approach to represent a footprint as an ALTO entity is to represent 1246 its footprint-type as an entity domain type, and its footprint value 1247 as a domain-specific identifier. 1249 Each existing footprint type can be represented as an entity domain 1250 type as follows: 1252 o According to [I-D.ietf-alto-unified-props-new], "ipv4" and "ipv6" 1253 are two predefined entity domain types, which can be used to 1254 represent "ipv4cidr" and "ipv6cidr" footprints respectively. 1256 o "pid" is also a predefined entity domain type, which can be used 1257 to represent "altopid" footprints. Note that "pid" is a resource- 1258 specific entity domain. To represent an "altopid" footprint, the 1259 specifying information resource of the corresponding "pid" entity 1260 domain MUST be the dependent network map used by the CDNI 1261 Advertisement resource providing this "altopid" footprint. 1263 o However, no existing entity domain type can represent "asn" and 1264 "countrycode" footprints. To represent footprint-type "asn" and 1265 "countrycode", this document registers two new domains in 1266 Section 7 in addition to the ones in 1267 [I-D.ietf-alto-unified-props-new]. 1269 Here is an example of representing a footprint object of "ipv4cidr" 1270 type as a set of "ipv4" entities in the ALTO property map. The 1271 representation of the footprint object of "ipv6cidr" type is similar. 1273 { "footprint-type": "ipv4cidr", 1274 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 1275 } --> "ipv4:192.0.2.0/24", "ipv4:198.51.100.0/24" 1277 6.1.1. ASN Domain 1279 The ASN domain associates property values with Autonomous Systems in 1280 the Internet. 1282 6.1.1.1. Entity Domain Type 1284 asn 1286 6.1.1.2. Domain-Specific Entity Identifiers 1288 The entity identifier of an entity in an asn domain is encoded as a 1289 string consisting of the characters "as" (in lowercase) followed by 1290 the Autonomous System Number [RFC6793]. 1292 6.1.1.3. Hierarchy and Inheritance 1294 There is no hierarchy or inheritance for properties associated with 1295 ASN. 1297 6.1.2. COUNTRYCODE Domain 1299 The COUNTRYCODE domain associates property values with countries. 1301 6.1.2.1. Entity Domain Type 1303 countrycode 1305 6.1.2.2. Domain-Specific Entity Identifiers 1307 The entity identifier of an entity in a countrycode domain is encoded 1308 as an ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1310 6.1.2.3. Hierarchy and Inheritance 1312 There is no hierarchy or inheritance for properties associated with 1313 country codes. 1315 6.2. Representing CDNI Capabilities as Property Map Entity Properties 1317 This document defines a new entity property type called "cdni- 1318 capabilities". An ALTO server can provide a property map resource 1319 mapping the "cdni-capablities" entity property type for a CDNI 1320 Advertisement resource that it provides to an "ipv4", "ipv6", "asn" 1321 or "countrycode" entity domain. 1323 6.2.1. Defining Information Resource Media Type for Property Type cdni- 1324 capabilities 1326 The entity property type "cdni-capabilities" allows to define 1327 resource-specific entity properties. When resource-specific entity 1328 properties are defined with entity property type "cdni-capabilities", 1329 the defining information resource for a "cdni-capabilities" property 1330 MUST be a CDNI Advertisement resource provided by the ALTO server. 1331 The media type of the defining information resource for a "cdni- 1332 capabilities" property is therefore: 1334 application/alto-cdni+json 1336 6.2.2. Intended Semantics of Property Type cdni-capabilities 1338 A "cdni-capabilities" property for an entity is to indicate all the 1339 CDNI capabilities that a corresponding CDNI Advertisement resource 1340 provides for the footprint represented by this entity. Thus, the 1341 value of a "cdni-capabilities" property MUST be a JSON array. Each 1342 element in a "cdni-capabilities" property MUST be an JSON object as 1343 format of CDNICapability (see Section 5.3). The value of a "cdni- 1344 capabilities" property for an "ipv4", "ipv6", "asn", "countrycode" or 1345 "altopid" entity MUST include all the CDNICapability objects that are 1346 provided by the defining CDNI Advertisement resource and the 1347 represented footprint object of this entity are in their footprint 1348 restrictions. 1350 6.3. Examples 1352 6.3.1. IRD Example 1354 The examples use the same IRD example given by Section 3.7.1. 1356 6.3.2. Property Map Example 1358 This example shows a full property map in which entities are 1359 footprints and entities' property is "cdni-capabilities". 1361 GET /propmap/full/cdnifci HTTP/1.1 1362 HOST: alto.example.com 1363 Accept: application/alto-propmap+json,application/alto-error+json 1365 HTTP/1.1 200 OK 1366 Content-Length: 1522 1367 Content-Type: application/alto-propmap+json 1369 { 1370 "property-map": { 1371 "meta": { 1372 "dependent-vtags": [ 1373 { "resource-id": "my-default-cdnifci", 1374 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1375 ] 1376 }, 1377 "countrycode:us": { 1378 "my-default-cdnifci.cdni-capabilities": [ 1379 { "capability-type": "FCI.DeliveryProtocol", 1380 "capability-value": { 1381 "delivery-protocols": ["http/1.1"]}}] 1382 }, 1383 "ipv4:192.0.2.0/24": { 1384 "my-default-cdnifci.cdni-capabilities": [ 1385 { "capability-type": "FCI.DeliveryProtocol", 1386 "capability-value": { 1387 "delivery-protocols": ["http/1.1"]}}] 1388 }, 1389 "ipv4:198.51.100.0/24": { 1390 "my-default-cdnifci.cdni-capabilities": [ 1391 { "capability-type": "FCI.DeliveryProtocol", 1392 "capability-value": { 1393 "delivery-protocols": ["https/1.1", "http/1.1"]}}] 1394 }, 1395 "ipv4:203.0.113.0/24": { 1396 "my-default-cdnifci.cdni-capabilities": [ 1397 { "capability-type": "FCI.AcquisitionProtocol", 1398 "capability-value": { 1399 "acquisition-protocols": ["http/1.1"]}}] 1400 }, 1401 "ipv6:2001:db8::/32": { 1402 "my-default-cdnifci.cdni-capabilities": [ 1403 { "capability-type": "FCI.DeliveryProtocol", 1404 "capability-value": { 1405 "delivery-protocols": ["http/1.1"]}}] 1406 }, 1407 "asn:as64496": { 1408 "my-default-cdnifci.cdni-capabilities": [ 1409 { "capability-type": "FCI.DeliveryProtocol", 1410 "capability-value": { 1411 "delivery-protocols": ["https/1.1", "http/1.1"]}}] 1412 } 1413 } 1414 } 1416 6.3.3. Filtered Property Map Example 1418 This example uses the filtered property map service to get "pid" and 1419 "cdni-capabilities" properties for two footprints "ipv4:192.0.2.0/24" 1420 and "ipv6:2001:db8::/32". 1422 POST /propmap/lookup/cdnifci-pid HTTP/1.1 1423 HOST: alto.example.com 1424 Content-Type: application/alto-propmapparams+json 1425 Accept: application/alto-propmap+json,application/alto-error+json 1426 Content-Length: 181 1428 { 1429 "entities": [ 1430 "ipv4:192.0.2.0/24", 1431 "ipv6:2001:db8::/32" 1432 ], 1433 "properties": [ "my-default-cdnifci.cdni-capabilities", 1434 "my-default-networkmap.pid" ] 1435 } 1437 HTTP/1.1 200 OK 1438 Content-Length: 796 1439 Content-Type: application/alto-propmap+json 1441 { 1442 "property-map": { 1443 "meta": { 1444 "dependent-vtags": [ 1445 {"resource-id": "my-default-cdnifci", 1446 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}, 1447 {"resource-id": "my-default-networkmap", 1448 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1449 ] 1450 }, 1451 "ipv4:192.0.2.0/24": { 1452 "my-default-cdnifci.cdni-capabilities": [ 1453 {"capability-type": "FCI.DeliveryProtocol", 1454 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1455 "my-default-networkmap.pid": "pid1" 1456 }, 1457 "ipv6:2001:db8::/32": { 1458 "my-default-cdnifci.cdni-capabilities": [ 1459 {"capability-type": "FCI.DeliveryProtocol", 1460 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1461 "my-default-networkmap.pid": "pid3" 1462 } 1463 } 1464 } 1466 6.3.4. Incremental Updates Example 1468 In this example, the client is interested in updates for the 1469 properties "cdni-capabilities" and "pid" of two footprints 1470 "ipv4:192.0.2.0/24" and "countrycode:fr". 1472 POST /updates/properties HTTP/1.1 1473 Host: alto.example.com 1474 Accept: text/event-stream,application/alto-error+json 1475 Content-Type: application/alto-updatestreamparams+json 1476 Content-Length: 337 1478 { "add": { 1479 "fci-propmap-stream": { 1480 "resource-id": "filtered-cdnifci-property-map", 1481 "input": { 1482 "properties": [ "my-default-cdnifci.cdni-capabilities", 1483 "my-default-networkmap.pid" ], 1484 "entities": [ "ipv4:192.0.2.0/24", 1485 "ipv6:2001:db8::/32" ] 1486 } 1487 } 1488 } 1489 } 1491 HTTP/1.1 200 OK 1492 Connection: keep-alive 1493 Content-Type: text/event-stream 1495 event: application/alto-updatestreamcontrol+json 1496 data: {"control-uri": 1497 data: "https://alto.example.com/updates/streams/1414213562373"} 1499 event: application/alto-cdni+json,fci-propmap-stream 1500 data: { ... filtered property map ... } 1502 event: application/merge-patch+json,fci-propmap-stream 1503 data: { 1504 data: "property-map": { 1505 data: "meta": { 1506 data: "dependent-vtags": [ 1507 data: { "resource-id": "my-default-cdnifci", 1508 data: "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"}, 1509 data: { "resource-id": "my-default-networkmap", 1510 data: "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1511 data: ] 1512 data: }, 1513 data: "ipv4:192.0.2.0/24": { 1514 data: "my-default-cdnifci.cdni-capabilities": [ 1515 data: { "capability-type": "FCI.DeliveryProtocol", 1516 data: "capability-value": { 1517 data: "delivery-protocols": ["http/1.1", "https/1.1"]}}] 1518 data: } 1519 data: } 1520 data: } 1522 event: application/json-patch+json,fci-propmap-stream 1523 data: [ 1524 data: { "op": "replace", 1525 data: "path": "/meta/dependent-vtags/0/tag", 1526 data: "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4" 1527 data: }, 1528 data: { "op": "replace", 1529 data: "path": 1530 data: "/property-map/countrycode:fr/my-default-networkmap.pid", 1531 data: "value": "pid5" 1532 data: } 1533 data: ] 1535 7. IANA Considerations 1537 7.1. application/alto-* Media Types 1539 This document registers two additional ALTO media types, listed in 1540 Table 1. 1542 +----------------+-------------------------+------------------------+ 1543 | Type | Subtype | Specification | 1544 +----------------+-------------------------+------------------------+ 1545 | application | alto- | Section 3 | 1546 | | cdni+json | | 1547 | application | alto- | Section 5 | 1548 | | cdnifilter+json | | 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 1559 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: 1581 Magic number(s): n/a 1583 File extension(s): This document uses the mime type to refer to 1584 protocol messages and thus does not require a file extension. 1586 Macintosh file type code(s): n/a 1588 Person & email address to contact for further information: 1589 See Authors' Addresses section. 1591 Intended usage: COMMON 1593 Restrictions on usage: n/a 1595 Author: See Authors' Addresses section. 1597 Change controller: Internet Engineering Task Force 1598 (mailto:iesg@ietf.org). 1600 7.2. CDNI Metadata Footprint Type Registry 1602 As proposed in Section 7.2 of [RFC8006], "CDNI Metadata Footprint 1603 Types" registry is requested. A new footprint type is to be 1604 registered, listed in Table 2. 1606 +----------------+---------------------+----------------------+ 1607 | Footprint Type | Description | Specification | 1608 +----------------+---------------------+----------------------+ 1609 | altopid | A list of PID names | Section 4 of RFCthis | 1610 +----------------+---------------------+----------------------+ 1612 Table 2: CDNI Metadata Footprint Type 1614 [RFC Editor: Please replace RFCthis with the published RFC number for 1615 this document.] 1617 7.3. ALTO Entity Domain Type Registry 1619 As proposed in Section 11.2 of [I-D.ietf-alto-unified-props-new], 1620 "ALTO Entity Domain Type Registry" is requested. Two new entity 1621 domain types are to be registered, listed in Table 3. 1623 +-------------+-----------------------+-------------+---------------+ 1624 | Identifier | Entity Address | Hierarchy & | Media Type of | 1625 | | Encoding | Inheritance | Defining | 1626 | | | | Resource | 1627 +-------------+-----------------------+-------------+---------------+ 1628 | asn | See | None | None | 1629 | | Section 6.1.1.2 of | | | 1630 | | RFCthis | | | 1631 | countrycode | See | None | None | 1632 | | Section 6.1.2.2 of | | | 1633 | | RFCthis | | | 1634 +-------------+-----------------------+-------------+---------------+ 1636 Table 3: Additional ALTO Entity Domain Types 1638 [RFC Editor: Please replace RFCthis with the published RFC number for 1639 this document.] 1641 7.4. ALTO Entity Property Type Registry 1643 As proposed in Section 11.3 of [I-D.ietf-alto-unified-props-new], 1644 "ALTO Entity Property Type Registry" is required. A new entity 1645 property type is to be registered, listed in Table 4. 1647 +-------------------+------------------+----------------------------+ 1648 | Identifier | Intended | Media Type of Defining | 1649 | | Semantics | Resource | 1650 +-------------------+------------------+----------------------------+ 1651 | cdni-capabilities | Section 6.2 of | application/alto-cdni+json | 1652 | | RFCthis | | 1653 +-------------------+------------------+----------------------------+ 1655 Table 4: Additional ALTO Entity Property Type 1657 [RFC Editor: Please replace RFCthis with the published RFC number for 1658 this document.] 1660 8. Security Considerations 1662 As an extension of the base ALTO protocol ([RFC7285]), this document 1663 fits into the architecture of the base protocol. And hence Security 1664 Considerations of the base protocol (Section 15 of [RFC7285]) fully 1665 apply when this extension is provided by an ALTO server. 1667 In the context of CDNI Advertisement, additional security 1668 considerations should be included as follows: 1670 o For authenticity and integrity of ALTO information, an attacker 1671 may disguise itself as an ALTO server for a dCDN, and provide 1672 false capabilities and footprints to a uCDN using the CDNI 1673 Advertisement service. Such false information may lead a uCDN to 1674 (1) select an incorrect dCDN to serve user requests, or (2) skip 1675 uCDNs in good conditions. 1677 o For potential undesirable guidance from authenticated ALTO 1678 information, a dCDN can provide a uCDN with limited capabilities 1679 and smaller footprint coverage so that the dCDN can avoid 1680 transferring traffic for a uCDN which they should have to 1681 transfer. 1683 o For confidentiality and privacy of ALTO information, footprint 1684 properties integrated with ALTO property maps may expose network 1685 location identifiers (e.g., IP addresses or fine-grained PIDs). 1687 o 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 [I-D.ietf-alto-unified-props-new] 1748 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 1749 Gao, "ALTO extension: Entity Property Maps", draft-ietf- 1750 alto-unified-props-new-15 (work in progress), November 1751 2020. 1753 [ISO3166-1] 1754 The International Organization for Standardization, "Codes 1755 for the representation of names of countries and their 1756 subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 1757 2013. 1759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1760 Requirement Levels", BCP 14, RFC 2119, 1761 DOI 10.17487/RFC2119, March 1997, 1762 . 1764 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1765 Autonomous System (AS) Number Space", RFC 6793, 1766 DOI 10.17487/RFC6793, December 2012, 1767 . 1769 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1770 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1771 2014, . 1773 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1774 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1775 "Application-Layer Traffic Optimization (ALTO) Protocol", 1776 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1777 . 1779 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1780 "Content Delivery Network Interconnection (CDNI) 1781 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1782 . 1784 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1785 R., and K. Ma, "Content Delivery Network Interconnection 1786 (CDNI) Request Routing: Footprint and Capabilities 1787 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1788 . 1790 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1791 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1792 May 2017, . 1794 11.2. Informative References 1796 [I-D.ietf-alto-path-vector] 1797 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 1798 "ALTO Extension: Path Vector", draft-ietf-alto-path- 1799 vector-13 (work in progress), November 2020. 1801 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1802 Optimization (ALTO) Problem Statement", RFC 5693, 1803 DOI 10.17487/RFC5693, October 2009, 1804 . 1806 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1807 Distribution Network Interconnection (CDNI) Problem 1808 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1809 2012, . 1811 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1812 "Framework for Content Distribution Network 1813 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1814 August 2014, . 1816 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1817 "Request Routing Redirection Interface for Content 1818 Delivery Network (CDN) Interconnection", RFC 7975, 1819 DOI 10.17487/RFC7975, October 2016, 1820 . 1822 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 1823 Optimization (ALTO) Incremental Updates Using Server-Sent 1824 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 1825 2020, . 1827 Authors' Addresses 1829 Jan Seedorf 1830 HFT Stuttgart - Univ. of Applied Sciences 1831 Schellingstrasse 24 1832 Stuttgart 70174 1833 Germany 1835 Phone: +49-0711-8926-2801 1836 Email: jan.seedorf@hft-stuttgart.de 1837 Y.R. Yang 1838 Yale University 1839 51 Prospect Street 1840 New Haven, CT 06511 1841 United States of America 1843 Email: yry@cs.yale.edu 1844 URI: http://www.cs.yale.edu/~yry/ 1846 Kevin J. Ma 1847 Ericsson 1848 43 Nagog Park 1849 Acton, MA 01720 1850 United States of America 1852 Phone: +1-978-844-5100 1853 Email: kevin.j.ma.ietf@gmail.com 1855 Jon Peterson 1856 NeuStar 1857 1800 Sutter St Suite 570 1858 Concord, CA 94520 1859 United States of America 1861 Email: jon.peterson@neustar.biz 1863 Jingxuan Jensen Zhang 1864 Tongji University 1865 4800 Cao'an Hwy 1866 Shanghai 201804 1867 China 1869 Email: jingxuan.zhang@tongji.edu.cn