idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-10.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 382: '...The "uses" field SHOULD NOT appear unl...' RFC 2119 keyword, line 385: '... resources MUST be included into the...' RFC 2119 keyword, line 393: '...DNI FCI response MUST include the "vta...' RFC 2119 keyword, line 398: '... MUST include the "dependent-vtags" ...' RFC 2119 keyword, line 438: '...Object, the ALTO client MUST interpret...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2020) is 1522 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) == Missing Reference: 'RFC7336' is mentioned on line 24, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' ** Downref: Normative reference to an Informational RFC: RFC 5693 ** Downref: Normative reference to an Informational RFC: RFC 6707 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-20 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-09 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-10 Summary: 4 errors (**), 0 flaws (~~), 5 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: August 27, 2020 Tongji/Yale 6 K. Ma 7 Ericsson 8 J. Peterson 9 Neustar 10 J. Zhang 11 Tongji 12 February 24, 2020 14 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 15 Footprint and Capabilities Advertisement using ALTO 16 draft-ietf-alto-cdni-request-routing-alto-10 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 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 27, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Semantics of FCI Advertisement . . . . . . . . . . . . . 5 69 2.2. ALTO Background and Benefits . . . . . . . . . . . . . . 6 70 3. CDNI FCI Service . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 8 74 3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 75 3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.7.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 11 79 3.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 14 80 3.7.3. Incremental Updates Example . . . . . . . . . . . . . 15 81 4. CDNI FCI Service using ALTO Network Map . . . . . . . . . . . 17 82 4.1. Network Map Footprint Type: altopid . . . . . . . . . . . 17 83 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.2.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 17 85 4.2.2. ALTO Network Map for CDNI FCI Footprints Example . . 18 86 4.2.3. ALTO PID Footprints in CDNI FCI . . . . . . . . . . . 18 87 4.2.4. Incremental Updates Example . . . . . . . . . . . . . 19 88 5. Filtered CDNI FCI using Capabilities . . . . . . . . . . . . 21 89 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 21 90 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 21 91 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 21 92 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 22 93 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 22 95 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 96 5.7.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 23 97 5.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 23 98 5.7.3. Incremental Updates Example . . . . . . . . . . . . . 25 99 6. Query Footprint Properties using ALTO Property Map Service . 26 100 6.1. Representing Footprint Objects as Property Map Entities . 27 101 6.1.1. ASN Domain . . . . . . . . . . . . . . . . . . . . . 27 102 6.1.2. COUNTRYCODE Domain . . . . . . . . . . . . . . . . . 28 103 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28 104 6.2.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 28 105 6.2.2. Property Map Example . . . . . . . . . . . . . . . . 28 106 6.2.3. Filtered Property Map Example . . . . . . . . . . . . 30 107 6.2.4. Incremental Updates Example . . . . . . . . . . . . . 32 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 109 7.1. CDNI Metadata Footprint Type Registry . . . . . . . . . . 33 110 7.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 34 111 7.3. ALTO Entity Property Type Registry . . . . . . . . . . . 34 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 113 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 116 10.2. Informative References . . . . . . . . . . . . . . . . . 36 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 119 1. Introduction 121 The ability to interconnect multiple content delivery networks (CDNs) 122 has many benefits, including increased coverage, capability, and 123 reliability. The Content Delivery Networks Interconnection (CDNI) 124 framework [RFC6707] defines four interfaces to achieve the 125 interconnection of CDNs: (1) the CDNI Request Routing Interface; (2) 126 the CDNI Metadata Interface; (3) the CDNI Logging Interface; and (4) 127 the CDNI Control Interface. 129 Among the four interfaces, the CDNI Request Routing Interface 130 provides key functions, as specified in [RFC6707]: "The CDNI Request 131 Routing interface enables a Request Routing function in an Upstream 132 CDN to query a Request Routing function in a Downstream CDN to 133 determine if the Downstream CDN is able (and willing) to accept the 134 delegated Content Request. It also allows the Downstream CDN to 135 control what should be returned to the User Agent in the redirection 136 message by the upstream Request Routing function." At a high level, 137 the scope of the CDNI Request Routing Interface, therefore, contains 138 two main tasks: (1) determining if the dCDN (downstream CDN) is 139 willing to accept a delegated content request, and (2) redirecting 140 the content request coming from a uCDN (upstream CDN) to the proper 141 entry point or entity in the dCDN. 143 Correspondingly, the request routing interface is broadly divided 144 into two functionalities: (1) the CDNI Footprint & Capabilities 145 Advertisement interface (FCI) defined in [RFC8008], and (2) the CDNI 146 Request Routing Redirection interface (RI) defined in [RFC7975]. 147 Since this document focuses on the first functionality (CDNI FCI), 148 below is more details about it. 150 Specifically, CDNI FCI allows both an advertisement from a dCDN to a 151 uCDN (push) and a query from a uCDN to a dCDN (pull) so that the uCDN 152 knows whether it can redirect a particular user request to that dCDN. 154 A key component in defining CDNI FCI is defining objects describing 155 the footprints and capabilities of a dCDN. Such objects are already 156 defined in [RFC8008]. A protocol to transport and update such 157 objects between a uCDN and a dCDN, however, is not defined. Hence, 158 the scope of this document is to define such a protocol by 159 introducing a new Application-Layer Traffic Optimization (ALTO) 160 [RFC7285] service called "CDNI FCI Service". 162 There are multiple benefits in using ALTO as a transport protocol, as 163 discussed in Section 2.2. 165 The rest of this document is organized as follows. Section 2 166 provides non-normative background on both CDNI FCI and ALTO. 167 Section 3 introduces the most basic service, called "CDNI FCI 168 Service", to realize CDNI FCI using ALTO. Section 4 demonstrates a 169 key benefit of using ALTO: the ability to integrate CDNI FCI with 170 ALTO network maps. Such integration provides new granularity to 171 describe footprints. Section 5 introduces "Filtered CDNI FCI 172 Service" to allow a uCDN to get footprints with given capabilities 173 instead of getting the full resource, which can be large. Section 6 174 further shows another benefit of using ALTO: the ability to query 175 footprint properties using ALTO unified properties. In this way, a 176 uCDN can effectively fetch capabilities of footprints in which it is 177 interested. IANA and security considerations are discussed in 178 Section 7 and Section 8 respectively. 180 2. Background 182 The design of CDNI FCI transport using ALTO depends on the 183 understanding of both FCI semantics and ALTO. Hence, this document 184 starts with a non-normative review for both. The review uses the 185 terminologies for CDNI as defined in [RFC6707], [RFC8006] and 186 [RFC8008]; those for ALTO as defined in [RFC7285] and [I-D.ietf-alto- 187 unified-props-new]. 189 2.1. Semantics of FCI Advertisement 191 [RFC8008] (CDNI "Footprint and Capabilities Semantics") defines the 192 semantics of CDNI FCI, provides guidance on what Footprint and 193 Capabilities mean in a CDNI context, and specifies the requirements 194 on the CDNI FCI transport protocol. The definitions in [RFC8008] 195 depend on [RFC8006]. Below is a non-normative review of key related 196 points of [RFC8008] and [RFC8006]. For detailed information and 197 normative specification, the reader is referred to these two RFCs. 199 o Multiple types of mandatory-to-implement footprints (ipv4cidr, 200 ipv6cidr, asn, and countrycode) are defined in [RFC8006]. A "Set 201 of IP-prefixes" can contain both full IP addresses (i.e., a /32 202 for IPv4 or a /128 for IPv6) and IP prefixes with an arbitrary 203 prefix length. There must also be support for multiple IP address 204 versions, i.e., IPv4 and IPv6, in such a footprint. 206 o Multiple "base" capabilities are defined [TODO: which RFC]. By 207 "base" capabilities, they are required in all cases and therefore 208 constitute mandatory capabilities to be supported by the CDNI FCI: 209 (1) Delivery Protocol, (2) Acquisition Protocol, (3) Redirection 210 Mode, (4) Capabilities related to CDNI Logging, and (5) 211 Capabilities related to CDNI Metadata. 213 o Footprint and capabilities are defined together and cannot be 214 interpreted independently from each other. Specifically, 215 [RFC8008] integrates footprint and capabilities with an approach 216 of "capabilities with footprint restrictions", by expressing 217 capabilities on a per footprint basis. 219 o Specifically, for all mandatory-to-implement footprint types, 220 footprints can be viewed as constraints for delegating requests to 221 a dCDN: A dCDN footprint advertisement tells the uCDN the 222 limitations for delegating a request to the dCDN. For IP prefixes 223 or ASN(s), the footprint signals to the uCDN that it should 224 consider the dCDN a candidate only if the IP address of the 225 request routing source falls within the prefix set (or ASN, 226 respectively). The CDNI specifications do not define how a given 227 uCDN determines what address ranges are in a particular ASN. 228 Similarly, for country codes, a uCDN should only consider the dCDN 229 a candidate if it covers the country of the request routing 230 source. The CDNI specifications do not define how a given uCDN 231 determines the country of the request routing source. Multiple 232 footprint constraints are additive, i.e., the advertisement of 233 different types of footprint narrows the dCDN candidacy 234 cumulatively. 236 o Given that a large part of Footprint and Capabilities 237 Advertisement may actually happen in contractual agreements, the 238 semantics of CDNI Footprint and Capabilities advertisement refers 239 to answering the following question: what exactly still needs to 240 be advertised by the CDNI FCI? For instance, updates about 241 temporal failures of part of a footprint can be useful information 242 to convey via the CDNI FCI. Such information would provide 243 updates on information previously agreed in contracts between the 244 participating CDNs. In other words, the CDNI FCI is a means for a 245 dCDN (downstream CDN) to provide changes/updates regarding a 246 footprint and/or capabilities that it has prior agreed to serve in 247 a contract with a uCDN (upstream CDN). Hence, server push and 248 incremental encoding will be necessary techniques. 250 2.2. ALTO Background and Benefits 252 Application-Layer Traffic Optimization (ALTO) [RFC7285] defines an 253 approach for conveying network layer (topology) information to 254 "guide" the resource provider selection process in distributed 255 applications that can choose among several candidate resources 256 providers to retrieve a given resource. Usually, it is assumed that 257 an ALTO server conveys information that these applications cannot 258 measure or have difficulty measuring themselves [RFC5693]. 260 Originally, ALTO was motivated by optimizing cross-ISP traffic 261 generated by P2P applications [RFC5693]. However, ALTO can also be 262 used for improving the request routing in CDNs. In particular, the 263 CDNI problem statement [RFC6707] explicitly mentions ALTO as a 264 candidate protocol for "actual algorithms for selection of CDN or 265 Surrogate by Request-Routing systems". 267 The following reasons make ALTO a suitable candidate protocol for 268 dCDN (downstream CDN) selection as part of CDNI request routing and, 269 in particular, for an FCI protocol: 271 o ALTO is a protocol specifically designed to improve application 272 layer traffic (and application layer connections among hosts on 273 the Internet) by providing additional information to applications 274 that these applications could not easily retrieve themselves. 275 This matches the need of CDNI: a uCDN wants to improve application 276 layer CDN request routing by using information (provided by a 277 dCDN) that the uCDN could not easily obtain otherwise. Hence, 278 ALTO can help a uCDN to select a proper dCDN by first providing 279 dCDNs' capabilities as well as footprints (see Section 3) and then 280 providing costs of surrogates in a dCDN by ALTO cost maps. 282 o The semantics of an ALTO network map is an exact match for the 283 needed information to convey a footprint by a dCDN, in particular, 284 if such a footprint is being expressed by IP-prefix ranges. 285 Please see Section 4. 287 o Security: The identification between uCDNs and dCDNs is an 288 important requirement. ALTO maps can be signed and hence provide 289 inherent integrity protection. Please see Section 8. 291 o RESTful-Design: The ALTO protocol has undergone extensive 292 revisions in order to provide a RESTful design regarding the 293 client-server interaction specified by the protocol. A CDNI FCI 294 interface based on ALTO would inherit this RESTful design. Please 295 see Section 3. 297 o Error-handling: The ALTO protocol provides extensive error- 298 handling in the whole request and response process (see 299 Section 8.5 of [RFC7285]). A CDNI FCI interface based on ALTO 300 would inherit this this extensive error-handling framework. 301 Please see Section 5. 303 o Filtered map service: The ALTO map filtering service would allow a 304 uCDN to query only for parts of an ALTO map. For example, the 305 ALTO filtered property map service can enable a uCDN to query 306 properties of a part of footprints efficiently (see Section 6). 308 o Server-initiated Notifications and Incremental Updates: When the 309 footprint or the capabilities of a dCDN change (i.e., unexpectedly 310 from the perspective of a uCDN), server-initiated notifications 311 would enable a dCDN to inform a uCDN about such changes directly. 312 Consider the case where - due to failure - part of the footprint 313 of the dCDN is not functioning, i.e., the CDN cannot serve content 314 to such clients with reasonable QoS. Without server-initiated 315 notifications, the uCDN might still use a recent network and cost 316 map from the dCDN, and therefore redirect requests to the dCDN 317 which it cannot serve. Similarly, the possibility for incremental 318 updates would enable efficient conveyance of the aforementioned 319 (or similar) status changes by the dCDN to the uCDN. The newest 320 design of ALTO supports server pushed incremental updates 321 [I-D.ietf-alto-incr-update-sse]. 323 o Content Availability on Hosts: A dCDN might want to express CDN 324 capabilities in terms of certain content types (e.g., codecs/ 325 formats, or content from certain content providers). The new 326 endpoint property for ALTO would enable a dCDN to make such 327 information available to a uCDN. This would enable a uCDN to 328 determine whether a dCDN actually has the capabilities for a given 329 type of content requested. 331 o Resource Availability on Hosts or Links: The capabilities on links 332 (e.g., maximum bandwidth) or caches (e.g., average load) might be 333 useful information for a uCDN for optimized dCDN selection. For 334 instance, if a uCDN receives a streaming request for content with 335 a certain bitrate, it needs to know if it is likely that a dCDN 336 can fulfill such stringent application-level requirements (i.e., 337 can be expected to have enough consistent bandwidth) before it 338 redirects the request. In general, if ALTO could convey such 339 information via new endpoint properties, it would enable more 340 sophisticated means for dCDN selection with ALTO. ALTO Path 341 Vector Extension [I-D.ietf-alto-path-vector] is designed to allow 342 ALTO clients to query information such as capacity regions for a 343 given set of flows. 345 3. CDNI FCI Service 347 The ALTO protocol is based on an ALTO Information Service Framework 348 which consists of several services, where all ALTO services are 349 "provided through a common transport protocol, messaging structure 350 and encoding, and transaction model" [RFC7285]. The ALTO protocol 351 specification [RFC7285] defines several such services, e.g., the ALTO 352 map service. 354 This document defines a new ALTO Service called "CDNI FCI Service" 355 which conveys JSON objects of media type "application/alto- 356 cdnifci+json". These JSON objects are used to transport 357 BaseAdvertisementObject objects defined in [RFC8008]; this document 358 specifies how to transport such BaseAdvertisementObject objects via 359 the ALTO protocol with the ALTO "CDNI FCI Service". Similar to other 360 ALTO services, this document defines the ALTO information resource 361 for the "CDNI FCI Service" as follows. 363 3.1. Media Type 365 The media type of the CDNI FCI resource is "application/alto- 366 cdnifci+json". 368 3.2. HTTP Method 370 A CDNI FCI resource is requested using the HTTP GET method. 372 3.3. Accept Input Parameters 374 None. 376 3.4. Capabilities 378 None. 380 3.5. Uses 382 The "uses" field SHOULD NOT appear unless the CDNI FCI resource 383 depends on some ALTO information resources. If the CDNI FCI resource 384 has some dependent resources, the resource IDs of its dependent 385 resources MUST be included into the "uses" field. This document only 386 defines one potential dependent resource for the CDNI FCI resource. 387 See Section 4 for details of when and how to use it. Future 388 documents may extend the CDNI FCI resource and allow other dependent 389 resources. 391 3.6. Response 393 The "meta" field of a CDNI FCI response MUST include the "vtag" field 394 defined in Section 10.3 of [RFC7285]. This field provides the 395 version of the retrieved CDNI FCI resource. 397 If a CDNI FCI response depends on an ALTO information resource, it 398 MUST include the "dependent-vtags" field, whose value is an array to 399 indicate the version tags of the resources used, where each resource 400 is specified in "uses" of its IRD entry. 402 The data component of an ALTO CDNI FCI response is named "cdni-fci", 403 which is a JSON object of type CDNIFCIData: 405 object { 406 CDNIFCIData cdni-fci; 407 } InfoResourceCDNIFCI : ResponseEntityBase; 409 object { 410 BaseAdvertisementObject capabilities<1..*>; 411 } CDNIFCIData; 413 Specifically, a CDNIFCIData object is a JSON object that includes 414 only one property named "capabilities", whose value is an array of 415 BaseAdvertisementObject objects. 417 The syntax and semantics of BaseAdvertisementObject are well defined 418 in Section 5.1 of [RFC8008]. A BaseAdvertisementObject object 419 includes multiple properties, including capability-type, capability- 420 value, and footprints, where footprints are defined in 421 Section 4.2.2.2 of [RFC8006]. 423 To be self-contained, below is a non-normative specification of 424 BaseAdvertisementObject. As mentioned above, the normative 425 specification of BaseAdvertisementObject is in [RFC8008] 427 object { 428 JSONString capability-type; 429 JSONValue capability-value; 430 Footprint footprints<0..*>; 431 } BaseAdvertisementObject; 433 object { 434 JSONString footprint-type; 435 JSONString footprint-value<1..*>; 436 } Footprint; 438 For each BaseAdvertisementObject, the ALTO client MUST interpret 439 footprints appearing multiple times as if they appeared only once. 440 If footprints in a BaseAdvertisementObject is null or empty or not 441 appearing, the ALTO client MUST understand that the capabilities in 442 this BaseAdvertisementObject have the "global" coverage. 444 Note: Further optimization of BaseAdvertisement objects to 445 effectively provide the advertisement of capabilities with footprint 446 restrictions is certainly possible. For example, these two examples 447 below both describe that the dCDN can provide capabilities 448 ["http/1.1", "https/1.1"] for the same footprints. However, the 449 latter one is smaller in its size. 451 EXAMPLE 1 452 { 453 "meta" : {...}, 454 "cdni-fci": { 455 "capabilities": [ 456 { 457 "capability-type": "FCI.DeliveryProtocol", 458 "capability-value": { 459 "delivery-protocols": [ 460 "http/1.1" 461 ] 462 }, 463 "footprints": [ 464 465 ] 466 }, 467 { 469 "capability-type": "FCI.DeliveryProtocol", 470 "capability-value": { 471 "delivery-protocols": [ 472 "https/1.1" 473 ] 474 }, 475 "footprints": [ 476 477 ] 478 } 479 ] 480 } 481 } 483 EXAMPLE 2 484 { 485 "meta" : {...}, 486 "cdni-fci": { 487 "capabilities": [ 488 { 489 "capability-type": "FCI.DeliveryProtocol", 490 "capability-value": { 491 "delivery-protocols": [ 492 "https/1.1", 493 "http/1.1" 494 ] 495 }, 496 "footprints": [ 497 498 ] 499 } 500 ] 501 } 502 } 504 Since such optimizations are not required for the basic 505 interconnection of CDNs, the specifics of such mechanisms are outside 506 the scope of this document. 508 3.7. Examples 510 3.7.1. IRD Example 512 Below is the information resource directory (IRD) of a simple, 513 example ALTO server. The server provides both base ALTO information 514 resources (e.g., network maps) and CDNI FCI related information 515 resources (e.g., CDNI FCI resource), demonstrating a single, 516 integrated environment. 518 Specifically, the IRD announces two network maps, one CDNI FCI 519 resource without dependency, one CDNI FCI resource depending on a 520 network map, one filtered CDNI FCI resource to be defined in 521 Section 5, one property map including "cdni-fci-capabilities" as its 522 entity property, one filtered property map including "cdni-fci- 523 capabilities" and "pid" as its entity properties, and two update 524 stream services (one for updating CDNI FCI resources, and the other 525 for updating property maps). 527 GET /directory HTTP/1.1 528 Host: alto.example.com 529 Accept: application/alto-directory+json,application/alto-error+json 531 { 532 "meta" : { ... }, 533 "resources": { 534 "my-default-network-map": { 535 "uri" : "http://alto.example.com/networkmap", 536 "media-type" : "application/alto-networkmap+json" 537 }, 538 "my-eu-netmap" : { 539 "uri" : "http://alto.example.com/myeunetmap", 540 "media-type" : "application/alto-networkmap+json" 541 }, 542 "my-default-cdnifci": { 543 "uri" : "http://alto.example.com/cdnifci", 544 "media-type": "application/alto-cdnifci+json" 545 }, 546 "my-cdnifci-with-pid-footprints": { 547 "uri" : "http://alto.example.com/networkcdnifci", 548 "media-type" : "application/alto-cdnifci+json", 549 "uses" : [ "my-eu-netmap" ] 550 }, 551 "my-filtered-cdnifci" : { 552 "uri" : "http://alto.example.com/cdnifci/filtered", 553 "media-type" : "application/alto-cdnifci+json", 554 "accepts" : "application/alto-cdnifcifilter+json", 555 "uses" : [ "my-default-cdnifci" ] 556 }, 557 "cdnifci-property-map" : { 558 "uri" : "http://alto.example.com/propmap/full/cdnifci", 559 "media-type" : "application/alto-propmap+json", 560 "uses": [ "my-default-cdni" ], 561 "capabilities" : { 562 "mappings": { 563 "ipv4": [ "my-default-cdni.cdni-fci-capabilities" ], 564 "ipv6": [ "my-default-cdni.cdni-fci-capabilities" ], 565 "countrycode": [ 566 "my-default-cdni.cdni-fci-capabilities" ], 567 "asn": [ "my-default-cdni.cdni-fci-capabilities" ], 568 } 569 } 570 }, 571 "filtered-cdnifci-property-map" : { 572 "uri" : "http://alto.example.com/propmap/lookup/cdnifci-pid", 573 "media-type" : "application/alto-propmap+json", 574 "accepts" : "application/alto-propmapparams+json", 575 "uses": [ "my-default-cdni", "my-default-network-map" ], 576 "capabilities" : { 577 "mappings": { 578 "ipv4": [ "my-default-cdni.cdni-fci-capabilities", 579 "my-default-network-map.pid" ], 580 "ipv6": [ "my-default-cdni.cdni-fci-capabilities", 581 "my-default-network-map.pid" ], 582 "countrycode": [ 583 "my-default-cdni.cdni-fci-capabilities" ], 584 "asn": [ "my-default-cdni.cdni-fci-capabilities" ], 585 } 586 } 587 }, 588 "update-my-cdni-fci" : { 589 "uri": "http:///alto.example.com/updates/cdnifci", 590 "media-type" : "text/event-stream", 591 "accepts" : "application/alto-updatestreamparams+json", 592 "uses" : [ 593 "my-default-network-map", 594 "my-eu-netmap", 595 "my-default-cdnifci", 596 "my-filtered-cdnifci" 597 "my-cdnifci-with-pid-footprints" 598 ], 599 "capabilities" : { 600 "incremental-change-media-types" : { 601 "my-default-network-map" : "application/json-patch+json", 602 "my-eu-netmap" : "application/json-patch+json", 603 "my-default-cdnifci" : 604 "application/merge-patch+json,application/json-patch+json", 605 "my-filtered-cdnifci" : 606 "application/merge-patch+json,application/json-patch+json", 607 "my-cdnifci-with-pid-footprints" : 608 "application/merge-patch+json,application/json-patch+json" 609 } 610 } 611 }, 612 "update-my-props": { 613 "uri" : "http://alto.example.com/updates/properties", 614 "media-type" : "text/event-stream", 615 "uses" : [ 616 "cdnifci-property-map", 617 "filtered-cdnifci-property-map" 618 ], 619 "capabilities" : { 620 "incremental-change-media-types": { 621 "cdnifci-property-map" : 622 "application/merge-patch+json,application/json-patch+json", 623 "filtered-cdnifci-property-map": 624 "application/merge-patch+json,application/json-patch+json" 625 } 626 } 627 } 628 } 629 } 631 3.7.2. Basic Example 633 This basic example demonstrates a simple CDNI FCI resource, which 634 does not depend on other resources. There are three 635 BaseAdvertisementObjects in this resource and these objects' 636 capabilities are http/1.1 delivery protocol, [http/1.1, https/1.1] 637 delivery protocol, and https/1.1 acquisition protocol, respectively. 639 GET /cdnifci HTTP/1.1 640 Host: alto.example.com 641 Accept: application/alto-cdnifci+json, 642 application/alto-error+json 644 HTTP/1.1 200 OK 645 Content-Length: XXX 646 Content-Type: application/alto-cdnifci+json 647 { 648 "meta" : { 649 "vtag": { 650 "resource-id": "my-default-cdnifci", 651 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 652 } 653 }, 654 "cdni-fci": { 655 "capabilities": [ 656 { 657 "capability-type": "FCI.DeliveryProtocol", 658 "capability-value": { 659 "delivery-protocols": [ 660 "http/1.1" 661 ] 663 }, 664 "footprints": [ 665 666 ] 667 }, 668 { 669 "capability-type": "FCI.DeliveryProtocol", 670 "capability-value": { 671 "delivery-protocols": [ 672 "https/1.1", 673 "http/1.1" 674 ] 675 }, 676 "footprints": [ 677 678 ] 679 }, 680 { 681 "capability-type": "FCI.AcquisitionProtocol", 682 "capability-value": { 683 "acquisition-protocols": [ 684 "https/1.1" 685 ] 686 }, 687 "footprints": [ 688 689 ] 690 } 691 ] 692 } 693 } 695 3.7.3. Incremental Updates Example 697 A benefit of using ALTO to provide CDNI FCI resources is that such 698 resources can be updated using ALTO incremental updates. Below is an 699 example that also shows the benefit of having both JSON merge patch 700 and JSON patch to encode updates. 702 At first, an ALTO client requests updates for "my-default-cdnifci", 703 and the ALTO server returns the "control-uri" followed by the full 704 CDNI FCI response. Then when there is a change in the delivery- 705 protocols in that `http/1.1` is removed (from http/1.1 and https/1.1 706 to only https/1.1) due to maintenance of the https/1.1 clusters, the 707 ALTO server uses JSON merge patch to encode the change and pushes the 708 change to the ALTO client. Later on, the ALTO server notifies the 709 ALTO client that "192.0.2.0/24" is added into the "ipv4" footprint 710 object for delivery-protocol https/1.1 by sending the change encoded 711 by JSON patch to the ALTO client. 713 POST /updates/cdnifci HTTP/1.1 714 Host: alto.example.com 715 Accept: text/event-stream,application/alto-error+json 716 Content-Type: application/alto-updatestreamparams+json 717 Content-Length: ### 719 { "add": { 720 "my-cdnifci-stream": { 721 "resource-id": "my-default-cdnifci" 722 } 723 } 725 HTTP/1.1 200 OK 726 Connection: keep-alive 727 Content-Type: text/event-stream 729 event: application/alto-updatestreamcontrol+json 730 data: {"control-uri": 731 data: "http://alto.example.com/updates/streams/3141592653589"} 733 event: application/alto-cdnifci+json,my-default-cdnifci 734 data: { ... full CDNI FCI map ... } 736 event: application/merge-patch+json,my-default-cdnifci 737 data: { 738 data: "meta": { 739 data: "vtag": { 740 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 741 data: } 742 data: }, 743 data: "cdni-fci": { 744 data: "capabilities": [ 745 data: { 746 data: "capability-type": "FCI.DeliveryProtocol", 747 data: "capability-value": { 748 data: "delivery-protocols": [ 749 data: "https/1.1" 750 data: ] 751 data: }, 752 data: "footprints": [ 753 data: 754 data: ] 755 data: } 756 data: ] 757 data: } 758 data: } 760 event: application/json-patch+json,my-default-cdnifci 761 data: [ 762 data: { "op": "replace", 763 data: "path": "/meta/vtag/tag", 764 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 765 data: }, 766 data: { "op": "add", 767 data: "path": 768 data: "/cdni-fci/capabilities/1/footprints/0/footprint-value/-", 769 data: "value": "192.0.2.0/24" 770 data: } 771 data: ] 773 4. CDNI FCI Service using ALTO Network Map 775 4.1. Network Map Footprint Type: altopid 777 The ALTO protocol defines a concept called PID to represent a group 778 of IPv4 or IPv6 addresses which can be applied the same management 779 policy. The PID is an alternative to the pre-defined CDNI footprint 780 types (i.e., ipv4cidr, ipv6cidr, asn, and countrycode). 782 Specifically, a CDNI FCI resource can depend on an ALTO network map 783 resource and use a new CDNI Footprint Type called "altopid" to 784 compress its CDNI Footprint Payload. 786 Specifically, the "altopid" footprint type indicates that the 787 corresponding footprint value is a list of PIDNames as defined in 788 [RFC7285]. These PIDNames are references of PIDs in a network map 789 resource. Hence a CDNI FCI with "altopid" footprints depends on a 790 network map. For such a CDNI FCI map, the resource id of its 791 dependent network map MUST be included in the "uses" field of its IRD 792 entry, and the "dependent-vtag" field with a reference to this 793 network map MUST be included in its response (see the example in 794 Section 4.2.3). 796 4.2. Examples 798 4.2.1. IRD Example 800 The examples below use the same IRD given in Section 3.7.1. 802 4.2.2. ALTO Network Map for CDNI FCI Footprints Example 804 Below is an example network map whose resource id is "my-eu-netmap", 805 and this map is referenced by the CDNI FCI example in Section 4.2.3. 807 GET /networkmap HTTP/1.1 808 Host: http://alto.example.com/myeunetmap 809 Accept: application/alto-networkmap+json,application/alto-error+json 811 HTTP/1.1 200 OK 812 Content-Length: XXX 813 Content-Type: application/alto-networkmap+json 815 { 816 "meta" : { 817 "vtag": [ 818 {"resource-id": "my-eu-netmap", 819 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 820 } 821 ] 822 }, 823 "network-map" : { 824 "south-france" : { 825 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] 826 }, 827 "germany" : { 828 "ipv4" : [ "192.0.3.0/24"] 829 } 830 } 831 } 833 4.2.3. ALTO PID Footprints in CDNI FCI 835 This example shows a CDNI FCI resource that depends on a network map 836 described in Section 4.2.2. 838 GET /networkcdnifci HTTP/1.1 839 Host: alto.example.com 840 Accept: application/alto-cdnifci+json,application/alto-error+json 842 HTTP/1.1 200 OK 843 Content-Length: 618 844 Content-Type: application/alto-cdnifci+json 846 { 847 "meta" : { 848 "dependent-vtags" : [ 849 { 850 "resource-id": "my-eu-netmap", 851 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 852 } 853 ] 854 }, 855 "cdni-fci": { 856 "capabilities": [ 857 { "capability-type": "FCI.DeliveryProtocol", 858 "capability-value": [ 859 "http/1.1" 860 ] 861 }, 862 { "capability-type": "FCI.DeliveryProtocol", 863 "capability-value": [ 864 "https/1.1" 865 ], 866 "footprints": [ 867 { "footprint-type": "altopid", 868 "footprint-value": [ 869 "germany", 870 "south-france" 871 ] 872 } 873 ] 874 } 875 ] 876 } 877 } 879 4.2.4. Incremental Updates Example 881 In this example, the ALTO client is interested in changes of "my- 882 cdnifci-with-pid-footprints". Considering two changes, the first one 883 is to change footprints of http/1.1 Delivery Protocol capability, and 884 the second one is to remove "south-france" from the footprints of 885 https/1.1 delivery protocol capability. 887 POST /updates/cdnifci HTTP/1.1 888 Host: alto.example.com 889 Accept: text/event-stream,application/alto-error+json 890 Content-Type: application/alto-updatestreamparams+json 891 Content-Length: ### 893 { "add": { 894 "my-network-map-cdnifci-stream": { 895 "resource-id": "my-cdnifci-with-pid-footprints" 896 } 897 } 899 HTTP/1.1 200 OK 900 Connection: keep-alive 901 Content-Type: text/event-stream 903 event: application/alto-updatestreamcontrol+json 904 data: {"control-uri": 905 data: "http://alto.example.com/updates/streams/3141592653590"} 907 event: application/alto-cdnifci+json,my-fci-stream 908 data: { ... full CDNI FCI resource ... } 910 event: application/merge-patch+json,my-fci-stream 911 data: { 912 data: "meta": { 913 data: "dependent-vtags" : [ 914 data: { 915 data: "resource-id": "my-eu-netmap", 916 data: "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 917 data: } 918 data: ], 919 data: "vtag": { 920 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 921 data: } 922 data: }, 923 data: { 924 data: "capability-type": "FCI.DeliveryProtocol", 925 data: "capability-value": { 926 data: "delivery-protocols": [ 927 data: "http/1.1" 928 data: ] 929 data: }, 930 data: "footprints": [ 931 data: 932 data: ] 933 data: } 934 data: } 935 event: application/json-patch+json,my-fci-stream 936 data: [ 938 data: { 939 data: "op": "replace", 940 data: "path": "/meta/vtag/tag", 941 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 942 data: }, 943 data: { "op": "remove", 944 data: "path": "/cdni-fci/capabilities/2/footprints/0/ 945 data: footprint-value/1", 946 data: } 947 data: ] 949 5. Filtered CDNI FCI using Capabilities 951 Section 3 and Section 4 describe CDNI FCI Service which can be used 952 to enable a uCDN to get capabilities with footprints constraints from 953 dCDNs. However, since always getting full CDNI FCI resources from 954 dCDNs is inefficient, this document introduces a new service named 955 "Filtered CDNI FCI Service", to allow a client to filter a CDNI FCI 956 resource using a client-given set of capabilities. For each entry of 957 the CDNI FCI response, an entry will only be returned to the client 958 if it contains at least one of the client given capabilities. The 959 relationship between a filtered CDNI FCI resource and a CDNI FCI 960 resource is similar to the relationship between a filtered network/ 961 cost map and a network/cost map. 963 5.1. Media Type 965 A filtered CDNI FCI resource uses the same media type defined for the 966 CDNI FCI resource in Section 3.1. 968 5.2. HTTP Method 970 A filtered CDNI FCI resource is requested using the HTTP POST method. 972 5.3. Accept Input Parameters 974 The input parameters for a filtered CDNI FCI resource are supplied in 975 the entity body of the POST request. This document specifies the 976 input parameters with a data format indicated by the media type 977 "application/alto-cdnifcifilter+json" which is a JSON object of type 978 ReqFilteredCDNIFCI, where: 980 object { 981 JSONString capability-type; 982 JSONValue capability-value; 983 } CDNIFCICapability; 985 object { 986 [CDNIFCICapability cdni-fci-capabilities<0..*>;] 987 } ReqFilteredCDNIFCI; 989 with fields: 991 capability-type: The same as Base Advertisement Object's capability- 992 type defined in Section 5.1 of [RFC8008]. 994 capability-value: The same as Base Advertisement Object's 995 capability-value defined in Section 5.1 of [RFC8008]. 997 cdni-fci-capabilities: A list of CDNI FCI capabilities defined in 998 Section 5.1 of [RFC8008] for which footprints are to be returned. 999 If a list is empty or not appearing, the ALTO server MUST 1000 interpret it as a request for the full CDNI FCI resource. The 1001 ALTO server MUST interpret entries appearing in a list multiple 1002 times as if they appeared only once. If the ALTO server does not 1003 define any footprints for a CDNI capability, it MUST omit this 1004 capability from the response. 1006 5.4. Capabilities 1008 None. 1010 5.5. Uses 1012 The resource ID of the CDNI FCI resource based on which the filtering 1013 is performed. 1015 5.6. Response 1017 The response MUST indicate an error, using ALTO protocol error 1018 handling specified in Section 8.5 of the ALTO protocol [RFC7285], if 1019 the request is invalid. 1021 Specifically, a filtered CDNI FCI request is invalid if: 1023 o the value of "capability-type" is null; 1025 o the value of "capability-value" is null; 1026 o the value of "capability-value" is inconsistent with "capability- 1027 type". 1029 When a request is invalid, the ALTO server MUST return an 1030 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], 1031 and the "value" field of the error message SHOULD indicate this CDNI 1032 FCI capability. 1034 The ALTO server returns a filtered CDNI FCI resource for a valid 1035 request. The format of a filtered CDNI FCI resource is the same as a 1036 full CDNI FCI resource (See Section 3.6.) 1038 The returned CDNI FCI resource MUST contain only 1039 BaseAdvertisementObject objects whose CDNI capability object is the 1040 superset of one of CDNI capability object in "cdni-fci-capabilities". 1041 Specifically, that a CDNI capability object A is the superset of 1042 another CDNI capability object B means that these two CDNI capability 1043 objects have the same capability type and mandatory properties in 1044 capability value of A MUST include mandatory properties in capability 1045 value of B semantically. See Section 5.7.2 for a concrete example. 1047 The version tag included in the "vtag" field of the response MUST 1048 correspond to the full CDNI FCI resource from which the filtered CDNI 1049 FCI resource is provided. This ensures that a single, canonical 1050 version tag is used independently of any filtering that is requested 1051 by an ALTO client. 1053 5.7. Examples 1055 5.7.1. IRD Example 1057 The examples below use the same IRD example as in Section 3.7.1. 1059 5.7.2. Basic Example 1061 This example filters the full CDNI FCI resource in Section 3.7.2 by 1062 selecting only the http/1.1 delivery protocol capability. Only the 1063 first two BaseAdvertisementObjects in the full resource will be 1064 returned because the first object's capability is http/1.1 delivery 1065 protocol and the second object's capability is http/1.1 and https/1.1 1066 delivery protocols which is the superset of http/1.1 delivery 1067 protocol. 1069 POST /cdnifci/filtered HTTP/1.1 1070 HOST: alto.example.com 1071 Content-Type: application/cdnifilter+json 1072 Accept: application/alto-cdnifci+json 1073 { 1074 "cdni-fci-capabilities": [ 1075 { 1076 "capability-type": "FCI.DeliveryProtocol", 1077 "capability-value": { 1078 "delivery-protocols": [ 1079 "http/1.1" 1080 ] 1081 } 1082 } 1083 ] 1084 } 1086 HTTP/1.1 200 OK 1087 Content-Length: XXX 1088 Content-Type: application/alto-cdnifci+json 1089 { 1090 "meta" : { 1091 "vtag": { 1092 "resource-id": "my-default-cdnifci", 1093 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 1094 } 1095 }, 1096 "cdni-fci": { 1097 "capabilities": [ 1098 { 1099 "capability-type": "FCI.DeliveryProtocol", 1100 "capability-value": { 1101 "delivery-protocols": [ 1102 "http/1.1" 1103 ] 1104 }, 1105 "footprints": [ 1106 1107 ] 1108 }, 1109 { 1110 "capability-type": "FCI.DeliveryProtocol", 1111 "capability-value": { 1112 "delivery-protocols": [ 1113 "https/1.1", 1114 "http/1.1" 1115 ] 1116 }, 1117 "footprints": [ 1118 1119 ] 1120 } 1122 ] 1123 } 1124 } 1126 5.7.3. Incremental Updates Example 1128 In this example, the ALTO client only cares about the updates of one 1129 Delivery Protocol object whose value is "http/1.1". So it adds its 1130 limitation of capabilities in "input" field of the POST request. 1132 POST /updates/cdnifci HTTP/1.1 1133 Host: fcialtoupdate.example.com 1134 Accept: text/event-stream,application/alto-error+json 1135 Content-Type: application/alto-updatestreamparams+json 1136 Content-Length: ### 1138 { "add": { 1139 "my-fci-stream": { 1140 "resource-id": "my-filtered-cdnifci", 1141 "input": { 1142 "cdni-fci-capabilities": [ 1143 { 1144 "capability-type": "FCI.DeliveryProtocol", 1145 "capability-value": { 1146 "delivery-protocols": [ 1147 "http/1.1" 1148 ] 1149 } 1150 } 1151 ] 1152 } 1153 } 1154 } 1155 } 1157 HTTP/1.1 200 OK 1158 Connection: keep-alive 1159 Content-Type: text/event-stream 1161 event: application/alto-updatestreamcontrol+json 1162 data: {"control-uri": 1163 data: "http://alto.example.com/updates/streams/3141592653590"} 1165 event: application/alto-cdnifci+json,my-fci-stream 1166 data: { ... full filtered CDNI FCI resource ... } 1168 event: application/merge-patch+json,my-fci-stream 1169 data: { 1170 data: "meta": { 1171 data: "vtag": { 1172 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 1173 data: } 1174 data: }, 1175 data: { 1176 data: "capability-type": "FCI.DeliveryProtocol", 1177 data: "capability-value": { 1178 data: "delivery-protocols": [ 1179 data: "http/1.1" 1180 data: ] 1181 data: }, 1182 data: "footprints": [ 1183 data: 1184 data: ] 1185 data: } 1186 data: } 1188 event: application/json-patch+json,my-fci-stream 1189 data: [ 1190 data: { 1191 data: "op": "replace", 1192 data: "path": "/meta/vtag/tag", 1193 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1194 data: }, 1195 data: { "op": "add", 1196 data: "path": "/cdni-fci/capabilities/0/footprints/-", 1197 data: "value": "ipv4:192.0.2.0/24" 1198 data: } 1199 data: ] 1201 6. Query Footprint Properties using ALTO Property Map Service 1203 Besides the requirement of retrieving footprints of given 1204 capabilities, another common requirement for uCDN is to query CDNI 1205 capabilities of given footprints. 1207 Considering each footprint as an entity with properties including 1208 CDNI capabilities, a natural way to satisfy this requirement is to 1209 use the ALTO property map as defined in 1210 [I-D.ietf-alto-unified-props-new]. This section describes how ALTO 1211 clients look up properties for individual footprints. First, it 1212 describes how to represent footprint objects as entities in the ALTO 1213 property map. Second, it provides examples of the full property map 1214 and the filtered property map supporting CDNI capabilities, and their 1215 incremental updates. 1217 6.1. Representing Footprint Objects as Property Map Entities 1219 A footprint object has two properties: footprint-type and footprint- 1220 value. A footprint-value is an array of footprint values conforming 1221 to the specification associated with the registered footprint type 1222 ("ipv4cidr", "ipv6cidr", "asn", and "countrycode"). Considering each 1223 ALTO entity defined in [I-D.ietf-alto-unified-props-new] also has two 1224 properties: entity domain type and domain-specific identifier, a 1225 straightforward approach to represent a footprint as an ALTO entity 1226 is to regard its footprint-type as an entity domain type, and its 1227 footprint value as a domain-specific identifier. According to 1228 [I-D.ietf-alto-unified-props-new], "ipv4" and "ipv6" are two 1229 predefined entity domain types, which can be used to represent 1230 "ipv4cidr" and "ipv6cidr" footprints respectively. However, no 1231 existing entity domain type can represent "asn" and "countrycode" 1232 footprints. To represent footprint-type "asn" and "countrycode", 1233 this document registers two new domains in Section 7 in addition to 1234 the ones in [I-D.ietf-alto-unified-props-new]. 1236 Here is an example of representing a footprint object as a set of 1237 entities in the ALTO property map. 1239 {"footprint-type": "ipv4cidr", "footprint-value": ["192.0.2.0/24", 1240 "198.51.100.0/24"]} --> "ipv4:192.168.2.0/24", "ipv4:198.51.100.0/24" 1242 6.1.1. ASN Domain 1244 The ASN domain associates property values with Autonomous Systems in 1245 the Internet. 1247 6.1.1.1. Entity Domain Type 1249 asn 1251 6.1.1.2. Domain-Specific Entity Identifiers 1253 The entity identifier of an entity in an asn domain is encoded as a 1254 string consisting of the characters "as" (in lowercase) followed by 1255 the Autonomous System Number [RFC6793]. 1257 6.1.1.3. Hierarchy and Inheritance 1259 There is no hierarchy or inheritance for properties associated with 1260 ASN. 1262 6.1.2. COUNTRYCODE Domain 1264 The COUNTRYCODE domain associates property values with countries. 1266 6.1.2.1. Entity Domain Type 1268 countrycode 1270 6.1.2.2. Domain-Specific Entity Identifiers 1272 The entity identifier of an entity in a countrycode domain is encoded 1273 as an ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1275 6.1.2.3. Hierarchy and Inheritance 1277 There is no hierarchy or inheritance for properties associated with 1278 country codes. 1280 6.2. Examples 1282 6.2.1. IRD Example 1284 The examples use the same IRD example given by Section 3.7.1. 1286 6.2.2. Property Map Example 1288 This example shows a full property map in which entities are 1289 footprints and entities' property is "cdni-fci-capabilities". 1291 GET /propmap/full/cdnifci HTTP/1.1 1292 HOST: alto.example.com 1293 Accept: application/alto-propmap+json,application/alto-error+json 1295 HTTP/1.1 200 OK 1296 Content-Length: ### 1297 Content-Type: application/alto-propmap+json 1299 { 1300 "property-map": { 1301 "meta": { 1302 "dependent-vtags": [ 1303 {"resource-id": "my-default-cdnifci", 1304 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1305 ] 1306 }, 1307 "countrycode:us": { 1308 "my-default-cdnifci.cdni-fci-capabilities": [ 1309 {"capability-type": "FCI.DeliveryProtocol", 1310 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1311 }, 1312 "ipv4:192.0.2.0/24": { 1313 "my-default-cdnifci.cdni-fci-capabilities": [ 1314 {"capability-type": "FCI.DeliveryProtocol", 1315 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1316 }, 1317 "ipv4:198.51.100.0/24": { 1318 "my-default-cdnifci.cdni-fci-capabilities": [ 1319 {"capability-type": "FCI.DeliveryProtocol", 1320 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1321 }, 1322 "ipv6:2001:db8::/32": { 1323 "my-default-cdnifci.cdni-fci-capabilities": [ 1324 {"capability-type": "FCI.DeliveryProtocol", 1325 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1326 }, 1327 "asn:as64496": { 1328 "my-default-cdnifci.cdni-fci-capabilities": [ 1329 {"capability-type": "FCI.DeliveryProtocol", 1330 "capability-value": {"delivery-protocols": ["http/1.1", 1331 "https/1.1"]}}] 1332 } 1333 } 1334 } 1336 6.2.3. Filtered Property Map Example 1338 This example uses the filtered property map service to get "pid" and 1339 "cdni-fci-capabilities" properties for two footprints 1340 "ipv4:192.0.2.0/24" and "ipv6:2001:db8::/32". 1342 POST /propmap/lookup/cdnifci-pid HTTP/1.1 1343 HOST: alto.example.com 1344 Content-Type: application/alto-propmapparams+json 1345 Accept: application/alto-propmap+json,application/alto-error+json 1346 Content-Length: 1348 { 1349 "entities": [ 1350 "ipv4:192.0.2.0/24", 1351 "ipv6:2001:db8::/32" 1352 ], 1353 "properties": [ "my-default-cdnifci.cdni-fci-capabilities", 1354 "my-default-networkmap.pid" ] 1355 } 1357 HTTP/1.1 200 OK 1358 Content-Length: ### 1359 Content-Type: application/alto-propmap+json 1361 { 1362 "property-map": { 1363 "meta": { 1364 "dependent-vtags": [ 1365 {"resource-id": "my-default-cdnifci", 1366 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}, 1367 {"resource-id": "my-default-networkmap", 1368 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1369 ] 1370 }, 1371 "ipv4:192.0.2.0/24": { 1372 "my-default-cdnifci.cdni-fci-capabilities": [ 1373 {"capability-type": "FCI.DeliveryProtocol", 1374 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1375 "my-default-networkmap.pid": "pid1" 1376 }, 1377 "ipv6:2001:db8::/32": { 1378 "my-default-cdnifci.cdni-fci-capabilities": [ 1379 {"capability-type": "FCI.DeliveryProtocol", 1380 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1381 "my-default-networkmap.pid": "pid3" 1382 } 1383 } 1384 } 1386 6.2.4. Incremental Updates Example 1388 In this example, here is a client want to request updates for the 1389 properties "cdni-fci-capabilities" and "pid" for two footprints 1390 "ipv4:192.0.2.0/24" and "countrycode:fr". 1392 POST /updates/properties HTTP/1.1 1393 Host: alto.example.com 1394 Accept: text/event-stream,application/alto-error+json 1395 Content-Type: application/alto-updatestreamparams+json 1396 Content-Length: ### 1398 { "add": { 1399 "property-map-including-capability-property": { 1400 "resource-id": "filtered-cdnifci-property-map", 1401 "input": { 1402 "properties": [ "my-default-cdnifci.cdni-fci-capabilities", 1403 "my-default-networkmap.pid" ], 1404 "entities": [ 1406 "ipv4:192.0.2.0/24", 1407 "ipv6:2001:db8::/32" 1408 ] 1409 } 1410 } 1411 } 1413 HTTP/1.1 200 OK 1414 Connection: keep-alive 1415 Content-Type: text/event-stream 1417 event: application/alto-updatestreamcontrol+json 1418 data: {"control-uri": 1419 data: "http://alto.example.com/updates/streams/1414213562373"} 1421 event: application/alto-cdnifci+json,my-fci-stream 1422 data: { ... full filtered unified property map ... } 1424 event: application/merge-patch+json,my-fci-stream 1425 data: { 1426 data: "property-map": 1427 data: { 1428 data: "meta": { 1429 data: "dependent-vtags": [ 1430 data: {"resource-id": "my-default-cdnifci", 1431 data: "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"}, 1432 data: {"resource-id": "my-default-networkmap", 1433 data: "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1434 data: ] 1435 data: }, 1436 data: "ipv4:192.0.2.0/24": 1437 data: { 1438 data: "my-default-cdnifci.cdni-fci-capabilities": [ 1439 data: {"capability-type": "FCI.DeliveryProtocol", 1440 data: "capability-value": { 1441 data: "delivery-protocols": ["http/1.1", "https/1.1"]}}] 1442 data: } 1443 data: } 1444 data: } 1446 event: application/json-patch+json,my-fci-stream 1447 data: {[ 1448 data: { 1449 data: { "op": "replace", 1450 data: "path": "/meta/dependent-vtags/0/tag", 1451 data: "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4" 1452 data: }, 1453 data: { "op": "replace", 1454 data: "path": 1455 data: "/property-map/countrycode:fr/my-default-networkmap.pid", 1456 data: "value": "pid5" 1457 data: } 1458 data: } 1459 data: ]} 1461 7. IANA Considerations 1463 7.1. CDNI Metadata Footprint Type Registry 1465 As proposed in Section 7.2 of [RFC8006], "CDNI Metadata Footprint 1466 Types" registry is requested. A new footprint type is to be 1467 registered, listed in Table 1. 1469 +----------------+---------------------+----------------------+ 1470 | Footprint Type | Description | Specification | 1471 +----------------+---------------------+----------------------+ 1472 | altopid | A list of PID-names | Section 4 of RFCthis | 1473 +----------------+---------------------+----------------------+ 1475 Table 1: CDNI Metadata Footprint Type 1477 [RFC Editor: Please replace RFCthis with the published RFC number for 1478 this document.] 1480 7.2. ALTO Entity Domain Type Registry 1482 As proposed in Section 11.2 of [I-D.ietf-alto-unified-props-new], 1483 "ALTO Entity Domain Type Registry" is requested. Two new entity 1484 domain types are to be registered, listed in Table 2. 1486 +-------------+-------------------------+-------------------------+ 1487 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1488 +-------------+-------------------------+-------------------------+ 1489 | asn | See Section 6.1.1.2 | None | 1490 | countrycode | See Section 6.1.2.2 | None | 1491 +-------------+-------------------------+-------------------------+ 1493 Table 2: ALTO Entity Domain Types 1495 7.3. ALTO Entity Property Type Registry 1497 As proposed in Section 11.3 of [I-D.ietf-alto-unified-props-new], 1498 "ALTO Entity Property Type Registry" is required. A new entity 1499 property type is to be registered, listed in Table 3. 1501 +-----------------------+-----------------------------------------+ 1502 | Identifier | Intended Semantics | 1503 +-----------------------+-----------------------------------------+ 1504 | cdni-fci-capabilities | An array of CDNI FCI capability objects | 1505 +-----------------------+-----------------------------------------+ 1507 Table 3: ALTO CDNI FCI Property Type 1509 8. Security Considerations 1511 As an extension of the base ALTO protocol ([RFC7285]), this document 1512 fits into the architecture of the base protocol. And hence its 1513 Security Considerations (Section 15 of [RFC7285]) fully apply when 1514 this extension is provided by an ALTO server. 1516 In the context of CDNI FCI, additional security considerations should 1517 be included as follows: 1519 For authenticity and integrity of ALTO information, an attacker may 1520 disguise itself as an ALTO server for a dCDN, and provide false 1521 capabilities and footprints to a uCDN using the CDNI FCI service. 1522 Such false information may lead a uCDN to (1) select an incorrect 1523 dCDN to serve user requests, or (2) skip uCDNs in good conditions. 1525 For potential undesirable guidance from authenticated ALTO 1526 information, a dCDN can provide a uCDN with limited capabilities and 1527 smaller footprint coverage so that the dCDN can avoid transferring 1528 traffic for a uCDN which they should have to transfer. 1530 For confidentiality and privacy of ALTO information, footprint 1531 properties integrated with ALTO unified property may expose network 1532 location identifiers (e.g., IP addresses or fine-grained PIDs). 1534 Without access control of ALTO services, an attacker may conduct 1535 service degradation attacks. It may request potentially large, full 1536 CDNI FCI resources from an ALTO server in a dCDN continuously, to 1537 consume the bandwidth resources of that ALTO server. It may also 1538 query filtered property map services with many smaller individual 1539 footprints, to consume the computation resources of the ALTO server. 1541 Protection strategies as described in RFC 7285 should be applied to 1542 address aforementioned security considerations. In addition, the 1543 isolation of full/filtered CDNI FCI resources should also be 1544 considered. In particular, if a dCDN signs agreements with multiple 1545 uCDNs, it must isolate full/ filtered CDNI FCI resources for 1546 different uCDNs in that uCDNs will not redirect requests which should 1547 not have to be served by this dCDN to this dCDN and it may not 1548 disclose extra information to uCDNs. 1550 One approach to reducing the risk is that a dCDN could consider 1551 generating URIs of different full/filtered CDNI FCI resources by 1552 hashing its company ID, a uCDN's company ID as well as their 1553 agreements. A dCDN SHOULD avoid exposing all full/filtered CDNI FCI 1554 resources in one of its IRDs. 1556 9. Acknowledgments 1558 The authors thank Matt Caulfield, Danny Alex Lachos Perez, Daryl 1559 Malas and Sanjay Mishra for their timely reviews and invaluable 1560 comments. Mr. Xiao Shawn Lin is an author of an early version of 1561 this document, with many contributions. 1563 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 1564 Architecture and Applications of Green Information Centric 1565 Networking), a research project supported jointly by the European 1566 Commission under its 7th Framework Program (contract no. 608518) and 1567 the National Institute of Information and Communications Technology 1568 (NICT) in Japan (contract no. 167). The views and conclusions 1569 contained herein are those of the authors and should not be 1570 interpreted as necessarily representing the official policies or 1571 endorsements, either expressed or implied, of the GreenICN project, 1572 the European Commission, or NICT. 1574 10. References 1576 10.1. Normative References 1578 [ISO3166-1] 1579 The International Organization for Standardization, "Codes 1580 for the representation of names of countries and their 1581 subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 1582 2013. 1584 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1585 Optimization (ALTO) Problem Statement", RFC 5693, DOI 1586 10.17487/RFC5693, October 2009, . 1589 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1590 Distribution Network Interconnection (CDNI) Problem 1591 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1592 2012, . 1594 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1595 Autonomous System (AS) Number Space", RFC 6793, DOI 1596 10.17487/RFC6793, December 2012, . 1599 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1600 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1601 "Application-Layer Traffic Optimization (ALTO) Protocol", 1602 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1603 . 1605 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1606 "Content Delivery Network Interconnection (CDNI) 1607 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1608 . 1610 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1611 R., and K. Ma, "Content Delivery Network Interconnection 1612 (CDNI) Request Routing: Footprint and Capabilities 1613 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1614 . 1616 10.2. Informative References 1618 [I-D.ietf-alto-incr-update-sse] 1619 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1620 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1621 sse-20 (work in progress), February 2020. 1623 [I-D.ietf-alto-path-vector] 1624 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 1625 "ALTO Extension: Path Vector", draft-ietf-alto-path- 1626 vector-09 (work in progress), November 2019. 1628 [I-D.ietf-alto-unified-props-new] 1629 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 1630 Gao, "Unified Properties for the ALTO Protocol", draft- 1631 ietf-alto-unified-props-new-10 (work in progress), 1632 November 2019. 1634 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1635 "Request Routing Redirection Interface for Content 1636 Delivery Network (CDN) Interconnection", RFC 7975, DOI 1637 10.17487/RFC7975, October 2016, . 1640 Authors' Addresses 1642 Jan Seedorf 1643 HFT Stuttgart - Univ. of Applied Sciences 1644 Schellingstrasse 24 1645 Stuttgart 70174 1646 Germany 1648 Phone: +49-0711-8926-2801 1649 Email: jan.seedorf@hft-stuttgart.de 1651 Y.R. Yang 1652 Yale University/PCL 1653 51 Prospect Street 1654 New Haven, CT 06511 1655 United States of America 1657 Email: yry@cs.yale.edu 1658 URI: http://www.cs.yale.edu/~yry/ 1660 Kevin J. Ma 1661 Ericsson 1662 43 Nagog Park 1663 Acton, MA 01720 1664 United States of America 1666 Phone: +1-978-844-5100 1667 Email: kevin.j.ma.ietf@gmail.com 1668 Jon Peterson 1669 NeuStar 1670 1800 Sutter St Suite 570 1671 Concord, CA 94520 1672 United States of America 1674 Email: jon.peterson@neustar.biz 1676 Jingxuan Jensen Zhang 1677 Tongji University 1678 4800 Cao'an Hwy 1679 Shanghai 201804 1680 China 1682 Email: jingxuan.zhang@tongji.edu.cn