idnits 2.17.1 draft-ietf-alto-unified-props-new-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1378 has weird spacing: '...rtyName prop...' == Line 1590 has weird spacing: '...country stat...' -- The document date (22 February 2021) is 1158 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' == Outdated reference: A later version (-22) exists of draft-ietf-alto-cdni-request-routing-alto-16 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-13 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG W. Roome 3 Internet-Draft S. Randriamasy 4 Intended status: Standards Track Nokia Bell Labs 5 Expires: 26 August 2021 Y. Yang 6 Yale University 7 J. Zhang 8 Tongji University 9 K. Gao 10 Sichuan University 11 22 February 2021 13 ALTO extension: Entity Property Maps 14 draft-ietf-alto-unified-props-new-16 16 Abstract 18 This document extends the base Application-Layer Traffic Optimization 19 (ALTO) Protocol by generalizing the concept of "endpoint properties" 20 as applied to endpoints as defined by IP addresses to endpoints 21 defined by a wider set of objects. Further, these properties are 22 presented as maps, similar to the network and cost maps in the base 23 ALTO protocol. The protocol is extended in two major directions. 24 First, from endpoints restricted to IP addresses to entities covering 25 a wider and extensible set of objects; second, from properties on 26 specific endpoints to entire entity property maps. These extensions 27 introduce additional features allowing entities and property values 28 to be specific to a given information resource. This is made 29 possible by a generic and flexible design of entity and property 30 types. 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 26 August 2021. 49 Copyright Notice 51 Copyright (c) 2021 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 68 3. Basic Features of the Entity Property Map Extension . . . . . 7 69 3.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 8 72 3.2.2. Entity Domain Name . . . . . . . . . . . . . . . . . 9 73 3.3. Entity Property Type . . . . . . . . . . . . . . . . . . 9 74 3.4. New information resource and media type: ALTO Property 75 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4. Advanced Features of the Entity Property Map Extension . . . 11 77 4.1. Entity Identifier and Entity Domain Name . . . . . . . . 11 78 4.2. Resource-Specific Entity Domain Name . . . . . . . . . . 11 79 4.3. Resource-Specific Entity Property Value . . . . . . . . . 12 80 4.4. Entity Hierarchy and Property Inheritance . . . . . . . . 13 81 4.4.1. Entity Hierarchy . . . . . . . . . . . . . . . . . . 13 82 4.4.2. Property Inheritance . . . . . . . . . . . . . . . . 14 83 4.4.3. Property Value Unicity . . . . . . . . . . . . . . . 14 84 4.5. Supported Properties on Entity Domains in Property Map 85 Capabilities . . . . . . . . . . . . . . . . . . . . . . 15 86 4.6. Defining Information Resource for Resource-Specific Entity 87 Domains . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.6.1. Defining Information Resource and its Media Type . . 16 89 4.6.2. Examples of defining information resources 90 media-types . . . . . . . . . . . . . . . . . . . . . 18 91 4.7. Defining Information Resource for Resource-Specific 92 Property Values . . . . . . . . . . . . . . . . . . . . . 18 93 5. Protocol Specification: Basic Data Types . . . . . . . . . . 18 94 5.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 18 95 5.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 18 96 5.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 19 97 5.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 21 98 5.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 21 99 5.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 22 100 5.2.1. Entity Property Type . . . . . . . . . . . . . . . . 22 101 5.2.2. Entity Property Name . . . . . . . . . . . . . . . . 23 102 5.2.3. Format for Entity Property Value . . . . . . . . . . 23 103 6. Entity Domain Types Defined in this Document . . . . . . . . 23 104 6.1. Internet Address Domain Types . . . . . . . . . . . . . . 24 105 6.1.1. Entity Domain Type: IPv4 . . . . . . . . . . . . . . 24 106 6.1.2. Entity Domain Type: IPv6 . . . . . . . . . . . . . . 24 107 6.1.3. Hierarchy and Inheritance of Internet Address 108 Domains . . . . . . . . . . . . . . . . . . . . . . . 25 109 6.1.4. Defining Information Resource Media Type for domain 110 types IPv4 and IPv6 . . . . . . . . . . . . . . . . . 26 111 6.2. Entity Domain Type: PID . . . . . . . . . . . . . . . . . 26 112 6.2.1. Entity Domain Type Identifier . . . . . . . . . . . . 26 113 6.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 26 114 6.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 27 115 6.2.4. Defining Information Resource Media Type for Domain 116 Type PID . . . . . . . . . . . . . . . . . . . . . . 27 117 6.2.5. Relationship To Internet Addresses Domains . . . . . 27 118 6.3. Internet Address Properties vs. PID Properties . . . . . 27 119 7. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 28 120 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 28 121 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 28 122 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 28 123 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 28 124 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 125 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 29 126 8. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 30 127 8.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 30 128 8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 30 129 8.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 30 130 8.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 31 131 8.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 31 132 8.6. Filtered Property Map Response . . . . . . . . . . . . . 31 133 8.7. Entity property type defined in this document . . . . . . 33 134 8.7.1. Entity Property Type: pid . . . . . . . . . . . . . . 33 135 9. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 33 136 9.1. Impact on Endpoint Property Service . . . . . . . . . . . 33 137 9.2. Impact on Resource-Specific Properties . . . . . . . . . 34 138 9.3. Impact on Other Properties . . . . . . . . . . . . . . . 34 139 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 140 10.1. Network Map . . . . . . . . . . . . . . . . . . . . . . 34 141 10.2. Property Definitions . . . . . . . . . . . . . . . . . . 35 142 10.3. Information Resource Directory (IRD) . . . . . . . . . . 36 143 10.4. Full Property Map Example . . . . . . . . . . . . . . . 38 144 10.5. Filtered Property Map Example #1 . . . . . . . . . . . . 39 145 10.6. Filtered Property Map Example #2 . . . . . . . . . . . . 40 146 10.7. Filtered Property Map Example #3 . . . . . . . . . . . . 42 147 10.8. Filtered Property Map Example #4 . . . . . . . . . . . . 43 148 10.9. Filtered Property Map for ANEs Example #5 . . . . . . . 44 149 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 150 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 151 12.1. application/alto-* Media Types . . . . . . . . . . . . . 46 152 12.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 47 153 12.2.1. Consistency Procedure between ALTO Address Type 154 Registry and ALTO Entity Domain Type Registry . . . . 48 155 12.2.2. ALTO Entity Domain Type Registration Process . . . . 50 156 12.3. ALTO Entity Property Type Registry . . . . . . . . . . . 51 157 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 158 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 159 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 160 14.2. Informative References . . . . . . . . . . . . . . . . . 54 161 Appendix A. Features introduced with the Entity Property Maps 162 extension . . . . . . . . . . . . . . . . . . . . . . . . 55 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 165 1. Introduction 167 The ALTO protocol [RFC7285] introduces the concept of "properties" 168 attached to "endpoint addresses", and defines the Endpoint Property 169 Service (EPS) to allow ALTO clients to retrieve those properties. 170 While useful, the EPS, as defined in [RFC7285], has at least three 171 limitations. 173 First, the EPS allows properties to be associated with only endpoints 174 that are identified by individual communication addresses like IPv4 175 and IPv6 addresses. It is reasonable to think that collections of 176 endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have 177 properties. Furthermore, recent ALTO use cases show that properties 178 of entities such as network flows [RFC7011] and routing elements 179 [RFC7921] are also useful. Such cases are documented in 180 [I-D.gao-alto-fcs]. The current EPS however is restricted to 181 individual endpoints and cannot be applied to those entities. 183 Second, the EPS only allows endpoints identified by global 184 communication addresses. However, an endpoint address may be a local 185 IP address or an anycast IP address that may not be globally unique. 186 Additionally, an entity such as a PID may have an identifier that is 187 not globally unique. That is, a same PID identifier may be used in 188 multiple network maps, while in each network map, this PID identifier 189 points to a different set of addresses. For example, PID "mypid10" 190 may be defined in "netmap1" and "netmap2" while in each network map, 191 "mypid10" covers a different set of addresses. 193 Third, the EPS is only defined as a POST-mode service. Clients must 194 request the properties for an explicit set of endpoint addresses. By 195 contrast, [RFC7285] defines a GET-mode cost map resource which 196 returns all available costs, so a client can get a full set of costs 197 once, and then process cost lookups without querying the ALTO server. 198 [RFC7285] does not define a similar service for endpoint properties. 199 At first, a map of endpoint properties might seem impractical, 200 because it could require enumerating the property value for every 201 possible endpoint. However, in practice, it is highly unlikely that 202 properties will be defined for every endpoint address. It is much 203 more likely that properties may be defined for only a subset of 204 endpoint addresses, and the specification of properties uses an 205 aggregation representation to allow enumeration. This is 206 particularly true if blocks of endpoint addresses with a common 207 prefix (e.g., a CIDR) have the same value for a property. Entities 208 in other domains may very well allow aggregated representation and 209 hence be enumerable as well. 211 To address the three limitations, this document specifies a protocol 212 extension for defining and retrieving ALTO properties: 214 * The first limitation is addressed by introducing a generic concept 215 called ALTO Entity, which generalizes an endpoint and may 216 represent a PID, a network element, a cell in a cellular network, 217 an abstracted network element as defined in 218 [I-D.ietf-alto-path-vector], or other physical or logical objects 219 involved in a network topology. Each entity is included in a 220 collection called an ALTO Entity Domain. Since each ALTO Entity 221 Domain includes only one type of entities, each Entity Domain can 222 be classified by the type of entities in it. 224 * The second limitation is addressed by using resource-specific 225 entity domains. A resource-specific entity domain contains 226 entities that are defined and identified with respect to a given 227 ALTO information resource, which provides scoping. For example, 228 an entity domain containing PIDs is identified with respect to the 229 network map in which these PIDs are defined. Likewise, an entity 230 domain containing local IP addresses may be defined with respect 231 to a local network map. 233 * The third limitation is addressed by defining two new types of 234 ALTO information resources: Property Map, detailed in Section 7 235 and Filtered Property Map, detailed in Section 8. The former is a 236 GET-mode resource that returns the property values for all 237 entities in one or more entity domains, and is analogous to a 238 network map or a cost map in [RFC7285]. The latter is a POST-mode 239 resource that returns the values for sets of properties and 240 entities requested by the client, and is analogous to a filtered 241 network map or a filtered cost map. 243 The protocol extension defined in this document is augmentable. New 244 entity domain types can be defined without revising the specification 245 defined in this document. Similarly, new cost metrics and new 246 endpoint properties can be defined in other documents without 247 revising the protocol specification defined in [RFC7285]. 249 1.1. Terminology 251 This document uses the following terms and abbreviations, that will 252 be further defined in the document. While this document introduces 253 the feature "entity property map", it will use both the term 254 "property map" and "entity property map" to refer to this feature. 256 * Transaction: A request/response exchange between an ALTO Client 257 and an ALTO Server. 259 * Client: When used with a capital "C", this term refers to an ALTO 260 Client. 262 * Server: When used with a capital "S", this term refers to an ALTO 263 Server. 265 * EPM: An abbreviation for entity property map 267 * FPM: An abbreviation for filtered property map. 269 * EPS: An abbreviation for Endpoint Property Service. 271 2. Requirements Language 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 275 "OPTIONAL" in this document are to be interpreted as described in BCP 276 14 [RFC2119] [RFC8174] when, and only when, they appear in all 277 capitals, as shown here. When the words appear in lower case, they 278 are to be interpreted with their natural language meanings. 280 3. Basic Features of the Entity Property Map Extension 282 This section gives a high-level overview of the basic features 283 involved in ALTO Entity Property Maps. It assumes the reader is 284 familiar with the ALTO protocol [RFC7285]. The purpose of this 285 extension is to allow conveying properties on objects that extend 286 ALTO Endpoints and are called ALTO Entities, or entities for short. 288 The features introduced in this section can be used as standalone. 289 However, in some cases, these features may depend on particular 290 information resources and need to be defined with respect to them. 291 To this end, Section 4 introduces additional features that extend the 292 ones presented in the present section. 294 The Entity Property Maps extension described in this document 295 introduces a number of features that are summarized in Appendix A, 296 where Table 4 lists the features and references the sections in this 297 document that give a high-level and normative description thereof. 299 3.1. Entity 301 The concept of an ALTO Entity generalizes the concept of an ALTO 302 Endpoint defined in Section 2.1 of [RFC7285]. An entity is an object 303 that can be an endpoint that is defined by its network address, but 304 can also be an object that has a defined mapping to a set of one or 305 more network addresses or an object that is not even related to any 306 network address. Thus, whereas all endpoints are entities, not all 307 entities are endpoints. 309 Examples of entities are: 311 * an ALTO endpoint, defined in [RFC7285], that represents an 312 application or a host identified by a communication address (e.g., 313 an IPv4 or IPv6 address) in a network, 315 * a PID, defined in [RFC7285], that has a provider defined human- 316 readable identifier specified by an ALTO network map, which maps a 317 PID to a set of IPv4 and IPv6 addresses, 319 * an autonomous system (AS), that has an AS number (ASN) as its 320 identifier and maps to a set of IPv4 and IPv6 addresses, 322 * a country with a code as specified in [ISO3166-1], to which 323 applications such as CDN providers associate properties and 324 capabilities, 326 * a TCP/IP network flow, that is identified by a TCP/IP 5-Tuple 327 specifying its source and destination addresses and port numbers 328 and the utilized protocol, 330 * a routing element, that is specified in [RFC7921] and is 331 associated with routing capabilities information, 333 * an abstract network element, that represents an abstraction of a 334 network part such as a router, one or more links, a network domain 335 or their aggregation. 337 3.2. Entity Domain 339 An entity domain defines a set of entities of the same semantic type. 340 An entity domain is characterized by its type and identified by its 341 name. 343 In this document, an entity must be owned by exactly one entity 344 domain name. An entity identifier must point to exactly one entity. 345 If two entities in two different entity domains refer to the same 346 physical or logical object, they are treated as different entities. 347 For example, if an object has both an IPv4 and an IPv6 address, these 348 two addresses will be treated as two entities, defined respectively 349 in the "ipv4" and "ipv6" entity domains. 351 3.2.1. Entity Domain Type 353 The type of an entity domain type defines the semantics of a type of 354 entity. Entity domain types can be defined in different documents. 355 For example: the present document defines entity domain types "ipv4", 356 "ipv6" and "pid" in sections Section 6.1 and Section 6.2. The entity 357 domain type "ane", that defines Abstract Network Elements (ANEs), is 358 introduced in [I-D.ietf-alto-path-vector]. The entity domain type 359 that defines country codes is introduced in 360 [I-D.ietf-alto-cdni-request-routing-alto]. An entity domain type 361 MUST be registered at the IANA, as specified in section 362 Section 12.2.2 and similarly to an ALTO address type. 364 3.2.2. Entity Domain Name 366 The name of an entity domain is defined in the scope of an ALTO 367 server. An entity domain name can sometimes be identical to the name 368 of its relevant entity domain type. This is the case when the 369 entities of a domain have an identifier that points to the same 370 object throughout all the information resources of the Server that 371 provide entity properties for this domain. For example, a domain of 372 type "ipv4" containing entities identified by a public IPv4 address 373 can be named "ipv4" because its entities are uniquely identified by 374 all the Server resources. 376 In some cases, a domain type and domain name must be different. 377 Indeed, for some domain types, entities are defined relative to a 378 given information resource. This is the case for entities of domain 379 type "pid". A PID is defined relative to a network map. For 380 example: an entity "mypid10" of domain type "pid" may be defined in a 381 given network map and be undefined in other network maps. Or 382 "mypid10" may even be defined in two different network maps and map, 383 in each of these network maps, to a different set of endpoint 384 addresses. In this case, naming an entity domain only by its type 385 "pid" does not guarantee that its set of entities is owned by exactly 386 one entity domain. 388 Section 4.2 and Section 5.1.2 of this document describe how a domain 389 is uniquely identified, across the ALTO Server, by a name that 390 associates the domain type and the related information resource. 392 3.3. Entity Property Type 394 An entity property defines a property of an entity. This is similar 395 to the endpoint property defined in Section 7.1 of [RFC7285]. An 396 entity property can convey either network-aware or network-agnostic 397 information. Similarly to an entity domain, an entity property is 398 characterized by its type and identified by its name. An entity 399 property type MUST be registered at the IANA, as specified in section 400 Section 12.3. 402 Below are some examples with real and fictitious entity domain and 403 property names: 405 * an entity in the "ipv4" domain type may have a property whose 406 value is an Autonomous System (AS) number indicating the AS that 407 owns this IPv4 address and another property named "countrycode" 408 indicating a country code mapping to this address, 410 * an entity identified by its country code in the entity domain type 411 "countrycode", defined in 412 [I-D.ietf-alto-cdni-request-routing-alto] may have a property 413 indicating what delivery protocol is used by a CDN, 415 * an entity in the "netmap1.pid" domain may have a property that 416 indicates the central geographical location of the endpoints it 417 includes. 419 It should be noted that some identifiers may be used for both an 420 entity domain type and a property type. For example: 422 * the identifier "countrycode" may point to both the entity domain 423 type "countrycode" and the fictitious property type "countrycode". 425 * the identifier "pid" may point to both the entity domain type 426 "pid" and the property type "pid". 428 Likewise, a same identifier may point to both a domain name and a 429 property name. For example: the identifier "netmap10.pid" may point 430 to either the domain defined by the PIDs of network map "netmap10" or 431 to a property that returns, for an entity defined by its IPv4 432 address, the PID of netmap10 that contains this entity. Such cases 433 will be further explained in Section 4. 435 3.4. New information resource and media type: ALTO Property Map 437 This document introduces a new ALTO information resource named 438 Property Map. An ALTO property map provides a set of properties on 439 one or more sets of entities. A property may apply to different 440 entity domain types and names. For example, an ALTO property map may 441 define the "ASN" property for both "ipv4" and "ipv6" entity domains. 443 The present extension also introduces a new media type. 445 This document uses the same definition of an information resource as 446 Section 9.1 of [RFC7285]. ALTO uses media types to uniquely indicate 447 the data format used to encode the content to be transmitted between 448 an ALTO server and an ALTO client in the HTTP entity body. In the 449 present case, an ALTO property map resource is defined by the media 450 type "application/alto-propmap+json". 452 A Property Map can be queried as a GET-mode resource, thus conveying 453 all properties on all entities indicated in its capabilities. It can 454 also be queried as a POST-mode resource, thus conveying a selection 455 of properties on a selection of entities. 457 4. Advanced Features of the Entity Property Map Extension 459 4.1. Entity Identifier and Entity Domain Name 461 In [RFC7285], an endpoint has an identifier that is explicitly 462 associated with the "ipv4" or "ipv6" address domain. Examples are 463 "ipv4:192.0.2.14" and "ipv6:2001:db8::12". 465 In this document, an entity must be owned by exactly one entity 466 domain name and an entity identifier must point to exactly one 467 entity. To ensure this, an entity identifier is explicitly attached 468 to the name of its entity domain and an entity domain type 469 characterizes the semantics and identifier format of its entities. 471 The encoding format of an entity identifier is further specified in 472 Section 5.1.3 of this document. 474 For instance: 476 * if an entity is an endpoint with example routable IPv4 address 477 "192.0.2.14", its identifier is associated with domain name "ipv4" 478 and is "ipv4:192.0.2.14", 480 * if an entity is a PID named "mypid10" in network map resource 481 "netmap2", its identifier is associated with domain name 482 "netmap2.pid" and is "netmap2.pid:mypid10". 484 4.2. Resource-Specific Entity Domain Name 486 Some entities are defined and identified uniquely and globally. This 487 is the case for instance when entities are endpoints that are 488 identified by a routable IPv4 or IPv6 address. The entity domain for 489 such entities can be globally defined and named "ipv4" or "ipv6". 490 Those entity domains are called resource-agnostic entity domains in 491 this document, as they are not associated with any specific ALTO 492 information resources. 494 Some other entities and entity types are only defined relatively to a 495 given information resource. This is the case for entities of domain 496 type "pid", that can only be understood with respect to the network 497 map where they are defined. For example, a PID named "mypid10" may 498 be defined to represent a set S1 of IP addresses in a network map 499 resource named "netmap1". Another network map "netmap2" may use the 500 same name "mypid10" and define it to represent another set S2 of IP 501 addresses. The identifier "pid:mypid10" may thus point to different 502 objects because the information on the originating information 503 resource is lost. 505 To solve this ambiguity, the present extension introduces the concept 506 of resources-specific entity domain. This concept applies to domain 507 types where entities are defined relatively to a given information 508 resource. It can also apply to entity domains that are defined 509 locally, such as local networks of objects identified with a local 510 IPv4 address. 512 In such cases, an entity domain type is explicitly associated with an 513 identifier of the information resource where these entities are 514 defined. Such an information resource is referred to as the 515 "specific information resource". Using a resource-aware entity 516 domain name, an ALTO property map can unambiguously identify distinct 517 entity domains of the same type, on which entity properties may be 518 queried. Examples of resource-specific entity domain names may look 519 like: "netmap1.pid" or "netmap2.pid". Thus, a name association such 520 as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" allows to 521 distinguish the two abovementioned PIDs that are both named "mypid10" 522 but in two different resources, "netmap1" and "netmap2". 524 An information resource is defined in the scope of an ALTO Server and 525 so is an entity domain name. The format of a resource-specific 526 entity domain name is further specified in Section 5.1.2. 528 4.3. Resource-Specific Entity Property Value 530 Like entity domains, some types of properties are defined relatively 531 to an information resource. That is, an entity may have a property 532 of a given type, whose values are associated to different information 533 resources. 535 For example, suppose entity "192.0.2.34" defined in the "ipv4" domain 536 has a property of type "pid", whose value is the PID to which address 537 "192.0.2.34" is attached in a network map. The mapping of network 538 addresses to PIDs is specific to a network map and probably different 539 from one network map resource to another one. Thus, if a property 540 "pid" is defined for entity "192.0.2.34" in two different network 541 maps "netmap1" and "netmap2", the value for this property will likely 542 be a different value in "netmap1" and "netmap2". 544 To support information resource dependent property values, this 545 document uses the same approach as in Section 10.8.1 of [RFC7285] 546 entitled "Resource-Specific Endpoint Properties". When a property 547 value depends on a given information resource, the name of this 548 property must be explicitly associated with the information resource 549 that defines it. 551 For example, the property "pid" queried on entity "ipv4:192.0.2.34" 552 and defined in both "netmap1" and "netmap2", can be named 553 "netmap1.pid" and "netmap2.pid". This allows a Client to get a 554 property of the same type but defined in different information 555 resources with a single query. Specifications on the property name 556 format are provided in Section 5.2. 558 4.4. Entity Hierarchy and Property Inheritance 560 For some domain types, entities can be grouped in a set and be 561 defined by the identifier of this set. This is the case for domain 562 types "ipv4" and "ipv6", where individual Internet addresses can be 563 grouped in blocks. When a same property value applies to a whole 564 set, a Server can define a property for the identifier of this set 565 instead of enumerating all the entities and their properties. This 566 allows a substantial reduction of transmission payload both for the 567 Server and the Client. For example, all the entities included in the 568 set defined by the address block "ipv6:2001:db8::1/64" share the same 569 properties and values defined for this block. 571 Additionally, entity sets sometimes are related by inclusion, 572 hierarchy or other relations. This allows defining inheritance rules 573 for entity properties that propagate properties among related entity 574 sets. The Server and the Client can use these inheritance rules for 575 further payload savings. Entity hierarchy and property inheritance 576 rules are specified in the documents that define the applicable 577 domain types. The present document defines these rules for the 578 "ipv4" and "ipv6" domain types. 580 This document introduces, for applicable domain types, "Entity 581 Property Inheritance rules", with the following concepts: Entity 582 Hierarchy, Property Inheritance and Property Value Unicity. A 583 detailed specification of entity hierarchy and property inheritance 584 rules is provided in Section 5.1.4. 586 4.4.1. Entity Hierarchy 588 An entity domain may allow using a single identifier to identify a 589 set of individual entities. For example, a CIDR block can be used to 590 identify a set of IPv4 or IPv6 entities. A CIDR block is called a 591 hierarchical entity identifier, as it can reflect inclusion relations 592 among entity sets. For example, the CIDR "ipv4:192.0.1.0/24" 593 includes all the individual IPv4 entities identified by the CIDR 594 "ipv4:192.0.1.0/26". 596 4.4.2. Property Inheritance 598 A property may be defined for a hierarchical entity identifier, while 599 it may be undefined for individual entities covered by this 600 identifier. In this case, these individual entities inherit the 601 property value defined for the identifier that covers them. For 602 example, suppose a property map defines a property P for which it 603 assigns value V1 only for the hierarchical entity identifier 604 "ipv4:192.0.1.0/24" but not for individual entities in this block. 605 Suppose also that inheritance rules are specified for CIDR blocks in 606 the "ipv4" domain type. When receiving this property map, a Client 607 can infer that entity "ipv4:192.0.1.1" inherits the property value V1 608 of block "ipv4:192.0.1.0/24" because the address "ipv4:192.0.1.1" is 609 included by the CIDR block "ipv4:192.0.1.0/24". 611 Property value inheritance rules also apply among entity sets. A 612 property map may define values for an entity set belonging to a 613 hierarchy but not for "sub" sets that are covered by this set 614 identifier. In this case, inheritance rules must specify how 615 entities in "sub" sets inherit property values from their "super" 616 set. For instance, if a property P is defined only for the entity 617 set identified by address block "ipv4:192.0.1.0/24", the entity set 618 identified by "ipv4:192.0.1.0/30" and thus included in the former 619 set, may inherit the property P value from set "ipv4:192.0.1.0/24". 621 4.4.3. Property Value Unicity 623 The inheritance rules must ensure that an entity belonging to a 624 hierarchical set of entities inherits no more than one property 625 value, for the sake of consistency. Indeed, a property map may 626 define a property on a hierarchy of entity sets that inherit property 627 values from one or more subsets (upper levels). On the other hand, a 628 property value, defined on a superset (lower level) may be different 629 from the value defined in a subset. In such a case, supersets may 630 potentially end up with different property values. This may be the 631 case for address blocs with increasing prefix length, on which a 632 property value gets increasingly accurate and thus may differ. For 633 example, a fictitious property such as "geo-location" or "average 634 transfer volume" may be defined at a progressively finer grain for 635 entity sets defined with progressively longer CIDR prefixes. It 636 seems more interesting to have property values of progressively 637 higher accuracy. A unicity rule, applied to the entity domain type 638 must specify an arbitration rule among the different property values 639 for an entity. An example illustrating the need for such rules is 640 provided in Section 6.1.3. 642 4.5. Supported Properties on Entity Domains in Property Map 643 Capabilities 645 A property type is not necessarily applicable to any domain type, or 646 an ALTO Server may choose not to provide a property on all applicable 647 domains. For instance, a property type reflecting link bandwidth is 648 likely not defined on entities of a domain of type "country-code". 649 Therefore an ALTO server providing Property Maps needs to specify the 650 properties that can be queried on the different entity domains it 651 supports. 653 This document explains how the Information Resources Directory (IRD) 654 capabilities of a Property Map resource unambiguously expose what 655 properties a Client can query on a given entity domain. 657 * a field named "mappings" lists the names of the entity domains 658 supported by the Property Map, 660 * for each listed entity domain, a list of the names of the 661 applicable properties is provided. 663 An example is provided in Section 10.3. The "mappings" field 664 associates entity domains and properties that can be resource- 665 agnostic or resource-specific. This allows a Client to formulate 666 compact and unambiguous entity property queries, possibly relating to 667 one or more information resources. In particular: 669 * it avoids a Client to query a property on entity domains on which 670 it is not defined, 672 * it allows a Client to query, for an entity E, values for a 673 property P that are defined in several information resources, 675 * it allows a Client to query a property P on entities that are 676 defined in several information resources. 678 Further specifications are provided in Section 7.4. 680 4.6. Defining Information Resource for Resource-Specific Entity Domains 682 A Client willing to query properties on entities belonging to a 683 domain needs to know how to retrieve these entities. To this end, 684 the Client can look up the "mappings" field exposed in IRD 685 capabilities of a property map, see Section 4.5. This field, in its 686 keys, exposes all the entity domains supported by the property map. 687 The syntax of the entity domain identifier specified in Section 5.1.2 688 allows the client to infer whether the entity domain is resource- 689 specific or not. The Client can extract, if applicable, the 690 identifier of the specific resource, query the resource and retrieve 691 the entities. For example: 693 * an entity domain named "netmap1.ipv4" includes the IPv4 addresses 694 that appear in the "ipv4" field of the endpoint address group of 695 each PID in the network map "netmap1", and that cannot be 696 recognized outside "netmap1" because, for instance, these are 697 local non-routable addresses, 699 * an entity domain named "netmap1.pid" includes the PIDs listed in 700 network map "netmap1". 702 * an entity domain named "ipv4" is resource-agnostic and covers all 703 the routable IPv4 addresses. 705 Besides, it is also necessary to inform a Client about which 706 associations of specific resources and entity domain types are 707 allowed, because it is not possible to prevent a Server from exposing 708 inappropriate associations. An informed Client will just ignore 709 inappropriate associations exposed by a Server and avoid error-prone 710 transactions with the Server. 712 For example, the association "costmap3.pid" is not allowed for the 713 following reason: although a cost map exposes PID identifiers, it 714 does not define the set of addresses included in this PID. Neither 715 does a cost map list all the PIDs on which properties can be queried, 716 because a cost map only exposes PID pairs on which a queried cost 717 type is defined. Therefore, the resource "costmap3" does not enable 718 a Client to extract information on the existing PID entities or on 719 the addresses they contain. 721 Instead, the cost map uses a network map, where all the PIDs used in 722 a cost map are defined together with the addresses contained by the 723 PIDs. This network map is qualified in this document as the Defining 724 Information Resource for the entity domain of type "pid" and this 725 concept is explained in Section 4.6.1. 727 4.6.1. Defining Information Resource and its Media Type 729 For the reasons explained in the previous section, this document 730 introduces the concept of defining information resource and media 731 type. 733 A defining information resource for an entity domain D is the 734 information resource where entities of D are defined. That is, all 735 the information on the entities of D can be retrieved in this 736 resource. This concept applies to resource-specific domains. This 737 is useful for entity domain types that are by essence domain- 738 specific, such as "pid" and "ane" domain types. It is also useful 739 for resource-specific entity domains constructed from resource- 740 agnostic domain types, such as network map specific domains of local 741 IPv4 addresses. 743 The defining information resource of an entity domain D has the 744 following specificities: 746 * it has an entry in the IRD, 748 * it defines the entities of D, 750 * it does not use another information resource that defines these 751 entities, 753 * it defines and exposes entity identifiers that are all persistent. 755 * its media type is unique and equal to the one that is specified 756 for the defining information resource of an entity domain type. 758 A fundamental attribute of a defining information resource is its 759 media type. There is a unique association between an entity domain 760 type and the media type of its defining information resource. When 761 an entity domain type allows associations with defining information 762 resources, the document that defines this entity domain type 763 specifies the media type of the potential defining information 764 resource. Likewise, the IANA registration of an entity domain type 765 also specifies the media type of potential defining information 766 resources. 768 When the Client wants to use a resource-specific entity domain, it 769 needs to be cognizant of the media-type of its defining information 770 resource. If the Server exposes resources a resource specific entity 771 domain with a non-compliant media type for the domain type, the 772 Client can avoid transaction errors by ignoring them. 774 The same holds for property types whose values are defined relatively 775 to an information resource. Similarly to resource specific entity 776 domains, the Client needs to be cognizant of appropriate associations 777 of information resource and property types. Therefore, when 778 specifying and registering a property type whose values are resource- 779 specific, it is necessary to specify the media type of its defining 780 information resource. For example: the defining information resource 781 for property type "pid" is a network map; the defining information 782 resource for property type "cdnifci- capab", defined in [draft-ietf- 783 alto-cdni-request-routing-alto] is a "cdnifci-map" information 784 resource, defined in that same document. 786 4.6.2. Examples of defining information resources media-types 788 Here are some examples of specific information resource types 789 associated to entity domain types and their media type. 791 * For entity domain type "pid": the media type of the specific 792 resource is "application/alto-networkmap+json", because PIDs are 793 defined in network map resources. 795 * For entity domain types "ipv4" and "ipv6": the media type of the 796 specific resource is "application/alto-networkmap+json", because 797 IPv4 and IPv6 addresses covered by the Server are defined in 798 network map resources. 800 * For entities of domain type "ane": [I-D.ietf-alto-path-vector] 801 defines entities named "ANE", where ANE stands for Abstracted 802 Network Element, and the entity domain type "ane". An ANE may 803 have a persistent identifier, say, "entity-4", that is provided by 804 the Server as a value of the "persistent-entity-id" property of 805 this ANE. Further properties may then be queried on an ANE by 806 using its persistent entity ID. These properties are available 807 from a persistent property map, that defines properties on a 808 specific "ane" domain. Together with the persistent identifier, 809 the Server also provides the property map resource identifier 810 where the "ane" domain containing "entity-4" is defined. The 811 definition of the "ane" entity domain containing "entity-4" is 812 thus specific to the property map. Therefore, for entities of 813 domain type "ane" that have a persitent identifier, the media type 814 of the specific information resource is "application/alto- 815 propmap+json". 817 4.7. Defining Information Resource for Resource-Specific Property 818 Values 820 5. Protocol Specification: Basic Data Types 822 5.1. Entity Domain 824 5.1.1. Entity Domain Type 826 An entity domain has a type, which is uniquely identified by a string 827 that MUST be no more than 64 characters, and MUST NOT contain 828 characters other than US-ASCII alphanumeric characters 829 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', 830 U+002D), or the low line ('_', U+005F). 832 For example, the strings "ipv4", "ipv6", and "pid" are valid entity 833 domain types. "ipv4.anycast" and "pid.local" are invalid. 835 The type EntityDomainType is used in this document to denote a JSON 836 string meeting the preceding requirements. 838 An entity domain type defines the semantics of a type of entity, 839 independently of any specifying resource. Each entity domain type 840 MUST be registered with the IANA. The format of the entity 841 identifiers (see Section 5.1.3) in that type of entity domain, as 842 well as any hierarchical or inheritance rules (see Section 5.1.4) for 843 those entities, MUST be specified at the same time. 845 5.1.2. Entity Domain Name 847 As said in Section 3.2 when introducing entity domains, an entity 848 domain is characterized by its type and identified by its name. 850 This document distinguishes three categories of entity domains: 851 resource-specific entity domains, resource-agnostic entity domains 852 and self-defined entity domains. Their entity domain names are 853 constructed as specified in the following sub-sections. 855 Each entity domain is identified by a unique entity domain name which 856 is a string of the following format: 858 EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType 860 Where the presence and construction of component: 862 "[ [ ResourceID ] '.' ]" 864 depends on the category of entity domain. 866 Note that the '.' separator is not allowed in EntityDomainType and 867 hence there is no ambiguity on whether an entity domain name refers 868 to a resource-agnostic entity domain or a resource-specific entity 869 domain. 871 Note also that Section 10.1 of [RFC7285] specifies the format of the 872 PID Name which is the format of the resource ID including the 873 following specification: "the '.' separator is reserved for future 874 use and MUST NOT be used unless specifically indicated in this 875 document, or an extension document". The present extension keeps the 876 format specification of [RFC7285], hence the '.' separator MUST NOT 877 be used in an information resource ID. 879 5.1.2.1. Resource-specific Entity Domain 881 A resource-specific entity domain is identified by an entity domain 882 name constructed as follows. It MUST start with a resource ID using 883 the ResourceID type defined in Section 10.2 of [RFC7285], followed by 884 the '.' separator (U+002E), followed by a string of the type 885 EntityDomainType specified in Section 5.1.1. 887 For example, if an ALTO server provides two network maps "netmap-1" 888 and "netmap-2", these network maps can define two resource-specific 889 domains of type "pid", respectively identified by "netmap-1.pid" and 890 "netmap-2.pid". 892 5.1.2.2. Resource-agnostic Entity Domain 894 A resource-agnostic entity domain contains entities that are 895 identified independently of any information resource. Hence, the 896 identifier of a resource-agnostic entity domain is simply the 897 identifier of its entity domain type. For example, "ipv4" and "ipv6" 898 identify the two resource-agnostic Internet address entity domains 899 defined in Section 6.1. 901 5.1.2.3. Self-defined Entity Domain 903 A property map can define properties on entities that are specific to 904 a unique information resource, which is the property map itself. 905 This may be the case when an ALTO Server provides properties on a set 906 of entities that are defined only in this property map, are not 907 relevant to another one and do not depend on another specific 908 resource. 910 For example: a specialised property map may define a domain of type 911 "ane", defined in [I-D.ietf-alto-path-vector], that contains a set of 912 ANEs representing data centers, that each have a persistent 913 identifier and are relevant only to this property map. 915 In this case, the entity domain is qualified as "self-defined". The 916 identifier of a self-defined entity domain can be of the format: 918 EntityDomainName ::= .EntityDomainType 920 where '.' indicates that the entity domain only exists within the 921 property map resource using it. 923 A self-defined entity domain can be viewed as a particular case of 924 resource-specific entity domain, where the specific resource is the 925 current resource that uses this entity domain. In that case, for the 926 sake of simplification, the component "ResourceID" SHOULD be omitted 927 in its entity domain name. 929 5.1.3. Entity Identifier 931 Entities in an entity domain are identified by entity identifiers 932 (EntityID) of the following format: 934 EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID 936 Examples from the Internet address entity domains include individual 937 IP addresses such as "net1.ipv4:192.0.2.14" and 938 "net1.ipv6:2001:db8::12", as well as address blocks such as 939 "net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::1/48". 941 The format of the second part of an entity identifier depends on the 942 entity domain type, and MUST be specified when defining a new entity 943 domain type and registering it with the IANA. Identifiers MAY be 944 hierarchical, and properties MAY be inherited based on that 945 hierarchy. The rules defining any hierarchy or inheritance MUST be 946 defined when the entity domain type is registered. 948 The type EntityID is used in this document to denote a JSON string 949 representing an entity identifier in this format. 951 Note that two entity identifiers with different valid textual 952 representations may refer to the same entity, for a given entity 953 domain. For example, the strings "net1.ipv6:2001:db8::1" and 954 "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the 955 "ipv6" entity domain. Such equivalences should be established by the 956 object represented by DomainTypeSpecificEntityID, for example, 957 [RFC5952] establishes equivalence for IPv6 addresses, while [RFC4632] 958 does so for IPv4 addresses. 960 5.1.4. Hierarchy and Inheritance 962 To simplify the representation, some types of entity domains allow 963 the ALTO Client and Server to use a hierarchical entity identifier 964 format to represent a block of individual entities. For instance, in 965 an IPv4 domain "net1.ipv4", a CIDR "net1.ipv4:192.0.2.0/26" covers 64 966 individual IPv4 entities. In this case, the corresponding property 967 inheritance rule MUST be defined for the entity domain type. The 968 hierarchy and inheritance rule MUST have no ambiguity. 970 5.2. Entity Property 972 Each entity property has a type to indicate the encoding and the 973 semantics of the value of this entity property, and has a name to 974 identify it. 976 5.2.1. Entity Property Type 978 The type EntityPropertyType is used in this document to indicate a 979 string denoting an entity property type. The string MUST be no more 980 than 32 characters, and it MUST NOT contain characters other than US- 981 ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 982 U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), or 983 the low line ('_', U+005F). Note that the '.' separator is not 984 allowed because it is reserved to separate an entity property type 985 and an information resource identifier when an entity property is 986 resource-specific. 988 Each entity property type MUST be registered with the IANA. The 989 intended semantics of the entity property type MUST be specified at 990 the same time. 992 Identifiers prefixed with "priv:" are reserved for Private Use 993 [RFC8126] without a need to register with IANA. All other 994 identifiers for entity property types appearing in an HTTP request or 995 response with an "application/alto-*" media type MUST be registered 996 in the "ALTO Entity Property Type Registry", defined in Section 12.3. 997 For an entity property identifier with the "priv:" prefix, an 998 additional string (e.g., company identifier or random string) MUST 999 follow the prefix to reduce potential collisions, that is, the string 1000 "priv:" alone is not a valid endpoint property identifier. 1002 To distinguish from the endpoint property type, the entity property 1003 type has the following characteristics: 1005 * Some entity property types are applicable to entities in 1006 particular entity domain types only. For example, the property 1007 type "pid" is applicable to entities in the entity domain types 1008 "ipv4" or "ipv6" while is not applicable to entities in an entity 1009 domain of type "pid". 1011 * The intended semantics of the value of an entity property may also 1012 depend on the entity domain type. For example, suppose that a 1013 property named "geo-location" is defined as the coordinates of a 1014 point, encoded as: "latitude longitude [altitude]." When applied 1015 to an entity that represents a specific host computer, identified 1016 by an address in an entity domain of type "ipv4" or "ipv6", the 1017 "geo-location" property would define the host's location. 1019 However, when applied to an entity in a "pid" domain type, the 1020 property would indicate the location of the center of all hosts in 1021 this "pid" entity. 1023 5.2.2. Entity Property Name 1025 Each entity property is identified by an entity property name, which 1026 is a string of the following format: 1028 EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType 1030 Similar to the endpoint property type defined in Section 10.8 of 1031 [RFC7285], each entity property may be defined by either the property 1032 map itself (self-defined) or some other specific information resource 1033 (resource-specific). 1035 The entity property name of a resource-specific entity property 1036 starts with a string of the type ResourceID defined in [RFC7285], 1037 followed by the '.' separator (U+002E) and a EntityDomainType typed 1038 string. For example, the "pid" properties of an "ipv4" entity 1039 defined by two different maps "net-map-1" and "net-map-2" are 1040 identified by "net-map-1.pid" and "net-map-2.pid" respectively. 1042 The specific information resource of an entity property may be the 1043 current information resource itself, that is, the property map 1044 defining the property. In that case, the ResourceID in the property 1045 name SHOULD be ignored. For example, the property name ".asn" 1046 applied to an entity identitifed by its IPv4 address, indicates the 1047 AS number of the AS that "owns" the entity, where the returned AS 1048 number is defined by the property map itself. 1050 5.2.3. Format for Entity Property Value 1052 [RFC7285] in Section 11.4.1.6, specifies that an implementation of 1053 the Endpoint Property Service specified in [RFC7285] SHOULD assume 1054 that the property value is a JSONString and fail to parse if it is 1055 not. This document extends the format of a property value by 1056 allowing it to be a JSONValue instead of just a JSONString. 1058 6. Entity Domain Types Defined in this Document 1060 This document requires the definition of each entity domain type MUST 1061 include (1) the entity domain type name and (2) domain-specific 1062 entity identifiers, and MAY include (3) hierarchy and inheritance 1063 semantics optionally. This document defines three initial entity 1064 domain types as follows. 1066 6.1. Internet Address Domain Types 1068 The document defines two entity domain types (IPv4 and IPv6) for 1069 Internet addresses. Both types are resource-agnostic entity domain 1070 types and hence define corresponding resource-agnostic entity domains 1071 as well. Since the two domains use the same hierarchy and 1072 inheritance semantics, we define the semantics together, instead of 1073 repeating for each. 1075 6.1.1. Entity Domain Type: IPv4 1077 6.1.1.1. Entity Domain Type Identifier 1079 ipv4 1081 6.1.1.2. Domain-Specific Entity Identifiers 1083 Individual addresses are strings as specified by the IPv4Addresses 1084 rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are 1085 prefix-match strings as specified in Section 3.1 of [RFC4632]. To 1086 define properties, an individual Internet address and the 1087 corresponding full-length prefix are considered aliases for the same 1088 entity. An individual Internet address and the corresponding full- 1089 length prefix are considered aliases for the same entity on which to 1090 define properties. Thus, "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" 1091 are equivalent. 1093 6.1.2. Entity Domain Type: IPv6 1095 6.1.2.1. Entity Domain Type Identifier 1097 ipv6 1099 6.1.2.2. Domain-Specific Entity Identifiers 1101 Individual addresses are strings as specified by Section 4 of 1102 [RFC5952]; Hierarchical addresses are prefix-match strings as 1103 specified in Section 7 of [RFC5952]. To define properties, an 1104 individual Internet address and the corresponding 128-bit prefix are 1105 considered aliases for the same entity. That is, "ipv6:2001:db8::1" 1106 and "ipv6:2001:db8::1/128" are equivalent, and have the same set of 1107 properties. 1109 6.1.3. Hierarchy and Inheritance of Internet Address Domains 1111 Both Internet address domains allow property values to be inherited. 1112 Specifically, if a property P is not defined for a specific Internet 1113 address I, but P is defined for a hierarchical Internet address C 1114 which prefix-matches I, then the address I inherits the value of P 1115 defined for the hierarchical address C. If more than one such 1116 hierarchical addresses define a value for P, I inherits the value of 1117 P in the hierarchical address with the longest prefix. Note that 1118 this longest prefix rule ensures no multiple value inheritances, and 1119 hence no ambiguity. 1121 Hierarchical addresses can also inherit properties: if a property P 1122 is not defined for the hierarchical address C, but is defined for 1123 another hierarchical address C' which covers all IP addresses in C, 1124 and C' has a shorter prefix length than C, then C MAY inherit the 1125 property from C'. If there are multiple such hierarchical addresses 1126 like C', C MUST inherit from the hierarchical address having the 1127 longest prefix length. 1129 As an example, suppose that a server defines a property P for the 1130 following entities: 1132 ipv4:192.0.2.0/26: P=v1 1133 ipv4:192.0.2.0/28: P=v2 1134 ipv4:192.0.2.0/30: P=v3 1135 ipv4:192.0.2.0: P=v4 1137 Figure 1: Defined Property Values. 1139 Then the following entities have the indicated values: 1141 ipv4:192.0.2.0: P=v4 1142 ipv4:192.0.2.1: P=v3 1143 ipv4:192.0.2.16: P=v1 1144 ipv4:192.0.2.32: P=v1 1145 ipv4:192.0.2.64: (not defined) 1146 ipv4:192.0.2.0/32: P=v4 1147 ipv4:192.0.2.0/31: P=v3 1148 ipv4:192.0.2.0/29: P=v2 1149 ipv4:192.0.2.0/27: P=v1 1150 ipv4:192.0.2.0/25: (not defined) 1152 Figure 2: Inherited Property Values. 1154 An ALTO server MAY explicitly indicate a property as not having a 1155 value for a particular entity. That is, a server MAY say that 1156 property P of entity X is "defined to have no value", instead of 1157 "undefined". To indicate "no value", a server MAY perform different 1158 behaviours: 1160 * If that entity would inherit a value for that property, then the 1161 ALTO server MUST return a "null" value for that property. In this 1162 case, the ALTO client MUST recognize a "null" value as "no value" 1163 and "do not apply the inheritance rules for this property." 1165 * If the entity would not inherit a value, then the ALTO server MAY 1166 return "null" or just omit the property. In this case, the ALTO 1167 client cannot infer the value for this property of this entity 1168 from the Inheritance rules. So the client MUST interpret that 1169 this property has no value. 1171 If the ALTO server does not define any properties for an entity, then 1172 the server MAY omit that entity from the response. 1174 6.1.4. Defining Information Resource Media Type for domain types IPv4 1175 and IPv6 1177 Entity domain types "ipv4" and "ipv6" both allow to define resource 1178 specific entity domains. When resource specific domains are defined 1179 with entities of domain type "ipv4" or "ipv6", the defining 1180 information resource for an entity domain of type "ipv4" or "ipv6" 1181 MUST be a Network Map. The media type of a defining information 1182 resource is therefore: 1184 application/alto-networkmap+json 1186 6.2. Entity Domain Type: PID 1188 The PID domain associates property values with the PIDs in a network 1189 map. Accordingly, this entity domain always depends on a network 1190 map. 1192 6.2.1. Entity Domain Type Identifier 1194 pid 1196 6.2.2. Domain-Specific Entity Identifiers 1198 The entity identifiers are the PID names of the associated network 1199 map. 1201 6.2.3. Hierarchy and Inheritance 1203 There is no hierarchy or inheritance for properties associated with 1204 PIDs. 1206 6.2.4. Defining Information Resource Media Type for Domain Type PID 1208 The entity domain type "pid" allows to define resource specific 1209 entity domains. When resource specific domains are defined with 1210 entities of domain type "pid", the defining information resource for 1211 entity domain type "pid" MUST be a Network Map. The media type of a 1212 defining information resource is therefore: 1214 application/alto-networkmap+json 1216 6.2.5. Relationship To Internet Addresses Domains 1218 The PID domain and the Internet address domains are completely 1219 independent; the properties associated with a PID have no relation to 1220 the properties associated with the prefixes or endpoint addresses in 1221 that PID. An ALTO server MAY choose to assign all the properties of 1222 a PID to the prefixes in that PID or only some of these properties. 1224 For example, suppose "PID1" consists of the prefix 1225 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 1226 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in 1227 the IPv4 domain MAY have a value for the property "P", and if they 1228 do, it is not necessarily "v1". 1230 6.3. Internet Address Properties vs. PID Properties 1232 Because the Internet address and PID domains relate to completely 1233 distinct domain types, the question may arise as to which entity 1234 domain type is the best for a property. In general, the Internet 1235 address domain types are RECOMMENDED for properties that are closely 1236 related to the Internet address, or are associated with, and 1237 inherited through, hierarchical addresses. 1239 The PID domain type is RECOMMENDED for properties that arise from the 1240 definition of the PID, rather than from the Internet address prefixes 1241 in that PID. 1243 For example, because Internet addresses are allocated to service 1244 providers by blocks of prefixes, an "ISP" property would be best 1245 associated with Internet address domain types. On the other hand, a 1246 property that explains why a PID was formed, or how it relates to a 1247 provider's network, would best be associated with the PID domain 1248 type. 1250 7. Property Map 1252 A property map returns the properties defined for all entities in one 1253 or more domains, e.g., the "location" property of entities in "pid" 1254 domain, and the "ASN" property of entities in "ipv4" and "ipv6" 1255 domains. 1257 Section 10.4 gives an example of a property map request and its 1258 response. 1260 7.1. Media Type 1262 The media type of a property map is "application/alto-propmap+json". 1264 7.2. HTTP Method 1266 The property map is requested using the HTTP GET method. 1268 7.3. Accept Input Parameters 1270 None. 1272 7.4. Capabilities 1274 The capabilities are defined by an object of type 1275 PropertyMapCapabilities: 1277 object { 1278 EntityPropertyMapping mappings; 1279 } PropertyMapCapabilities; 1281 object-map { 1282 EntityDomainName -> EntityPropertyName<1..*>; 1283 } EntityPropertyMapping 1285 with fields: 1287 mappings: A JSON object whose keys are names of entity domains and 1288 values are the supported entity properties of the corresponding 1289 entity domains. 1291 7.5. Uses 1293 The "uses" field of a property map resource in an IRD entry specifies 1294 dependent resources of this property map. It is an array of the 1295 resource ID(s) of the resource(s). 1297 7.6. Response 1299 If the entity domains in this property map depend on other resources, 1300 the "dependent-vtags" field in the "meta" field of the response MUST 1301 be an array that includes the version tags of those resources, and 1302 the order MUST be consistent with the "uses" field of this property 1303 map resource. The data component of a property map response is named 1304 "property-map", which is a JSON object of type PropertyMapData, 1305 where: 1307 object { 1308 PropertyMapData property-map; 1309 } InfoResourceProperties : ResponseEntityBase; 1311 object-map { 1312 EntityID -> EntityProps; 1313 } PropertyMapData; 1315 object { 1316 EntityPropertyName -> JSONValue; 1317 } EntityProps; 1319 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 1321 Specifically, a PropertyMapData object has one member for each entity 1322 in the property map. The entity's properties are encoded in the 1323 corresponding EntityProps object. EntityProps encodes one name/value 1324 pair for each property, where the property names are encoded as 1325 strings of type PropertyName. A protocol implementation SHOULD 1326 assume that the property value is either a JSONString or a JSON 1327 "null" value, and fail to parse if it is not, unless the 1328 implementation is using an extension to this document that indicates 1329 when and how property values of other data types are signaled. 1331 For each entity in the property map: 1333 * If the entity is in a resource-specific entity domain, the ALTO 1334 server SHOULD only return self-defined properties and resource- 1335 specific properties which depend on the same resource as the 1336 entity does. The ALTO client SHOULD ignore the resource-specific 1337 property in this entity if their mapping is not registered in the 1338 ALTO Resource Entity Property Transfer Registry of the type of the 1339 corresponding resource. 1341 * If the entity is in a shared entity domain, the ALTO server SHOULD 1342 return self-defined properties and all resource-specific 1343 properties defined for all resource-specific entities which have 1344 the same domain-specific entity identifier as this entity does. 1346 For efficiency, the ALTO server SHOULD omit property values that are 1347 inherited rather than explicitly defined; if a client needs inherited 1348 values, the client SHOULD use the entity domain's inheritance rules 1349 to deduce those values. 1351 8. Filtered Property Map 1353 A filtered property map returns the values of a set of properties for 1354 a set of entities selected by the client. 1356 Section 10.5, Section 10.6, Section 10.7 and Section 10.8 give 1357 examples of filtered property map requests and responses. 1359 8.1. Media Type 1361 The media type of a property map resource is "application/alto- 1362 propmap+json". 1364 8.2. HTTP Method 1366 The filtered property map is requested using the HTTP POST method. 1368 8.3. Accept Input Parameters 1370 The input parameters for a filtered property map request are supplied 1371 in the body of the POST request. This document specifies the input 1372 parameters with a data format indicated by the media type 1373 "application/alto-propmapparams+json", which is a JSON object of type 1374 ReqFilteredPropertyMap: 1376 object { 1377 EntityID entities<1..*>; 1378 EntityPropertyName properties<1..*>; 1379 } ReqFilteredPropertyMap; 1381 with fields: 1383 entities: List of entity identifiers for which the specified 1384 properties are to be returned. The ALTO server MUST interpret 1385 entries appearing multiple times as if they appeared only once. 1386 The domain of each entity MUST be included in the list of entity 1387 domains in this resource's "capabilities" field (see Section 8.4). 1389 properties: List of properties to be returned for each entity. Each 1390 specified property MUST be included in the list of properties in 1391 this resource's "capabilities" field (see Section 8.4). The ALTO 1392 server MUST interpret entries appearing multiple times as if they 1393 appeared only once. 1395 Note that the "entities" and "properties" fields MUST have at 1396 least one entry each. 1398 8.4. Capabilities 1400 The capabilities are defined by an object of type 1401 PropertyMapCapabilities, as defined in Section 7.4. 1403 8.5. Uses 1405 Same to the "uses" field of the Property Map resource (see 1406 Section 7.5). 1408 8.6. Filtered Property Map Response 1410 The response MUST indicate an error, using ALTO protocol error 1411 handling, as defined in Section 8.5 of [RFC7285], if the request is 1412 invalid. 1414 Specifically, a filtered property map request can be invalid in the 1415 following cases: 1417 * An entity identifier in the "entities" field of the request is 1418 invalid if: 1420 - The domain of this entity is not defined in the "entity- 1421 domains" capability of this resource in the IRD, 1423 - The entity identifier is not valid for the entity domain. 1425 A valid entity identifier does never generate an error, even if 1426 the filtered property map resource does not define any properties 1427 for it. 1429 If an entity identifier in the "entities" field of the request is 1430 invalid, the ALTO server MUST return an "E_INVALID_FIELD_VALUE" 1431 error defined in Section 8.5.2 of [RFC7285], and the "value" field 1432 of the error message SHOULD indicate the provided invalid entity 1433 identifier. 1435 * A property name in the "properties" field of the request is 1436 invalid if this property name is not defined in the "properties" 1437 capability of this resource in the IRD. 1439 When a filtered property map resource does not define a value for 1440 a property requested on a particular entity, it is not an error. 1441 In this case, the ALTO server MUST omit that property from the 1442 response for that endpoint. 1444 If a property name in "properties" in the request is invalid, the 1445 ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined 1446 in Section 8.5.2 of [RFC7285]. The "value" field of the error 1447 message SHOULD indicate the property name. 1449 The response to a valid request is the same as for the Property Map 1450 (see Section 7.6), except that: 1452 * If the requested entities include entities in the shared entity 1453 domain, the "dependent-vtags" field in its "meta" field MUST 1454 include version tags of all dependent resources appearing in the 1455 "uses" field. 1457 * If the requested entities only include entities in resource- 1458 specific entity domains, the "dependent-vtags" field in its "meta" 1459 field MUST include the version tags of the resources on which the 1460 requested resource-specific entity domains and the requested 1461 resource-specific properties are dependent on. 1463 * The response only includes the entities and properties requested 1464 by the client. If an entity in the request is identified by a 1465 hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the 1466 response MUST cover properties for all identifiers in this 1467 hierarchical identifier. 1469 The filtered property map response MUST include all the inherited 1470 property values for the requested entities and all the entities which 1471 are able to inherit property values from the requested entities. To 1472 achieve this goal, the ALTO server MAY follow three rules: 1474 * If a property for a requested entity is inherited from another 1475 entity not included in the request, the response SHOULD include 1476 this property for the requested entity. For example, A full 1477 property map may skip a property P for an entity A (e.g., 1478 ipv4:192.0.2.0/31) if P can be derived using inheritance from 1479 another entity B (e.g., ipv4:192.0.2.0/30). A filtered property 1480 map request may include only A but not B. In such a case, the 1481 property P SHOULD be included in the response for A. 1483 * If there are entities covered by a requested entity but having 1484 different values for the requested properties, the response SHOULD 1485 include all those entities and the different property values for 1486 them. For example, considering a request for property P of entity 1487 A (e.g., ipv4:192.0.2.0/31), if P has value v1 for 1488 A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the 1489 response SHOULD include A1 and A2. 1491 * If an entity address in the response is already covered by other 1492 entities addresses in the same response, it SHOULD be removed from 1493 the response, for the sake of compactness. In the previous 1494 example, the entity A = ipv4:192.0.2.0/31 SHOULD be removed 1495 because A1 and A2 cover all the addresses in A. 1497 An ALTO client should be aware that the entities in the response MAY 1498 be different from the entities in its request. 1500 8.7. Entity property type defined in this document 1502 This document defines the entity property type "pid". This property 1503 type extends the ALTO Endpoint Property Type "pid" defined in section 1504 7.1.1 of [RFC7285] as follows: the property has the same semantics 1505 and applies to IPv4 and IPv6 addresses; the difference is that the 1506 IPv4 and IPv6 addresses have evolved from the status of endpoints to 1507 the status of entities. 1509 The defining information resource for property type MUST be a network 1510 map. This document requests a IANA registration for this property 1512 8.7.1. Entity Property Type: pid 1514 1. Identifier: pid 1516 2. Semantics: the intended semantics are the same as in [RFC7285] 1517 for the ALTO Endpoint Property Type "pid" 1519 3. Media type of defining information resource: application/alto- 1520 networkmap+json 1522 4. Security considerations: for entity property type "pid" are the 1523 same as documented in [RFC7285] for the ALTO Endpoint Property 1524 Type "pid". 1526 9. Impact on Legacy ALTO Servers and ALTO Clients 1528 9.1. Impact on Endpoint Property Service 1530 Since the Property Map and the Filtered Property Map defined in this 1531 document provide a functionality that covers the Endpoint Property 1532 Service (EPS) defined in Section 11.4 of [RFC7285], ALTO servers may 1533 prefer to provide Property Map and Filtered Property Map in place of 1534 EPS. However, for the legacy endpoint properties, it is recommended 1535 that ALTO servers also provide EPS so that legacy clients can still 1536 be supported. 1538 9.2. Impact on Resource-Specific Properties 1540 Section 10.8 of [RFC7285] defines two categories of endpoint 1541 properties: "resource-specific" and "global". Resource-specific 1542 property names are prefixed with the ID of the resource they depend 1543 on, while global property names have no such prefix. The property 1544 map and the filtered property map defined in this document define 1545 similar categories of entity properties. The difference is that 1546 entity property maps do not define "global" entity properties. 1547 Instead, they define "self-defined" entity properties as a special 1548 case of "resource-specific" entity properties, where the specific 1549 resource is the property map itself. This means that "self-defined" 1550 properties are defined within the scope of the property map. 1552 9.3. Impact on Other Properties 1554 In the present extension, properties can now be defined on sets of 1555 entity addresses, rather than just individual endpoint addresses as 1556 is is the case in RFC7285. This might change the semantics of a 1557 property. These sets can be for example hierachical IP address 1558 blocs. For instance, a property such as fictitious "geo-location", 1559 defined on a set of IP addresses would have a value corresponding to 1560 the barycenter of this set of addresses. 1562 10. Examples 1564 10.1. Network Map 1566 The examples in this section use a very simple default network map: 1568 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1569 pid1: ipv4:192.0.2.0/25 1570 pid2: ipv4:192.0.2.0/27 1571 pid3: ipv4:192.0.3.0/28 1572 pid4: ipv4:192.0.3.16/28 1574 Figure 3: Example Default Network Map 1576 And another simple alternative network map: 1578 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1579 pid1: ipv4:192.0.2.0/27 1580 pid2: ipv4:192.0.3.0/27 1582 Figure 4: Example Alternative Network Map 1584 10.2. Property Definitions 1586 Beyond "pid", the examples in this section use four additional 1587 properties for Internet address domains, "ISP", "ASN", "country" and 1588 "state", with the following values: 1590 ISP ASN country state 1591 ipv4:192.0.2.0/23: BitsRus - us - 1592 ipv4:192.0.2.0/28: - 12345 - NJ 1593 ipv4:192.0.2.16/28: - 12345 - CT 1594 ipv4:192.0.2.1: - - - PA 1595 ipv4:192.0.3.0/28: - 12346 - TX 1596 ipv4:192.0.3.16/28: - 12346 - MN 1598 Figure 5: Example Property Values for Internet Address Domains 1600 And the examples in this section use the property "region" for the 1601 PID domain of the default network map with the following values: 1603 region 1604 pid:defaultpid: - 1605 pid:pid1: us-west 1606 pid:pid2: us-east 1607 pid:pid3: us-south 1608 pid:pid4: us-north 1610 Figure 6: Example Property Values for Default Network Map's PID 1611 Domain 1613 Note that "-" means the value of the property for the entity is 1614 "undefined". So the entity would inherit a value for this property 1615 by the inheritance rule if possible. For example, the value of the 1616 "ISP" property for "ipv4:192.0.2.1" is "BitsRus" because of 1617 "ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid" 1618 has no value because no entity from which it can inherit. 1620 Similar to the PID domain of the default network map, the examples in 1621 this section use the property "ASN" for the PID domain of the 1622 alternative network map with the following values: 1624 ASN 1625 pid:defaultpid: - 1626 pid:pid1: 12345 1627 pid:pid2: 12346 1629 Figure 7: Example Property Values for Alternative Network Map's 1630 PID Domain 1632 10.3. Information Resource Directory (IRD) 1634 The following IRD defines ALTO Server information resources that are 1635 relevant to the Entity Property Service. It provides two property 1636 maps: one for the "ISP" and "ASN" properties, and another one for the 1637 "country" and "state" properties. The server could have provided a 1638 single property map for all four properties, but does not, presumably 1639 because the organization that runs the ALTO server believes that a 1640 client is not necessarily interested in getting all four properties. 1642 The server provides several filtered property maps. The first 1643 returns all four properties, and the second returns only the "pid" 1644 property for the default network map. 1646 The filtered property maps for the "ISP", "ASN", "country" and 1647 "state" properties do not depend on the default network map (it does 1648 not have a "uses" capability), because the definitions of those 1649 properties do not depend on the default network map. The Filtered 1650 Property Map providing the "pid" property does have a "uses" 1651 capability for the default network map, because the default network 1652 map defines the values of the "pid" property. 1654 Note that for legacy clients, the ALTO server provides an Endpoint 1655 Property Service for the "pid" property defined on the endpoints of 1656 the default network map. 1658 The server provides another filtered Property map resource, named 1659 "ane-dc-property-map", that returns a fictitious properties named 1660 "storage-capacity", "ram" and "cpu" for ANEs that have a persistent 1661 identifier. The entity domain to which the ANEs belong is "self- 1662 defined" and valid only within the property map. 1664 GET /directory HTTP/1.1 1665 Host: alto.example.com 1666 Accept: application/alto-directory+json,application/alto-error+json 1668 HTTP/1.1 200 OK 1669 Content-Length: 2827 1670 Content-Type: application/alto-directory+json 1672 { 1673 "meta" : { 1674 "default-alto-network-map" : "default-network-map" 1675 }, 1676 "resources" : { 1677 "default-network-map" : { 1678 "uri" : "http://alto.example.com/networkmap/default", 1679 "media-type" : "application/alto-networkmap+json" 1680 }, 1681 "alt-network-map" : { 1682 "uri" : "http://alto.example.com/networkmap/alt", 1683 "media-type" : "application/alto-networkmap+json" 1684 }, 1685 "ia-property-map" : { 1686 "uri" : "http://alto.example.com/propmap/full/inet-ia", 1687 "media-type" : "application/alto-propmap+json", 1688 "uses": [ "default-network-map", "alt-network-map" ], 1689 "capabilities" : { 1690 "mappings": { 1691 "ipv4": [ ".ISP", ".ASN" ], 1692 "ipv6": [ ".ISP", ".ASN" ] 1693 } 1694 } 1695 }, 1696 "iacs-property-map" : { 1697 "uri" : "http://alto.example.com/propmap/lookup/inet-iacs", 1698 "media-type" : "application/alto-propmap+json", 1699 "accepts": "application/alto-propmapparams+json", 1700 "uses": [ "default-network-map", "alt-network-map" ], 1701 "capabilities" : { 1702 "mappings": { 1703 "ipv4": [ ".ISP", ".ASN", ".country", ".state" ], 1704 "ipv6": [ ".ISP", ".ASN", ".country", ".state" ] 1705 } 1706 } 1707 }, 1708 "region-property-map": { 1709 "uri": "http://alto.example.com/propmap/lookup/region", 1710 "media-type": "application/alto-propmap+json", 1711 "accepts": "application/alto-propmapparams+json", 1712 "uses" : [ "default-network-map", "alt-network-map" ], 1713 "capabilities": { 1714 "mappings": { 1715 "default-network-map.pid": [ ".region" ], 1716 "alt-network-map.pid": [ ".ASN" ] 1717 } 1718 } 1719 }, 1720 "ip-pid-property-map" : { 1721 "uri" : "http://alto.example.com/propmap/lookup/pid", 1722 "media-type" : "application/alto-propmap+json", 1723 "accepts" : "application/alto-propmapparams+json", 1724 "uses" : [ "default-network-map", "alt-network-map" ], 1725 "capabilities" : { 1726 "mappings": { 1727 "ipv4": [ "default-network-map.pid", 1728 "alt-network-map.pid" ], 1729 "ipv6": [ "default-network-map.pid", 1730 "alt-network-map.pid" ] 1731 } 1732 } 1733 }, 1734 "legacy-endpoint-property" : { 1735 "uri" : "http://alto.example.com/legacy/eps-pid", 1736 "media-type" : "application/alto-endpointprop+json", 1737 "accepts" : "application/alto-endpointpropparams+json", 1738 "capabilities" : { 1739 "properties" : [ "default-network-map.pid", 1740 "alt-network-map.pid" ] 1741 } 1742 }, 1743 "ane-dc-property-map": { 1744 "uri" : "http://alto.example.com/propmap/lookup/ane-dc", 1745 "media-type" : "application/alto-propmap+json", 1746 "accepts": "application/alto-propmapparams+json", 1747 "capabilities": { 1748 "mappings": { 1749 ".ane" : [ "storage-capacity", "ram", "cpu" ] 1750 } 1751 } 1752 } 1753 } 1754 } 1756 Figure 8: Example IRD 1758 10.4. Full Property Map Example 1760 The following example uses the properties and IRD defined above in 1761 Section 10.3 to retrieve a Property Map for entities with the "ISP" 1762 and "ASN" properties. 1764 Note that, to be compact, the response does not include the entity 1765 "ipv4:192.0.2.0", because values of all those properties for this 1766 entity are inherited from other entities. 1768 Also note that the entities "ipv4:192.0.2.0/28" and 1769 "ipv4:192.0.2.16/28" are merged into "ipv4:192.0.2.0/27", because 1770 they have the same value of the "ASN" property. The same rule 1771 applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". 1772 Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value 1773 for the "ISP" property, because it is inherited from 1774 "ipv4:192.0.2.0/23". 1776 GET /propmap/full/inet-ia HTTP/1.1 1777 Host: alto.example.com 1778 Accept: application/alto-propmap+json,application/alto-error+json 1780 HTTP/1.1 200 OK 1781 Content-Length: 418 1782 Content-Type: application/alto-propmap+json 1784 { 1785 "meta": { 1786 "dependent-vtags": [ 1787 {"resource-id": "default-network-map", 1788 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1789 {"resource-id": "alt-network-map", 1790 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1791 ] 1792 }, 1793 "property-map": { 1794 "ipv4:192.0.2.0/23": {".ISP": "BitsRus"}, 1795 "ipv4:192.0.2.0/27": {".ASN": "12345"}, 1796 "ipv4:192.0.3.0/27": {".ASN": "12346"} 1797 } 1798 } 1800 10.5. Filtered Property Map Example #1 1802 The following example uses the filtered property map resource to 1803 request the "ISP", "ASN" and "state" properties for several IPv4 1804 addresses. 1806 Note that the value of "state" for "ipv4:192.0.2.0" is the only 1807 explicitly defined property; the other values are all derived by the 1808 inheritance rules for Internet address entities. 1810 POST /propmap/lookup/inet-iacs HTTP/1.1 1811 Host: alto.example.com 1812 Accept: application/alto-propmap+json,application/alto-error+json 1813 Content-Length: 158 1814 Content-Type: application/alto-propmapparams+json 1816 { 1817 "entities" : [ "ipv4:192.0.2.0", 1818 "ipv4:192.0.2.1", 1819 "ipv4:192.0.2.17" ], 1820 "properties" : [ ".ISP", ".ASN", ".state" ] 1821 } 1823 HTTP/1.1 200 OK 1824 Content-Length: 540 1825 Content-Type: application/alto-propmap+json 1827 { 1828 "meta": { 1829 "dependent-vtags": [ 1830 {"resource-id": "default-network-map", 1831 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1832 {"resource-id": "alt-network-map", 1833 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1834 ] 1835 }, 1836 "property-map": { 1837 "ipv4:192.0.2.0": 1838 {".ISP": "BitsRus", ".ASN": "12345", ".state": "PA"}, 1839 "ipv4:192.0.2.1": 1840 {".ISP": "BitsRus", ".ASN": "12345", ".state": "NJ"}, 1841 "ipv4:192.0.2.17": 1842 {".ISP": "BitsRus", ".ASN": "12345", ".state": "CT"} 1843 } 1844 } 1846 10.6. Filtered Property Map Example #2 1848 The following example uses the filtered property map resource to 1849 request the "ASN", "country" and "state" properties for several IPv4 1850 prefixes. 1852 Note that the property values for both entities "ipv4:192.0.2.0/26" 1853 and "ipv4:192.0.3.0/26" are not explicitly defined. They are 1854 inherited from the entity "ipv4:192.0.2.0/23". 1856 Also note that some entities like "ipv4:192.0.2.0/28" and 1857 "ipv4:192.0.2.16/28" in the response are not explicitly listed in the 1858 request. The response includes them because they are refinements of 1859 the requested entities and have different values for the requested 1860 properties. 1862 The entity "ipv4:192.0.4.0/26" is not included in the response, 1863 because there are neither entities which it is inherited from, nor 1864 entities inherited from it. 1866 POST /propmap/lookup/inet-iacs HTTP/1.1 1867 Host: alto.example.com 1868 Accept: application/alto-propmap+json,application/alto-error+json 1869 Content-Length: 170 1870 Content-Type: application/alto-propmapparams+json 1872 { 1873 "entities" : [ "ipv4:192.0.2.0/26", 1874 "ipv4:192.0.3.0/26", 1875 "ipv4:192.0.4.0/26" ], 1876 "properties" : [ ".ASN", ".country", ".state" ] 1877 } 1878 HTTP/1.1 200 OK 1879 Content-Length: 766 1880 Content-Type: application/alto-propmap+json 1882 { 1883 "meta": { 1884 "dependent-vtags": [ 1885 {"resource-id": "default-network-map", 1886 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1887 {"resource-id": "alt-network-map", 1888 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1889 ] 1890 }, 1891 "property-map": { 1892 "ipv4:192.0.2.0/26": {".country": "us"}, 1893 "ipv4:192.0.2.0/28": {".ASN": "12345", 1894 ".state": "NJ"}, 1895 "ipv4:192.0.2.16/28": {".ASN": "12345", 1896 ".state": "CT"}, 1897 "ipv4:192.0.2.0": {".state": "PA"}, 1898 "ipv4:192.0.3.0/26": {".country": "us"}, 1899 "ipv4:192.0.3.0/28": {".ASN": "12345", 1900 ".state": "TX"}, 1901 "ipv4:192.0.3.16/28": {".ASN": "12345", 1902 ".state": "MN"} 1903 } 1904 } 1906 10.7. Filtered Property Map Example #3 1908 The following example uses the filtered property map resource to 1909 request the "default-network-map.pid" property and the "alt-network- 1910 map.pid" property for a set of IPv4 addresses and prefixes. 1912 Note that the entity "ipv4:192.0.3.0/27" is decomposed into two 1913 entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have 1914 different "default-network-map.pid" property values. 1916 POST /propmap/lookup/pid HTTP/1.1 1917 Host: alto.example.com 1918 Accept: application/alto-propmap+json,application/alto-error+json 1919 Content-Length: 221 1920 Content-Type: application/alto-propmapparams+json 1922 { 1923 "entities" : [ 1924 "ipv4:192.0.2.128", 1925 "ipv4:192.0.2.0/27", 1926 "ipv4:192.0.3.0/27" ], 1927 "properties" : [ "default-network-map.pid", 1928 "alt-network-map.pid ] 1929 } 1931 HTTP/1.1 200 OK 1932 Content-Length: 774 1933 Content-Type: application/alto-propmap+json 1935 { 1936 "meta": { 1937 "dependent-vtags": [ 1938 {"resource-id": "default-network-map", 1939 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1940 {"resource-id": "alt-network-map", 1941 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1942 ] 1943 }, 1944 "property-map": { 1945 "ipv4:192.0.2.128": {"default-network-map.pid": "defaultpid", 1946 "alt-network-map.pid": "defaultpid"}, 1947 "ipv4:192.0.2.0/27": {"default-network-map.pid": "pid2", 1948 "alt-network-map.pid": "pid1"}, 1949 "ipv4:192.0.3.0/28": {"default-network-map.pid": "pid3", 1950 "alt-network-map.pid": "pid2"}, 1951 "ipv4:192.0.3.16/28": {"default-network-map.pid": "pid4", 1952 "alt-network-map.pid": "pid2"} 1953 } 1954 } 1956 10.8. Filtered Property Map Example #4 1958 Here is an example of using the filtered property map to query the 1959 regions for several PIDs in "default-network-map". The "region" 1960 property is specified as a "self-defined" property, i.e., the values 1961 of this property are defined by this property map resource. 1963 POST /propmap/lookup/region HTTP/1.1 1964 Host: alto.example.com 1965 Accept: application/alto-propmap+json,application/alto-error+json 1966 Content-Length: 132 1967 Content-Type: application/alto-propmapparams+json 1969 { 1970 "entities" : ["default-network-map.pid:pid1", 1971 "default-network-map.pid:pid2"], 1972 "properties" : [ ".region" ] 1973 } 1975 HTTP/1.1 200 OK 1976 Content-Length: 326 1977 Content-Type: application/alto-propmap+json 1979 { 1980 "meta" : { 1981 "dependent-vtags" : [ 1982 {"resource-id": "default-network-map", 1983 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1984 ] 1985 }, 1986 "property-map": { 1987 "default-network-map.pid:pid1": { 1988 ".region": "us-west" 1989 }, 1990 "default-network-map.pid:pid2": { 1991 ".region": "us-east" 1992 } 1993 } 1994 } 1996 10.9. Filtered Property Map for ANEs Example #5 1998 The following example uses the filtered property map resource "ane- 1999 dc-property-map" to request properties "storage-capacity" and "cpu" 2000 on several ANEs defined in this property map. 2002 POST /propmap/lookup/ane-dc HTTP/1.1 2003 Host: alto.example.com 2004 Accept: application/alto-propmap+json,application/alto-error+json 2005 Content-Length: 155 2006 Content-Type: application/alto-propmapparams+json 2008 { 2009 "entities" : [".ane:dc21", 2010 ".ane:dc45.srv9", 2011 ".ane:dc6.srv-cluster8"], 2012 "properties" : [ "storage-capacity", "cpu"] 2013 } 2015 HTTP/1.1 200 OK 2016 Content-Length: 295 2017 Content-Type: application/alto-propmap+json 2019 { 2020 "meta" : { 2021 }, 2022 "property-map": { 2023 ".ane:dc21": 2024 {"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores}, 2025 ".ane:dc45.srv9": 2026 {"storage-capacity" : 100 Gbytes, "cpu" : 20 Cores}, 2027 ".ane:dc6.srv-cluster8": 2028 {"storage-capacity" : 6000 Gbytes, "cpu" : 100 Cores} 2029 } 2030 } 2032 11. Security Considerations 2034 Both Property Map and Filtered Property Map defined in this document 2035 fit into the architecture of the ALTO base protocol, and hence the 2036 Security Considerations (Section 15 of [RFC7285]) of the base 2037 protocol fully apply: authenticity and integrity of ALTO information 2038 (i.e., authenticity and integrity of Property Maps), potential 2039 undesirable guidance from authenticated ALTO information (e.g., 2040 potentially imprecise or even wrong value of a property such as geo- 2041 location), confidentiality of ALTO information (e.g., exposure of a 2042 potentially sensitive entity property such as geo-location), privacy 2043 for ALTO users, and availability of ALTO services should all be 2044 considered. 2046 A particular fundamental security consideration when an ALTO server 2047 provides a Property Map is to define precisely the policies on who 2048 can access what properties for which entities. Security mechanisms 2049 such as authentication and confidentiality mechanisms should then be 2050 applied to enforce the policy. For example, a policy can be that a 2051 property P can be accessed only by its owner (e.g., the customer who 2052 is allocated a given IP address). Then, the ALTO server will need to 2053 deploy corresponding mechanisms to realize the policy. The policy 2054 may allow non-owners to access a coarse-grained value of the property 2055 P. In such a case, the ALTO server may provide a different URI to 2056 provide the information. 2058 12. IANA Considerations 2060 This document defines additional application/alto-* media types. It 2061 defines an ALTO Entity Domain Type Registry that extends the ALTO 2062 Address Type Registry defined in [RFC7285]. It also defines an ALTO 2063 Entity Property Type Registry that extends the ALTO endpoint property 2064 registry defined in [RFC7285]. 2066 12.1. application/alto-* Media Types 2068 This document registers two additional ALTO media types, listed in 2069 Table 1. 2071 +=============+=========================+===============+ 2072 | Type | Subtype | Specification | 2073 +=============+=========================+===============+ 2074 | application | alto-propmap+json | Section 7.1 | 2075 +-------------+-------------------------+---------------+ 2076 | application | alto-propmapparams+json | Section 8.3 | 2077 +-------------+-------------------------+---------------+ 2079 Table 1: Additional ALTO Media Types. 2081 Type name: 2082 application 2084 Subtype name: 2085 This document registers multiple subtypes, as listed in Table 1. 2087 Required parameters: 2088 n/a 2090 Optional parameters: 2091 n/a 2093 Encoding considerations: 2094 Encoding considerations are identical to those specified for the 2095 "application/json" media type. See [RFC8259]. 2097 Security considerations: 2098 Security considerations related to the generation and consumption 2099 of ALTO Protocol messages are discussed in Section 15 of 2100 [RFC7285]. 2102 Interoperability considerations: 2103 This document specifies formats of conforming messages and the 2104 interpretation thereof. 2106 Published specification: 2107 This document is the specification for these media types; see 2108 Table 1 for the section documenting each media type. 2110 Applications that use this media type: 2111 ALTO servers and ALTO clients either stand alone or are embedded 2112 within other applications. 2114 Additional information: 2115 Magic number(s): n/a 2117 File extension(s): This document uses the mime type to refer to 2118 protocol messages and thus does not require a file extension. 2120 Macintosh file type code(s): n/a 2122 Person & email address to contact for further information: 2123 See Authors' Addresses section. 2125 Intended usage: 2126 COMMON 2128 Restrictions on usage: 2129 n/a 2131 Author: 2132 See Authors' Addresses section. 2134 Change controller: 2135 Internet Engineering Task Force (mailto:iesg@ietf.org). 2137 12.2. ALTO Entity Domain Type Registry 2139 This document requests IANA to create and maintain the "ALTO Entity 2140 Domain Type Registry", listed in Table 2. 2142 +============+============+=============+======================+ 2143 | Identifier | Entity | Hierarchy & | Media Type of | 2144 | | Identifier | Inheritance | Defining Resource | 2145 | | Encoding | | | 2146 +============+============+=============+======================+ 2147 | ipv4 | See | See Section | application/alto- | 2148 | | Section | 6.1.3 | networkmap+json | 2149 | | 6.1.1 | | | 2150 +------------+------------+-------------+----------------------+ 2151 | ipv6 | See | See Section | application/alto- | 2152 | | Section | 6.1.3 | networkmap+json | 2153 | | 6.1.2 | | | 2154 +------------+------------+-------------+----------------------+ 2155 | pid | See | None | application/alto- | 2156 | | Section | | networkmap+json | 2157 | | 6.2 | | | 2158 +------------+------------+-------------+----------------------+ 2160 Table 2: ALTO Entity Domain Types 2162 This registry serves two purposes. First, it ensures uniqueness of 2163 identifiers referring to ALTO entity domain types. Second, it states 2164 the requirements for allocated entity domain types. 2166 12.2.1. Consistency Procedure between ALTO Address Type Registry and 2167 ALTO Entity Domain Type Registry 2169 One potential issue of introducing the "ALTO Entity Domain Type 2170 Registry" is its relationship with the "ALTO Address Types Registry" 2171 already defined in Section 14.4 of [RFC7285]. In particular, the 2172 entity identifier of a type of an entity domain registered in the 2173 "ALTO Entity Domain Type Registry" MAY match an address type defined 2174 in "ALTO Address Type Registry". It is necessary to precisely define 2175 and guarantee the consistency between "ALTO Address Type Registry" 2176 and "ALTO Entity Domain Registry". 2178 We define that the ALTO Entity Domain Type Registry is consistent 2179 with ALTO Address Type Registry if two conditions are satisfied: 2181 * When an address type is already or able to be registered in the 2182 ALTO Address Type Registry [RFC7285], the same identifier MUST be 2183 used when a corresponding entity domain type is registered in the 2184 ALTO Entity Domain Type Registry. 2186 * If an ALTO entity domain type has the same identifier as an ALTO 2187 address type, their addresses encoding MUST be compatible. 2189 To achieve this consistency, the following items MUST be checked 2190 before registering a new ALTO entity domain type in a future 2191 document: 2193 * Whether the ALTO Address Type Registry contains an address type 2194 that can be used as an identifier for the candidate entity domain 2195 type identifier. This has been done for the identifiers "ipv4" 2196 and "ipv6" of Table 2. 2198 * Whether the candidate entity domain type identifier can 2199 potentially be an endpoint address type, as defined in Sections 2200 2.1 and 2.2 of [RFC7285]. 2202 When a new ALTO entity domain type is registered, the consistency 2203 with the ALTO Address Type Registry MUST be ensured by the following 2204 procedure: 2206 * Test: Do corresponding entity domain type identifiers match a 2207 known "network" address type? 2209 - If yes (e.g., cell, MAC or socket addresses): 2211 o Test: Is such an address type present in the ALTO Address 2212 Type Registry? 2214 + If yes: Set the new ALTO entity domain type identifier to 2215 be the found ALTO address type identifier. 2217 + If no: Define a new ALTO entity domain type identifier 2218 and use it to register a new address type in the ALTO 2219 Address Type Registry following Section 14.4 of 2220 [RFC7285]. 2222 o Use the new ALTO entity domain type identifier to register a 2223 new ALTO entity domain type in the ALTO Entity Domain Type 2224 Registry following Section 12.2.2 of this document. 2226 - If no (e.g., pid name, ane name or country code): Proceed with 2227 the ALTO Entity Domain Type registration as described in 2228 Section 12.2.2. 2230 12.2.2. ALTO Entity Domain Type Registration Process 2232 New ALTO entity domain types are assigned after IETF Review [RFC8126] 2233 to ensure that proper documentation regarding the new ALTO entity 2234 domain types and their security considerations has been provided. 2235 RFCs defining new entity domain types SHOULD indicate how an entity 2236 in a registered type of domain is encoded as an EntityID, and, if 2237 applicable, the rules defining the entity hierarchy and property 2238 inheritance. Updates and deletions of ALTO entity domains types 2239 follow the same procedure. 2241 Registered ALTO entity domain type identifiers MUST conform to the 2242 syntactical requirements specified in Section 5.1.2. Identifiers are 2243 to be recorded and displayed as strings. 2245 Requests to the IANA to add a new value to the Entity Domain Type 2246 registry MUST include the following information: 2248 * Identifier: The name of the desired ALTO entity domain type. 2250 * Entity Identifier Encoding: The procedure for encoding the 2251 identifier of an entity of the registered domain type as an 2252 EntityID (see Section 5.1.3). If corresponding entity identifiers 2253 of an entity domain type match a known "network" address type, the 2254 Entity Identifier Encoding of this domain identifier MUST include 2255 both Address Encoding and Prefix Encoding of the same identifier 2256 registered in the ALTO Address Type Registry [RFC7285]. To define 2257 properties, an individual entity identifier and the corresponding 2258 full-length prefix MUST be considered aliases for the same entity. 2260 * Hierarchy: If the entities form a hierarchy, the procedure for 2261 determining that hierarchy. 2263 * Inheritance: If entities can inherit property values from other 2264 entities, the procedure for determining that inheritance. 2266 * Media type of defining information resource: some entity domain 2267 types allow an entity domain name to be combined with an 2268 information resource name to define a resource-specific entity 2269 domain. Such an information resource is called "defining 2270 information resource". In this case, the authorized media type of 2271 the defining information resources MUST be specified in the 2272 document defining the entity domain type. When an entity domain 2273 type allows combinations with defining resources, this must be 2274 indicated and the conditions fully specified in the document. The 2275 defining information resource for an entity domain type is the one 2276 that: 2278 - has an entry in the IRD, 2280 - defines these entities, 2282 - does not use another information resource that defines these 2283 entities, 2285 - defines and exposes entity identifiers that are all persistent. 2287 - has a unique media type equal to the one specified in the 2288 document defining the entity domain type. 2290 * Knowing the media type of the defining information resource is 2291 useful when Servers indicate resource specific entity domains in 2292 the property map capabilities. Clients need to know if the 2293 combination of information resource type and entity domain type is 2294 allowed. See also, Section 4.6 and Section 5.1 for more 2295 information. 2297 * Mapping to ALTO Address Type: A boolean value to indicate if the 2298 entity domain type can be mapped to the ALTO address type with the 2299 same identifier. 2301 * Security Considerations: In some usage scenarios, entity 2302 identifiers carried in ALTO Protocol messages may reveal 2303 information about an ALTO client or an ALTO service provider. 2304 Applications and ALTO service providers using addresses of the 2305 registered type should be cognizant of how (or if) the addressing 2306 scheme relates to private information and network proximity. 2308 This specification requests registration of the identifiers "ipv4", 2309 "ipv6" and "pid", as shown in Table 2. 2311 12.3. ALTO Entity Property Type Registry 2313 This document requests IANA to create and maintain the "ALTO Entity 2314 Property Type Registry", listed in Table 3. 2316 This registry extends the "ALTO Endpoint Property Type Registry", 2317 defined in [RFC7285], in that a property type is defined on one or 2318 more entity domains, rather than just on IPv4 and IPv6 Internet 2319 address domains. An entry in this registry is an ALTO entity 2320 property type defined in Section 5.2.1. Thus, a registered ALTO 2321 entity property type identifier MUST conform to the syntactical 2322 requirements specified in that section. 2324 +============+====================+=================================+ 2325 | Identifier | Intended Semantics | Media Type of | 2326 | | | Defining Resource | 2327 +============+====================+=================================+ 2328 | pid | See Section 7.1.1 | application/alto- | 2329 | | of [RFC7285] | networkmap+json | 2330 +------------+--------------------+---------------------------------+ 2332 Table 3: ALTO Entity Property Types. 2334 Requests to the IANA to add a new value to the registry MUST include 2335 the following information: 2337 * Identifier: The unique id for the desired ALTO entity property 2338 type. The format MUST be as defined in Section 5.2.1 of this 2339 document. It includes the information of the applied ALTO entity 2340 domain and the property name. 2342 * Intended Semantics: ALTO entity properties carry with them 2343 semantics to guide their usage by ALTO clients. Hence, a document 2344 defining a new type SHOULD provide guidance to both ALTO service 2345 providers and applications utilizing ALTO clients as to how values 2346 of the registered ALTO entity property should be interpreted. 2348 * Media type of defining information resource: when the property 2349 type allows values to be defined relatively to a given information 2350 resource, the latter is referred to as the "defining information 2351 resource", see also description in Section 4.7. The media type of 2352 the possibly used defining information resource MUST be indicated. 2354 * Security Considerations: ALTO entity properties expose information 2355 to ALTO clients. ALTO service providers should be cognizant of 2356 the security ramifications related to the exposure of an entity 2357 property. 2359 In security considerations, the request should also discuss the 2360 sensitivity of the information, and why it is required for ALTO-based 2361 operations. Regarding this discussion, the request SHOULD follow the 2362 recommendations of Section 14.3. ALTO Endpoint Property Type 2363 Registry in [RFC7285]. 2365 This document requests registration of the identifier "pid", listed 2366 in Table 3. Semantics for this property are documented in 2367 Section 7.1.1 of [RFC7285]. No security issues related to the 2368 exposure of a "pid" identifier are considered, as it is exposed with 2369 the Network Map Service defined and mandated in [RFC7285]. 2371 13. Acknowledgments 2373 The authors would like to thank Dawn Chen (Tongji University), and 2374 Shenshen Chen (Tongji/Yale University) for their contributions to 2375 earlier drafts. Thank you also to Qiao Xiang (Yale University), 2376 Shawn Lin, Xin Wang and Vijay Gurbani (Vail systems) for fruitful 2377 discussions. Last, big thanks to Danny Perez (University of 2378 Campinas) and Luis Contreras (Telefonica) for their substantial 2379 review feedback and suggestions to improve this document. 2381 14. References 2383 14.1. Normative References 2385 [ISO3166-1] 2386 The International Organization for Standardization, "Codes 2387 for the representation of names of countries and their 2388 subdivisions -- Part 1: Country codes, ISO 3166-1:2013", 2389 2013. 2391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2392 Requirement Levels", BCP 14, RFC 2119, 2393 DOI 10.17487/RFC2119, March 1997, 2394 . 2396 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2397 Resource Identifier (URI): Generic Syntax", STD 66, 2398 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2399 . 2401 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2402 (CIDR): The Internet Address Assignment and Aggregation 2403 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2404 2006, . 2406 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2407 Address Text Representation", RFC 5952, 2408 DOI 10.17487/RFC5952, August 2010, 2409 . 2411 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 2412 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 2413 "Application-Layer Traffic Optimization (ALTO) Protocol", 2414 RFC 7285, DOI 10.17487/RFC7285, September 2014, 2415 . 2417 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2418 Writing an IANA Considerations Section in RFCs", BCP 26, 2419 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2420 . 2422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2424 May 2017, . 2426 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2427 Interchange Format", STD 90, RFC 8259, 2428 DOI 10.17487/RFC8259, December 2017, 2429 . 2431 14.2. Informative References 2433 [I-D.gao-alto-fcs] 2434 Zhang, J., Gao, K., Wang, J., and Y. Yang, "ALTO 2435 Extension: Flow-based Cost Query", Work in Progress, 2436 Internet-Draft, draft-gao-alto-fcs-07, 16 March 2020, 2437 . 2439 [I-D.ietf-alto-cdni-request-routing-alto] 2440 Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang, 2441 "Content Delivery Network Interconnection (CDNI) Request 2442 Routing: CDNI Footprint and Capabilities Advertisement 2443 using ALTO", Work in Progress, Internet-Draft, draft-ietf- 2444 alto-cdni-request-routing-alto-16, 12 January 2021, 2445 . 2448 [I-D.ietf-alto-path-vector] 2449 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 2450 "ALTO Extension: Path Vector", Work in Progress, Internet- 2451 Draft, draft-ietf-alto-path-vector-13, 20 November 2020, 2452 . 2455 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2456 "Specification of the IP Flow Information Export (IPFIX) 2457 Protocol for the Exchange of Flow Information", STD 77, 2458 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2459 . 2461 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 2462 Nadeau, "An Architecture for the Interface to the Routing 2463 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 2464 . 2466 Appendix A. Features introduced with the Entity Property Maps extension 2468 The Entity Property Maps extension described in this document 2469 introduces a number of features that are summarized in table below. 2470 The first column provides the name of the feature. The second column 2471 provides the section number of this document that gives a high level 2472 description of the feature. The third column provides the section 2473 number of this document that gives a normative description relating 2474 to the feature, when applicable. 2476 +======================+=============+==============================+ 2477 | Feature | High-level | Related normative | 2478 | | description | description | 2479 +======================+=============+==============================+ 2480 | Entity | Section 3.1 | Section 5.1.3 | 2481 +----------------------+-------------+------------------------------+ 2482 | Entity domain | Section 3.2 | | 2483 | (ED) | | | 2484 +----------------------+-------------+------------------------------+ 2485 | Entity domain | Section | Section 5.1.1 | 2486 | type | 3.2.1 | | 2487 +----------------------+-------------+------------------------------+ 2488 | Entity domain | Section | Section 5.1.2 | 2489 | name | 3.2.2 | | 2490 +----------------------+-------------+------------------------------+ 2491 | Entity property | Section 3.3 | Section 5.2, Section 5.2.1, | 2492 | (EP) type | | Section 5.2.2, Section 5.2.3 | 2493 +----------------------+-------------+------------------------------+ 2494 | Entity property | Section 3.4 | Section 7, Section 8 | 2495 | map | | | 2496 +----------------------+-------------+------------------------------+ 2497 | Resource-specific | Section 4.2 | Section 5.1.2, | 2498 | ED name | | Section 5.1.2.1 | 2499 +----------------------+-------------+------------------------------+ 2500 | Resource-specific | Section 4.3 | Section 5.2.3 | 2501 | EP value | | | 2502 +----------------------+-------------+------------------------------+ 2503 | Entity Hierarchy | Section 4.4 | Section 5.1.4 | 2504 | and property | | | 2505 | inheritance | | | 2506 +----------------------+-------------+------------------------------+ 2507 | Defining | Section | Section 12.2.2, Section 12.3 | 2508 | information | 4.6, | | 2509 | resource | Section 4.7 | | 2510 +----------------------+-------------+------------------------------+ 2512 Table 4: Features introduced with ALTO Entity Property Maps 2514 Authors' Addresses 2516 Wendy Roome 2517 Nokia Bell Labs (Retired) 2518 124 Burlington Rd 2519 Murray Hill, NJ 07974 2520 United States of America 2522 Phone: +1-908-464-6975 2523 Email: wendy@wdroome.com 2525 Sabine Randriamasy 2526 Nokia Bell Labs 2527 Route de Villejust 2528 91460 NOZAY 2529 France 2531 Email: Sabine.Randriamasy@nokia-bell-labs.com 2533 Y. Richard Yang 2534 Yale University 2535 51 Prospect Street 2536 New Haven, CT 06511 2537 United States of America 2539 Phone: +1-203-432-6400 2540 Email: yry@cs.yale.edu 2542 Jingxuan Jensen Zhang 2543 Tongji University 2544 4800 Caoan Road 2545 Shanghai 2546 201804 2547 China 2549 Email: jingxuan.n.zhang@gmail.com 2551 Kai Gao 2552 Sichuan University 2553 No.24 South Section 1, Yihuan Road 2554 Chengdu 2555 610000 2556 China 2557 Email: kaigao@scu.edu.cn