idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 397: '... the network map MUST be included in "...' RFC 2119 keyword, line 399: '...sources, "uses" field MUST NOT appear....' RFC 2119 keyword, line 403: '...FCI map response MUST include the "vta...' RFC 2119 keyword, line 408: '... map, it MUST include the "dependent...' RFC 2119 keyword, line 450: '...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 (March 11, 2019) is 1872 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) -- 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 ** Downref: Normative reference to an Informational RFC: RFC 7336 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-07 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-04 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-00 Summary: 6 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: September 12, 2019 Tongji/Yale 6 K. Ma 7 Ericsson 8 J. Peterson 9 Neustar 10 X. Lin 11 Tongji 12 March 11, 2019 14 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 15 Footprint and Capabilities Advertisement using ALTO 16 draft-ietf-alto-cdni-request-routing-alto-05 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 https://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 September 12, 2019. 49 Copyright Notice 51 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 6.1. Representing Footprint Objects as Unified Property Map 102 Entities . . . . . . . . . . . . . . . . . . . . . . . . 27 103 6.1.1. ASN Domain . . . . . . . . . . . . . . . . . . . . . 27 104 6.1.2. COUNTRYCODE Domain . . . . . . . . . . . . . . . . . 27 105 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28 106 6.2.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 28 107 6.2.2. Property Map Example . . . . . . . . . . . . . . . . 28 108 6.2.3. Filtered Property Map Example . . . . . . . . . . . . 30 109 6.2.4. Incremental Updates Example . . . . . . . . . . . . . 31 110 7. Design Decisions and Discussions . . . . . . . . . . . . . . 32 111 7.1. Table versus Map . . . . . . . . . . . . . . . . . . . . 32 112 7.2. Filter-based Query versus Test-based Query . . . . . . . 33 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 114 8.1. CDNI Metadata Footprint Type Registry . . . . . . . . . . 33 115 8.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 33 116 8.3. ALTO CDNI FCI Property Type Registry . . . . . . . . . . 34 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 118 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 120 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 121 11.2. Informative References . . . . . . . . . . . . . . . . . 37 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 124 1. Introduction 126 The ability to interconnect multiple content delivery networks (CDNs) 127 has many benefits, including increased coverage, capability, and 128 reliability. The Content Delivery Networks Interconnection (CDNI) 129 framework [RFC6707] defines four interfaces to achieve 130 interconnection of CDNs: (1) the CDNI Request Routing Interface; (2) 131 the CDNI Metadata Interface; (3) the CDNI Logging Interface; and (4) 132 the CDNI Control Interface. 134 Among the four interfaces, the CDNI Request Routing Interface 135 provides key functions, as specified in [RFC6707]: "The CDNI Request 136 Routing interface enables a Request Routing function in an Upstream 137 CDN to query a Request Routing function in a Downstream CDN to 138 determine if the Downstream CDN is able (and willing) to accept the 139 delegated Content Request. It also allows the Downstream CDN to 140 control what should be returned to the User Agent in the redirection 141 message by the upstream Request Routing function." On a high level, 142 the scope of the CDNI Request Routing Interface, therefore, contains 143 two main tasks: (1) determining if the downstream CDN (dCDN) is 144 willing to accept a delegated content request; (2) redirecting the 145 content request coming from an upstream CDN (uCDN) to the proper 146 entry point or entity in the downstream CDN. 148 Correspondingly, the request routing interface is broadly divided 149 into two functionalities: (1) CDNI Footprint & Capabilities 150 Advertisement interface (FCI); (2) CDNI Request Routing Redirection 151 interface (RI). Since this document focuses on the first 152 functionality, CDNI FCI, we will describe it in a more detailed way. 153 CDNI FCI is an advertisement from a dCDN to a uCDN (push) or a query 154 from a uCDN to a dCDN (pull) so that the uCDN knows whether it can 155 redirect a particular user request to that dCDN. 157 A key component in defining CDNI FCI is defining objects describing 158 the footprints and capabilities of a dCDN. Such objects are already 159 in [RFC8008]. A protocol to transport and update such objects 160 between a uCDN and a dCDN, however, is not defined. Hence, the scope 161 of this document is to define such a protocol by introducing a new 162 Application-Layer Traffic Optimization (ALTO) [RFC7285] service 163 called "CDNI FCI Map Service". 165 There are multiple benefits in using ALTO as a transport protocol, as 166 we discuss in Section 2.2. 168 The rest of this document is organized as follows. Section 2 169 provides non-normative background on both CDNI FCI and ALTO. 170 Section 3 introduces the most basic service, called CDNI FCI Map, to 171 realize CDNI FCI using ALTO. Section 4 demonstrates a key benefit of 172 using ALTO: the ability to integrate CDNI FCI with ALTO network maps. 173 Such integration provides a new granularity to describe footprints. 174 Section 5 builds on filtered ALTO maps to introduce filtered CDNI FCI 175 maps using capabilities so that a uCDN can get footprints with given 176 capabilities instead of getting the full map which can be huge. 177 Section 6 further shows a benefit of using ALTO: the ability to query 178 footprint properties using ALTO unified properties. In this way, a 179 uCDN can effectively fetch capabilities of some footprints in which 180 it is interested. IANA and security considerations are discussed in 181 Section 8 and Section 9 respectively. 183 Throughout this document, we use the terminology for CDNI defined in 184 [RFC6707], [RFC8006], [RFC8008] and we use the terminology for ALTO 185 defined in [RFC7285], [I-D.ietf-alto-unified-props-new]. 187 2. Background 189 The design of CDNI FCI transport using ALTO depends on the 190 understanding of both FCI semantics and ALTO. Hence, we start with a 191 review of both. 193 2.1. Semantics of FCI Advertisement 195 The CDNI document on "Footprint and Capabilities Semantics" [RFC8008] 196 defines the semantics of CDNI FCI, and provides guidance on what 197 Footprint and Capabilities mean in a CDNI context and how a protocol 198 solution should in principle look like. The definitions in [RFC8008] 199 depend on [RFC8006]. Here we briefly summarize key related points of 200 [RFC8008] and [RFC8006]. For a detailed discussion, the reader is 201 referred to the RFCs. 203 o Footprint and capabilities are tied together and cannot be 204 interpreted independently from each other. Hence, capabilities 205 must be expressed on a per footprint basis. [RFC8008] integrates 206 footprint and capabilities with an approach of "capabilities with 207 footprint restrictions". 209 o Given that a large part of Footprint and Capabilities 210 Advertisement will actually happen in contractual agreements, the 211 semantics of CDNI Footprint and Capabilities advertisement refers 212 to answering the following question: what exactly still needs to 213 be advertised by the CDNI FCI? For instance, updates about 214 temporal failures of part of a footprint can be useful information 215 to convey via the CDNI request routing interface. Such 216 information would provide updates on information previously agreed 217 in contracts between the participating CDNs. In other words, the 218 CDNI FCI is a means for a dCDN to provide changes/updates 219 regarding a footprint and/or capabilities that it has prior agreed 220 to serve in a contract with a uCDN. Hence, server push and 221 incremental encoding will be necessary techniques. 223 o Multiple types of footprints (ipv4cidr, ipv6cidr, asn and 224 countrycode) are defined in [RFC8006]. 226 o A "Set of IP-prefixes" can contain both full IP addresses (i.e., a 227 /32 for IPv4 and a /128 for IPv6) and IP prefixes with an 228 arbitrary prefix length. There must also be support for multiple 229 IP address versions, i.e., IPv4 and IPv6, in such a footprint. 231 o For all of these mandatory-to-implement footprint types, 232 footprints can be viewed as constraints for delegating requests to 233 a dCDN: A dCDN footprint advertisement tells the uCDN the 234 limitations for delegating a request to the dCDN. For IP prefixes 235 or ASN(s), the footprint signals to the uCDN that it should 236 consider the dCDN a candidate only if the IP address of the 237 request routing source falls within the prefix set (or ASN, 238 respectively). The CDNI specifications do not define how a given 239 uCDN determines what address ranges are in a particular ASN. 240 Similarly, for country codes, a uCDN should only consider the dCDN 241 a candidate if it covers the country of the request routing 242 source. The CDNI specifications do not define how a given uCDN 243 determines the country of the request routing source. Multiple 244 footprint constraints are additive, i.e., the advertisement of 245 different types of footprint narrows the dCDN candidacy 246 cumulatively. 248 o The following capabilities are defined as "base" capabilities; 249 that is, they are required in all cases and therefore constitute 250 mandatory capabilities to be supported by the CDNI FCI: (1) 251 Delivery Protocol; (2) Acquisition Protocol; (3) Redirection Mode; 252 (4) Capabilities related to CDNI Logging; (5) Capabilities related 253 to CDNI Metadata. 255 2.2. ALTO Background and Benefits 257 Application-Layer Traffic Optimization (ALTO) [RFC7285] is an 258 approach for guiding the resource provider selection process in 259 distributed applications that can choose among several candidate 260 resources providers to retrieve a given resource. By conveying 261 network layer (topology) information, an ALTO server can provide 262 important information to "guide" the resource provider selection 263 process in distributed applications. Usually, it is assumed that an 264 ALTO server conveys information that these applications cannot or 265 have difficulty to measure themselves [RFC5693]. 267 Originally, ALTO was motivated by optimizing cross-ISP traffic 268 generated by P2P applications [RFC5693]. Recently, however, ALTO is 269 also being considered for improving the request routing in CDNs 270 [I-D.jenkins-alto-cdn-use-cases]. The CDNI problem statement 271 explicitly mentions ALTO as a candidate protocol for "actual 272 algorithms for selection of CDN or Surrogate by Request-Routing 273 systems" [RFC6707]. 275 The following reasons make ALTO a suitable candidate protocol for 276 downstream CDN selection as part of CDNI request routing and in 277 particular for an FCI protocol: 279 o ALTO is a protocol specifically designed to improve application 280 layer traffic (and application layer connections among hosts on 281 the Internet) by providing additional information to applications 282 that these applications could not easily retrieve themselves. For 283 CDNI, this is exactly the case: a uCDN wants to improve 284 application layer CDN request routing by using dedicated 285 information (provided by a dCDN) that the uCDN could not easily 286 obtain otherwise. ALTO can help a uCDN to select a proper dCDN by 287 first providing dCDNs' capabilities as well as footprints (see 288 Section 3) and then providing costs of surrogates in a dCDN by 289 ALTO cost maps. 291 o The semantics of an ALTO network map is an exact match for the 292 needed information to convey a footprint by a downstream CDN, in 293 particular if such a footprint is being expressed by IP-prefix 294 ranges. Please see Section 4. 296 o Security: Identifications between uCDNs and dCDNs are extremely 297 important. ALTO maps can be signed and hence provide inherent 298 integrity protection. Please see Section 9. 300 o RESTful-Design: The ALTO protocol has undergone extensive 301 revisions in order to provide a RESTful design regarding the 302 client-server interaction specified by the protocol. A CDNI FCI 303 interface based on ALTO would inherit this RESTful design. Please 304 see Section 3. 306 o Error-handling: The ALTO protocol has undergone extensive 307 revisions in order to provide sophisticated error-handling, in 308 particular regarding unexpected cases. A CDNI FCI interface based 309 on ALTO would inherit this thought-through and mature error- 310 handling. Please see Section 5. 312 o Filtered map service: The ALTO map filtering service would allow a 313 uCDN to query only for parts of an ALTO map. For example, 314 filtered unified property map service can enable a uCDN to query 315 properties of a part of footprints in an effective way (see 316 Section 6). 318 o Server-initiated Notifications and Incremental Updates: When the 319 footprint or the capabilities of a downstream CDN change (i.e., 320 unexpectedly from the perspective of an upstream CDN), server- 321 initiated notifications would enable a dCDN to directly inform an 322 upstream CDN about such changes. Consider the case where - due to 323 failure - part of the footprint of the dCDN is not functioning, 324 i.e., the CDN cannot serve content to such clients with reasonable 325 QoS. Without server-initiated notifications, the uCDN might still 326 use a very recent network and cost map from dCDN, and therefore 327 redirect requests to dCDN which it cannot serve. Similarly, the 328 possibility for incremental updates would enable efficient 329 conveyance of the aforementioned (or similar) status changes by 330 the dCDN to the uCDN. The newest design of ALTO supports server 331 pushed incremental updates [I-D.ietf-alto-incr-update-sse]. 333 o Content Availability on Hosts: A dCDN might want to express CDN 334 capabilities in terms of certain content types (e.g., codecs/ 335 formats, or content from certain content providers). The new 336 endpoint property for ALTO would enable a dCDN to make such 337 information available to an upstream CDN. This would enable a 338 uCDN to determine if a given dCDN actually has the capabilities 339 for a given request with respect to the type of content requested. 341 o Resource Availability on Hosts or Links: The capabilities on links 342 (e.g. maximum bandwidth) or caches (e.g. average load) might be 343 useful information for an upstream CDN for optimized downstream 344 CDN selection. For instance, if a uCDN receives a streaming 345 request for content with a certain bitrate, it needs to know if it 346 is likely that a dCDN can fulfill such stringent application-level 347 requirements (i.e., can be expected to have enough consistent 348 bandwidth) before it redirects the request. In general, if ALTO 349 could convey such information via new endpoint properties, it 350 would enable more sophisticated means for downstream CDN selection 351 with ALTO. ALTO Path Vector Extension [I-D.ietf-alto-path-vector] 352 is designed to allow ALTO clients to query information such as 353 capacity regions for a given set of flows. 355 3. CDNI FCI Map 357 The ALTO protocol is based on an ALTO Information Service Framework 358 which consists of several services, where all ALTO services are 359 "provided through a common transport protocol, messaging structure 360 and encoding, and transaction model" [RFC7285]. The ALTO protocol 361 specification [RFC7285] defines several such services, e.g. the ALTO 362 map service. 364 This document defines a new ALTO Map Service called "CDNI FCI Map 365 Service" which conveys JSON objects of media type "application/alto- 366 cdnifcimap+json". These JSON objects are used to transport 367 BaseAdvertisementObject objects defined in [RFC8008]; this document 368 specifies how to transport such BaseAdvertisementObject objects via 369 the ALTO protocol with the ALTO "CDNI FCI Map Service". Given that 370 the "CDNI FCI Map Service" is very similar in structure to the two 371 already defined map services (network maps and cost maps), the 372 specification of CDNI FCI Map below uses the same specification 373 structure for Cost Map specification in Section 11.2.3 of [RFC7285] 374 when specifying cost maps. 376 3.1. Media Type 378 The media type of the CDNI FCI Map is "application/alto- 379 cdnifcimap+json". 381 3.2. HTTP Method 383 A CDNI FCI map resource is requested using the HTTP GET method. 385 3.3. Accept Input Parameters 387 None. 389 3.4. Capabilities 391 None. 393 3.5. Uses 395 The resource ID of the resource based on which the CDNI FCI map will 396 be defined. For example, if a CDNI FCI map depends on a network map, 397 the resource ID of the network map MUST be included in "uses" field. 398 Please see Section 4 for details. If the CDNI FCI map does not 399 depend on any other resources, "uses" field MUST NOT appear. 401 3.6. Response 403 The "meta" field of a CDNI FCI map response MUST include the "vtag" 404 field defined in Section 10.3 of [RFC7285]. This field provides the 405 version of the retrieved CDNI FCI map. 407 If a CDNI FCI map response depends on a resource such as a network 408 map, it MUST include the "dependent-vtags" field, whose value is an 409 array to indicate the version tags of the resources used, where each 410 resource is specified in "uses" of the IRD. The current defined 411 dependent resource is only network map, and the usage of it is 412 described in Section 4. 414 The data component of an ALTO CDNI FCI map response is named "cdni- 415 fci-map", which is a JSON object of type CDNIFCIMapData: 417 object { 418 CDNIFCIMapData cdni-fci-map; 419 } InfoResourceCDNIFCIMap : ResponseEntityBase; 421 object { 422 BaseAdvertisementObject capabilities<1..*>; 423 } CDNIFCIMapData; 425 Specifically, a CDNIFCIMapData object is a JSON object that includes 426 only one property named "capabilities", whose value is an array of 427 BaseAdvertisementObject objects. 429 The syntax and semantics of BaseAdvertisementObject are well defined 430 in Section 5.1 of [RFC8008]. A BaseAdvertisementObject object 431 includes multiple properties, including capability-type, capability- 432 value and footprints, where footprints are defined in Section 4.2.2.2 433 of [RFC8006]. 435 To be self-contained, we give a non-normative specification of 436 BaseAdvertisementObject below. As mentioned above, the normative 437 specification of BaseAdvertisementObject is in [RFC8008] 439 object { 440 JSONString capability-type; 441 JSONValue capability-value; 442 Footprint footprints<0..*>; 443 } BaseAdvertisementObject; 445 object { 446 JSONString footprint-type; 447 JSONString footprint-value<1..*>; 448 } Footprint; 450 For each BaseAdvertisementObject, the ALTO client MUST interpret 451 footprints appearing multiple times as if they appeared only once. 452 If footprints in a BaseAdvertisementObject is null or empty or not 453 appearing, the ALTO client MUST understand that the capabilities in 454 this BaseAdvertisementObject have the "global" coverage. 456 Note: Further optimization of BaseAdvertisement objects to 457 effectively provide the advertisement of capabilities with footprint 458 restrictions is certainly possible. For example, these two examples 459 below both describe that the dCDN can provide capabilities 460 ["http/1.1", "https/1.1"] for the same footprints. However, the 461 latter one is smaller in its size. 463 EXAMPLE 1 464 { 465 "meta" : {...}, 466 "cdni-fci-map": { 467 "capabilities": [ 468 { 469 "capability-type": "FCI.DeliveryProtocol", 470 "capability-value": { 471 "delivery-protocols": [ 472 "http/1.1" 473 ] 474 }, 475 "footprints": [ 476 478 ] 479 }, 480 { 481 "capability-type": "FCI.DeliveryProtocol", 482 "capability-value": { 483 "delivery-protocols": [ 484 "https/1.1" 485 ] 486 }, 487 "footprints": [ 488 489 ] 490 } 491 ] 492 } 493 } 495 EXAMPLE 2 496 { 497 "meta" : {...}, 498 "cdni-fci-map": { 499 "capabilities": [ 500 { 501 "capability-type": "FCI.DeliveryProtocol", 502 "capability-value": { 503 "delivery-protocols": [ 504 "https/1.1", 505 "http/1.1" 506 ] 507 }, 508 "footprints": [ 509 510 ] 511 } 512 ] 513 } 514 } 516 Since such optimizations are not necessary for the basic 517 interconnection of CDNs, the specifics of such mechanisms are outside 518 the scope of this document. 520 3.7. Examples 521 3.7.1. IRD Example 523 Below is the information resource directory (IRD) of a simple, 524 example ALTO server. The server provides both base ALTO information 525 resources (e.g., network maps) and CDNI FCI information resources 526 (e.g., CDNI FCI map), demonstrating a single, integrated environment. 528 Specifically, the IRD announces two network maps, one CDNI FCI map 529 without dependency, one CDNI FCI map depending on a network map, one 530 filtered CDNI FCI map to be defined in Section 5, one unified 531 property map including "cdni-fci-capabilities" as its entities' 532 property, one filtered unified property map including "cdni-fci- 533 capabilities" and "pid" as its entities' properties, and two update 534 stream services (one for updating CDNI FCI maps, and the other for 535 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-map": { 553 "uri" : "http://alto.example.com/cdnifcimap", 554 "media-type": "application/alto-cdnifcimap+json" 555 }, 556 "my-filtered-cdnifci-map" : { 557 "uri" : "http://alto.example.com/cdnifcimap/filtered", 558 "media-type" : "application/alto-cdnifcimap+json", 559 "accepts" : "application/alto-cdnifcimapfilter+json", 560 "uses" : [ "my-default-cdnifci-map" ] 561 }, 562 "my-cdnifci-map-with-network-map-footprints": { 563 "uri" : "http://alto.example.com/networkcdnifcimap", 564 "media-type" : "application/alto-cdnifcimap+json", 565 "uses" : [ "my-eu-netmap" ] 566 }, 567 "cdnifci-property-map" : { 568 "uri" : "http://alto.example.com/propmap/full/cdnifci", 569 "media-type" : "application/alto-propmap+json", 570 "capabilities" : { 571 "domain-types" : [ "ipv4", "ipv6", "coutrycode", "asn" ], 572 "prop-types" : [ "cdni-fci-capabilities" ] 573 } 574 }, 575 "filtered-cdnifci-property-map" : { 576 "uri" : "http://alto.example.com/propmap/lookup/cdnifci-pid", 577 "media-type" : "application/alto-propmap+json", 578 "accepts" : "application/alto-propmapparams+json", 579 "capabilities" : { 580 "domain-types" : [ "ipv4", "ipv6", "coutrycode", "asn" ], 581 "prop-types" : [ "cdni-fci-capabilities", "pid" ] 582 } 583 }, 584 "update-my-cdni-fci-maps" : { 585 "uri": "http:///alto.example.com/updates/cdnifcimaps", 586 "media-type" : "text/event-stream", 587 "accepts" : "application/alto-updatestreamparams+json", 588 "uses" : [ 589 "my-default-network-map", 590 "my-eu-netmap", 591 "my-default-cdnifci-map", 592 "my-filtered-cdnifci-map" 593 "my-cdnifci-map-with-network-map-footprints" 594 ], 595 "capabilities" : { 596 "incremental-change-media-types" : { 597 "my-default-network-map" : "application/json-patch+json", 598 "my-eu-netmap" : "application/json-patch+json", 599 "my-default-cdnifci-map" : 600 "application/merge-patch+json,application/json-patch+json", 601 "my-filtered-cdnifci-map" : 602 "application/merge-patch+jso,application/json-patch+json", 603 "my-cdnifci-map-with-network-map-footprints" : 604 "application/merge-patch+json,application/json-patch+json" 605 } 606 } 607 }, 608 "update-my-props": { 609 "uri" : "http://alto.example.com/updates/properties", 610 "media-type" : "text/event-stream", 611 "uses" : [ 612 "cdnifci-property-map", 613 "filtered-cdnifci-property-map" 614 ], 615 "capabilities" : { 616 "incremental-change-media-types": { 617 "cdnifci-property-map" : 618 "application/merge-patch+json,application/json-patch+json", 619 "filtered-cdnifci-property-map": 620 "application/merge-patch+json,application/json-patch+json" 621 } 622 } 623 } 624 } 625 } 627 3.7.2. Basic Example 629 In this example, we demonstrate a simple CDNI FCI map; this map does 630 not depend on other resources. There are three 631 BaseAdvertisementObjects in this map and these objects' capabilities 632 are http/1.1 delivery protocol, [http/1.1, https/1.1] delivery 633 protocol and https/1.1 acquisition protocol respectively. 635 GET /cdnifcimap HTTP/1.1 636 Host: alto.example.com 637 Accept: application/alto-cdnifcimap+json 638 Accept: application/alto-error+json 640 HTTP/1.1 200 OK 641 Content-Length: XXX 642 Content-Type: application/alto-cdnifcimap+json 643 { 644 "meta" : { 645 "vtag": { 646 "resource-id": "my-default-cdnifci-map", 647 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 648 } 649 }, 650 "cdni-fci-map": { 651 "capabilities": [ 652 { 653 "capability-type": "FCI.DeliveryProtocol", 654 "capability-value": { 655 "delivery-protocols": [ 656 "http/1.1" 657 ] 658 }, 659 "footprints": [ 660 661 ] 662 }, 663 { 664 "capability-type": "FCI.DeliveryProtocol", 665 "capability-value": { 666 "delivery-protocols": [ 667 "https/1.1", 668 "http/1.1" 669 ] 670 }, 671 "footprints": [ 672 673 ] 674 }, 675 { 676 "capability-type": "FCI.AcquisitionProtocol", 677 "capability-value": { 678 "acquisition-protocols": [ 679 "https/1.1" 680 ] 681 }, 682 "footprints": [ 683 684 ] 685 } 686 ] 687 } 688 } 690 3.7.3. Incremental Updates Example 692 A benefit of using ALTO to provide CDNI FCI maps is that such maps 693 can be updated using ALTO incremental updates. Below is an example 694 that also shows the benefit of having both JSON merge patch and JSON 695 patch to encode updates. 697 At first, an ALTO client requests the ALTO server updates for "my- 698 default-cdnifci-map", and the ALTO server returns the "control-uri" 699 followed by the full CDNI FCI map. Then when there is a huge change 700 in footprint objects in delivery-protocol http/1.1, the ALTO server 701 uses JSON merge patch to encode the change and sends it to the ALTO 702 client. Later on, the ALTO server notifies the ALTO client that 703 "ipv4:192.0.2.0/24" is added into the footprints in delivery-protocol 704 http/1.1 by sending the change encoded by JSON patch to the ALTO 705 client. 707 POST /updates/cdnifcimaps HTTP/1.1 708 Host: alto.example.com 709 Accept: text/event-stream,application/alto-error+json 710 Content-Type: application/alto-updatestreamparams+json 711 Content-Length: ### 712 { "add": { 713 "my-cdnifci-stream": { 714 "resource-id": "my-default-cdnifci-map" 715 } 716 } 718 HTTP/1.1 200 OK 719 Connection: keep-alive 720 Content-Type: text/event-stream 722 event: application/alto-updatestreamcontrol+json 723 data: {"control-uri": 724 data: "http://alto.example.com/updates/streams/3141592653589"} 726 event: application/alto-cdnifcimap+json,my-default-cdnifci-map 727 data: { ... full CDNI FCI map ... } 729 event: application/merge-patch+json,my-default-cdnifci-map 730 data: { 731 data: "meta": { 732 data: "vtag": { 733 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 734 data: } 735 data: }, 736 data: { 737 data: "capability-type": "FCI.DeliveryProtocol", 738 data: "capability-value": { 739 data: "delivery-protocols": [ 740 data: "http/1.1" 741 data: ] 742 data: }, 743 data: "footprints": [ 744 data: 746 data: ] 747 data: } 748 data: } 750 event: application/json-patch+json,my-default-cdnifci-map 751 data: [ 752 data: { 753 data: "op": "replace", 754 data: "path": "/meta/vtag/tag", 755 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 756 data: }, 757 data: { "op": "add", 758 data: "path": "/cdni-fci-map/capabilities/0/footprints/-", 759 data: "value": "ipv4:192.0.2.0/24" 760 data: } 761 data: ] 763 4. CDNI FCI Map using ALTO Network Map 765 4.1. Network Map Footprint Type: altonetworkmap 767 In addition to the already defined CDNI footprint types (e.g., 768 ipv4cidr, ipv6cidr, asn, countrycode), ALTO network maps can be a 769 type of FCI footprint. 771 Specifically, CDNI footprints using ALTO network maps should use a 772 new CDNI Footprint Type called "altonetworkmap". 774 "altonetworkmap" footprint type indicates that the corresponding 775 footprint value is a list of PIDNames as defined in [RFC7285]. These 776 PIDNames are references of PIDs in a network map resource. Hence a 777 CDNI FCI map with "altonetworkmap" footprints depends on a network 778 map. For such a CDNI FCI map, the "dependent-vtag" field with a 779 reference to a network map it depends on MUST be included in it (see 780 the example in Section 4.2.3). 782 4.2. Examples 784 4.2.1. IRD Example 786 We use the same IRD example given in Section 3.7.1. 788 4.2.2. ALTO Network Map for CDNI FCI Footprints Example 790 Below is an example network map whose resource id is "my-eu-netmap", 791 and this map is referenced by the CDNI FCI map example in 792 Section 4.2.3. 794 GET /networkmap HTTP/1.1 795 Host: http://alto.example.com/myeunetmap 796 Accept: application/alto-networkmap+json,application/alto-error+json 797 HTTP/1.1 200 OK 798 Content-Length: XXX 799 Content-Type: application/alto-networkmap+json 801 { 802 "meta" : { 803 "vtag": [ 804 {"resource-id": "my-eu-netmap", 805 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 806 } 807 ] 808 }, 809 "network-map" : { 810 "south-france" : { 811 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] 812 }, 813 "germany" : { 814 "ipv4" : [ "192.0.3.0/24"] 815 } 816 } 817 } 819 4.2.3. ALTO Network Map Footprints in CDNI FCI Map 821 In this example, we show a CDNI FCI map that depends on a network map 822 described in Section 4.2.2. 824 GET /networkcdnifcimap HTTP/1.1 825 Host: alto.example.com 826 Accept: application/alto-cdnifcimap+json,application/alto-error+json 827 HTTP/1.1 200 OK 828 Content-Length: 618 829 Content-Type: application/alto-cdnifcimap+json 831 { 832 "meta" : { 833 "dependent-vtags" : [ 834 { 835 "resource-id": "my-eu-netmap", 836 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 837 } 838 ] 839 }, 840 "cdni-fci-map": { 841 "capabilities": [ 842 { "capability-type": "FCI.DeliveryProtocol", 843 "capability-value": [ 844 "http/1.1" 845 ] 846 }, 847 { "capability-type": "FCI.DeliveryProtocol", 848 "capability-value": [ 849 "https/1.1" 850 ], 851 "footprints": [ 852 { "footprint-type": "altonetworkmap", 853 "footprint-value": [ 854 "germany", 855 "south-france" 856 ] 857 } 858 ] 859 } 860 ] 861 } 862 } 864 4.2.4. Incremental Updates Example 866 In this example, the ALTO client is interested in changes of "my- 867 cdnifci-map-with-network-map-footprints". Considering two changes, 868 the first one is to change footprints of http/1.1 Delivery Protocol 869 capability, and the second one is to remove "south-france" from the 870 footprints of https/1.1 delivery protocol capability. 872 POST /updates/cdnifcimaps HTTP/1.1 873 Host: alto.example.com 874 Accept: text/event-stream,application/alto-error+json 875 Content-Type: application/alto-updatestreamparams+json 876 Content-Length: ### 878 { "add": { 879 "my-network-map-cdnifci-stream": { 880 "resource-id": "my-cdnifci-map-with-network-map-footprints" 881 } 882 } 884 HTTP/1.1 200 OK 885 Connection: keep-alive 886 Content-Type: text/event-stream 888 event: application/alto-updatestreamcontrol+json 889 data: {"control-uri": 890 data: "http://alto.example.com/updates/streams/3141592653590"} 892 event: application/alto-cdnifcimap+json,my-fci-stream 893 data: { ... full CDNI FCI map ... } 895 event: application/merge-patch+json,my-fci-stream 896 data: { 897 data: "meta": { 898 data: "dependent-vtags" : [ 899 data: { 900 data: "resource-id": "my-eu-netmap", 901 data: "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 902 data: } 903 data: ], 904 data: "vtag": { 905 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 906 data: } 907 data: }, 908 data: { 909 data: "capability-type": "FCI.DeliveryProtocol", 910 data: "capability-value": { 911 data: "delivery-protocols": [ 912 data: "http/1.1" 913 data: ] 914 data: }, 915 data: "footprints": [ 916 data: 918 data: ] 919 data: } 920 data: } 922 event: application/json-patch+json,my-fci-stream 923 data: [ 924 data: { 925 data: "op": "replace", 926 data: "path": "/meta/vtag/tag", 927 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 928 data: }, 929 data: { "op": "remove", 930 data: "path": "/cdni-fci-map/capabilities/2/footprints/0/ 931 data: footprint-value/1", 932 data: } 933 data: ] 935 5. Filtered CDNI FCI Map using Capabilities 937 Section 3 and Section 4 describe CDNI FCI Map Service which can be 938 used to enable a uCDN to get capabilities with footprints constrains 939 from dCDNs. However, always getting full CDNI FCI maps from dCDNs is 940 very inefficient, hence we introduce a new service named "Filtered 941 CDNI FCI Map Service" to allow a client to filter a CDNI FCI map 942 using a client-given set of capabilities. For each entry of the CDNI 943 FCI map, only if the entry contains at least one of the client-given 944 capabilities will it be returned to the client. The relationship 945 between a filtered CDNI FCI map and a CDNI FCI map is similar to the 946 relationship between a filtered network/cost map and a network/cost 947 map. 949 5.1. Media Type 951 Since a filtered CDNI FCI map is still a CDNI FCI map, it uses the 952 media type defined for CDNI FCI maps in Section 3.1. 954 5.2. HTTP Method 956 A filtered CDNI FCI map is requested using the HTTP POST method. 958 5.3. Accept Input Parameters 960 The input parameters for a filtered CDNI FCI map are supplied in the 961 entity body of the POST request. This document specifies the input 962 parameters with a data format indicated by the media type 963 "application/alto-cdnifcifilter+json" which is a JSON object of type 964 ReqFilteredCDNIFCIMap, where: 966 object { 967 JSONString capability-type; 968 JSONValue capability-value; 969 } CDNIFCICapability; 971 object { 972 [CDNIFCICapability cdni-fci-capabilities<0..*>;] 973 } ReqFilteredCDNIFCIMap; 975 with fields: 977 capability-type: The same as Base Advertisement Object's capability- 978 type defined in Section 5.1 of [RFC8008]. 980 capability-value: The same as Base Advertisement Object's 981 capability-value defined in Section 5.1 of [RFC8008]. 983 cdni-fci-capabilities: A list of CDNI FCI capabilities defined in 984 Section 5.1 of [RFC8008] for which footprints are to be returned. 985 If a list is empty or not appearing, the ALTO server MUST 986 interpret it as a request for the full CDNI FCI Map. The ALTO 987 server MUST interpret entries appearing in a list multiple times 988 as if they appeared only once. If a "capability-type" or a 989 "capability-value" is not defined, the ALTO server MUST ignore 990 this capability. If there is only one capability in the list and 991 its "capability-type" or "capability-value" is not defined, the 992 ALTO server MUST return nothing. 994 5.4. Capabilities 996 None. 998 5.5. Uses 1000 The resource ID of the CDNI FCI map based on which the filtering is 1001 performed. 1003 5.6. Response 1005 The response MUST indicate an error, using ALTO protocol error 1006 handling specified in Section 8.5 of the ALTO protocol [RFC7285], if 1007 the request is invalid. 1009 Specifically, a filtered CDNI FCI map request can be invalid as 1010 follows: 1012 o The value of "capability-type" is null; 1013 o The value of "capability-value" is null; 1015 o The value of "capability-value" is inconsistent with "capability- 1016 type". 1018 When the request is invalid, the ALTO server MUST return an 1019 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], 1020 and the "value" field of the error message SHOULD indicate this CDNI 1021 FCI capability. 1023 The ALTO server return a filtered CDNI FCI map for a valid request. 1024 The format of a filtered CDNI FCI map is the same as an unfiltered 1025 CDNI FCI map. See Section 3.6 for the format. 1027 The returned CDNI FCI map MUST contain only BaseAdvertisementObject 1028 objects whose CDNI capability object is the superset of one of CDNI 1029 capability object in "cdni-fci-capabilities". Specifically, that a 1030 CDNI capability object A is the superset of another CDNI capability 1031 object B means that these two CDNI capability objects have the same 1032 capability type and mandatory properties in capability value of A 1033 MUST include mandatory properties in capability value of B 1034 semantically. See Section 5.7.2 for a concrete example. 1036 The version tag included in the "vtag" field of the response MUST 1037 correspond to the full CDNI FCI map resource from which the filtered 1038 CDNI FCI map is provided. This ensures that a single, canonical 1039 version tag is used independently of any filtering that is requested 1040 by an ALTO client. 1042 5.7. Examples 1044 5.7.1. IRD Example 1046 We use the same IRD example by Section 3.7.1. 1048 5.7.2. Basic Example 1050 This example filters the full CDNI FCI map in Section 3.7.2 by 1051 selecting only http/1.1 delivery protocol capability. Only the first 1052 two BaseAdvertisementObjects in the full map will be returned because 1053 the first object's capability is http/1.1 delivery protocol and the 1054 second object's capability is http/1.1 and https/1.1 delivery 1055 protocols which is the superset of http/1.1 delivery protocol. 1057 POST /cdnifcimap/filtered HTTP/1.1 1058 HOST: alto.example.com 1059 Content-Type: application/cdnifilter+json 1060 Accept: application/alto-cdnifcimap+json 1061 { 1062 "cdni-fci-capabilities": [ 1063 { 1064 "capability-type": "FCI.DeliveryProtocol", 1065 "capability-value": { 1066 "delivery-protocols": [ 1067 "http/1.1" 1068 ] 1069 } 1070 } 1071 ] 1072 } 1074 HTTP/1.1 200 OK 1075 Content-Length: XXX 1076 Content-Type: application/alto-cdnifcimap+json 1077 { 1078 "meta" : { 1079 "vtag": { 1080 "resource-id": "my-default-cdnifci-map", 1081 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 1082 } 1083 }, 1084 "cdni-fci-map": { 1085 "capabilities": [ 1086 { 1087 "capability-type": "FCI.DeliveryProtocol", 1088 "capability-value": { 1089 "delivery-protocols": [ 1090 "http/1.1" 1091 ] 1092 }, 1093 "footprints": [ 1094 1095 ] 1096 }, 1097 { 1098 "capability-type": "FCI.DeliveryProtocol", 1099 "capability-value": { 1100 "delivery-protocols": [ 1101 "https/1.1", 1102 "http/1.1" 1103 ] 1104 }, 1105 "footprints": [ 1106 1107 ] 1108 } 1110 ] 1111 } 1112 } 1114 5.7.3. Incremental Updates Example 1116 In this example, the ALTO client only cares about the updates of one 1117 Delivery Protocol object whose value is "http/1.1". So it adds its 1118 limitation of capabilities in "input" field of the POST request. 1120 POST /updates/cdnifcimaps HTTP/1.1 1121 Host: fcialtoupdate.example.com 1122 Accept: text/event-stream,application/alto-error+json 1123 Content-Type: application/alto-updatestreamparams+json 1124 Content-Length: ### 1126 { "add": { 1127 "my-fci-stream": { 1128 "resource-id": "my-filtered-cdnifci-map", 1129 "input": { 1130 "cdni-fci-capabilities": [ 1131 { 1132 "capability-type": "FCI.DeliveryProtocol", 1133 "capability-value": { 1134 "delivery-protocols": [ 1135 "http/1.1" 1136 ] 1137 } 1138 } 1139 ] 1140 } 1141 } 1142 } 1143 } 1145 HTTP/1.1 200 OK 1146 Connection: keep-alive 1147 Content-Type: text/event-stream 1149 event: application/alto-updatestreamcontrol+json 1150 data: {"control-uri": 1151 data: "http://alto.example.com/updates/streams/3141592653590"} 1153 event: application/alto-cdnifcimap+json,my-fci-stream 1154 data: { ... full filtered CDNI FCI map ... } 1156 event: application/merge-patch+json,my-fci-stream 1157 data: { 1158 data: "meta": { 1159 data: "vtag": { 1160 data: "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716" 1161 data: } 1162 data: }, 1163 data: { 1164 data: "capability-type": "FCI.DeliveryProtocol", 1165 data: "capability-value": { 1166 data: "delivery-protocols": [ 1167 data: "http/1.1" 1168 data: ] 1169 data: }, 1170 data: "footprints": [ 1171 data: 1173 data: ] 1174 data: } 1175 data: } 1177 event: application/json-patch+json,my-fci-stream 1178 data: [ 1179 data: { 1180 data: "op": "replace", 1181 data: "path": "/meta/vtag/tag", 1182 data: "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" 1183 data: }, 1184 data: { "op": "add", 1185 data: "path": "/cdni-fci-map/capabilities/0/footprints/-", 1186 data: "value": "ipv4:192.0.2.0/24" 1187 data: } 1188 data: ] 1190 6. Query Footprint Properties using ALTO Unified Property Service 1192 Above sections describe how a uCDN can get the whole capabilities and 1193 footprints from dCDNs and how a uCDN can get the footprints of given 1194 capabilities. But there is another important case which is how a 1195 uCDN can get properties (i.e., capabilities) of given footprints. 1197 The most natrual way to solve this problem is to use ALTO unified 1198 property map defined in [I-D.ietf-alto-unified-props-new] since 1199 footprints can be easily presented as groups of entities and Filtered 1200 Property Maps are already well-defined. In this section, we describe 1201 how ALTO clients look up properties for individual footprints. We 1202 firstly describe how to represent footprint objects as unified 1203 property map entities, and then we provide examples of the full 1204 property map, the filtered property map and the incremental updates. 1206 6.1. Representing Footprint Objects as Unified Property Map Entities 1208 A footprint object has two properties: footprint-type and footprint- 1209 value. A footprint-value is an array of footprint values conforming 1210 to the specification associated with the registered footprint type 1211 ("ipv4cidr", "ipv6cidr", "asn", and "countrycode"). Since each 1212 unified property map entity has a unique address and each pair of 1213 footprint-type and a footprint value determines a group of unique 1214 addresses, a footprint object can be represented as a set of entities 1215 according to their different footprint-type and footprint values. 1216 However, [I-D.ietf-alto-unified-props-new] only defines IPv4 Domain 1217 and IPv6 Domain which represent footprint-type "ipv4cidr" and 1218 "ipv6cidr" respectively. To represent footprint-type "asn" and 1219 "countrycode", this document registers two new domains in Section 8. 1221 Here gives an example of representing a footprint object as a set of 1222 unified property map entities. 1224 {"footprint-type": "ipv4cidr", "footprint-value": ["192.0.2.0/24", 1225 "198.51.100.0/24"]} --> "ipv4:192.168.2.0/24", "ipv4:198.51.100.0/24" 1227 6.1.1. ASN Domain 1229 This document specifies a new domain in addition to the ones in 1230 [I-D.ietf-alto-unified-props-new]. ASN is the abbreviation of 1231 Autonomous System Number. 1233 6.1.1.1. Domain Name 1235 asn 1237 6.1.1.2. Domain-Specific Entity Addresses 1239 The entity address of asn domain is encoded as a string consisting of 1240 the characters "as" (in lowercase) followed by the ASN [RFC6793]. 1242 6.1.1.3. Hierarchy and Inheritance 1244 There is no hierarchy or inheritance for properties associated with 1245 ASN. 1247 6.1.2. COUNTRYCODE Domain 1249 This document specifies a new domain in addition to the ones in 1250 [I-D.ietf-alto-unified-props-new]. 1252 6.1.2.1. Domain Name 1254 countrycode 1256 6.1.2.2. Domain-Specific Entity Addresses 1258 The entity address of countrycode domain is encoded as an ISO 3166-1 1259 alpha-2 code [ISO3166-1] in lowercase. 1261 6.1.2.3. Hierarchy and Inheritance 1263 There is no hierarchy or inheritance for properties associated with 1264 country codes. 1266 6.2. Examples 1268 6.2.1. IRD Example 1270 We use the same IRD example given by Section 3.7.1. 1272 6.2.2. Property Map Example 1274 This example shows a full unified property map in which entities are 1275 footprints and entities' property is "cdni-fci-capabilities". 1277 GET /propmap/full/cdnifci HTTP/1.1 1278 HOST: alto.example.com 1279 Accept: application/alto-propmap+json,application/alto-error+json 1281 HTTP/1.1 200 OK 1282 Content-Length: ### 1283 Content-Type: application/alto-propmap+json 1285 { 1286 "property-map": { 1287 "meta": { 1288 "dependent-vtags": [ 1289 {"resource-id": "my-default-cdnifci-map", 1290 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1291 ] 1292 }, 1293 "countrycode:us": { 1294 "cdni-fci-capabilities": [ 1295 {"capability-type": "FCI.DeliveryProtocol", 1296 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1297 }, 1298 "ipv4:192.0.2.0/24": { 1299 "cdni-fci-capabilities": [ 1300 {"capability-type": "FCI.DeliveryProtocol", 1301 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1302 }, 1303 "ipv4:198.51.100.0/24": { 1304 "cdni-fci-capabilities": [ 1305 {"capability-type": "FCI.DeliveryProtocol", 1306 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1307 }, 1308 "ipv6:2001:db8::/32": { 1309 "cdni-fci-capabilities": [ 1310 {"capability-type": "FCI.DeliveryProtocol", 1311 "capability-value": {"delivery-protocols": ["http/1.1"]}}] 1312 }, 1313 "asn:as64496": { 1314 "cdni-fci-capabilities": [ 1315 {"capability-type": "FCI.DeliveryProtocol", 1316 "capability-value": {"delivery-protocols": ["http/1.1", 1317 "https/1.1"]}}] 1318 } 1319 } 1320 } 1322 6.2.3. Filtered Property Map Example 1324 In this example, we use filtered property map service to get "pid" 1325 and "cdni-fci-capabilities" properties for two footprints 1326 "ipv4:192.0.2.0/24" and "ipv6:2001:db8::/32". 1328 POST /propmap/lookup/cdnifci-pid HTTP/1.1 1329 HOST: alto.example.com 1330 Content-Type: application/alto-propmapparams+json 1331 Accept: application/alto-propmap+json,application/alto-error+json 1332 Content-Length: 1334 { 1335 "entities": [ 1336 "ipv4:192.0.2.0/24", 1337 "ipv6:2001:db8::/32" 1338 ], 1339 "properties": [ "cdni-fci-capabilities", "pid" ] 1340 } 1342 HTTP/1.1 200 OK 1343 Content-Length: ### 1344 Content-Type: application/alto-propmap+json 1346 { 1347 "property-map": { 1348 "meta": { 1349 "dependent-vtags": [ 1350 {"resource-id": "my-default-cdnifci-map", 1351 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}, 1352 {"resource-id": "my-default-networkmap", 1353 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1354 ] 1355 }, 1356 "ipv4:192.0.2.0/24": { 1357 "cdni-fci-capabilities": [ 1358 {"capability-type": "FCI.DeliveryProtocol", 1359 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1360 "pid": "pid1" 1361 }, 1362 "ipv6:2001:db8::/32": { 1363 "cdni-fci-capabilities": [ 1364 {"capability-type": "FCI.DeliveryProtocol", 1365 "capability-value": {"delivery-protocols": ["http/1.1"]}}], 1366 "pid": "pid3" 1367 } 1368 } 1369 } 1371 6.2.4. Incremental Updates Example 1373 In this example, here is a client want to request updates for the 1374 properties "cdni-fci-capabilities" and "pid" for two footprints 1375 "ipv4:192.0.2.0/24" and "ipv6:2001:db8::/32". 1377 POST /updates/properties HTTP/1.1 1378 Host: alto.example.com 1379 Accept: text/event-stream,application/alto-error+json 1380 Content-Type: application/alto-updatestreamparams+json 1381 Content-Length: ### 1383 { "add": { 1384 "property-map-including-capability-property": { 1385 "resource-id": "filtered-cdnifci-property-map", 1386 "input": { 1387 "properties": ["cdni-fci-capabilities", "pid"], 1388 "entities": [ 1389 "ipv4:192.0.2.0/24", 1390 "ipv6:2001:db8::/32" 1391 ] 1392 } 1393 } 1394 } 1396 HTTP/1.1 200 OK 1397 Connection: keep-alive 1398 Content-Type: text/event-stream 1400 event: application/alto-updatestreamcontrol+json 1401 data: {"control-uri": 1402 data: "http://alto.example.com/updates/streams/1414213562373"} 1404 event: application/alto-cdnifcimap+json,my-fci-stream 1405 data: { ... full filtered unified property map ... } 1407 event: application/merge-patch+json,my-fci-stream 1408 data: { 1409 data: "property-map": 1410 data: { 1411 data: "meta": { 1412 data: "dependent-vtags": [ 1413 data: {"resource-id": "my-default-cdnifci-map", 1414 data: "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"}, 1415 data: {"resource-id": "my-default-networkmap", 1416 data: "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"} 1417 data: ] 1418 data: }, 1419 data: "ipv4:192.0.2.0/24": 1420 data: { 1421 data: "cdni-fci-capabilities": [ 1422 data: {"capability-type": "FCI.DeliveryProtocol", 1423 data: "capability-value": { 1424 data: "delivery-protocols": ["http/1.1"]}}] 1425 data: } 1426 data: } 1427 data: } 1429 event: application/json-patch+json,my-fci-stream 1430 data: {[ 1431 data: { 1432 data: { "op": "replace", 1433 data: "path": "/meta/dependent-vtags/0/tag", 1434 data: "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4" 1435 data: }, 1436 data: { "op": "replace", 1437 data: "path": "/property-map/ipv4:192.0.2.0/124/", 1438 data: "value": "pid5" 1439 data: } 1440 data: } 1441 data: ]} 1443 7. Design Decisions and Discussions 1445 7.1. Table versus Map 1447 A major design decision is if the Map service is suitable to provide 1448 the CDNI FCI. Current ALTO protocol uses Map service to provide 1449 network information, such as Network Maps, Cost Maps and Property 1450 Maps. Their common idea is to use Map-like data structure to 1451 represent information. It is different from the data structure of 1452 the CDNI FCI designed in [RFC8008], which suggests to use a set of 1453 BaseAdvertisementObjects to represent the CDNI FCI information, which 1454 actually is Table-like data structure. Both Table and Map can be 1455 represented as a set of data entries. But the difference of them is 1456 whether there is a primary key to index each data entry. 1458 The main advantage of Map-like data design is to simplify the filter- 1459 based query. According to the discussion in [RFC8008] about benefits 1460 and concerns of advertisement-based design and query-based design, 1461 filter-based query can make the CDNI FCI scalable when the dCDN has 1462 thousands or tens of thousands of FCI objects. To transfer Table- 1463 like data to Map-like data, introducing the primary key is necessary. 1464 This document already defines two different solution to introduce the 1465 primary key: (1) set unique identifiers for CDNI capability objects; 1466 (2) set unique identifiers for CDNI footprint objects. 1468 But the major concern of the Map-like data design is the redundancy. 1469 In Map-like data design, whatever we choose CDNI capability objects 1470 or footprint objects as the key, each data entry can only represent 1471 the 1-N relation. But there are lots of CDNI FCI objects have the 1472 N-N relation. 1474 7.2. Filter-based Query versus Test-based Query 1476 Another design decision is the query approach. ALTO is a query-based 1477 protocol. So using ALTO, uCDN should send a query request to the 1478 dCDN to pull the CDNI FCI proactively. To make the query efficiently 1479 instead of pulling the whole FCI data base every time, query approach 1480 design is very important. 1482 This document only defines the filter-based query. A uCDN can 1483 specify a set of FCI capability objects or footprint objects to only 1484 query the information including them. But there are two limitations: 1485 (1) uCDN cannot filter both of them simultaneously; (2) cannot 1486 specify complex filters. 1488 One example is that uCDN wants to filter all CDNI FCI objects whose 1489 capabilities are in range C1 and footprints are in range F1, or 1490 capabilities are in range C2 and footprints are in range F2. 1492 8. IANA Considerations 1494 8.1. CDNI Metadata Footprint Type Registry 1496 +-----------------+-----------------------+-----------------------+ 1497 | Footprint Type | Description | Specification | 1498 +-----------------+-----------------------+-----------------------+ 1499 | altonetworkmap | A list of PID-names | RFCthis | 1500 +-----------------+-----------------------+-----------------------+ 1502 Table 1: CDNI Metadata Footprint Type 1504 [RFC Editor: Please replace RFCthis with the published RFC number for 1505 this document.] 1507 8.2. ALTO Entity Domain Registry 1509 As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new], 1510 "ALTO Entity Domain Registry" is requested. Besides, two new domains 1511 are to be registered, listed in Table 2. 1513 +--------------+-------------------------+--------------------------+ 1514 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1515 +--------------+-------------------------+--------------------------+ 1516 | asn | See Section 6.1.1.2 | None | 1517 | countrycode | See Section 6.1.2.2 | None | 1518 +--------------+-------------------------+--------------------------+ 1520 Table 2: ALTO Entity Domain 1522 8.3. ALTO CDNI FCI Property Type Registry 1524 The "ALTO CDNI FCI Property Type Registry" is required by the ALTO 1525 Entity Domain "asn", "countrycode", "pid", "ipv4" and "ipv6", listed 1526 in Table 3. 1528 +------------------------+------------------------------------------+ 1529 | Identifier | Intended Semantics | 1530 +------------------------+------------------------------------------+ 1531 | cdni-fci-capabilities | An array of CDNI FCI capability objects | 1532 +------------------------+------------------------------------------+ 1534 Table 3: ALTO CDNI FCI Property Type 1536 9. Security Considerations 1538 Although CDNI FCI Map resource defined in this document is relatively 1539 different from other existed resources defined in the base protocol, 1540 the Security Considerations of the base protocol (Section 15 of 1541 RFC7285) still apply. 1543 For authenticity and Integrity of ALTO information, an attacker may 1544 disguise itself as an ALTO server in a dCDN, and it may provide false 1545 capabilities and footprints to an ALTO client in a uCDN by the CDNI 1546 FCI map. Such false information may lead a uCDN to select a wrong 1547 dCDN to serve user requests or even block uCDNs utilizing some dCDNs 1548 in good condition. 1550 For potential undesirable guidance from authenticated ALTO 1551 information, dCDNs can provide a uCDN with limited capabilities and 1552 smaller footprint coverage so that dCDNs can avoid transferring 1553 traffic for a uCDN which they should have to transfer. 1555 For confidentiality of ALTO information, an attacker may infer the 1556 whole and exact capabilities and footprints of a dCDN by means of 1557 pretending it is one of different uCDNs of a dCDN respectively, 1558 getting different CDNI FCI maps from a dCDN and combining these maps 1559 together. 1561 For privacy for ALTO users, querying footprint properties using ALTO 1562 unified property may expose network location identifiers (IP 1563 addresses or fine-grained PIDs) to the ALTO server in a dCDN. In 1564 such case, a dCDN may potentially monitor and analyze user behaviors 1565 and communication patterns of uCDNs' customers. 1567 For availability of ALTO services, an attacker may get the potential 1568 huge full CDNI FCI maps from an ALTO server in a dCDN continuously to 1569 run out of bandwidth resources of that ALTO server or may query 1570 filtered CDNI FCI services with complex capabilities to run out of 1571 computation resources of an ALTO server. 1573 Protection Strategies described in RFC 7285 can solve problems 1574 mentioned above well. However, the isolation of full/filtered CDNI 1575 FCI maps should also be considered. 1577 If a dCDN signs agreements with multiple uCDNs, it must isolate full/ 1578 filtered CDNI FCI maps for different uCDNs in that uCDNs will not 1579 redirect requests which should not have to served by this dCDN to 1580 this dCDN and it may not disclose extra information to uCDNs. 1582 To avoid this risk, a dCDN may consider generating URIs of different 1583 full/filtered CDNI FCI maps by hashing its company ID, a uCDN's 1584 company ID as well as their agreements. And it needs to avoid 1585 expoing all full/filtered CDNI FCI maps resources in one of its IRDs. 1587 10. Acknowledgments 1589 The authors would like to thank Daryl Malas, Matt Caulfield for their 1590 timely reviews and invaluable comments. 1592 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 1593 Architecture and Applications of Green Information Centric 1594 Networking), a research project supported jointly by the European 1595 Commission under its 7th Framework Program (contract no. 608518) and 1596 the National Institute of Information and Communications Technology 1597 (NICT) in Japan (contract no. 167). The views and conclusions 1598 contained herein are those of the authors and should not be 1599 interpreted as necessarily representing the official policies or 1600 endorsements, either expressed or implied, of the GreenICN project, 1601 the European Commission, or NICT. 1603 11. References 1604 11.1. Normative References 1606 [ISO3166-1] 1607 The International Organization for Standardization, "Codes 1608 for the representation of names of countries and their 1609 subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 1610 2013. 1612 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1613 Optimization (ALTO) Problem Statement", RFC 5693, 1614 DOI 10.17487/RFC5693, October 2009, 1615 . 1617 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1618 Distribution Network Interconnection (CDNI) Problem 1619 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1620 2012, . 1622 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1623 Autonomous System (AS) Number Space", RFC 6793, 1624 DOI 10.17487/RFC6793, December 2012, 1625 . 1627 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1628 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1629 "Application-Layer Traffic Optimization (ALTO) Protocol", 1630 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1631 . 1633 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1634 "Framework for Content Distribution Network 1635 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1636 August 2014, . 1638 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1639 "Content Delivery Network Interconnection (CDNI) 1640 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1641 . 1643 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1644 R., and K. Ma, "Content Delivery Network Interconnection 1645 (CDNI) Request Routing: Footprint and Capabilities 1646 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1647 . 1649 11.2. Informative References 1651 [I-D.ietf-alto-incr-update-sse] 1652 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1653 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1654 sse-07 (work in progress), July 2017. 1656 [I-D.ietf-alto-path-vector] 1657 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 1658 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 1659 Vector Cost Type", draft-ietf-alto-path-vector-04 (work in 1660 progress), July 2018. 1662 [I-D.ietf-alto-unified-props-new] 1663 Roome, W. and Y. Yang, "Extensible Property Maps for the 1664 ALTO Protocol", draft-ietf-alto-unified-props-new-00 (work 1665 in progress), July 2017. 1667 [I-D.jenkins-alto-cdn-use-cases] 1668 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 1669 S. Previdi, "Use Cases for ALTO within CDNs", draft- 1670 jenkins-alto-cdn-use-cases-03 (work in progress), June 1671 2012. 1673 Authors' Addresses 1675 Jan Seedorf 1676 HFT Stuttgart - Univ. of Applied Sciences 1677 Schellingstrasse 24 1678 Stuttgart 70174 1679 Germany 1681 Phone: +49-0711-8926-2801 1682 Email: jan.seedorf@hft-stuttgart.de 1684 Y.R. Yang 1685 Tongji/Yale University 1686 51 Prospect Street 1687 New Haven, CT 06511 1688 United States of America 1690 Email: yry@cs.yale.edu 1691 URI: http://www.cs.yale.edu/~yry/ 1692 Kevin J. Ma 1693 Ericsson 1694 43 Nagog Park 1695 Acton, MA 01720 1696 United States of America 1698 Phone: +1-978-844-5100 1699 Email: kevin.j.ma@ericsson.com 1701 Jon Peterson 1702 NeuStar 1703 1800 Sutter St Suite 570 1704 Concord, CA 94520 1705 United States of America 1707 Email: jon.peterson@neustar.biz 1709 Xiao Shawn Lin 1710 Tongji University 1711 4800 Cao'an Hwy 1712 Shanghai 201804 1713 China 1715 Email: x.shawn.lin@gmail.com