idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-22.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 : ---------------------------------------------------------------------------- == 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 February 2022) is 799 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-22 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-21 Summary: 0 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 August 2022 Yale University 6 K. Ma 7 Ericsson 8 J. Peterson 9 NeuStar 10 J. Zhang 11 Tongji University 12 17 February 2022 14 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 15 Footprint and Capabilities Advertisement using ALTO 16 draft-ietf-alto-cdni-request-routing-alto-22 18 Abstract 20 The Content Delivery Networks Interconnection (CDNI) framework in RFC 21 6707 defines a set of protocols to interconnect CDNs to achieve 22 multiple goals, including extending the reach of a given CDN. A CDNI 23 Request Routing Footprint & Capabilities Advertisement interface 24 (FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines the 25 FCI semantics and provides guidelines on the FCI protocol, but the 26 exact protocol is not specified. This document defines a new 27 Application-Layer Traffic Optimization (ALTO) service, called "CDNI 28 Advertisement Service", that provides an implementation of the FCI, 29 following the guidelines defined in RFC 8008. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 21 August 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology and Background . . . . . . . . . . . . . . . . . 4 66 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Semantics of FCI Advertisement . . . . . . . . . . . . . 5 68 2.3. ALTO Background and Benefits . . . . . . . . . . . . . . 6 69 3. CDNI Advertisement Service . . . . . . . . . . . . . . . . . 8 70 3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 9 73 3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 74 3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.7.1. IRD . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.7.2. A Basic Example . . . . . . . . . . . . . . . . . . . 15 79 3.7.3. Incremental Updates . . . . . . . . . . . . . . . . . 17 80 4. CDNI Advertisement Service using ALTO Network Map . . . . . . 18 81 4.1. Network Map Footprint Type: altopid . . . . . . . . . . . 19 82 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 83 4.2.1. ALTO Network Map for CDNI Advertisements . . . . . . 19 84 4.2.2. ALTO PID Footprints in CDNI Advertisements . . . . . 20 85 4.2.3. Incremental Updates . . . . . . . . . . . . . . . . . 21 86 5. Filtered CDNI Advertisement using CDNI Capabilities . . . . . 23 87 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 23 88 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 23 89 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 23 90 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 24 91 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 24 93 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 94 5.7.1. A Basic Example . . . . . . . . . . . . . . . . . . . 25 95 5.7.2. Incremental Updates . . . . . . . . . . . . . . . . . 26 97 6. Query Footprint Properties using ALTO Property Map Service . 28 98 6.1. Representing Footprint Objects as Property Map 99 Entities . . . . . . . . . . . . . . . . . . . . . . . . 28 100 6.1.1. ASN Domain . . . . . . . . . . . . . . . . . . . . . 29 101 6.1.2. COUNTRYCODE Domain . . . . . . . . . . . . . . . . . 30 102 6.2. Representing CDNI Capabilities as Property Map Entity 103 Properties . . . . . . . . . . . . . . . . . . . . . . . 30 104 6.2.1. Defining Information Resource Media Type for Property 105 Type cdni-capabilities . . . . . . . . . . . . . . . 30 106 6.2.2. Intended Semantics of Property Type 107 cdni-capabilities . . . . . . . . . . . . . . . . . . 31 108 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 31 109 6.3.1. Property Map . . . . . . . . . . . . . . . . . . . . 31 110 6.3.2. Filtered Property Map . . . . . . . . . . . . . . . . 32 111 6.3.3. Incremental Updates . . . . . . . . . . . . . . . . . 34 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 113 7.1. application/alto-cdni+json Media Type . . . . . . . . . . 35 114 7.2. application/alto-cdnifilter+json Media Type . . . . . . . 36 115 7.3. CDNI Metadata Footprint Type Registry . . . . . . . . . . 38 116 7.4. ALTO Entity Domain Type Registry . . . . . . . . . . . . 38 117 7.5. ALTO Entity Property Type Registry . . . . . . . . . . . 39 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 119 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 120 9.1. Normative References . . . . . . . . . . . . . . . . . . 41 121 9.2. Informative References . . . . . . . . . . . . . . . . . 42 122 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 123 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 43 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 126 1. Introduction 128 The ability to interconnect multiple content delivery networks (CDNs) 129 has many benefits, including increased coverage, capability, and 130 reliability. The Content Delivery Networks Interconnection (CDNI) 131 framework [RFC6707] defines four interfaces to interconnect CDNs: (1) 132 the CDNI Request Routing Interface, (2) the CDNI Metadata Interface, 133 (3) the CDNI Logging Interface, and (4) the CDNI Control Interface. 135 Among these four interfaces, the CDNI Request Routing Interface 136 provides key functions, as specified in [RFC6707]: "The CDNI Request 137 Routing interface enables a Request Routing function in an Upstream 138 CDN to query a Request Routing function in a Downstream CDN to 139 determine if the Downstream CDN is able (and willing) to accept the 140 delegated Content Request. It also allows the Downstream CDN to 141 control what should be returned to the User Agent in the redirection 142 message by the upstream Request Routing function." At a high level, 143 the scope of the CDNI Request Routing Interface, therefore, contains 144 two main tasks: (1) determining if the dCDN (downstream CDN) is 145 willing to accept a delegated content request, and (2) redirecting 146 the content request coming from a uCDN (upstream CDN) to the proper 147 entry point or entity in the dCDN. 149 Correspondingly, the Request Routing Interface is broadly divided 150 into two functionalities: (1) the CDNI Footprint & Capabilities 151 Advertisement interface (FCI) defined in [RFC8008], and (2) the CDNI 152 Request Routing Redirection interface (RI) defined in [RFC7975]. 153 This document focuses on the first functionality (CDNI FCI). 155 Specifically, CDNI FCI allows both an advertisement from a dCDN to a 156 uCDN (push) and a query from a uCDN to a dCDN (pull) so that the uCDN 157 knows whether it can redirect a particular user request to that dCDN. 159 A key component in defining CDNI FCI is defining objects describing 160 the footprints and capabilities of a dCDN. Such objects are already 161 defined in Section 5 of [RFC8008]. However, no protocol is defined 162 to transport and update such objects between a uCDN and a dCDN. 164 To define such a protocol, this document specifies an extension of 165 the Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol 166 by introducing a new ALTO service called "CDNI Advertisement 167 Service". 169 Section 2.3 discusses the benefits in using ALTO as a transport 170 protocol. 172 2. Terminology and Background 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119][RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 The design of CDNI FCI transport using ALTO assumes an understanding 181 of both FCI semantics and ALTO. Hence, this document starts with a 182 non-normative review for both. 184 2.1. Terminology 186 The document uses the CDNI terms defined in [RFC6707], [RFC8006] and 187 [RFC8008]. Also, the document uses the ALTO terms defined in 188 [RFC7285] and [I-D.ietf-alto-unified-props-new]. This document uses 189 the following abbreviations: 191 * ALTO: Application-Layer Traffic Optimization 192 * ASN: Autonomous System Number 194 * CDN: Content Delivery Network 196 * CDNI: CDN Interconnection 198 * dCDN: Downstream CDN 200 * FCI: CDNI FCI, CDNI Request Routing Footprint & Capabilities 201 Advertisement interface 203 * IRD: Information Resource Directory in ALTO 205 * PID: Provider-defined Identifier in ALTO 207 * uCDN: Upstream CDN 209 2.2. Semantics of FCI Advertisement 211 [RFC8008] defines the semantics of CDNI FCI, provides guidance on 212 what Footprint and Capabilities mean in a CDNI context, and specifies 213 the requirements on the CDNI FCI transport protocol. The definitions 214 in [RFC8008] depend on [RFC8006]. Below is a non-normative review of 215 key related points of [RFC8008] and [RFC8006]. For detailed 216 information and normative specification, the reader should refer to 217 these two RFCs. 219 * Multiple types of mandatory-to-implement footprints (i.e., 220 ipv4cidr, ipv6cidr, asn, and countrycode) are defined in 221 [RFC8006]. A "Set of IP-prefixes" can contain both full IP 222 addresses (i.e., a /32 for IPv4 or a /128 for IPv6) and IP 223 prefixes with an arbitrary prefix length. There must also be 224 support for multiple IP address versions, i.e., IPv4 and IPv6, in 225 such a footprint. 227 * Multiple initial types of capabilities are defined in [RFC8008] 228 including (1) Delivery Protocol, (2) Acquisition Protocol, (3) 229 Redirection Mode, (4) Capabilities related to CDNI Logging, and 230 (5) Capabilities related to CDNI Metadata. They are required in 231 all cases and, therefore, considered as mandatory-to-implement 232 capabilities for all CDNI FCI implementations. 234 * Footprint and capabilities are defined together and cannot be 235 interpreted independently from each other. Specifically, 236 [RFC8008] integrates footprint and capabilities with an approach 237 of "capabilities with footprint restrictions", by expressing 238 capabilities on a per footprint basis. 240 * Specifically, for all mandatory-to-implement footprint types, 241 footprints can be viewed as constraints for delegating requests to 242 a dCDN: A dCDN footprint advertisement tells the uCDN the 243 limitations for delegating a request to the dCDN. For IP prefixes 244 or Autonomous System Numbers (ASNs), the footprint signals to the 245 uCDN that it should consider the dCDN a candidate only if the IP 246 address of the request routing source falls within the prefix set 247 or ASN, respectively. The CDNI specifications do not define how a 248 given uCDN determines what address ranges are in a particular ASN. 249 Similarly, for country codes, a uCDN should only consider the dCDN 250 a candidate if it covers the country of the request routing 251 source. The CDNI specifications do not define how a given uCDN 252 determines the country of the request routing source. Different 253 types of footprint constraints can be combined together to narrow 254 the dCDN candidacy, i.e., the uCDN should consider the dCDN a 255 candidate only if the request routing source satisfies all the 256 types of footprint constraints in the advertisement. 258 * Given that a large part of Footprint and Capabilities 259 Advertisement may happen in contractual agreements, the semantics 260 of CDNI Footprint and Capabilities advertisement refers to 261 answering the following question: what exactly still needs to be 262 advertised by the CDNI FCI? For instance, updates about temporal 263 failures of part of a footprint can be useful information to 264 convey via the CDNI FCI. Such information would provide updates 265 on information previously agreed in contracts between the 266 participating CDNs. In other words, the CDNI FCI is a means for a 267 dCDN to provide changes/updates regarding a footprint and/or 268 capabilities that it has previously agreed to serve in a contract 269 with a uCDN. Hence, server push and incremental encoding will be 270 necessary techniques. 272 2.3. ALTO Background and Benefits 274 Application-Layer Traffic Optimization (ALTO) [RFC7285] defines an 275 approach for conveying network layer (topology) information to 276 "guide" the resource provider selection process in distributed 277 applications that can choose among several candidate resources 278 providers to retrieve a given resource. Usually, it is assumed that 279 an ALTO server conveys information that these applications cannot 280 measure or have difficulty measuring themselves [RFC5693]. 282 Originally, ALTO was motivated by optimizing cross-ISP traffic 283 generated by P2P applications [RFC5693]. However, ALTO can also be 284 used for improving the request routing in CDNs. In particular, 285 Section 5 of [RFC7971] explicitly mentions ALTO as a candidate 286 protocol to improve the selection of a CDN surrogate or origin. 288 The following reasons make ALTO a suitable candidate protocol for 289 dCDN selection as part of CDNI request routing and, in particular, 290 for an FCI protocol: 292 * Application Layer-oriented: ALTO is a protocol specifically 293 designed to improve application layer traffic (and application 294 layer connections among hosts on the Internet) by providing 295 additional information to applications that these applications 296 could not easily retrieve themselves. This matches the need of 297 CDNI, where a uCDN wants to improve application layer CDN request 298 routing by using information (provided by a dCDN) that the uCDN 299 could not easily obtain otherwise. Hence, ALTO can help a uCDN to 300 select a proper dCDN by first providing dCDNs' capabilities as 301 well as footprints (see Section 3) and then providing costs of 302 surrogates in a dCDN by ALTO cost maps. 304 * Security: The identification between uCDNs and dCDNs is an 305 important requirement (see Section 8). ALTO maps can be signed 306 and hence provide inherent origin protection. Please see 307 Section 15.1.2 of [RFC7285] for detailed protection strategies. 309 * RESTful design: The ALTO protocol has undergone extensive 310 revisions in order to provide a RESTful design regarding the 311 client-server interaction specified by the protocol. It is 312 flexible and extensible enough to handle existing and potential 313 future data formats defined by CDNI. It can provide the 314 consistent client-server interaction model for other existing CDNI 315 interfaces or potential future extensions and therefore reduce the 316 learning cost for both users and developers, although they are not 317 in the scope of this document. A CDNI FCI interface based on ALTO 318 would inherit this RESTful design. Please see Section 3. 320 * Error-handling: The ALTO protocol provides extensive error- 321 handling in the whole request and response process (see 322 Section 8.5 of [RFC7285]). A CDNI FCI interface based on ALTO 323 would inherit this extensive error-handling framework. Please see 324 Section 5. 326 * Map Service: The semantics of an ALTO network map is an exact 327 match for the needed information to convey a footprint by a dCDN, 328 in particular, if such a footprint is being expressed by IP-prefix 329 ranges. Please see Section 4. 331 * Filtered Map Service: The ALTO map filtering service would allow a 332 uCDN to query only for parts of an ALTO map. For example, the 333 ALTO filtered property map service can enable a uCDN to query 334 properties of a part of footprints efficiently. Please see 335 Section 6. 337 * Server-initiated notifications and incremental updates: When the 338 footprint or the capabilities of a dCDN change (i.e., unexpectedly 339 from the perspective of a uCDN), server-initiated notifications 340 would enable a dCDN to inform a uCDN about such changes directly. 341 Consider the case where - due to failure - part of the footprint 342 of the dCDN is not functioning, i.e., the CDN cannot serve content 343 to such clients with reasonable QoS. Without server-initiated 344 notifications, the uCDN might still use a recent network and cost 345 map from the dCDN, and therefore redirect requests to the dCDN 346 which it cannot serve. Similarly, the possibility for incremental 347 updates would enable efficient conveyance of the aforementioned 348 (or similar) status changes by the dCDN to the uCDN. The newest 349 design of ALTO supports server pushed incremental updates 350 [RFC8895]. 352 * Content availability on hosts: A dCDN might want to express CDN 353 capabilities in terms of certain content types (e.g., codecs/ 354 formats, or content from certain content providers). ALTO Entity 355 Property Map [I-D.ietf-alto-unified-props-new] would enable a dCDN 356 to make such information available to a uCDN. This would enable a 357 uCDN to access whether a dCDN has the capabilities for a given 358 type of content requested. 360 * Resource availability on hosts or links: The capabilities on links 361 (e.g., maximum bandwidth) or caches (e.g., average load) might be 362 useful information for a uCDN for optimized dCDN selection. For 363 instance, if a uCDN receives a streaming request for content with 364 a certain bitrate, it needs to know if it is likely that a dCDN 365 can fulfill such stringent application-level requirements (i.e., 366 can be expected to have enough consistent bandwidth) before it 367 redirects the request. In general, if ALTO could convey such 368 information via ALTO Entity Property Map 369 [I-D.ietf-alto-unified-props-new], it would enable more 370 sophisticated means for dCDN selection with ALTO. ALTO Path 371 Vector Extension [I-D.ietf-alto-path-vector] is designed to allow 372 ALTO clients to query information such as capacity regions for a 373 given set of flows. 375 3. CDNI Advertisement Service 377 The ALTO protocol relies upon the ALTO Information Service framework 378 which consists of multiple services. All ALTO services are "provided 379 through a common transport protocol, messaging structure and 380 encoding, and transaction model" [RFC7285]. The ALTO protocol 381 specification defines multiple initial services, e.g., the ALTO 382 network map service and cost map service. 384 This document defines a new ALTO service, called "CDNI Advertisement 385 Service", which conveys JSON [RFC8259] objects of media type 386 "application/alto-cdni+json". These JSON objects are used to 387 transport BaseAdvertisementObject objects defined in [RFC8008]. This 388 document specifies how to transport such BaseAdvertisementObject 389 objects via the ALTO protocol with the ALTO "CDNI Advertisement 390 Service". Similar to other ALTO services, this document defines the 391 ALTO information resource for the "CDNI Advertisement Service" as 392 follows. 394 Note that the encoding of BaseAdvertisementObject reuses the one 395 defined in [RFC8008] and therefore also follows the recommendations 396 of I-JSON (Internet JSON) [RFC7493], which is required by [RFC8008]. 398 3.1. Media Type 400 The media type of the CDNI Advertisement resource is "application/ 401 alto-cdni+json" (see Section 7). 403 3.2. HTTP Method 405 A CDNI Advertisement resource is requested using the HTTP GET method. 407 3.3. Accept Input Parameters 409 There are no applicable Accept Input parameters. 411 3.4. Capabilities 413 There are no applicable capabilities. 415 3.5. Uses 417 The "uses" field MUST NOT appear unless the CDNI Advertisement 418 resource depends on other ALTO information resources. If the CDNI 419 Advertisement resource has dependent resources, the resource IDs of 420 its dependent resources MUST be included into the "uses" field. This 421 document only defines one potential dependent resource for the CDNI 422 Advertisement resource. See Section 4 for details of when and how to 423 use it. Future documents may extend the CDNI Advertisement resource 424 and allow other dependent resources. 426 3.6. Response 428 The "meta" field of a CDNI Advertisement response MUST include the 429 "vtag" field defined in Section 10.3 of [RFC7285]. This field 430 provides the version of the retrieved CDNI FCI resource. 432 If a CDNI Advertisement response depends on other ALTO information 433 resources, it MUST include the "dependent-vtags" field, whose value 434 is an array to indicate the version tags of the resources used, where 435 each resource is specified in "uses" of its Information Resource 436 Directory (IRD) entry. 438 The data component of an ALTO CDNI Advertisement response is named 439 "cdni-advertisement", which is a JSON object of type 440 CDNIAdvertisementData: 442 object { 443 CDNIAdvertisementData cdni-advertisement; 444 } InfoResourceCDNIAdvertisement : ResponseEntityBase; 446 object { 447 BaseAdvertisementObject capabilities-with-footprints<0..*>; 448 } CDNIAdvertisementData; 450 Specifically, a CDNIAdvertisementData object is a JSON object that 451 includes only one property named "capabilities-with-footprints", 452 whose value is an array of BaseAdvertisementObject objects. It 453 provides capabilities with footprint restrictions for uCDN to decide 454 the dCDN selection. If the value of this property is an empty array, 455 it means the corresponding dCDN cannot provide any mandatory-to- 456 implement CDNI capabilities for any footprints. 458 The syntax and semantics of BaseAdvertisementObject are well defined 459 in Section 5.1 of [RFC8008]. A BaseAdvertisementObject object 460 includes multiple properties, including capability-type, capability- 461 value, and footprints, where footprints are defined in 462 Section 4.2.2.2 of [RFC8006]. 464 To be self-contained, below is an equivalent specification of 465 BaseAdvertisementObject described in the ALTO-style notation (see 466 Section 8.2 of [RFC7285]). As mentioned above, the normative 467 specification of BaseAdvertisementObject is in [RFC8008]. 469 object { 470 JSONString capability-type; 471 JSONValue capability-value; 472 Footprint footprints<0..*>; 473 } BaseAdvertisementObject; 475 object { 476 JSONString footprint-type; 477 JSONString footprint-value<1..*>; 478 } Footprint; 480 For each BaseAdvertisementObject, the ALTO client MUST interpret 481 footprints appearing multiple times as if they appeared only once. 482 If footprints in a BaseAdvertisementObject is null or empty or not 483 appearing, the ALTO client MUST understand that the capabilities in 484 this BaseAdvertisementObject have the "global" coverage, i.e., the 485 corresponding dCDN can provide them for any request routing source. 487 Note: Further optimization of BaseAdvertisement objects to 488 effectively provide the advertisement of capabilities with footprint 489 restrictions is certainly possible. For example, these two examples 490 below both describe that the dCDN can provide capabilities 491 ["http/1.1", "https/1.1"] for the same footprints. However, the 492 latter one is smaller in its size. 494 EXAMPLE 1 495 { 496 "meta": {...}, 497 "cdni-advertisement": { 498 "capabilities-with-footprints": [ 499 { 500 "capability-type": "FCI.DeliveryProtocol", 501 "capability-value": { 502 "delivery-protocols": [ 503 "http/1.1" 504 ] 505 }, 506 "footprints": [ 507 508 ] 509 }, 510 { 512 "capability-type": "FCI.DeliveryProtocol", 513 "capability-value": { 514 "delivery-protocols": [ 515 "https/1.1" 516 ] 517 }, 518 "footprints": [ 519 520 ] 521 } 522 ] 523 } 524 } 526 EXAMPLE 2 527 { 528 "meta": {...}, 529 "cdni-advertisement": { 530 "capabilities-with-footprints": [ 531 { 532 "capability-type": "FCI.DeliveryProtocol", 533 "capability-value": { 534 "delivery-protocols": [ 535 "https/1.1", 536 "http/1.1" 537 ] 538 }, 539 "footprints": [ 540 541 ] 542 } 543 ] 544 } 545 } 547 Since such optimizations are not required for the basic 548 interconnection of CDNs, the specifics of such mechanisms are outside 549 the scope of this document. 551 This document only requires the ALTO server to provide the initial 552 FCI-specific CDNI Payload Types defined in [RFC8008] as the 553 mandatory-to-implement CDNI capabilities. 555 3.7. Examples 557 3.7.1. IRD 559 Below is the IRD of a simple, example ALTO server. The server 560 provides both base ALTO information resources (e.g., network maps) 561 and CDNI FCI related information resources (e.g., CDNI Advertisement 562 resources), demonstrating a single, integrated environment. 564 Specifically, the IRD announces nine information resources as 565 follows: 567 * two network maps, 569 * one CDNI Advertisement resource without dependency, 571 * one CDNI Advertisement resource depending on a network map, 573 * one filtered CDNI Advertisement resource to be defined in 574 Section 5, 576 * one property map including "cdni-capabilities" as its entity 577 property, 579 * one filtered property map including "cdni-capabilities" and "pid" 580 as its entity properties, and 582 * two update stream services: 584 - one for updating CDNI Advertisement resources, 586 - one for updating property maps 588 GET /directory HTTP/1.1 589 Host: alto.example.com 590 Accept: application/alto-directory+json,application/alto-error+json 592 HTTP/1.1 200 OK 593 Content-Length: 3531 594 Content-Type: application/alto-directory+json 596 { 597 "meta": { 598 "default-alto-network-map": "my-default-network-map" 599 }, 600 "resources": { 601 "my-default-network-map": { 602 "uri": "https://alto.example.com/networkmap", 603 "media-type": "application/alto-networkmap+json" 604 }, 605 "my-eu-netmap": { 606 "uri": "https://alto.example.com/myeunetmap", 607 "media-type": "application/alto-networkmap+json" 608 }, 609 "my-default-cdnifci": { 610 "uri": "https://alto.example.com/cdnifci", 611 "media-type": "application/alto-cdni+json" 612 }, 613 "my-cdnifci-with-pid-footprints": { 614 "uri": "https://alto.example.com/networkcdnifci", 615 "media-type": "application/alto-cdni+json", 616 "uses": [ "my-eu-netmap" ] 617 }, 618 "my-filtered-cdnifci": { 619 "uri": "https://alto.example.com/cdnifci/filtered", 620 "media-type": "application/alto-cdni+json", 621 "accepts": "application/alto-cdnifilter+json" 622 }, 623 "cdnifci-property-map": { 624 "uri": "https://alto.example.com/propmap/full/cdnifci", 625 "media-type": "application/alto-propmap+json", 626 "uses": [ "my-default-cdni" ], 627 "capabilities": { 628 "mappings": { 629 "ipv4": [ "my-default-cdni.cdni-capabilities" ], 630 "ipv6": [ "my-default-cdni.cdni-capabilities" ], 631 "countrycode": [ 632 "my-default-cdni.cdni-capabilities" ], 633 "asn": [ "my-default-cdni.cdni-capabilities" ] 634 } 635 } 636 }, 637 "filtered-cdnifci-property-map": { 638 "uri": "https://alto.example.com/propmap/lookup/cdnifci-pid", 639 "media-type": "application/alto-propmap+json", 640 "accepts": "application/alto-propmapparams+json", 641 "uses": [ "my-default-cdni", "my-default-network-map" ], 642 "capabilities": { 643 "mappings": { 644 "ipv4": [ "my-default-cdni.cdni-capabilities", 645 "my-default-network-map.pid" ], 646 "ipv6": [ "my-default-cdni.cdni-capabilities", 647 "my-default-network-map.pid" ], 648 "countrycode": [ 649 "my-default-cdni.cdni-capabilities" ], 650 "asn": [ "my-default-cdni.cdni-capabilities" ] 651 } 652 } 653 }, 654 "update-my-cdni-fci": { 655 "uri": "https://alto.example.com/updates/cdnifci", 656 "media-type": "text/event-stream", 657 "accepts": "application/alto-updatestreamparams+json", 658 "uses": [ 659 "my-default-network-map", 660 "my-eu-netmap", 661 "my-default-cdnifci", 662 "my-filtered-cdnifci", 663 "my-cdnifci-with-pid-footprints" 664 ], 665 "capabilities": { 666 "incremental-change-media-types": { 667 "my-default-network-map": "application/json-patch+json", 668 "my-eu-netmap": "application/json-patch+json", 669 "my-default-cdnifci": 670 "application/merge-patch+json,application/json-patch+json", 671 "my-filtered-cdnifci": 673 "application/merge-patch+json,application/json-patch+json", 674 "my-cdnifci-with-pid-footprints": 675 "application/merge-patch+json,application/json-patch+json" 676 } 677 } 678 }, 679 "update-my-props": { 680 "uri": "https://alto.example.com/updates/properties", 681 "media-type": "text/event-stream", 682 "uses": [ 683 "cdnifci-property-map", 684 "filtered-cdnifci-property-map" 685 ], 686 "capabilities": { 687 "incremental-change-media-types": { 688 "cdnifci-property-map": 689 "application/merge-patch+json,application/json-patch+json", 690 "filtered-cdnifci-property-map": 691 "application/merge-patch+json,application/json-patch+json" 692 } 693 } 694 } 695 } 696 } 698 3.7.2. A Basic Example 700 This basic example demonstrates a simple CDNI Advertisement resource, 701 which does not depend on other resources. There are three 702 BaseAdvertisementObjects in this resource and these objects' 703 capabilities are http/1.1 delivery protocol, [http/1.1, https/1.1] 704 delivery protocol, and https/1.1 acquisition protocol, respectively. 706 GET /cdnifci HTTP/1.1 707 Host: alto.example.com 708 Accept: application/alto-cdni+json,application/alto-error+json 710 HTTP/1.1 200 OK 711 Content-Length: 1411 712 Content-Type: application/alto-cdni+json 714 { 715 "meta": { 716 "vtag": { 717 "resource-id": "my-default-cdnifci", 718 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 719 } 720 }, 721 "cdni-advertisement": { 722 "capabilities-with-footprints": [ 723 { 724 "capability-type": "FCI.DeliveryProtocol", 725 "capability-value": { 726 "delivery-protocols": [ 727 "http/1.1" 728 ] 729 }, 730 "footprints": [ 731 { 732 "footprint-type": "ipv4cidr", 733 "footprint-value": [ "192.0.2.0/24" ] 734 }, 735 { 736 "footprint-type": "ipv6cidr", 737 "footprint-value": [ "2001:db8::/32" ] 738 } 739 ] 740 }, 741 { 742 "capability-type": "FCI.DeliveryProtocol", 743 "capability-value": { 744 "delivery-protocols": [ 745 "https/1.1", 746 "http/1.1" 747 ] 748 }, 749 "footprints": [ 750 { 751 "footprint-type": "ipv4cidr", 752 "footprint-value": [ "198.51.100.0/24" ] 753 } 754 ] 755 }, 756 { 757 "capability-type": "FCI.AcquisitionProtocol", 758 "capability-value": { 759 "acquisition-protocols": [ 760 "https/1.1" 761 ] 762 }, 763 "footprints": [ 764 { 765 "footprint-type": "ipv4cidr", 766 "footprint-value": [ "203.0.113.0/24" ] 767 } 768 ] 770 } 771 ] 772 } 773 } 775 3.7.3. Incremental Updates 777 A benefit of using ALTO to provide CDNI Advertisement resources is 778 that such resources can be updated using ALTO incremental updates 779 [RFC8895]. Below is an example that also shows the benefit of having 780 both JSON merge patch and JSON patch to encode updates. 782 At first, an ALTO client requests updates for "my-default-cdnifci", 783 and the ALTO server returns the "control-uri" followed by the full 784 CDNI Advertisement response. Then when there is a change in the 785 delivery-protocols in that http/1.1 is removed (from [http/1.1, 786 https/1.1] to only https/1.1) due to maintenance of the http/1.1 787 clusters, the ALTO server regenerates the new CDNI Advertisement 788 resource and pushes the full replacement to the ALTO client. Later 789 on, the ALTO server notifies the ALTO client that "192.0.2.0/24" is 790 added into the "ipv4" footprint object for delivery-protocol 791 https/1.1 by sending the change encoded by JSON patch to the ALTO 792 client. 794 POST /updates/cdnifci HTTP/1.1 795 Host: alto.example.com 796 Accept: text/event-stream,application/alto-error+json 797 Content-Type: application/alto-updatestreamparams+json 798 Content-Length: 94 800 { 801 "add": { 802 "my-cdnifci-stream": { 803 "resource-id": "my-default-cdnifci" 804 } 805 } 806 } 808 HTTP/1.1 200 OK 809 Connection: keep-alive 810 Content-Type: text/event-stream 812 event: application/alto-updatestreamcontrol+json 813 data: {"control-uri": 814 data: "https://alto.example.com/updates/streams/3141592653589"} 816 event: application/alto-cdni+json,my-cdnifci-stream 817 data: { ... full CDNI Advertisement resource ... } 818 event: application/alto-cdni+json,my-cdnifci-stream 819 data: { 820 data: "meta": { 821 data: "vtag": { 822 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 823 data: } 824 data: }, 825 data: "cdni-advertisement": { 826 data: "capabilities-with-footprints": [ 827 data: { 828 data: "capability-type": "FCI.DeliveryProtocol", 829 data: "capability-value": { 830 data: "delivery-protocols": [ 831 data: "https/1.1" 832 data: ] 833 data: }, 834 data: "footprints": [ 835 data: { "footprint-type": "ipv4cidr", 836 data: "footprint-value": [ "203.0.113.0/24" ] 837 data: } 838 data: ] 839 data: }, 840 data: { ... other CDNI advertisement object ... } 841 data: ] 842 data: } 843 data: } 845 event: application/json-patch+json,my-cdnifci-stream 846 data: [ 847 data: { "op": "replace", 848 data: "path": "/meta/vtag/tag", 849 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 850 data: }, 851 data: { "op": "add", 852 data: "path": "/cdni-advertisement/capabilities-with-footprints 853 /0/footprints/0/footprint-value/-", 854 data: "value": "192.0.2.0/24" 855 data: } 856 data: ] 858 4. CDNI Advertisement Service using ALTO Network Map 859 4.1. Network Map Footprint Type: altopid 861 The ALTO protocol defines a concept called Provider-defined 862 Identifier (PID) to represent a group of IPv4 or IPv6 addresses which 863 can be applied the same management policy. The PID is an alternative 864 to the pre-defined CDNI footprint types (i.e., ipv4cidr, ipv6cidr, 865 asn, and countrycode). 867 To leverage this concept, this document defines a new CDNI Footprint 868 Type called "altopid". A CDNI Advertisement resource can depend on 869 an ALTO network map resource and use "altopid" footprints to compress 870 its CDNI Footprint Payload. 872 Specifically, the "altopid" footprint type indicates that the 873 corresponding footprint value is a list of PIDNames as defined in 874 [RFC7285]. These PIDNames are references of PIDs in a network map 875 resource. Hence a CDNI Advertisement resource using "altopid" 876 footprints depends on a network map. For such a CDNI Advertisement 877 resource, the resource id of its dependent network map MUST be 878 included in the "uses" field of its IRD entry, and the "dependent- 879 vtags" field with a reference to this network map MUST be included in 880 its response (see the example in Section 4.2.2). 882 4.2. Examples 884 The following examples use the same IRD given in Section 3.7.1. 886 4.2.1. ALTO Network Map for CDNI Advertisements 888 Below provides a sample network map whose resource id is "my-eu- 889 netmap". This map is referenced by the CDNI Advertisement example in 890 Section 4.2.2. 892 GET /myeunetmap HTTP/1.1 893 Host: alto.example.com 894 Accept: application/alto-networkmap+json,application/alto-error+json 896 HTTP/1.1 200 OK 897 Content-Length: 344 898 Content-Type: application/alto-networkmap+json 900 { 901 "meta": { 902 "vtag": [ 903 { "resource-id": "my-eu-netmap", 904 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 905 } 906 ] 907 }, 908 "network-map": { 909 "south-france" : { 910 "ipv4": [ "192.0.2.0/24", "198.51.100.0/25" ], 911 "ipv6": [ "2001:db8::/32" ] 912 }, 913 "germany": { 914 "ipv4": [ "203.0.113.0/24" ] 915 } 916 } 917 } 919 4.2.2. ALTO PID Footprints in CDNI Advertisements 921 This example shows a CDNI Advertisement resource that depends on a 922 network map described in Section 4.2.1. 924 GET /networkcdnifci HTTP/1.1 925 Host: alto.example.com 926 Accept: application/alto-cdni+json,application/alto-error+json 928 HTTP/1.1 200 OK 929 Content-Length: 736 930 Content-Type: application/alto-cdni+json 932 { 933 "meta": { 934 "dependent-vtags": [ 935 { 936 "resource-id": "my-eu-netmap", 937 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 938 } 939 ] 940 }, 941 "cdni-advertisement": { 942 "capabilities-with-footprints": [ 943 { "capability-type": "FCI.DeliveryProtocol", 944 "capability-value": [ "https/1.1" ], 945 "footprints": [ 946 { "footprint-type": "altopid", 947 "footprint-value": [ "south-france" ] 948 } 949 ] 950 }, 951 { "capability-type": "FCI.AcquisitionProtocol", 952 "capability-value": [ "https/1.1" ], 953 "footprints": [ 954 { "footprint-type": "altopid", 955 "footprint-value": [ "germany", "south-france" ] 956 } 957 ] 958 } 959 ] 960 } 961 } 963 4.2.3. Incremental Updates 965 In this example, the ALTO client is interested in changes of "my- 966 cdnifci-with-pid-footprints" and its dependent network map "my-eu- 967 netmap". Considering two changes, the first one is to change 968 footprints of the https/1.1 delivery protocol capability, and the 969 second one is to remove the "south-france" PID from the footprints of 970 the https/1.1 acquisition protocol capability. 972 POST /updates/cdnifci HTTP/1.1 973 Host: alto.example.com 974 Accept: text/event-stream,application/alto-error+json 975 Content-Type: application/alto-updatestreamparams+json 976 Content-Length: 185 978 { 979 "add": { 980 "my-eu-netmap-stream": { 981 "resource-id": "my-eu-netmap" 982 }, 983 "my-netmap-cdnifci-stream": { 984 "resource-id": "my-cdnifci-with-pid-footprints" 985 } 986 } 987 } 989 HTTP/1.1 200 OK 990 Connection: keep-alive 991 Content-Type: text/event-stream 993 event: application/alto-updatestreamcontrol+json 994 data: {"control-uri": 995 data: "https://alto.example.com/updates/streams/3141592653590"} 997 event: application/alto-networkmap+json,my-eu-netmap-stream 998 data: { ... full Network Map of my-eu-netmap ... } 1000 event: application/alto-cdnifci+json,my-netmap-cdnifci-stream 1001 data: { ... full CDNI Advertisement resource ... } 1003 event: application/json-patch+json,my-netmap-cdnifci-stream 1004 data: [ 1005 data: { "op": "replace", 1006 data: "path": "/meta/vtag/tag", 1007 data: "value": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 1008 data: }, 1009 data: { "op": "add", 1010 data: "path": 1011 data: "/cdni-advertisement/capabilities-with-footprints 1012 /0/footprints/0/footprint-value/-", 1013 data: "value": "germany" 1014 data: } 1015 data: ] 1017 event: application/json-patch+json,my-netmap-cdnifci-stream 1018 data: [ 1019 data: { "op": "replace", 1020 data: "path": "/meta/vtag/tag", 1021 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1022 data: }, 1023 data: { "op": "remove", 1024 data: "path": 1025 data: "/cdni-advertisement/capabilities-with-footprints 1026 /1/footprints/0/footprint-value/1" 1027 data: } 1028 data: ] 1030 5. Filtered CDNI Advertisement using CDNI Capabilities 1032 Sections 3 (Section 3) and 4 (Section 4) describe CDNI Advertisement 1033 Service which can be used to enable a uCDN to get capabilities with 1034 footprint restrictions from dCDNs. However, since always getting 1035 full CDNI Advertisement resources from dCDNs is inefficient, this 1036 document introduces a new service named "Filtered CDNI Advertisement 1037 Service", to allow a client to filter a CDNI Advertisement resource 1038 using a client-given set of CDNI capabilities. For each entry of the 1039 CDNI Advertisement response, an entry will only be returned to the 1040 client if it contains at least one of the client given CDNI 1041 capabilities. The relationship between a filtered CDNI Advertisement 1042 resource and a CDNI Advertisement resource is similar to the 1043 relationship between a filtered network/cost map and a network/cost 1044 map. 1046 5.1. Media Type 1048 A filtered CDNI Advertisement resource uses the same media type 1049 defined for the CDNI Advertisement resource in Section 3.1: 1050 "application/alto-cdni+json". 1052 5.2. HTTP Method 1054 A filtered CDNI Advertisement resource is requested using the HTTP 1055 POST method. 1057 5.3. Accept Input Parameters 1059 The input parameters for a filtered CDNI Advertisement resource are 1060 supplied in the entity body of the POST request. This document 1061 specifies the input parameters with a data format indicated by the 1062 media type "application/alto-cdnifilter+json" which is a JSON object 1063 of type ReqFilteredCDNIAdvertisement, where: 1065 object { 1066 JSONString capability-type; 1067 JSONValue capability-value; 1068 } CDNICapability; 1070 object { 1071 CDNICapability cdni-capabilities<0..*>; 1072 } ReqFilteredCDNIAdvertisement; 1074 with fields: 1076 capability-type: The same as Base Advertisement Object's capability- 1077 type defined in Section 5.1 of [RFC8008]. 1079 capability-value: The same as Base Advertisement Object's 1080 capability-value defined in Section 5.1 of [RFC8008]. 1082 cdni-capabilities: A list of CDNI capabilities defined in 1083 Section 5.1 of [RFC8008] for which footprints are to be returned. 1084 If this list is empty, the ALTO server MUST interpret it as a 1085 request for the full CDNI Advertisement resource. The ALTO server 1086 MUST interpret entries appearing in this list multiple times as if 1087 they appeared only once. If the ALTO server does not define any 1088 footprints for a CDNI capability, it MUST omit this capability 1089 from the response. 1091 5.4. Capabilities 1093 There are no applicable capabilities. 1095 5.5. Uses 1097 Same to the "uses" field of the CDNI Advertisement resource (see 1098 Section 3.5). 1100 5.6. Response 1102 If the request is invalid, the response MUST indicate an error, using 1103 ALTO protocol error handling specified in Section 8.5 of [RFC7285]. 1105 Specifically, a filtered CDNI Advertisement request is invalid if: 1107 * the value of "capability-type" is null; 1109 * the value of "capability-value" is null; 1111 * the value of "capability-value" is inconsistent with "capability- 1112 type". 1114 When a request is invalid, the ALTO server MUST return an 1115 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], 1116 and the "value" field of the error message SHOULD indicate this CDNI 1117 capability. 1119 The ALTO server returns a filtered CDNI Advertisement resource for a 1120 valid request. The format of a filtered CDNI Advertisement resource 1121 is the same as a full CDNI Advertisement resource (See Section 3.6.) 1123 The returned filtered CDNI Advertisement resource MUST contain all 1124 the BaseAdvertisementObject objects satisfying the following 1125 condition: The CDNI capability object of each included 1126 BaseAdvertisementObject object MUST follow two constraints: 1128 * The "cdni-capabilities" field of the input includes a CDNI 1129 capability object X having the same capability type as it. 1131 * All the mandatory properties in its capability value is a superset 1132 of mandatory properties in capability value of X semantically. 1134 See Section 5.7.1 for a concrete example. 1136 The version tag included in the "vtag" field of the response MUST 1137 correspond to the full CDNI Advertisement resource from which the 1138 filtered CDNI Advertisement resource is provided. This ensures that 1139 a single, canonical version tag is used independently of any 1140 filtering that is requested by an ALTO client. 1142 5.7. Examples 1144 The following examples use the same IRD example as in Section 3.7.1. 1146 5.7.1. A Basic Example 1148 This example filters the full CDNI Advertisement resource in 1149 Section 3.7.2 by selecting only the http/1.1 delivery protocol 1150 capability. Only the second BaseAdvertisementObjects in the full 1151 resource will be returned because the second object's capability is 1152 http/1.1 and https/1.1 delivery protocols which is the superset of 1153 https/1.1 delivery protocol. 1155 POST /cdnifci/filtered HTTP/1.1 1156 Host: alto.example.com 1157 Accept: application/alto-cdni+json 1158 Content-Type: application/cdnifilter+json 1159 Content-Length: 176 1161 { 1162 "cdni-capabilities": [ 1163 { 1164 "capability-type": "FCI.DeliveryProtocol", 1165 "capability-value": { 1166 "delivery-protocols": [ "https/1.1" ] 1167 } 1168 } 1169 ] 1170 } 1172 HTTP/1.1 200 OK 1173 Content-Length: 570 1174 Content-Type: application/alto-cdni+json 1176 { 1177 "meta": { 1178 "vtag": { 1179 "resource-id": "my-filtered-cdnifci", 1180 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 1181 } 1182 }, 1183 "cdni-advertisement": { 1184 "capabilities-with-footprints": [ 1185 { 1186 "capability-type": "FCI.DeliveryProtocol", 1187 "capability-value": { 1188 "delivery-protocols": [ 1189 "https/1.1", 1190 "http/1.1" 1191 ] 1192 }, 1193 "footprints": [ 1194 { 1195 "footprint-type": "ipv4cidr", 1196 "footprint-value": [ "198.51.100.0/24" ] 1197 } 1198 ] 1199 } 1200 ] 1201 } 1202 } 1204 5.7.2. Incremental Updates 1206 In this example, the ALTO client only cares about the updates of one 1207 advertisement object for delivery protocol capability whose value 1208 includes "https/1.1". Thus, it adds its limitation of capabilities 1209 in "input" field of the POST request. 1211 POST /updates/cdnifci HTTP/1.1 1212 Host: fcialtoupdate.example.com 1213 Accept: text/event-stream,application/alto-error+json 1214 Content-Type: application/alto-updatestreamparams+json 1215 Content-Length: 346 1217 { 1218 "add": { 1219 "my-filtered-fci-stream": { 1220 "resource-id": "my-filtered-cdnifci", 1221 "input": { 1222 "cdni-capabilities": [ 1223 { 1224 "capability-type": "FCI.DeliveryProtocol", 1225 "capability-value": { 1226 "delivery-protocols": [ "https/1.1" ] 1227 } 1228 } 1229 ] 1230 } 1231 } 1232 } 1233 } 1235 HTTP/1.1 200 OK 1236 Connection: keep-alive 1237 Content-Type: text/event-stream 1239 event: application/alto-updatestreamcontrol+json 1240 data: {"control-uri": 1241 data: "https://alto.example.com/updates/streams/3141592653590"} 1243 event: application/alto-cdni+json,my-filtered-fci-stream 1244 data: { ... filtered CDNI Advertisement resource ... } 1246 event: application/json-patch+json,my-filtered-fci-stream 1247 data: [ 1248 data: { 1249 data: "op": "replace", 1250 data: "path": "/meta/vtag/tag", 1251 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1252 data: }, 1253 data: { "op": "add", 1254 data: "path": 1255 data: "/cdni-advertisement/capabilities-with-footprints 1256 /0/footprints/0/footprint-value/-", 1257 data: "value": "192.0.2.0/24" 1258 data: } 1259 data: ] 1261 6. Query Footprint Properties using ALTO Property Map Service 1263 Besides the requirement of retrieving footprints of given 1264 capabilities, another common requirement for uCDN is to query CDNI 1265 capabilities of given footprints. 1267 Considering each footprint as an entity with properties including 1268 CDNI capabilities, a natural way to satisfy this requirement is to 1269 use the ALTO property map as defined in 1270 [I-D.ietf-alto-unified-props-new]. This section describes how ALTO 1271 clients look up properties for individual footprints. First, it 1272 describes how to represent footprint objects as entities in the ALTO 1273 property map. Then it describes how to represent footprint 1274 capabilities as entity properties in the ALTO property map. Finally, 1275 it provides examples of the full property map and the filtered 1276 property map supporting CDNI capabilities, and their incremental 1277 updates. 1279 6.1. Representing Footprint Objects as Property Map Entities 1281 A footprint object has two properties: footprint-type and footprint- 1282 value. A footprint-value is an array of footprint values conforming 1283 to the specification associated with the registered footprint type 1284 ("ipv4cidr", "ipv6cidr", "asn", "countrycode", and "altopid"). 1285 Considering each ALTO entity defined in 1286 [I-D.ietf-alto-unified-props-new] also has two properties: entity 1287 domain type and domain-specific identifier, a straightforward 1288 approach to represent a footprint as an ALTO entity is to represent 1289 its footprint-type as an entity domain type, and its footprint value 1290 as a domain-specific identifier. 1292 Each existing footprint type can be represented as an entity domain 1293 type as follows: 1295 * According to [I-D.ietf-alto-unified-props-new], "ipv4" and "ipv6" 1296 are two predefined entity domain types, which can be used to 1297 represent "ipv4cidr" and "ipv6cidr" footprints respectively. Note 1298 that both "ipv4" and "ipv6" domains can include not only 1299 hierarchical addresses but also individual addresses. Therefore, 1300 a "ipv4cidr" or "ipv6cidr" footprint with the longest prefix can 1301 also be represented by an individual address entity. When the 1302 uCDN receives a property map with individual addresses in an 1303 "ipv4" or "ipv6" domain, it can translate them as corresponding 1304 "ipv4cidr" or "ipv6cidr" footprints with the longest prefix. 1306 * "pid" is also a predefined entity domain type, which can be used 1307 to represent "altopid" footprints. Note that "pid" is a resource- 1308 specific entity domain. To represent an "altopid" footprint, the 1309 specifying information resource of the corresponding "pid" entity 1310 domain MUST be the dependent network map used by the CDNI 1311 Advertisement resource providing this "altopid" footprint. 1313 * However, no existing entity domain type can represent "asn" and 1314 "countrycode" footprints. To represent footprint-type "asn" and 1315 "countrycode", this document registers two new entity domains in 1316 Section 7 in addition to the ones in 1317 [I-D.ietf-alto-unified-props-new]. 1319 Here is an example of representing a footprint object of "ipv4cidr" 1320 type as a set of "ipv4" entities in the ALTO property map. The 1321 representation of the footprint object of "ipv6cidr" type is similar. 1323 { "footprint-type": "ipv4cidr", 1324 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 1325 } --> "ipv4:192.0.2.0/24", "ipv4:198.51.100.0/24" 1327 And here is an example of corresponding footprint object of 1328 "ipv4cidr" type represented by an individual address in an "ipv4" 1329 domain in the ALTO property map. The translation of the entities in 1330 an "ipv6" domain is similar. 1332 "ipv4:203.0.113.100" --> { 1333 "footprint-type": "ipv4cidr", 1334 "footprint-value": ["203.0.113.100/32"] 1335 } 1337 6.1.1. ASN Domain 1339 The ASN domain associates property values with Autonomous Systems in 1340 the Internet. 1342 6.1.1.1. Entity Domain Type 1344 The entity domain type of the ASN domain is "asn" (in lowercase). 1346 6.1.1.2. Domain-Specific Entity Identifiers 1348 The entity identifier of an entity in an ASN domain MUST be encoded 1349 as a string consisting of the characters "as" (in lowercase) followed 1350 by the ASN [RFC6793] as a decimal number without leading zeros. 1352 6.1.1.3. Hierarchy and Inheritance 1354 There is no hierarchy or inheritance for properties associated with 1355 ASN. 1357 6.1.2. COUNTRYCODE Domain 1359 The COUNTRYCODE domain associates property values with countries. 1361 6.1.2.1. Entity Domain Type 1363 The entity domain type of the COUNTRYCODE domain is "countrycode" (in 1364 lowercase). 1366 6.1.2.2. Domain-Specific Entity Identifiers 1368 The entity identifier of an entity in a COUNTRYCODE domain is encoded 1369 as an ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1371 6.1.2.3. Hierarchy and Inheritance 1373 There is no hierarchy or inheritance for properties associated with 1374 country codes. 1376 6.2. Representing CDNI Capabilities as Property Map Entity Properties 1378 This document defines a new entity property type called "cdni- 1379 capabilities". An ALTO server can provide a property map resource 1380 mapping the "cdni-capablities" entity property type for a CDNI 1381 Advertisement resource that it provides to an "ipv4", "ipv6", "asn" 1382 or "countrycode" entity domain. 1384 6.2.1. Defining Information Resource Media Type for Property Type cdni- 1385 capabilities 1387 The entity property type "cdni-capabilities" allows defining 1388 resource-specific entity properties. When resource-specific entity 1389 properties are defined with entity property type "cdni-capabilities", 1390 the defining information resource for a "cdni-capabilities" property 1391 MUST be a CDNI Advertisement resource provided by the ALTO server. 1392 The media type of the defining information resource for a "cdni- 1393 capabilities" property is therefore: 1395 application/alto-cdni+json 1397 6.2.2. Intended Semantics of Property Type cdni-capabilities 1399 A "cdni-capabilities" property for an entity is to indicate all the 1400 CDNI capabilities that a corresponding CDNI Advertisement resource 1401 provides for the footprint represented by this entity. Thus, the 1402 value of a "cdni-capabilities" property MUST be a JSON array. Each 1403 element in a "cdni-capabilities" property MUST be an JSON object as 1404 format of CDNICapability (see Section 5.3). The value of a "cdni- 1405 capabilities" property for an "ipv4", "ipv6", "asn", "countrycode" or 1406 "altopid" entity MUST include all the CDNICapability objects 1407 satisfying the following conditions: (1) they are provided by the 1408 defining CDNI Advertisement resource; and (2) the represented 1409 footprint object of this entity is in their footprint restrictions. 1411 6.3. Examples 1413 The following examples use the same IRD example given by 1414 Section 3.7.1. 1416 6.3.1. Property Map 1418 This example shows a full property map in which entities are 1419 footprints and entities' property is "cdni-capabilities". 1421 GET /propmap/full/cdnifci HTTP/1.1 1422 Host: alto.example.com 1423 Accept: application/alto-propmap+json,application/alto-error+json 1425 HTTP/1.1 200 OK 1426 Content-Length: 1522 1427 Content-Type: application/alto-propmap+json 1429 { 1430 "property-map": { 1431 "meta": { 1432 "dependent-vtags": [ 1433 { "resource-id": "my-default-cdnifci", 1434 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1435 ] 1436 }, 1437 "countrycode:us": { 1438 "my-default-cdnifci.cdni-capabilities": [ 1439 { "capability-type": "FCI.DeliveryProtocol", 1440 "capability-value": { 1441 "delivery-protocols": ["http/1.1"]}}] 1442 }, 1443 "ipv4:192.0.2.0/24": { 1444 "my-default-cdnifci.cdni-capabilities": [ 1445 { "capability-type": "FCI.DeliveryProtocol", 1446 "capability-value": { 1447 "delivery-protocols": ["http/1.1"]}}] 1448 }, 1449 "ipv4:198.51.100.0/24": { 1450 "my-default-cdnifci.cdni-capabilities": [ 1451 { "capability-type": "FCI.DeliveryProtocol", 1452 "capability-value": { 1453 "delivery-protocols": ["https/1.1", "http/1.1"]}}] 1454 }, 1455 "ipv4:203.0.113.0/24": { 1456 "my-default-cdnifci.cdni-capabilities": [ 1457 { "capability-type": "FCI.AcquisitionProtocol", 1458 "capability-value": { 1459 "acquisition-protocols": ["http/1.1"]}}] 1460 }, 1461 "ipv6:2001:db8::/32": { 1462 "my-default-cdnifci.cdni-capabilities": [ 1463 { "capability-type": "FCI.DeliveryProtocol", 1464 "capability-value": { 1465 "delivery-protocols": ["http/1.1"]}}] 1466 }, 1467 "asn:as64496": { 1468 "my-default-cdnifci.cdni-capabilities": [ 1469 { "capability-type": "FCI.DeliveryProtocol", 1470 "capability-value": { 1471 "delivery-protocols": ["https/1.1", "http/1.1"]}}] 1472 } 1473 } 1474 } 1476 6.3.2. Filtered Property Map 1478 This example uses the filtered property map service to get "pid" and 1479 "cdni-capabilities" properties for two footprints "ipv4:192.0.2.0/24" 1480 and "ipv6:2001:db8::/32". 1482 POST /propmap/lookup/cdnifci-pid HTTP/1.1 1483 Host: alto.example.com 1484 Content-Type: application/alto-propmapparams+json 1485 Accept: application/alto-propmap+json,application/alto-error+json 1486 Content-Length: 181 1488 { 1489 "entities": [ 1490 "ipv4:192.0.2.0/24", 1491 "ipv6:2001:db8::/32" 1492 ], 1493 "properties": [ "my-default-cdnifci.cdni-capabilities", 1494 "my-default-networkmap.pid" ] 1495 } 1497 HTTP/1.1 200 OK 1498 Content-Length: 796 1499 Content-Type: application/alto-propmap+json 1501 { 1502 "property-map": { 1503 "meta": { 1504 "dependent-vtags": [ 1505 {"resource-id": "my-default-cdnifci", 1506 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}, 1507 {"resource-id": "my-default-networkmap", 1508 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1509 ] 1510 }, 1511 "ipv4:192.0.2.0/24": { 1512 "my-default-cdnifci.cdni-capabilities": [ 1513 {"capability-type": "FCI.DeliveryProtocol", 1514 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1515 "my-default-networkmap.pid": "pid1" 1516 }, 1517 "ipv6:2001:db8::/32": { 1518 "my-default-cdnifci.cdni-capabilities": [ 1519 {"capability-type": "FCI.DeliveryProtocol", 1520 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1521 "my-default-networkmap.pid": "pid3" 1522 } 1523 } 1524 } 1526 6.3.3. Incremental Updates 1528 In this example, the ALTO client is interested in updates for the 1529 properties "cdni-capabilities" and "pid" of two footprints 1530 "ipv4:192.0.2.0/24" and "countrycode:fr". 1532 POST /updates/properties HTTP/1.1 1533 Host: alto.example.com 1534 Accept: text/event-stream,application/alto-error+json 1535 Content-Type: application/alto-updatestreamparams+json 1536 Content-Length: 339 1538 { 1539 "add": { 1540 "fci-propmap-stream": { 1541 "resource-id": "filtered-cdnifci-property-map", 1542 "input": { 1543 "properties": [ "my-default-cdnifci.cdni-capabilities", 1544 "my-default-networkmap.pid" ], 1545 "entities": [ "ipv4:192.0.2.0/24", 1546 "ipv6:2001:db8::/32" ] 1547 } 1548 } 1549 } 1550 } 1552 HTTP/1.1 200 OK 1553 Connection: keep-alive 1554 Content-Type: text/event-stream 1556 event: application/alto-updatestreamcontrol+json 1557 data: {"control-uri": 1558 data: "https://alto.example.com/updates/streams/1414213562373"} 1560 event: application/alto-cdni+json,fci-propmap-stream 1561 data: { ... filtered property map ... } 1563 event: application/merge-patch+json,fci-propmap-stream 1564 data: { 1565 data: "property-map": { 1566 data: "meta": { 1567 data: "dependent-vtags": [ 1568 data: { "resource-id": "my-default-cdnifci", 1569 data: "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"}, 1570 data: { "resource-id": "my-default-networkmap", 1571 data: "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1572 data: ] 1573 data: }, 1574 data: "ipv4:192.0.2.0/24": { 1575 data: "my-default-cdnifci.cdni-capabilities": [ 1576 data: { "capability-type": "FCI.DeliveryProtocol", 1577 data: "capability-value": { 1578 data: "delivery-protocols": ["http/1.1", "https/1.1"]}}] 1579 data: } 1580 data: } 1581 data: } 1583 event: application/json-patch+json,fci-propmap-stream 1584 data: [ 1585 data: { "op": "replace", 1586 data: "path": "/meta/dependent-vtags/0/tag", 1587 data: "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4" 1588 data: }, 1589 data: { "op": "replace", 1590 data: "path": 1591 data: "/property-map/countrycode:fr/my-default-networkmap.pid", 1592 data: "value": "pid5" 1593 data: } 1594 data: ] 1596 7. IANA Considerations 1598 This document defines two new media types: "application/alto- 1599 cdni+json", as described in Section 7.1, and "application/ 1600 cdnifilter+json", as described in Section 7.2. It also defines a new 1601 CDNI metadata footprint type (Section 7.3), two new ALTO entity 1602 domain types (Section 7.4), and a new ALTO entity property type 1603 (Section 7.5). 1605 7.1. application/alto-cdni+json Media Type 1607 Type name: 1608 application 1610 Subtype name: 1611 alto-cdni+json 1613 Required parameters: 1614 N/A 1616 Optional parameters: 1617 N/A 1619 Encoding considerations: 1620 Encoding considerations are identical to those specified for the 1621 "application/json" media type. See [RFC8259]. 1623 Security considerations: 1624 Security considerations related to the generation and consumption 1625 of ALTO Protocol messages are discussed in Section 15 of 1626 [RFC7285]. 1628 Interoperability considerations: 1629 N/A 1631 Published specification: 1632 Section 3 of RFCthis 1634 Applications that use this media type: 1635 ALTO servers and ALTO clients [RFC7285] either stand alone or are 1636 embedded within other applications that provides CDNI interfaces 1637 for uCDNs or dCDNs. 1639 Fragment identifier considerations: 1640 N/A 1642 Additional information: 1643 Magic number(s): N/A 1645 File extension(s): N/A 1647 Macintosh file type code(s): N/A 1649 Person & email address to contact for further information: 1650 See Authors' Addresses section. 1652 Intended usage: 1653 COMMON 1655 Restrictions on usage: 1656 N/A 1658 Author: 1659 See Authors' Addresses section. 1661 Change controller: 1662 Internet Engineering Task Force (mailto:iesg@ietf.org). 1664 7.2. application/alto-cdnifilter+json Media Type 1666 Type name: 1667 application 1669 Subtype name: 1670 alto-cdnifilter+json 1672 Required parameters: 1673 N/A 1675 Optional parameters: 1676 N/A 1678 Encoding considerations: 1679 Encoding considerations are identical to those specified for the 1680 "application/json" media type. See [RFC8259]. 1682 Security considerations: 1683 Security considerations related to the generation and consumption 1684 of ALTO Protocol messages are discussed in Section 15 of 1685 [RFC7285]. 1687 Interoperability considerations: 1688 N/A 1690 Published specification: 1691 Section 5 of RFCthis 1693 Applications that use this media type: 1694 ALTO servers and ALTO clients [RFC7285] either stand alone or are 1695 embedded within other applications that provides CDNI interfaces 1696 for uCDNs or dCDNs and supports CDNI capability-based filtering. 1698 Fragment identifier considerations: 1699 N/A 1701 Additional information: 1702 Magic number(s): N/A 1704 File extension(s): N/A 1706 Macintosh file type code(s): N/A 1708 Person & email address to contact for further information: 1709 See Authors' Addresses section. 1711 Intended usage: 1712 COMMON 1714 Restrictions on usage: 1715 N/A 1717 Author: 1718 See Authors' Addresses section. 1720 Change controller: 1721 Internet Engineering Task Force (mailto:iesg@ietf.org). 1723 7.3. CDNI Metadata Footprint Type Registry 1725 This document updates the CDNI Metadata Footprint Types Registry 1726 created by Section 7.2 of [RFC8006]. A new footprint type is to be 1727 registered, listed in Table 1. 1729 +================+=====================+======================+ 1730 | Footprint Type | Description | Specification | 1731 +================+=====================+======================+ 1732 | altopid | A list of PID names | Section 4 of RFCthis | 1733 +----------------+---------------------+----------------------+ 1735 Table 1: CDNI Metadata Footprint Type 1737 [RFC Editor: Please replace RFCthis with the published RFC number for 1738 this document.] 1740 7.4. ALTO Entity Domain Type Registry 1742 This document updates the ALTO Entity Domain Type Registry created by 1743 Section 11.2 of [I-D.ietf-alto-unified-props-new]. Two new entity 1744 domain types are to be registered, listed in Table 2. 1746 +=============+============+=============+=============+=========+ 1747 | Identifier | Entity | Hierarchy & | Media Type | Mapping | 1748 | | Address | Inheritance | of Defining | to ALTO | 1749 | | Encoding | | Resource | Address | 1750 | | | | | Type | 1751 +=============+============+=============+=============+=========+ 1752 | asn | See | None | None | false | 1753 | | Section | | | | 1754 | | 6.1.1.2 of | | | | 1755 | | RFCthis | | | | 1756 +-------------+------------+-------------+-------------+---------+ 1757 | countrycode | See | None | None | false | 1758 | | Section | | | | 1759 | | 6.1.2.2 of | | | | 1760 | | RFCthis | | | | 1761 +-------------+------------+-------------+-------------+---------+ 1763 Table 2: Additional ALTO Entity Domain Types 1765 [RFC Editor: Please replace RFCthis with the published RFC number for 1766 this document.] 1768 7.5. ALTO Entity Property Type Registry 1770 This document updates the ALTO Entity Property Type Registry created 1771 by Section 11.3 of [I-D.ietf-alto-unified-props-new]. A new entity 1772 property type is to be registered, listed in Table 3. 1774 +===================+====================+===================+ 1775 | Identifier | Intended Semantics | Media Type of | 1776 | | | Defining Resource | 1777 +===================+====================+===================+ 1778 | cdni-capabilities | Section 6.2 of | application/alto- | 1779 | | RFCthis | cdni+json | 1780 +-------------------+--------------------+-------------------+ 1782 Table 3: Additional ALTO Entity Property Type 1784 [RFC Editor: Please replace RFCthis with the published RFC number for 1785 this document.] 1787 8. Security Considerations 1789 As an extension of the base ALTO protocol [RFC7285], this document 1790 fits into the architecture of the base protocol. And hence Security 1791 Considerations of the base protocol (Section 15 of [RFC7285]) fully 1792 apply when this extension is provided by an ALTO server. 1794 In the context of CDNI Advertisement, the following security risk 1795 scenarios should be considered: 1797 * For authenticity and integrity of ALTO information, an attacker 1798 may disguise itself as an ALTO server for a dCDN (e.g., by 1799 starting a man-in-the-middle attack), and provide false 1800 capabilities and footprints to a uCDN using the CDNI Advertisement 1801 service. Such false information may lead a uCDN to (1) select an 1802 incorrect dCDN to serve user requests, or (2) skip uCDNs in good 1803 conditions. To address this risk, protection strategies in 1804 Section 15.1.2 of [RFC7285] can be applied. 1806 * For potential undesirable guidance from authenticated ALTO 1807 information, a dCDN can provide a uCDN with limited capabilities 1808 and smaller footprint coverage so that the dCDN can avoid 1809 transferring traffic for a uCDN which they should have to 1810 transfer. To reduce this risk, the protection strategies in 1811 Section 15.2.2 of [RFC7285] can be considered. 1813 * For confidentiality and privacy of ALTO information, footprint 1814 properties integrated with ALTO property maps may expose network 1815 location identifiers (e.g., IP addresses or fine-grained PIDs). 1817 To address this risk, the protection strategy for risk types (1) 1818 and (3) as described in Section 15.3 of [RFC7285] can be 1819 considered. 1821 * For availability of ALTO services, an attacker may conduct service 1822 degradation attacks using services defined in this document to 1823 disable ALTO services of a network. It may request potentially 1824 large, full CDNI Advertisement resources from an ALTO server in a 1825 dCDN continuously, to consume the bandwidth resources of that ALTO 1826 server. It may also query filtered property map services with 1827 many smaller individual footprints, to consume the computation 1828 resources of the ALTO server. To mitigate these risks, the 1829 protection strategies in Section 15.5.2 of [RFC7285] can be 1830 applied. 1832 Although protection strategies as described in Section 15 of 1833 [RFC7285] should be applied to address aforementioned security and 1834 privacy considerations, two special cases need to be included as 1835 follows: 1837 * As required by section 7 of [RFC8008], 1839 "All protocols that implement these capabilities and footprint 1840 advertisement objects are REQUIRED to provide integrity and 1841 authentication services." 1843 Therefore, the uCDN (ALTO Client) MUST be authenticated to the 1844 dCDN (ALTO Server). And the dCDN (ALTO Server) MUST support HTTP 1845 Digest Authentication and MAY also support TLS mutual 1846 authentication. The authentication method will need to be 1847 negotiated out of band and is out of scope for this document, as 1848 is the approach for provisioning and managing these credentials. 1850 * One specific information leakage risk introduced by this document 1851 could not be addressed by these strategies. In particular, if a 1852 dCDN signs agreements with multiple uCDNs without any isolation, 1853 this dCDN may disclose extra information of one uCDN to another 1854 one. In that case, one uCDN may redirect requests which should 1855 not have to be served by this dCDN to it. 1857 To reduce the risk, a dCDN SHOULD isolate full/filtered CDNI 1858 Advertisement resources for different uCDNs. It could consider 1859 generating URIs of different full/filtered CDNI Advertisement 1860 resources by hashing its company ID, a uCDN's company ID as well 1861 as their agreements. A dCDN SHOULD avoid exposing all full/ 1862 filtered CDNI Advertisement resources in one of its IRDs. 1864 9. References 1865 9.1. Normative References 1867 [I-D.ietf-alto-unified-props-new] 1868 Roome, W., Randriamasy, S., Yang, Y. R., Zhang, J. J., and 1869 K. Gao, "An ALTO Extension: Entity Property Maps", Work in 1870 Progress, Internet-Draft, draft-ietf-alto-unified-props- 1871 new-22, 25 January 2022, 1872 . 1875 [ISO3166-1] 1876 ISO (International Organization for Standardization), ., 1877 "ISO 3166-1: Codes for the representation of names of 1878 countries and their subdivisions -- Part 1: Country 1879 codes", 2020. 1881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1882 Requirement Levels", BCP 14, RFC 2119, 1883 DOI 10.17487/RFC2119, March 1997, 1884 . 1886 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1887 Autonomous System (AS) Number Space", RFC 6793, 1888 DOI 10.17487/RFC6793, December 2012, 1889 . 1891 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1892 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1893 "Application-Layer Traffic Optimization (ALTO) Protocol", 1894 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1895 . 1897 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 1898 DOI 10.17487/RFC7493, March 2015, 1899 . 1901 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1902 "Content Delivery Network Interconnection (CDNI) 1903 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1904 . 1906 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1907 R., and K. Ma, "Content Delivery Network Interconnection 1908 (CDNI) Request Routing: Footprint and Capabilities 1909 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1910 . 1912 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1913 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1914 May 2017, . 1916 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1917 Interchange Format", STD 90, RFC 8259, 1918 DOI 10.17487/RFC8259, December 2017, 1919 . 1921 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 1922 Optimization (ALTO) Incremental Updates Using Server-Sent 1923 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 1924 2020, . 1926 9.2. Informative References 1928 [I-D.ietf-alto-path-vector] 1929 Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J. 1930 Zhang, "An ALTO Extension: Path Vector", Work in Progress, 1931 Internet-Draft, draft-ietf-alto-path-vector-21, 2 February 1932 2022, . 1935 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1936 Optimization (ALTO) Problem Statement", RFC 5693, 1937 DOI 10.17487/RFC5693, October 2009, 1938 . 1940 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1941 Distribution Network Interconnection (CDNI) Problem 1942 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1943 2012, . 1945 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1946 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1947 Deployment Considerations", RFC 7971, 1948 DOI 10.17487/RFC7971, October 2016, 1949 . 1951 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1952 "Request Routing Redirection Interface for Content 1953 Delivery Network (CDN) Interconnection", RFC 7975, 1954 DOI 10.17487/RFC7975, October 2016, 1955 . 1957 Acknowledgments 1959 The authors thank Matt Caulfield, Danny Alex Lachos Perez, Daryl 1960 Malas and Sanjay Mishra for their timely reviews and invaluable 1961 comments. Big thanks also to ALTO WG Chairs (Qin Wu and Vijay 1962 Gurbani), and all the directorate reviewers and IESG reviewers 1963 (Martin Duke, Erik Kline, Martin Vigoureux, Murray Kucherawy, Roman 1964 Danyliw, Zaheduzzaman Sarker, Eric Vyncke, and Francesca Palombini), 1965 for their thorough reviews, discussions, guidance and shepherding, 1966 that further improve this document. 1968 Jan Seedorf has been partially supported by the GreenICN project 1969 (GreenICN: Architecture and Applications of Green Information Centric 1970 Networking), a research project supported jointly by the European 1971 Commission under its 7th Framework Program (contract no. 608518) and 1972 the National Institute of Information and Communications Technology 1973 (NICT) in Japan (contract no. 167). The views and conclusions 1974 contained herein are those of the authors and should not be 1975 interpreted as necessarily representing the official policies or 1976 endorsements, either expressed or implied, of the GreenICN project, 1977 the European Commission, or NICT. 1979 This document has also been supported by the Coordination Support 1980 Action entitled 'Supporting European Experts Presence in 1981 lnternational Standardisation Activities in ICT' ("StandlCT.eu") 1982 funded by the European Commission under the Horizon 2020 Programme 1983 with Grant Agreement no. 780439. The views and conclusions contained 1984 herein are those of the authors and should not be interpreted as 1985 necessarily representing the official policies or endorsements, 1986 either expressed or implied, of the European Commission. 1988 Contributors 1990 Xiao Shawn Lin 1991 Huawei 1992 2222 Newjinqiao Rd 1993 Shanghai 1994 200125 1995 China 1996 Phone: +86-15316812351 1997 Email: x.shawn.lin@gmail.com 1999 Authors' Addresses 2000 Jan Seedorf 2001 HFT Stuttgart - Univ. of Applied Sciences 2002 Schellingstrasse 24 2003 70174 Stuttgart 2004 Germany 2005 Phone: +49-0711-8926-2801 2006 Email: jan.seedorf@hft-stuttgart.de 2008 Y. Richard Yang 2009 Yale University 2010 51 Prospect Street 2011 New Haven, CT 06511 2012 United States of America 2013 Phone: +1-203-432-6400 2014 Email: yry@cs.yale.edu 2015 URI: http://www.cs.yale.edu/~yry/ 2017 Kevin J. Ma 2018 Ericsson 2019 43 Nagog Park 2020 Acton, MA 01720 2021 United States of America 2022 Phone: +1-978-844-5100 2023 Email: kevin.j.ma.ietf@gmail.com 2025 Jon Peterson 2026 NeuStar 2027 1800 Sutter St Suite 570 2028 Concord, CA 94520 2029 United States of America 2030 Email: jon.peterson@neustar.biz 2032 Jingxuan Jensen Zhang 2033 Tongji University 2034 4800 Cao'an Hwy 2035 Shanghai 2036 201804 2037 China 2038 Email: jingxuan.zhang@tongji.edu.cn