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