idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-04.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 394: '... the network map MUST be included in "...' RFC 2119 keyword, line 396: '...sources, "uses" field MUST NOT appear....' RFC 2119 keyword, line 400: '...FCI map response MUST include the "vta...' RFC 2119 keyword, line 405: '... map, it MUST include the "dependent...' RFC 2119 keyword, line 447: '...Object, the ALTO client MUST interpret...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2018) is 1984 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) ** Downref: Normative reference to an Informational RFC: RFC 5693 ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Downref: Normative reference to an Informational RFC: RFC 7336 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-04 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-07 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-00 Summary: 5 errors (**), 0 flaws (~~), 4 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: May 21, 2019 Tongji/Yale 6 K. Ma 7 Ericsson 8 J. Peterson 9 Neustar 10 X. Lin 11 Tongji 12 November 17, 2018 14 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 15 Footprint and Capabilities Advertisement using ALTO 16 draft-ietf-alto-cdni-request-routing-alto-04 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. In this document, we follow the 29 guidelines to define an FCI protocol using the Application-Layer 30 Traffic Optimization (ALTO) protocol. 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 May 21, 2019. 49 Copyright Notice 51 Copyright (c) 2018 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 Map . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 12 79 3.7.2. Basic Example . . . . . . . . . . . . . . . . . . . . 14 80 3.7.3. Incremental Updates Example . . . . . . . . . . . . . 15 81 4. CDNI FCI Map using ALTO Network Map . . . . . . . . . . . . . 17 82 4.1. Network Map Footprint Type: altonetworkmap . . . . . . . 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 . . 17 86 4.2.3. ALTO Network Map Footprints in CDNI FCI Map . . . . . 18 87 4.2.4. Incremental Updates Example . . . . . . . . . . . . . 19 88 5. Filtered CDNI FCI Map 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 Unified Property 100 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 6.1. Representing Footprint Objects as Unified Property Map 102 Entities . . . . . . . . . . . . . . . . . . . . . . . . 27 103 6.1.1. ASN Domain . . . . . . . . . . . . . . . . . . . . . 28 104 6.1.2. COUNTRYCODE Domain . . . . . . . . . . . . . . . . . 28 105 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 29 106 6.2.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 29 107 6.2.2. Property Map Example . . . . . . . . . . . . . . . . 29 108 6.2.3. Filtered Property Map Example . . . . . . . . . . . . 30 109 6.2.4. Incremental Updates Example . . . . . . . . . . . . . 31 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 111 7.1. CDNI Metadata Footprint Type Registry . . . . . . . . . . 33 112 7.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 33 113 7.3. ALTO CDNI FCI Property Type Registry . . . . . . . . . . 34 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 115 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 117 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 118 10.2. Informative References . . . . . . . . . . . . . . . . . 36 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 121 1. Introduction 123 The ability to interconnect multiple content delivery networks (CDNs) 124 has many benefits, including increased coverage, capability, and 125 reliability. The Content Delivery Networks Interconnection (CDNI) 126 framework [RFC6707] defines four interfaces to achieve 127 interconnection of CDNs: (1) the CDNI Request Routing Interface; (2) 128 the CDNI Metadata Interface; (3) the CDNI Logging Interface; and (4) 129 the CDNI Control Interface. 131 Among the four interfaces, the CDNI Request Routing Interface 132 provides key functions, as specified in [RFC6707]: "The CDNI Request 133 Routing interface enables a Request Routing function in an Upstream 134 CDN to query a Request Routing function in a Downstream CDN to 135 determine if the Downstream CDN is able (and willing) to accept the 136 delegated Content Request. It also allows the Downstream CDN to 137 control what should be returned to the User Agent in the redirection 138 message by the upstream Request Routing function." On a high level, 139 the scope of the CDNI Request Routing Interface, therefore, contains 140 two main tasks: (1) determining if the downstream CDN (dCDN) is 141 willing to accept a delegated content request; (2) redirecting the 142 content request coming from an upstream CDN (uCDN) to the proper 143 entry point or entity in the downstream CDN. 145 Correspondingly, the request routing interface is broadly divided 146 into two functionalities: (1) CDNI Footprint & Capabilities 147 Advertisement interface (FCI); (2) CDNI Request Routing Redirection 148 interface (RI). Since this document focuses on the first 149 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 in [RFC8008]. A protocol to transport and update such objects 157 between a uCDN and a dCDN, however, is not defined. Hence, the scope 158 of this document is to define such a protocol by introducing a new 159 Application-Layer Traffic Optimization (ALTO) [RFC7285] service 160 called "CDNI FCI Map 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 Map, to 168 realize CDNI FCI using ALTO. Section 4 demonstrates a key benefit of 169 using ALTO: the ability to integrate CDNI FCI with ALTO network maps. 170 Such integration provides a new granularity to describe footprints. 171 Section 5 builds on filtered ALTO maps to introduce filtered CDNI FCI 172 maps using capabilities so that a uCDN can get footprints with given 173 capabilities instead of getting the full map which can be huge. 174 Section 6 further shows a 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 terminology for CDNI defined in 181 [RFC6707], [RFC8006], [RFC8008] and we use the terminology for ALTO 182 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 like. 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. Hence, server push and 218 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 and a /128 for IPv6) and IP prefixes with an 225 arbitrary prefix length. There must also be support for multiple 226 IP address 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; (5) Capabilities related 250 to CDNI Metadata. 252 2.2. ALTO Background and Benefits 254 Application-Layer Traffic Optimization (ALTO) [RFC7285] is an 255 approach for guiding the resource provider selection process in 256 distributed applications that can choose among several candidate 257 resources providers to retrieve a given resource. By conveying 258 network layer (topology) information, an ALTO server can provide 259 important information to "guide" the resource provider selection 260 process in distributed applications. Usually, it is assumed that an 261 ALTO server conveys information that these applications cannot or 262 have difficulty to measure themselves [RFC5693]. 264 Originally, ALTO was motivated by optimizing cross-ISP traffic 265 generated by P2P applications [RFC5693]. Recently, however, ALTO is 266 also being considered for improving the request routing in CDNs 267 [I-D.jenkins-alto-cdn-use-cases]. The CDNI problem statement 268 explicitly mentions ALTO as a candidate protocol for "actual 269 algorithms for selection of CDN or Surrogate by Request-Routing 270 systems" [RFC6707]. 272 The following reasons make ALTO a suitable candidate protocol for 273 downstream CDN selection as part of CDNI request routing and in 274 particular for an FCI protocol: 276 o ALTO is a protocol specifically designed to improve application 277 layer traffic (and application layer connections among hosts on 278 the Internet) by providing additional information to applications 279 that these applications could not easily retrieve themselves. For 280 CDNI, this is exactly the case: a uCDN wants to improve 281 application layer CDN request routing by using dedicated 282 information (provided by a dCDN) that the uCDN could not easily 283 obtain otherwise. ALTO can help a uCDN to select a proper dCDN by 284 first providing dCDNs' capabilities as well as footprints (see 285 Section 3) and then providing costs of surrogates in a dCDN by 286 ALTO cost maps. 288 o The semantics of an ALTO network map is an exact match for the 289 needed information to convey a footprint by a downstream CDN, in 290 particular if such a footprint is being expressed by IP-prefix 291 ranges. Please see Section 4. 293 o Security: Identifications between uCDNs and dCDNs are extremely 294 important. ALTO maps can be signed and hence provide inherent 295 integrity protection. Please see Section 8. 297 o RESTful-Design: The ALTO protocol has undergone extensive 298 revisions in order to provide a RESTful design regarding the 299 client-server interaction specified by the protocol. A CDNI FCI 300 interface based on ALTO would inherit this RESTful design. Please 301 see Section 3. 303 o Error-handling: The ALTO protocol has undergone extensive 304 revisions in order to provide sophisticated error-handling, in 305 particular regarding unexpected cases. A CDNI FCI interface based 306 on ALTO would inherit this thought-through and mature error- 307 handling. Please see Section 5. 309 o Filtered map service: The ALTO map filtering service would allow a 310 uCDN to query only for parts of an ALTO map. For example, 311 filtered unified property map service can enable a uCDN to query 312 properties of a part of footprints in an effective way (see 313 Section 6). 315 o Server-initiated Notifications and Incremental Updates: When the 316 footprint or the capabilities of a downstream CDN change (i.e., 317 unexpectedly from the perspective of an upstream CDN), server- 318 initiated notifications would enable a dCDN to directly inform an 319 upstream CDN about such changes. Consider the case where - due to 320 failure - part of the footprint of the dCDN is not functioning, 321 i.e., the CDN cannot serve content to such clients with reasonable 322 QoS. Without server-initiated notifications, the uCDN might still 323 use a very recent network and cost map from dCDN, and therefore 324 redirect requests to dCDN which it cannot serve. Similarly, the 325 possibility for incremental updates would enable efficient 326 conveyance of the aforementioned (or similar) status changes by 327 the dCDN to the uCDN. The newest design of ALTO supports server 328 pushed incremental updates [I-D.ietf-alto-incr-update-sse]. 330 o Content Availability on Hosts: A dCDN might want to express CDN 331 capabilities in terms of certain content types (e.g., codecs/ 332 formats, or content from certain content providers). The new 333 endpoint property for ALTO would enable a dCDN to make such 334 information available to an upstream CDN. This would enable a 335 uCDN to determine if a given dCDN actually has the capabilities 336 for a given request with respect to the type of content requested. 338 o Resource Availability on Hosts or Links: The capabilities on links 339 (e.g. maximum bandwidth) or caches (e.g. average load) might be 340 useful information for an upstream CDN for optimized downstream 341 CDN selection. For instance, if a uCDN receives a streaming 342 request for content with a certain bitrate, it needs to know if it 343 is likely that a dCDN can fulfill such stringent application-level 344 requirements (i.e., can be expected to have enough consistent 345 bandwidth) before it redirects the request. In general, if ALTO 346 could convey such information via new endpoint properties, it 347 would enable more sophisticated means for downstream CDN selection 348 with ALTO. ALTO Path Vector Extension [I-D.ietf-alto-path-vector] 349 is designed to allow ALTO clients to query information such as 350 capacity regions for a given set of flows. 352 3. CDNI FCI Map 354 The ALTO protocol is based on an ALTO Information Service Framework 355 which consists of several services, where all ALTO services are 356 "provided through a common transport protocol, messaging structure 357 and encoding, and transaction model" [RFC7285]. The ALTO protocol 358 specification [RFC7285] defines several such services, e.g. the ALTO 359 map service. 361 This document defines a new ALTO Map Service called "CDNI FCI Map 362 Service" which conveys JSON objects of media type "application/alto- 363 cdnifcimap+json". These JSON objects are used to transport 364 BaseAdvertisementObject objects defined in [RFC8008]; this document 365 specifies how to transport such BaseAdvertisementObject objects via 366 the ALTO protocol with the ALTO "CDNI FCI Map Service". Given that 367 the "CDNI FCI Map Service" is very similar in structure to the two 368 already defined map services (network maps and cost maps), the 369 specification of CDNI FCI Map below uses the same specification 370 structure for Cost Map specification in Section 11.2.3 of [RFC7285] 371 when specifying cost maps. 373 3.1. Media Type 375 The media type of the CDNI FCI Map is "application/alto- 376 cdnifcimap+json". 378 3.2. HTTP Method 380 A CDNI FCI map resource is requested using the HTTP GET method. 382 3.3. Accept Input Parameters 384 None. 386 3.4. Capabilities 388 None. 390 3.5. Uses 392 The resource ID of the resource based on which the CDNI FCI map will 393 be defined. For example, if a CDNI FCI map depends on a network map, 394 the resource ID of the network map MUST be included in "uses" field. 395 Please see Section 4 for details. If the CDNI FCI map does not 396 depend on any other resources, "uses" field MUST NOT appear. 398 3.6. Response 400 The "meta" field of a CDNI FCI map response MUST include the "vtag" 401 field defined in Section 10.3 of [RFC7285]. This field provides the 402 version of the retrieved CDNI FCI map. 404 If a CDNI FCI map response depends on a resource such as a network 405 map, it MUST include the "dependent-vtags" field, whose value is an 406 array to indicate the version tags of the resources used, where each 407 resource is specified in "uses" of the IRD. The current defined 408 dependent resource is only network map, and the usage of it is 409 described in Section 4. 411 The data component of an ALTO CDNI FCI map response is named "cdni- 412 fci-map", which is a JSON object of type CDNIFCIMapData: 414 object { 415 CDNIFCIMapData cdni-fci-map; 416 } InfoResourceCDNIFCIMap : ResponseEntityBase; 418 object { 419 BaseAdvertisementObject capabilities<1..*>; 420 } CDNIFCIMapData 422 Specifically, a CDNIFCIMapData object is a JSON object that includes 423 only one property named "capabilities", whose value is an array of 424 BaseAdvertisementObject objects. 426 The syntax and semantics of BaseAdvertisementObject are well defined 427 in Section 5.1 of [RFC8008]. A BaseAdvertisementObject object 428 includes multiple properties, including capability-type, capability- 429 value and footprints, where footprints are defined in Section 4.2.2.2 430 of [RFC8006]. 432 To be self-contained, we give a non-normative specification of 433 BaseAdvertisementObject below. As mentioned above, the normative 434 specification of BaseAdvertisementObject is in [RFC8008] 436 object { 437 JSONString capability-type; 438 JSONValue capability-value; 439 Footprint footprints<0..*>; 440 } BaseAdvertisementObject; 442 object { 443 JSONString footprint-type; 444 JSONString footprint-value<1..*>; 445 } Footprint 447 For each BaseAdvertisementObject, the ALTO client MUST interpret 448 footprints appearing multiple times as if they appeared only once. 449 If footprints in a BaseAdvertisementObject is null or empty or not 450 appearing, the ALTO client MUST understand that the capabilities in 451 this BaseAdvertisementObject have the "global" coverage. 453 Note: Further optimization of BaseAdvertisement objects to 454 effectively provide the advertisement of capabilities with footprint 455 restrictions is certainly possible. For example, these two examples 456 below both describe that the dCDN can provide capabilities 457 ["http/1.1", "https/1.1"] for the same footprints. However, the 458 latter one is smaller in its size. 460 EXAMPLE 1 461 { 462 "meta" : {...}, 463 "cdni-fci-map": { 464 "capabilities": [ 465 { 466 "capability-type": "FCI.DeliveryProtocol", 467 "capability-value": { 468 "delivery-protocols": [ 469 "http/1.1" 470 ] 471 }, 472 "footprints": [ 473 475 ] 476 }, 477 { 478 "capability-type": "FCI.DeliveryProtocol", 479 "capability-value": { 480 "delivery-protocols": [ 481 "https/1.1" 482 ] 483 }, 484 "footprints": [ 485 486 ] 487 } 488 ] 489 } 490 } 492 EXAMPLE 2 493 { 494 "meta" : {...}, 495 "cdni-fci-map": { 496 "capabilities": [ 497 { 498 "capability-type": "FCI.DeliveryProtocol", 499 "capability-value": { 500 "delivery-protocols": [ 501 "https/1.1", 502 "http/1.1" 503 ] 504 }, 505 "footprints": [ 506 507 ] 508 } 509 ] 510 } 511 } 513 Since such optimizations are not necessary for the basic 514 interconnection of CDNs, the specifics of such mechanisms are outside 515 the scope of this document. 517 3.7. Examples 518 3.7.1. IRD Example 520 Below is the information resource directory (IRD) of a simple, 521 example ALTO server. The server provides both base ALTO information 522 resources (e.g., network maps) and CDNI FCI information resources 523 (e.g., CDNI FCI map), demonstrating a single, integrated environment. 525 Specifically, the IRD announces two network maps, one CDNI FCI map 526 without dependency, one CDNI FCI map depending on a network map, one 527 filtered CDNI FCI map to be defined in Section 5, one unified 528 property map including "cdni-fci-capabilities" as its entities' 529 property, one filtered unified property map including "cdni-fci- 530 capabilities" and "pid" as its entities' properties, and two update 531 stream services (one for updating CDNI FCI maps, and the other for 532 updating property maps). 534 GET /directory HTTP/1.1 535 Host: alto.example.com 536 Accept: application/alto-directory+json,application/alto-error+json 538 { 539 "meta" : { ... }, 540 "resources": { 541 "my-default-network-map": { 542 "uri" : "http://alto.example.com/networkmap", 543 "media-type" : "application/alto-networkmap+json" 544 }, 545 "my-eu-netmap" : { 546 "uri" : "http://alto.example.com/myeunetmap", 547 "media-type" : "application/alto-networkmap+json" 548 }, 549 "my-default-cdnifci-map": { 550 "uri" : "http://alto.example.com/cdnifcimap", 551 "media-type": "application/alto-cdnifcimap+json" 552 }, 553 "my-filtered-cdnifci-map" : { 554 "uri" : "http://alto.example.com/cdnifcimap/filtered", 555 "media-type" : "application/alto-cdnifcimap+json", 556 "accepts" : "application/alto-cdnifcimapfilter+json", 557 "uses" : [ "my-default-cdnifci-map" ] 558 }, 559 "my-cdnifci-map-with-network-map-footprints": { 560 "uri" : "http://alto.example.com/networkcdnifcimap", 561 "media-type" : "application/alto-cdnifcimap+json", 562 "uses" : [ "my-eu-netmap" ] 563 }, 564 "cdnifci-property-map" : { 565 "uri" : "http://alto.example.com/propmap/full/cdnifci", 566 "media-type" : "application/alto-propmap+json", 567 "capabilities" : { 568 "domain-types" : [ "ipv4", "ipv6", "coutrycode", "asn" ], 569 "prop-types" : [ "cdni-fci-capabilities" ] 570 } 571 }, 572 "filtered-cdnifci-property-map" : { 573 "uri" : "http://alto.example.com/propmap/lookup/cdnifci-pid", 574 "media-type" : "application/alto-propmap+json", 575 "accepts" : "application/alto-propmapparams+json", 576 "capabilities" : { 577 "domain-types" : [ "ipv4", "ipv6", "coutrycode", "asn" ], 578 "prop-types" : [ "cdni-fci-capabilities", "pid" ] 579 } 580 }, 581 "update-my-cdni-fci-maps" : { 582 "uri": "http:///alto.example.com/updates/cdnifcimaps", 583 "media-type" : "text/event-stream", 584 "accepts" : "application/alto-updatestreamparams+json", 585 "uses" : [ 586 "my-default-network-map", 587 "my-eu-netmap", 588 "my-default-cdnifci-map", 589 "my-filtered-cdnifci-map" 590 "my-cdnifci-map-with-network-map-footprints" 591 ], 592 "capabilities" : { 593 "incremental-change-media-types" : { 594 "my-default-network-map" : "application/json-patch+json", 595 "my-eu-netmap" : "application/json-patch+json", 596 "my-default-cdnifci-map" : 597 "application/merge-patch+json,application/json-patch+json", 598 "my-filtered-cdnifci-map" : 599 "application/merge-patch+jso,application/json-patch+json", 600 "my-cdnifci-map-with-network-map-footprints" : 601 "application/merge-patch+json,application/json-patch+json" 602 } 603 } 604 }, 605 "update-my-props": { 606 "uri" : "http://alto.example.com/updates/properties", 607 "media-type" : "text/event-stream", 608 "uses" : [ 609 "cdnifci-property-map", 610 "filtered-cdnifci-property-map" 611 ], 612 "capabilities" : { 613 "incremental-change-media-types": { 614 "cdnifci-property-map" : 615 "application/merge-patch+json,application/json-patch+json", 616 "filtered-cdnifci-property-map": 617 "application/merge-patch+json,application/json-patch+json" 618 } 619 } 620 } 621 } 622 } 624 3.7.2. Basic Example 626 In this example, we demonstrate a simple CDNI FCI map; this map does 627 not depend on other resources. There are three 628 BaseAdvertisementObjects in this map and these objects' capabilities 629 are http/1.1 delivery protocol, [http/1.1, https/1.1] delivery 630 protocol and https/1.1 acquisition protocol respectively. 632 GET /cdnifcimap HTTP/1.1 633 Host: alto.example.com 634 Accept: application/alto-cdnifcimap+json,application/alto-error+json 636 HTTP/1.1 200 OK 637 Content-Length: XXX 638 Content-Type: application/alto-cdnifcimap+json 639 { 640 "meta" : { 641 "vtag": { 642 "resource-id": "my-default-cdnifci-map", 643 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 644 } 645 }, 646 "cdni-fci-map": { 647 "capabilities": [ 648 { 649 "capability-type": "FCI.DeliveryProtocol", 650 "capability-value": { 651 "delivery-protocols": [ 652 "http/1.1" 653 ] 654 }, 655 "footprints": [ 656 657 ] 658 }, 659 { 660 "capability-type": "FCI.DeliveryProtocol", 661 "capability-value": { 662 "delivery-protocols": [ 663 "https/1.1", 664 "http/1.1" 665 ] 666 }, 667 "footprints": [ 668 669 ] 670 }, 671 { 672 "capability-type": "FCI.AcquisitionProtocol", 673 "capability-value": { 674 "acquisition-protocols": [ 675 "https/1.1" 676 ] 677 }, 678 "footprints": [ 679 680 ] 681 } 682 ] 683 } 684 } 686 3.7.3. Incremental Updates Example 688 A benefit of using ALTO to provide CDNI FCI maps is that such maps 689 can be updated using ALTO incremental updates. Below is an example 690 that also shows the benefit of having both JSON merge patch and JSON 691 patch to encode updates. 693 At first, an ALTO client requests the ALTO server updates for "my- 694 default-cdnifci-map", and the ALTO server returns the "control-uri" 695 followed by the full CDNI FCI map. Then when there is a huge change 696 in footprint objects in delivery-protocol http/1.1, the ALTO server 697 uses JSON merge patch to encode the change and sends it to the ALTO 698 client. Later on, the ALTO server notifies the ALTO client that 699 "ipv4:192.0.2.0/24" is added into the footprints in delivery-protocol 700 http/1.1 by sending the change encoded by JSON patch to the ALTO 701 client. 703 POST /updates/cdnifcimaps HTTP/1.1 704 Host: alto.example.com 705 Accept: text/event-stream,application/alto-error+json 706 Content-Type: application/alto-updatestreamparams+json 707 Content-Length: ### 709 { "add": { 710 "my-cdnifci-stream": { 711 "resource-id": "my-default-cdnifci-map" 712 } 713 } 715 HTTP/1.1 200 OK 716 Connection: keep-alive 717 Content-Type: text/event-stream 719 event: application/alto-updatestreamcontrol+json 720 data: {"control-uri": 721 data: "http://alto.example.com/updates/streams/3141592653589"} 723 event: application/alto-cdnifcimap+json,my-default-cdnifci-map 724 data: { ... full CDNI FCI map ... } 726 event: application/merge-patch+json,my-default-cdnifci-map 727 data: { 728 data: "meta": { 729 data: "vtag": { 730 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 731 data: } 732 data: }, 733 data: { 734 data: "capability-type": "FCI.DeliveryProtocol", 735 data: "capability-value": { 736 data: "delivery-protocols": [ 737 data: "http/1.1" 738 data: ] 739 data: }, 740 data: "footprints": [ 741 data: 743 data: ] 744 data: } 745 data: } 747 event: application/json-patch+json,my-default-cdnifci-map 748 data: [ 749 data: { 750 data: "op": "replace", 751 data: "path": "/meta/vtag/tag", 752 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 753 data: }, 754 data: { "op": "add", 755 data: "path": "/cdni-fci-map/capabilities/0/footprints/-", 756 data: "value": "ipv4:192.0.2.0/24" 757 data: } 758 data: ] 760 4. CDNI FCI Map using ALTO Network Map 762 4.1. Network Map Footprint Type: altonetworkmap 764 In addition to the already defined CDNI footprint types (e.g., 765 ipv4cidr, ipv6cidr, asn, countrycode), ALTO network maps can be a 766 type of FCI footprint. 768 Specifically, CDNI footprints using ALTO network maps should use a 769 new CDNI Footprint Type called "altonetworkmap". 771 "altonetworkmap" footprint type indicates that the corresponding 772 footprint value is a list of PIDNames as defined in [RFC7285]. These 773 PIDNames are references of PIDs in a network map resource. Hence a 774 CDNI FCI map with "altonetworkmap" footprints depends on a network 775 map. For such a CDNI FCI map, the "dependent-vtag" field with a 776 reference to a network map it depends on MUST be included in it (see 777 the example in Section 4.2.3). 779 4.2. Examples 781 4.2.1. IRD Example 783 We use the same IRD example given in Section 3.7.1. 785 4.2.2. ALTO Network Map for CDNI FCI Footprints Example 787 Below is an example network map whose resource id is "my-eu-netmap", 788 and this map is referenced by the CDNI FCI map example in 789 Section 4.2.3. 791 GET /networkmap HTTP/1.1 792 Host: http://alto.example.com/myeunetmap 793 Accept: application/alto-networkmap+json,application/alto-error+json 794 HTTP/1.1 200 OK 795 Content-Length: XXX 796 Content-Type: application/alto-networkmap+json 798 { 799 "meta" : { 800 "vtag": [ 801 {"resource-id": "my-eu-netmap", 802 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 803 } 804 ] 805 }, 806 "network-map" : { 807 "south-france" : { 808 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] 809 }, 810 "germany" : { 811 "ipv4" : [ "192.0.3.0/24"] 812 } 813 } 814 } 816 4.2.3. ALTO Network Map Footprints in CDNI FCI Map 818 In this example, we show a CDNI FCI map that depends on a network map 819 described in Section 4.2.2. 821 GET /networkcdnifcimap HTTP/1.1 822 Host: alto.example.com 823 Accept: application/alto-cdnifcimap+json,application/alto-error+json 824 HTTP/1.1 200 OK 825 Content-Length: 618 826 Content-Type: application/alto-cdnifcimap+json 828 { 829 "meta" : { 830 "dependent-vtags" : [ 831 { 832 "resource-id": "my-eu-netmap", 833 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 834 } 835 ] 836 }, 837 "cdni-fci-map": { 838 "capabilities": [ 839 { "capability-type": "FCI.DeliveryProtocol", 840 "capability-value": [ 841 "http/1.1" 842 ] 843 }, 844 { "capability-type": "FCI.DeliveryProtocol", 845 "capability-value": [ 846 "values": [ 847 "https/1.1" 848 ], 849 "footprints": [ 850 { "footprint-type": "altonetworkmap", 851 "footprint-value": [ 852 "germany", 853 "south-france" 854 ] 855 } 856 ] 857 } 858 ] 859 } 860 } 862 4.2.4. Incremental Updates Example 864 In this example, the ALTO client is interested in changes of "my- 865 cdnifci-map-with-network-map-footprints". Considering two changes, 866 the first one is to change footprints of http/1.1 Delivery Protocol 867 capability, and the second one is to remove "south-france" from the 868 footprints of https/1.1 delivery protocol capability. 870 POST /updates/cdnifcimaps HTTP/1.1 871 Host: alto.example.com 872 Accept: text/event-stream,application/alto-error+json 873 Content-Type: application/alto-updatestreamparams+json 874 Content-Length: ### 876 { "add": { 877 "my-network-map-cdnifci-stream": { 878 "resource-id": "my-cdnifci-map-with-network-map-footprints" 879 } 880 } 882 HTTP/1.1 200 OK 883 Connection: keep-alive 884 Content-Type: text/event-stream 886 event: application/alto-updatestreamcontrol+json 887 data: {"control-uri": 888 data: "http://alto.example.com/updates/streams/3141592653590"} 890 event: application/alto-cdnifcimap+json,my-fci-stream 891 data: { ... full CDNI FCI map ... } 893 event: application/merge-patch+json,my-fci-stream 894 data: { 895 data: "meta": { 896 data: "dependent-vtags" : [ 897 data: { 898 data: "resource-id": "my-eu-netmap", 899 data: "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 900 data: } 901 data: ], 902 data: "vtag": { 903 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 904 data: } 905 data: }, 906 data: { 907 data: "capability-type": "FCI.DeliveryProtocol", 908 data: "capability-value": { 909 data: "delivery-protocols": [ 910 data: "http/1.1" 911 data: ] 912 data: }, 913 data: "footprints": [ 914 data: 916 data: ] 917 data: } 918 data: } 919 event: application/json-patch+json,my-fci-stream 920 data: [ 921 data: { 922 data: "op": "replace", 923 data: "path": "/meta/vtag/tag", 924 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 925 data: }, 926 data: { "op": "remove", 927 data: "path": "/cdni-fci-map/capabilities/2/footprints/0/ 928 data: footprint-value/1", 929 data: } 930 data: ] 932 5. Filtered CDNI FCI Map using Capabilities 934 Section 3 and Section 4 describe CDNI FCI Map Service which can be 935 used to enable a uCDN to get capabilities with footprints constrains 936 from dCDNs. However, always getting full CDNI FCI maps from dCDNs is 937 very inefficient, hence we introduce a new service named "Filtered 938 CDNI FCI Map Service" to allow a client to filter a CDNI FCI map 939 using a client-given set of capabilities. For each entry of the CDNI 940 FCI map, only if the entry contains at least one of the client-given 941 capabilities will it be returned to the client. The relationship 942 between a filtered CDNI FCI map and a CDNI FCI map is similar to the 943 relationship between a filtered network/cost map and a network/cost 944 map. 946 5.1. Media Type 948 Since a filtered CDNI FCI map is still a CDNI FCI map, it uses the 949 media type defined for CDNI FCI maps in Section 3.1. 951 5.2. HTTP Method 953 A filtered CDNI FCI map is requested using the HTTP POST method. 955 5.3. Accept Input Parameters 957 The input parameters for a filtered CDNI FCI map are supplied in the 958 entity body of the POST request. This document specifies the input 959 parameters with a data format indicated by the media type 960 "application/alto-cdnifcifilter+json" which is a JSON object of type 961 ReqFilteredCDNIFCIMap, where: 963 object { 964 JSONString capability-type; 965 JSONValue capability-value; 966 } CDNIFCICapability; 968 object { 969 [CDNIFCICapability cdni-fci-capabilities<0..*>;] 970 } ReqFilteredCDNIFCIMap; 972 with fields: 974 capability-type: The same as Base Advertisement Object's capability- 975 type defined in Section 5.1 of [RFC8008]. 977 capability-value: The same as Base Advertisement Object's 978 capability-value defined in Section 5.1 of [RFC8008]. 980 cdni-fci-capabilities: A list of CDNI FCI capabilities defined in 981 Section 5.1 of [RFC8008] for which footprints are to be returned. 982 If a list is empty or not appearing, the ALTO server MUST 983 interpret it as a request for the full CDNI FCI Map. The ALTO 984 server MUST interpret entries appearing in a list multiple times 985 as if they appeared only once. If a "capability-type" or a 986 "capability-value" is not defined, the ALTO server MUST ignore 987 this capability. If there is only one capability in the list and 988 its "capability-type" or "capability-value" is not defined, the 989 ALTO server MUST return nothing. 991 5.4. Capabilities 993 None. 995 5.5. Uses 997 The resource ID of the CDNI FCI map based on which the filtering is 998 performed. 1000 5.6. Response 1002 The response MUST indicate an error, using ALTO protocol error 1003 handling specified in Section 8.5 of the ALTO protocol [RFC7285], if 1004 the request is invalid. 1006 Specifically, a filtered CDNI FCI map request can be invalid as 1007 follows: 1009 o The value of "capability-type" is null; 1010 o The value of "capability-value" is null; 1012 o The value of "capability-value" is inconsistent with "capability- 1013 type". 1015 When the request is invalid, the ALTO server MUST return an 1016 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], 1017 and the "value" field of the error message SHOULD indicate this CDNI 1018 FCI capability. 1020 The ALTO server return a filtered CDNI FCI map for a valid request. 1021 The format of a filtered CDNI FCI map is the same as an unfiltered 1022 CDNI FCI map. See Section 3.6 for the format. 1024 The returned CDNI FCI map MUST contain only BaseAdvertisementObject 1025 objects whose CDNI capability object is the superset of one of CDNI 1026 capability object in "cdni-fci-capabilities". Specifically, that a 1027 CDNI capability object A is the superset of another CDNI capability 1028 object B means that these two CDNI capability objects have the same 1029 capability type and mandatory properties in capability value of A 1030 MUST include mandatory properties in capability value of B 1031 semantically. See Section 5.7.2 for a concrete example. 1033 The version tag included in the "vtag" field of the response MUST 1034 correspond to the full CDNI FCI map resource from which the filtered 1035 CDNI FCI map is provided. This ensures that a single, canonical 1036 version tag is used independently of any filtering that is requested 1037 by an ALTO client. 1039 5.7. Examples 1041 5.7.1. IRD Example 1043 We use the same IRD example by Section 3.7.1. 1045 5.7.2. Basic Example 1047 This example filters the full CDNI FCI map in Section 3.7.2 by 1048 selecting only http/1.1 delivery protocol capability. Only the first 1049 two BaseAdvertisementObjects in the full map will be returned because 1050 the first object's capability is http/1.1 delivery protocol and the 1051 second object's capability is http/1.1 and https/1.1 delivery 1052 protocols which is the superset of http/1.1 delivery protocol. 1054 POST /cdnifcimap/filtered HTTP/1.1 1055 HOST: alto.example.com 1056 Content-Type: application/cdnifilter+json 1057 Accept: application/alto-cdnifcimap+json 1059 { 1060 "cdni-fci-capabilities": [ 1061 { 1062 "capability-type": "FCI.DeliveryProtocol", 1063 "capability-value": { 1064 "delivery-protocols": [ 1065 "http/1.1" 1066 ] 1067 } 1068 } 1069 ] 1070 } 1071 HTTP/1.1 200 OK 1072 Content-Length: XXX 1073 Content-Type: application/alto-cdnifcimap+json 1074 { 1075 "meta" : { 1076 "vtag": { 1077 "resource-id": "my-default-cdnifci-map", 1078 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 1079 } 1080 }, 1081 "cdni-fci-map": { 1082 "capabilities": [ 1083 { 1084 "capability-type": "FCI.DeliveryProtocol", 1085 "capability-value": { 1086 "delivery-protocols": [ 1087 "http/1.1" 1088 ] 1089 }, 1090 "footprints": [ 1091 1092 ] 1093 }, 1094 { 1095 "capability-type": "FCI.DeliveryProtocol", 1096 "capability-value": { 1097 "delivery-protocols": [ 1098 "https/1.1", 1099 "http/1.1" 1100 ] 1101 }, 1102 "footprints": [ 1103 1104 ] 1105 } 1106 ] 1107 } 1108 } 1110 5.7.3. Incremental Updates Example 1112 In this example, the ALTO client only cares about the updates of one 1113 Delivery Protocol object whose value is "http/1.1". So it adds its 1114 limitation of capabilities in "input" field of the POST request. 1116 POST /updates/cdnifcimaps HTTP/1.1 1117 Host: fcialtoupdate.example.com 1118 Accept: text/event-stream,application/alto-error+json 1119 Content-Type: application/alto-updatestreamparams+json 1120 Content-Length: ### 1122 { "add": { 1123 "my-fci-stream": { 1124 "resource-id": "my-filtered-cdnifci-map", 1125 "input": { 1126 "cdni-fci-capabilities": [ 1127 { 1128 "capability-type": "FCI.DeliveryProtocol", 1129 "capability-value": { 1130 "delivery-protocols": [ 1131 "http/1.1" 1132 ] 1133 } 1134 } 1135 ] 1136 } 1137 } 1138 } 1139 } 1141 HTTP/1.1 200 OK 1142 Connection: keep-alive 1143 Content-Type: text/event-stream 1145 event: application/alto-updatestreamcontrol+json 1146 data: {"control-uri": 1147 data: "http://alto.example.com/updates/streams/3141592653590"} 1149 event: application/alto-cdnifcimap+json,my-fci-stream 1150 data: { ... full filtered CDNI FCI map ... } 1152 event: application/merge-patch+json,my-fci-stream 1153 data: { 1154 data: "meta": { 1155 data: "vtag": { 1156 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 1157 data: } 1158 data: }, 1159 data: { 1160 data: "capability-type": "FCI.DeliveryProtocol", 1161 data: "capability-value": { 1162 data: "delivery-protocols": [ 1163 data: "http/1.1" 1164 data: ] 1165 data: }, 1166 data: "footprints": [ 1167 data: 1169 data: ] 1170 data: } 1171 data: } 1173 event: application/json-patch+json,my-fci-stream 1174 data: [ 1175 data: { 1176 data: "op": "replace", 1177 data: "path": "/meta/vtag/tag", 1178 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1179 data: }, 1180 data: { "op": "add", 1181 data: "path": "/cdni-fci-map/capabilities/0/footprints/-", 1182 data: "value": "ipv4:192.0.2.0/24" 1183 data: } 1184 data: ] 1186 6. Query Footprint Properties using ALTO Unified Property Service 1188 Above sections describe how a uCDN can get the whole capabilities and 1189 footprints from dCDNs and how a uCDN can get the footprints of given 1190 capabilities. But there is another important case which is how a 1191 uCDN can get properties (i.e., capabilities) of given footprints. 1193 The most natrual way to solve this problem is to use ALTO unified 1194 property map defined in [I-D.ietf-alto-unified-props-new] since 1195 footprints can be easily presented as groups of entities and Filtered 1196 Property Maps are already well-defined. In this section, we describe 1197 how ALTO clients look up properties for individual footprints. We 1198 firstly describe how to represent footprint objects as unified 1199 property map entities, and then we provide examples of the full 1200 property map, the filtered property map and the incremental updates. 1202 6.1. Representing Footprint Objects as Unified Property Map Entities 1204 A footprint object has two properties: footprint-type and footprint- 1205 value. A footprint-value is an array of footprint values conforming 1206 to the specification associated with the registered footprint type 1207 ("ipv4cidr", "ipv6cidr", "asn", and "countrycode"). Since each 1208 unified property map entity has a unique address and each pair of 1209 footprint-type and a footprint value determines a group of unique 1210 addresses, a footprint object can be represented as a set of entities 1211 according to their different footprint-type and footprint values. 1212 However, [I-D.ietf-alto-unified-props-new] only defines IPv4 Domain 1213 and IPv6 Domain which represent footprint-type "ipv4cidr" and 1214 "ipv6cidr" respectively. To represent footprint-type "asn" and 1215 "countrycode", this document registers two new domains in Section 7. 1217 Here gives an example of representing a footprint object as a set of 1218 unified property map entities. 1220 {"footprint-type": "ipv4cidr", "footprint-value": ["192.0.2.0/24", 1221 "198.51.100.0/24"]} --> "ipv4:192.168.2.0/24", "ipv4:198.51.100.0/24" 1223 6.1.1. ASN Domain 1225 This document specifies a new domain in addition to the ones in 1226 [I-D.ietf-alto-unified-props-new]. ASN is the abbreviation of 1227 Autonomous System Number. 1229 6.1.1.1. Domain Name 1231 asn 1233 6.1.1.2. Domain-Specific Entity Addresses 1235 The entity address of asn domain is encoded as a string consisting of 1236 the characters "as" (in lowercase) followed by the ASN [RFC6793]. 1238 6.1.1.3. Hierarchy and Inheritance 1240 There is no hierarchy or inheritance for properties associated with 1241 ASN. 1243 6.1.2. COUNTRYCODE Domain 1245 This document specifies a new domain in addition to the ones in 1246 [I-D.ietf-alto-unified-props-new]. 1248 6.1.2.1. Domain Name 1250 countrycode 1252 6.1.2.2. Domain-Specific Entity Addresses 1254 The entity address of countrycode domain is encoded as an ISO 3166-1 1255 alpha-2 code [ISO3166-1] in lowercase. 1257 6.1.2.3. Hierarchy and Inheritance 1259 There is no hierarchy or inheritance for properties associated with 1260 country codes. 1262 6.2. Examples 1264 6.2.1. IRD Example 1266 We use the same IRD example given by Section 3.7.1. 1268 6.2.2. Property Map Example 1270 This example shows a full unified property map in which entities are 1271 footprints and entities' property is "cdni-fci-capabilities". 1273 GET /propmap/full/cdnifci HTTP/1.1 1274 HOST: alto.example.com 1275 Accept: application/alto-propmap+json,application/alto-error+json 1276 HTTP/1.1 200 OK 1277 Content-Length: ### 1278 Content-Type: application/alto-propmap+json 1280 { 1281 "property-map": { 1282 "meta": { 1283 "dependent-vtags": [ 1284 {"resource-id": "my-default-cdnifci-map", 1285 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1286 ] 1287 }, 1288 "countrycode:us": { 1289 "cdni-fci-capabilities": [{"capability-type":, 1290 "capability-value":}] 1291 }, 1292 "ipv4:192.0.2.0/24": { 1293 "cdni-fci-capabilities": [{"capability-type":, 1294 "capability-value":}] 1295 }, 1296 "ipv4:198.51.100.0/24": { 1297 "cdni-fci-capabilities": [{"capability-type":, 1298 "capability-value":}] 1299 }, 1300 "ipv6:2001:db8::/32": { 1301 "cdni-fci-capabilities": [{"capability-type":, 1302 "capability-value":}] 1303 }, 1304 "asn:as64496": { 1305 "cdni-fci-capabilities": [{"capability-type":, 1306 "capability-value":}] 1307 } 1308 } 1309 } 1311 6.2.3. Filtered Property Map Example 1313 In this example, we use filtered property map service to get "pid" 1314 and "cdni-fci-capabilities" properties for two footprints 1315 "ipv4:192.0.2.0/24" and "ipv6:2001:db8::/32". 1317 POST /propmap/lookup/cdnifci-pid HTTP/1.1 1318 HOST: alto.example.com 1319 Content-Type: application/alto-propmapparams+json 1320 Accept: application/alto-propmap+json,application/alto-error+json 1321 Content-Length: 1323 { 1324 "entities": [ 1325 "ipv4:192.0.2.0/24", 1326 "ipv6:2001:db8::/32" 1327 ], 1328 "properties": [ "cdni-fci-capabilities", "pid" ] 1329 } 1331 HTTP/1.1 200 OK 1332 Content-Length: ### 1333 Content-Type: application/alto-propmap+json 1335 { 1336 "property-map": { 1337 "meta": { 1338 "dependent-vtags": [ 1339 {"resource-id": "my-default-cdnifci-map", 1340 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}, 1341 {"resource-id": "my-default-networkmap", 1342 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1343 ] 1344 }, 1345 "ipv4:192.0.2.0/24": { 1346 "cdni-fci-capabilities": [{"capability-type":, 1347 "capability-value":}], 1348 "pid": "pid1" 1349 }, 1350 "ipv6:2001:db8::/32": { 1351 "cdni-fci-capabilities": [{"capability-type":, 1352 "capability-value":}], 1353 "pid": "pid3" 1354 } 1355 } 1356 } 1358 6.2.4. Incremental Updates Example 1360 In this example, here is a client want to request updates for the 1361 properties "cdni-fci-capabilities" and "pid" for two footprints 1362 "ipv4:192.0.2.0/24" and "ipv6:2001:db8::/32". 1364 POST /updates/properties HTTP/1.1 1365 Host: alto.example.com 1366 Accept: text/event-stream,application/alto-error+json 1367 Content-Type: application/alto-updatestreamparams+json 1368 Content-Length: ### 1370 { "add": { 1371 "property-map-including-capability-property": { 1372 "resource-id": "filtered-cdnifci-property-map", 1373 "input": { 1374 "properties": ["cdni-fci-capabilities", "pid"], 1375 "entities": [ 1376 "ipv4:192.0.2.0/24", 1377 "ipv6:2001:db8::/32" 1378 ] 1379 } 1380 } 1381 } 1383 HTTP/1.1 200 OK 1384 Connection: keep-alive 1385 Content-Type: text/event-stream 1387 event: application/alto-updatestreamcontrol+json 1388 data: {"control-uri": 1389 data: "http://alto.example.com/updates/streams/1414213562373"} 1391 event: application/alto-cdnifcimap+json,my-fci-stream 1392 data: { ... full filtered unified property map ... } 1394 event: application/merge-patch+json,my-fci-stream 1395 data: { 1396 data: "property-map": 1397 data: { 1398 data: "meta": { 1399 data: "dependent-vtags": [ 1400 data: {"resource-id": "my-default-cdnifci-map", 1401 data: "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"}, 1402 data: {"resource-id": "my-default-networkmap", 1403 data: "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1404 data: ] 1405 data: }, 1406 data: "ipv4:192.0.2.0/24": 1407 data: { 1408 data: "cdni-fci-capabilities": 1409 data: [{"capability-type":,"capability-value":}] 1410 data: } 1411 data: } 1412 data: } 1413 event: application/json-patch+json,my-fci-stream 1414 data: {[ 1415 data: { 1416 data: { "op": "replace", 1417 data: "path": "/meta/dependent-vtags/0/tag", 1418 data: "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4" 1419 data: }, 1420 data: { "op": "replace", 1421 data: "path": "/property-map/ipv4:192.0.2.0/124/", 1422 data: "value": "pid5" 1423 data: } 1424 data: } 1425 data: ]} 1427 7. IANA Considerations 1429 7.1. CDNI Metadata Footprint Type Registry 1431 +-----------------+-----------------------+-----------------------+ 1432 | Footprint Type | Description | Specification | 1433 +-----------------+-----------------------+-----------------------+ 1434 | altonetworkmap | A list of PID-names | RFCthis | 1435 +-----------------+-----------------------+-----------------------+ 1437 Table 1: CDNI Metadata Footprint Type 1439 [RFC Editor: Please replace RFCthis with the published RFC number for 1440 this document.] 1442 7.2. ALTO Entity Domain Registry 1444 As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new], 1445 "ALTO Entity Domain Registry" is requested. Besides, two new domains 1446 are to be registered, listed in Table 2. 1448 +--------------+-------------------------+--------------------------+ 1449 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1450 +--------------+-------------------------+--------------------------+ 1451 | asn | See Section 6.1.1.2 | None | 1452 | countrycode | See Section 6.1.2.2 | None | 1453 +--------------+-------------------------+--------------------------+ 1455 Table 2: ALTO Entity Domain 1457 7.3. ALTO CDNI FCI Property Type Registry 1459 The "ALTO CDNI FCI Property Type Registry" is required by the ALTO 1460 Entity Domain "asn", "countrycode", "pid", "ipv4" and "ipv6", listed 1461 in Table 3. 1463 +------------------------+------------------------------------------+ 1464 | Identifier | Intended Semantics | 1465 +------------------------+------------------------------------------+ 1466 | cdni-fci-capabilities | An array of CDNI FCI capability objects | 1467 +------------------------+------------------------------------------+ 1469 Table 3: ALTO CDNI FCI Property Type 1471 8. Security Considerations 1473 Although CDNI FCI Map resource defined in this document is relatively 1474 different from other existed resources defined in the base protocol, 1475 the Security Considerations of the base protocol (Section 15 of 1476 RFC7285) still apply. 1478 For authenticity and Integrity of ALTO information, an attacker may 1479 disguise itself as an ALTO server in a dCDN, and it may provide false 1480 capabilities and footprints to an ALTO client in a uCDN by the CDNI 1481 FCI map. Such false information may lead a uCDN to select a wrong 1482 dCDN to serve user requests or even block uCDNs utilizing some dCDNs 1483 in good condition. 1485 For potential undesirable guidance from authenticated ALTO 1486 information, dCDNs can provide a uCDN with limited capabilities and 1487 smaller footprint coverage so that dCDNs can avoid transferring 1488 traffic for a uCDN which they should have to transfer. 1490 For confidentiality of ALTO information, an attacker may infer the 1491 whole and exact capabilities and footprints of a dCDN by means of 1492 pretending it is one of different uCDNs of a dCDN respectively, 1493 getting different CDNI FCI maps from a dCDN and combining these maps 1494 together. 1496 For privacy for ALTO users, querying footprint properties using ALTO 1497 unified property may expose network location identifiers (IP 1498 addresses or fine-grained PIDs) to the ALTO server in a dCDN. In 1499 such case, a dCDN may potentially monitor and analyze user behaviors 1500 and communication patterns of uCDNs' customers. 1502 For availability of ALTO services, an attacker may get the potential 1503 huge full CDNI FCI maps from an ALTO server in a dCDN continuously to 1504 run out of bandwidth resources of that ALTO server or may query 1505 filtered CDNI FCI services with complex capabilities to run out of 1506 computation resources of an ALTO server. 1508 Protection Strategies described in RFC 7285 can solve problems 1509 mentioned above well. However, the isolation of full/filtered CDNI 1510 FCI maps should also be considered. 1512 If a dCDN signs agreements with multiple uCDNs, it must isolate full/ 1513 filtered CDNI FCI maps for different uCDNs in that uCDNs will not 1514 redirect requests which should not have to served by this dCDN to 1515 this dCDN and it may not disclose extra information to uCDNs. 1517 To avoid this risk, a dCDN may consider generating URIs of different 1518 full/filtered CDNI FCI maps by hashing its company ID, a uCDN's 1519 company ID as well as their agreements. And it needs to avoid 1520 expoing all full/filtered CDNI FCI maps resources in one of its IRDs. 1522 9. Acknowledgments 1524 The authors would like to thank Daryl Malas, Matt Caulfield for their 1525 timely reviews and invaluable comments. 1527 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 1528 Architecture and Applications of Green Information Centric 1529 Networking), a research project supported jointly by the European 1530 Commission under its 7th Framework Program (contract no. 608518) and 1531 the National Institute of Information and Communications Technology 1532 (NICT) in Japan (contract no. 167). The views and conclusions 1533 contained herein are those of the authors and should not be 1534 interpreted as necessarily representing the official policies or 1535 endorsements, either expressed or implied, of the GreenICN project, 1536 the European Commission, or NICT. 1538 10. References 1540 10.1. Normative References 1542 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1543 Optimization (ALTO) Problem Statement", RFC 5693, 1544 DOI 10.17487/RFC5693, October 2009, . 1547 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1548 Distribution Network Interconnection (CDNI) Problem 1549 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1550 2012, . 1552 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1553 Autonomous System (AS) Number Space", RFC 6793, 1554 DOI 10.17487/RFC6793, December 2012, . 1557 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1558 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1559 "Application-Layer Traffic Optimization (ALTO) Protocol", 1560 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1561 . 1563 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1564 "Framework for Content Distribution Network 1565 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1566 August 2014, . 1568 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1569 "Content Delivery Network Interconnection (CDNI) 1570 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1571 . 1573 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1574 R., and K. Ma, "Content Delivery Network Interconnection 1575 (CDNI) Request Routing: Footprint and Capabilities 1576 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1577 . 1579 [ISO3166-1] 1580 The International Organization for Standardization, "Codes 1581 for the representation of names of countries and their 1582 subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 1583 2013. 1585 10.2. Informative References 1587 [I-D.ietf-alto-path-vector] 1588 Bernstein, G., Chen, S., Lee, Y., Roome, W., Scharf, M., 1589 Yang, Y., and J. Zhang, "ALTO Extension: Path Vector Cost 1590 Type", draft-ietf-alto-path-vector-04 (work in progress), 1591 July 2018. 1593 [I-D.ietf-alto-incr-update-sse] 1594 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1595 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1596 sse-07 (work in progress), July 2017. 1598 [I-D.jenkins-alto-cdn-use-cases] 1599 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 1600 S. Previdi, "Use Cases for ALTO within CDNs", draft- 1601 jenkins-alto-cdn-use-cases-03 (work in progress), June 1602 2012. 1604 [I-D.ietf-alto-unified-props-new] 1605 Roome, W. and Y. Yang, "Extensible Property Maps for the 1606 ALTO Protocol", draft-ietf-alto-unified-props-new-00 (work 1607 in progress), July 2017. 1609 Authors' Addresses 1611 Jan Seedorf 1612 HFT Stuttgart - Univ. of Applied Sciences 1613 Schellingstrasse 24 1614 Stuttgart 70174 1615 Germany 1617 Phone: +49-0711-8926-2801 1618 Email: jan.seedorf@hft-stuttgart.de 1620 Y.R. Yang 1621 Tongji/Yale University 1622 51 Prospect Street 1623 New Haven, CT 06511 1624 United States of America 1626 Email: yry@cs.yale.edu 1627 URI: http://www.cs.yale.edu/~yry/ 1629 Kevin J. Ma 1630 Ericsson 1631 43 Nagog Park 1632 Acton, MA 01720 1633 United States of America 1635 Phone: +1-978-844-5100 1636 Email: kevin.j.ma@ericsson.com 1637 Jon Peterson 1638 NeuStar 1639 1800 Sutter St Suite 570 1640 Concord, CA 94520 1641 United States of America 1643 Email: jon.peterson@neustar.biz 1645 Xiao Shawn Lin 1646 Tongji University 1647 4800 Cao'an Hwy 1648 Shanghai 201804 1649 China 1651 Email: x.shawn.lin@gmail.com