idnits 2.17.1 draft-ietf-alto-unified-props-new-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1350 has weird spacing: '...rtyName prop...' == Line 1544 has weird spacing: '...country stat...' == Line 1605 has weird spacing: '...axresbw per...' == Line 2412 has weird spacing: '...esource doma...' -- The document date (July 13, 2020) is 1381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8174' is mentioned on line 273, but not defined == Unused Reference: 'RFC8008' is defined on line 2377, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7921 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-09 Summary: 4 errors (**), 0 flaws (~~), 9 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: January 14, 2021 Y. Yang 6 Yale University 7 J. Zhang 8 Tongji University 9 K. Gao 10 Sichuan University 11 July 13, 2020 13 Unified properties for the ALTO protocol 14 draft-ietf-alto-unified-props-new-12 16 Abstract 18 This document extends the Application-Layer Traffic Optimization 19 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 20 properties" to generic types of entities, and by presenting those 21 properties as maps, similar to the network and cost maps in 22 [RFC7285]. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 14, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 67 3. Basic Features of the Unified Property Extension . . . . . . 6 68 3.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 8 71 3.2.2. Entity Domain Name . . . . . . . . . . . . . . . . . 8 72 3.3. Entity Property Type . . . . . . . . . . . . . . . . . . 8 73 3.4. New information resource and media type: ALTO Property 74 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Advanced Features of the Unified Property Extension . . . . . 10 76 4.1. Entity Identifier and Entity Domain Name . . . . . . . . 10 77 4.2. Resource-Specific Entity Domain Name . . . . . . . . . . 10 78 4.3. Resource-Specific Entity Property Value . . . . . . . . . 11 79 4.4. Entity Hierarchy and Property Inheritance . . . . . . . . 12 80 4.4.1. Entity Hierarchy . . . . . . . . . . . . . . . . . . 12 81 4.4.2. Property Inheritance . . . . . . . . . . . . . . . . 13 82 4.4.3. Property Value Unicity . . . . . . . . . . . . . . . 13 83 4.5. Supported Properties on Entity Domains in Property Map 84 Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 85 4.6. Defining Information Resource . . . . . . . . . . . . . . 14 86 4.6.1. Defining Information Resource and Media Type . . . . 15 87 4.6.2. Examples of specific resources media-types . . . . . 16 88 4.7. Defining Information Resource for Resource-Specific 89 Property Values . . . . . . . . . . . . . . . . . . . . . 17 90 4.7.1. Examples of defining resources media-types for 91 properties . . . . . . . . . . . . . . . . . . . . . 17 92 5. Protocol Specification: Basic Data Type . . . . . . . . . . . 17 93 5.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 17 94 5.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 18 95 5.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 18 96 5.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 20 97 5.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 20 98 5.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 21 99 5.2.1. Entity Property Type . . . . . . . . . . . . . . . . 21 100 5.2.2. Entity Property Name . . . . . . . . . . . . . . . . 22 101 5.2.3. Format for Entity Property Value . . . . . . . . . . 22 102 6. Entity Domain Types Defined in this Document . . . . . . . . 22 103 6.1. Internet Address Domain Types . . . . . . . . . . . . . . 23 104 6.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 23 105 6.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 23 106 6.1.3. Hierarchy and Inheritance of Internet Address Domains 23 107 6.1.4. Defining Information Resource Media Type for domain 108 types IPv4 and IPv6 . . . . . . . . . . . . . . . . . 25 109 6.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 25 110 6.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 25 111 6.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 25 112 6.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 25 113 6.2.4. Defining Information Resource Media Type for Domain 114 Type PID . . . . . . . . . . . . . . . . . . . . . . 25 115 6.2.5. Relationship To Internet Addresses Domains . . . . . 26 116 6.3. Internet Address Properties vs. PID Properties . . . . . 26 117 7. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 26 118 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 27 119 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 27 120 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 27 121 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 27 122 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 27 123 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 27 124 8. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 29 125 8.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 29 126 8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 29 127 8.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 29 128 8.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 30 129 8.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 30 130 8.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 30 131 8.7. Entity property type defined in this document . . . . . . 32 132 9. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 32 133 9.1. Impact on Endpoint Property Service . . . . . . . . . . . 32 134 9.2. Impact on Resource-Specific Properties . . . . . . . . . 32 135 9.3. Impact on Other Properties . . . . . . . . . . . . . . . 32 136 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 137 10.1. Network Map . . . . . . . . . . . . . . . . . . . . . . 33 138 10.2. Property Definitions . . . . . . . . . . . . . . . . . . 33 139 10.3. Properties for Abstract Network Elements . . . . . . . . 34 140 10.4. Information Resource Directory (IRD) . . . . . . . . . . 35 141 10.5. Full Property Map Example . . . . . . . . . . . . . . . 37 142 10.6. Filtered Property Map Example #1 . . . . . . . . . . . . 38 143 10.7. Filtered Property Map Example #2 . . . . . . . . . . . . 39 144 10.8. Filtered Property Map Example #3 . . . . . . . . . . . . 41 145 10.9. Filtered Property Map Example #4 . . . . . . . . . . . . 42 146 10.10. Filtered Property Map for ANEs Example #5 . . . . . . . 43 147 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 148 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 149 12.1. application/alto-* Media Types . . . . . . . . . . . . . 45 150 12.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 46 151 12.2.1. Consistency Procedure between ALTO Address Type 152 Registry and ALTO Entity Domain Type Registry . . . 46 153 12.2.2. ALTO Entity Domain Type Registration Process . . . . 48 154 12.3. ALTO Entity Property Type Registry . . . . . . . . . . . 49 155 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 156 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 157 14.1. Normative References . . . . . . . . . . . . . . . . . . 51 158 14.2. Informative References . . . . . . . . . . . . . . . . . 52 159 Appendix A. Scope of Property Map . . . . . . . . . . . . . . . 52 160 A.1. Example Property Map . . . . . . . . . . . . . . . . . . 53 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 163 1. Introduction 165 The ALTO protocol [RFC7285] introduces the concept of "properties" 166 attached to "endpoint addresses", and defines the Endpoint Property 167 Service (EPS) to allow ALTO clients to retrieve those properties. 168 While useful, the EPS, as defined in [RFC7285], has at least three 169 limitations. 171 First, the EPS allows properties to be associated with only endpoints 172 which are identified by individual communication addresses like IPv4 173 and IPv6 addresses. It is reasonable to think that collections of 174 endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have 175 properties. Furthermore, recent ALTO use cases show that properties 176 of network flows [RFC7011] and routing elements [RFC7921] are also 177 very useful. Since the EPS cannot be extended to those generic 178 entities, new services, with new request and response messages, would 179 have to be defined for them. 181 Second, the EPS only allows endpoints identified by global 182 communication addresses. However, an endpoint address may be a local 183 IP address or an anycast IP address which is also not globally 184 unique. Additionally, a generic entity such as a PID may have an 185 identifier that is not globally unique. For example, a PID 186 identifier may be used in multiple network maps, where in each 187 network map, this PID identifier points to a different set of 188 addresses. 190 Third, the EPS is only defined as a POST-mode service. Clients must 191 request the properties for an explicit set of endpoint addresses. By 192 contrast, [RFC7285] defines a GET-mode cost map resource which 193 returns all available costs, so a client can get a full set of costs 194 once, and then process cost lookups without querying the ALTO server. 195 [RFC7285] does not define a similar service for endpoint properties. 196 At first, a map of endpoint properties might seem impractical, 197 because it could require enumerating the property value for every 198 possible endpoint. However, in practice, it is highly unlikely that 199 properties will be defined for every endpoint address. It is much 200 more likely that properties may be defined for only a subset of 201 endpoint addresses, and the specification of properties uses an 202 aggregation representation to allow enumeration. This is 203 particularly true if blocks of endpoint addresses with a common 204 prefix (e.g., a CIDR) have the same value for a property. Entities 205 in other domains may very well allow aggregated representation and 206 hence be enumerable as well. 208 To address the three limitations, this document specifies a protocol 209 extension for defining and retrieving ALTO properties: 211 o The first limitation is addressed by introducing a generic concept 212 called ALTO Entity, which generalizes an endpoint and may 213 represent a PID, a network element, a cell in a cellular network, 214 an abstracted network element as defined in [REF path-vector], or 215 other physical or logical objects used by ALTO. Each entity is 216 included in a collection called an ALTO Entity Domain. Since each 217 ALTO Entity Domain includes only one type of entities, each Entity 218 Domain can be classified by the type of entities in it. 220 o The second limitation is addressed by using resource-specific 221 entity domains. A resource-specific entity domain contains 222 entities that are defined and identified with respect to a given 223 ALTO information resource, which provides scoping. For example, 224 an entity domain containing PIDs is identified with respect to the 225 network map in which these PIDs are defined. Likewise an entity 226 domain containing local IP addresses may be defined with respect 227 to a local network map. 229 o The third limitation is addressed by defining two new types of 230 ALTO information resources: Property Map, detailed in Section 7 231 and Filtered Property Map, detailed in Section 8. The former is a 232 GET-mode resource that returns the property values for all 233 entities in one or more entity domains, and is analogous to a 234 network map or a cost map in [RFC7285]. The latter is a POST-mode 235 resource that returns the values for a set of properties and 236 entities requested by the client, and is analogous to a filtered 237 network map or a filtered cost map. 239 The protocol extension defined in this document is extensible. New 240 entity domain types can be defined without revising the specification 241 defined in this document. Similarly, new cost metrics and new 242 endpoint properties can be defined in other documents without 243 revising the protocol specification defined in [RFC7285]. 245 This document subsumes the Endpoint Property Service defined in 246 [RFC7285], although that service may be retained for legacy clients 247 (see Section 9). 249 This document assumes the reader is familiar with the base ALTO 250 protocol defined in [RFC7285]. 252 1.1. Terminology 254 TODO: TBC 256 o Client: When starting with a capital "C", this term refers to an 257 ALTO client. 259 o Server: When starting with a capital "S", this term refers to an 260 ALTO server. 262 o TBC 264 2. Requirements Language 266 TODO: REAL RFC xrefs The key words "MUST", "MUST NOT", "REQUIRED", 267 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 268 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 269 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 270 when, they appear in all capitals, as shown here. When the words 271 appear in lower case, they are to be interpreted with their natural 272 language meanings. 274 3. Basic Features of the Unified Property Extension 276 This section gives a high-level overview of the the basic features 277 involved in ALTO Entity Property Maps. It assumes the reader is 278 familiar with the ALTO protocol [RFC7285]. The purpose of this 279 extension is to convey properties on objects that extend ALTO 280 Endpoints and are called ALTO Entities, entities for short. 282 3.1. Entity 284 The concept of an ALTO Entity generalizes the concept of an ALTO 285 Endpoint defined in Section 2.1 of [RFC7285]. An entity is an object 286 that can be an endpoint that is defined by its network address, but 287 can also be an object that has a defined mapping to a set of one or 288 more network addresses or an object that is not even related to any 289 network address. Thus, where as all endpoints are entities, not all 290 entities are endpoints. 292 Examples of entities are: 294 o an ALTO endpoint, defined in [RFC7285], that represents an 295 application or a host identified by a communication address (e.g., 296 an IPv4 or IPv6 address) in a network, 298 o a PID, defined in [RFC7285], that has a provider defined human- 299 readable identifier specified by an ALTO network map, which maps a 300 PID to a set of ipv4 and ipv6 addresses, 302 o an autonomous system (AS), that has an AS number (ASN) as its 303 identifier and maps to a set of ipv4 and ipv6 addresses, 305 o a country with a code as specified in [ISO3166-1], to which 306 applications such as CDN providers associate properties and 307 capabilities, 309 o a TCP/IP network flow, that is identified by a TCP/IP 5-Tuple 310 specifying its source and destination addresses and port numbers 311 and the utilized protocol, 313 o a routing element, that is specified in [RFC7921] and is 314 associated with routing capabilities information, 316 o an abstract network element, that represents an abstraction of a 317 network part such as a routable network node, one or more links, a 318 network domain or their aggregation. 320 3.2. Entity Domain 322 An entity domain defines a set of entities of the same semantic type. 323 An entity domain is characterized by its type and identified by its 324 name. 326 In this document, an entity must be owned by exactly one entity 327 domain name. An entity identifier must point to exactly one entity. 328 If two entities in two different entity domains refer to the same 329 physical or logical object, they are treated as different entities. 330 For example, if an object has both an IPv4 and an IPv6 address, these 331 two addresses will be treated as two entities, defined respectively 332 in the "ipv4" and "ipv6" entity domains. 334 3.2.1. Entity Domain Type 336 The type of an entity domain type defines the semantics of a type of 337 entity. Entity domain types can be defined in different documents. 338 For example: the present document defines entity domain types "ipv4", 339 "ipv6" and "pid" in sections Section 6.1 and Section 6.2. The entity 340 domain type "ane", that defines Abstract Network Elements (ANEs), is 341 introduced in [I-D.ietf-alto-path-vector]. The entity domain type 342 that defines country codes is introduced in 343 [draft-ietf-alto-cdni-request-routing-alto]. An entity domain type 344 is expected to be registered at the IANA, as specified in section 345 Section 12.2.2 and similarly to an ALTO address type. 347 3.2.2. Entity Domain Name 349 The name of an entity domain is defined in the scope of an ALTO 350 server. An entity domain name can be identical to its relevant 351 entity domain type in the following case: when the entities of an 352 entity domain have an identifier that points to the same object 353 throughout all the information resources of the Server that provide 354 entity properties for this domain. For example, a domain of type 355 "ipv4" that contains entities identified by a public IPv4 address can 356 be named "ipv4" because its entities are uniquely identified by all 357 the resources of the Server. 359 In some cases, a domain type and domain name must be different. 360 Indeed, for some domain types, entities are defined relatively to a 361 given information resource. As a consequence, entities in such 362 domains may be defined in a resource handling this domain type but 363 not in other resources handling this same domain type. Moreover, 364 across different ALTO information resources handling a domain type, 365 an entity identifier may point to different objects. This is the 366 case for entities of domain type "pid". A PID is defined relatively 367 to a network map. For example: an entity "mypid10" of domain type 368 "pid" may be defined in a given network map resource and be undefined 369 in other network maps, or may even map to a different set of endpoint 370 addresses. In this case, naming an entity domain only by its type 371 "pid" does not guarantee that its entities are owned by exactly one 372 entity domain name. Section 4.2 and related of this document 373 describe how a domain is uniquely identified by a name that 374 associates the domain type and the related information resource. 376 3.3. Entity Property Type 378 An entity property defines a property of an entity. This is similar 379 to the endpoint property defined in Section 7.1 of [RFC7285]. An 380 entity property can convey either network-aware or network-agnostic 381 information. Simularly to an entity domain, an entity property is 382 characterized by its type and identified by its name. An entity 383 property type is expected to be registered at the IANA, as specified 384 in section Section 12.3. 386 For example: 388 o an entity in the "ipv4" domain may have a property whose value is 389 an Autonomous System (AS) number indicating the AS that owns this 390 IPv4 address and another property named "countrycode" indicating a 391 country code mapping to this address, 393 o an entity identified by its country code in the "countrycode" 394 domain, defined in [draft-ietf-alto-cdni-request-routing-alto] may 395 have a property indicating what delivery protocol is used by a 396 CDN, 398 o an entity in the "netmap1.pid" domain may have a property that 399 indicates the central geographical location of the endpoints it 400 includes. 402 It should be noted that some identifiers may be used for both an 403 entity domain type and a property type. For example: 405 o the identifier "countrycode" may point to both the entity domain 406 type "countrycode" and the property type "countrycode". 408 o the identifier "pid" may point to both the entity domain type 409 "pid" and the property type "pid". 411 Likewise, a same identifier may point to both a domain name and a 412 property name. 414 3.4. New information resource and media type: ALTO Property Map 416 This document introduces a new ALTO information resource named 417 Property Map. An ALTO property map provides a set of properties on 418 one or more sets of entities. A property may apply to different 419 entity domain types and names. For example, an ALTO property map may 420 define the "ASN" property for both "ipv4" and "ipv6" entity domains. 422 The present extension also introduces a new media type. 424 This document uses the same definition of an information resource as 425 Section 9.1 of [RFC7285]. ALTO uses media types to uniquely indicate 426 the data format used to encode the content to be transmitted between 427 an ALTO server and an ALTO client in the HTTP entity body. In the 428 present case, an ALTO property map resource is defined by the media 429 type "application/alto-propmap+json". 431 A Property Map can be queried as a GET-mode resource, thus conveying 432 values of all properties on all entities indicated in its 433 capabilities. It can also be queried as a POST-mode resource, thus 434 conveying a selection of properties on a selection of entities. 436 4. Advanced Features of the Unified Property Extension 438 4.1. Entity Identifier and Entity Domain Name 440 In [RFC7285], an endpoint has an identifier which is explicitly 441 associated with the "ipv4" or "ipv6" address domain. Examples are 442 "ipv4:192.0.2.14" and "ipv6:2001:db8::12". 444 In this document, an entity must be owned by exactly one entity 445 domain name and an entity identifier must point to exactly one 446 entity. To ensure this, an entity identifier is explicitly attached 447 to the name of its entity domain and an entity domain type 448 characterizes the semantics and identifier format of its entities. 450 The encoding format of an entity identifier is further specified in 451 Section 5.1.3 of this document. 453 For instance: 455 o if an entity is an endpoint with example routable IPv4 address 456 "192.0.2.14", its identifier is associated with domain name "ipv4" 457 and is "ipv4:192.0.2.14", 459 o if an entity is a PID named "mypid10" in network map resource 460 "netmap2", its identifier is associated with domain name 461 "netmap2.pid" and is "netmap2.pid:mypid10". 463 4.2. Resource-Specific Entity Domain Name 465 Some entities are defined and identified in a unique and global way. 466 This is the case for instance for entities that are endpoints 467 identified by a routable IPv4 or IPv6 address. The entity domain for 468 such entities can be globally defined and named "ipv4" or "ipv6". 469 Those entity domains are called resource-agnostic entity domains in 470 this document, as they are not associated to any specific ALTO 471 information resources. 473 Some other entities and entity types are only defined relatively to a 474 given information resource. This is the case for entities of domain 475 type "pid", that can only be understood with respect to the network 476 map where they are defined. For example, a PID named "mypid10" may 477 be defined to represent a set S1 of IP addresses in a network map 478 resource named "netmap1". Another network map "netmap2" may use the 479 same name "mypid10" and define it to represent another set S2 of IP 480 addresses. The identifier "pid:mypid10" may thus point to different 481 objects because the information on the originating information 482 resource is lost. 484 To solve this ambiguity, the present extension introduces the concept 485 of resources-specific entity domain. This concept applies to domain 486 types where entities are defined relatively to a given information 487 resource. It can also apply to entity domains that are defined 488 locally, such as local networks of objects identified with a local 489 IPv4 address. 491 In such cases, an entity domain type is explicitly associated with an 492 identifier of the information resource where these entities are 493 defined. Such an information resource is referred to as the 494 "specific information resource". Using a resource-aware entity 495 domain name, an ALTO property map can unambiguously identify distinct 496 entity domains of the same type, on which entity properties may be 497 queried. Example resource-specific entity domain names may look 498 like: "netmap1.pid" or "netmap2.pid". Thus, a name association such 499 as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" allows to 500 distinguish the two abovementioned PIDs that are both named "mypid10" 501 but in two different resources, "netmap1" and "netmap2". 503 An information resource is defined in the scope of an ALTO Server and 504 so is an entity domain name. The format of a resource-specific 505 entity domain name is further specified in Section 5.1.2. 507 4.3. Resource-Specific Entity Property Value 509 Like entity domains, some types of properties are defined relatively 510 to an information resource. That is, an entity may have a property 511 of a given type, whose values are associated to different information 512 resources. 514 For example, suppose entity "192.0.2.34" defined in the "ipv4" domain 515 has a property of type "pid", whose value is the PID to which address 516 "192.0.2.34" is attached in a network map. The mapping of network 517 addresses to PIDs is specific to a network map and probably different 518 from one network map resource to another one. So that if a property 519 "pid" is defined for entity "192.0.2.34" in two different network 520 maps "netmap1" and "netmap2", the value for this property will likely 521 be different value in "netmap1" and "netmap2". 523 To support information resource dependent property values, this 524 document uses the same approach as in Section 10.8.1 of [RFC7285] 525 entitled "Resource-Specific Endpoint Properties". When a property 526 value depends on a given information resource, the name of this 527 property must be explicitly associated with the information resource 528 that defines it. 530 For example, the property "pid" queried on entity "ipv4:192.0.2.34" 531 and defined in both "netmap1" and "netmap2", can be named 532 "netmap1.pid" and "netmap2.pid". This allows a Client to get a 533 property of the same type but defined in different information 534 resources with a single query. Specifications on the property name 535 format are provided in Section 5.2. 537 4.4. Entity Hierarchy and Property Inheritance 539 For some domain types, entities can be grouped in a set and be 540 defined by the identifier of this set. This is the case for domain 541 types "ipv4" and "ipv6", where individual Internet addresses can be 542 grouped in blocks. When a same property value applies to a whole 543 set, a Server can define a property for the identifier of this set 544 instead of enumerating all the entities and their properties. This 545 allows substantial reduction of transmission payload both for the 546 Server and the Client. For example, all the entities included in the 547 set defined by the address block "ipv6:2001:db8::1/64" share the same 548 properties and values defined for this block. 550 Additionally, entity sets sometimes are related by inclusion, 551 hierarchy or other relations. This allows defining inheritance rules 552 for entity properties that propagate properties among related entity 553 sets. The Server and the Client can use these inheritance rules for 554 further payload savings. Entity hierarchy and property inheritance 555 rules are specified in the documents that define the applicable 556 domain types. The present document defines these rules for the 557 "ipv4" and "ipv6" domain types. 559 This document introduces, for applicable domain types, "Entity 560 Property Inheritance rules", with the following concepts: Entity 561 Hierarchy, Property Inheritance and Property Value Unicity. A 562 detailed specification of entity hierarchy and property inheritance 563 rules is provided in Section 5.1.4. 565 4.4.1. Entity Hierarchy 567 An entity domain may allow using a single identifier to identify a 568 set of individual entities. For example, a CIDR block can be used to 569 identify a set of IPv4 or IPv6 entities. A CIDR block is called a 570 hierarchical entity identifier, as it can reflect inclusion relations 571 among entity sets. For example, the CIDR "ipv4:192.0.1.0/24" 572 includes all the individual ipv4 entities identified by the CIDR 573 "ipv4:192.0.1.0/26". 575 4.4.2. Property Inheritance 577 A property may be defined for a hierarchical entity identifier while 578 it may be undefined for individual entities covered by this 579 identifier. In this case these individual entities inherit the 580 property value defined for the identifier that covers them. For 581 example, suppose a property map defines the ASN property only for the 582 hierarchical entity identifier "ipv4:192.0.1.0/24" but not for 583 individual entities in this block. Suppose also that inheritance 584 rules are specified for CIDR blocks in the "ipv4" domain type. When 585 receiving this property map, a Client can infer that entity 586 "ipv4:192.0.1.1" inherits the "ASN" property value of block 587 "ipv4:192.0.1.0/24" because the address "ipv4:192.0.1.1" is included 588 by the CIDR block "ipv4:192.0.1.0/24". 590 Property value inheritance rules also apply among entity sets. A 591 property map may define values for an entity set belonging to a 592 hierarchy but not for "sub" sets that are covered by this set 593 identifier. In this case, inheritance rules must specify how 594 entities in "sub" sets inherit property values from their "super" 595 set. For instance, if the "ASN" property is defined only for the 596 entity set identified by block "ipv4:192.0.1.0/24", the entity set 597 identified by "ipv4:192.0.1.0/30" and thus included in the former 598 set, may inherit the "ASN" property values from set 599 "ipv4:192.0.1.0/24". 601 4.4.3. Property Value Unicity 603 The inheritance rules must ensure that an entity belonging to a 604 hierarchical set of entities inherits no more than one property 605 value. Indeed, a property map may define a property on a hierarchy 606 of entity sets that inherit property values from one or more 607 including sets in the upper levels. On the other hand, a property 608 value, defined at a lower level of the hierarchy may be different 609 from the value defined at an upper level. In such a case, a set in 610 the lower level of the hierarchy may potentially end up with 611 different values. This may be the case for address blocs with 612 increasing prefix length, on which a property value gets increasingly 613 accurate and thus may differ. For example, a fictitious property 614 such as "geo-location" or "average transfer volume" may be defined at 615 a progressively finer grain for entity sets defined with 616 progressively longer CIDR prefixes. It seems more interesting to 617 have property values of progressively higher accuracy. A unicity 618 rule, applied to the entity domain type must specify an arbitration 619 rule among the different property values for an entity. 621 4.5. Supported Properties on Entity Domains in Property Map 622 Capabilities 624 A property type is not necessarily applicable to any domain type, or 625 an ALTO Server may just not provide a property on all applicable 626 domains. For instance, a property type reflecting link bandwidth is 627 likely not defined on entities of a domain of type "country-code". 628 Therefore an ALTO server providing Property Maps specifies the 629 properties that can be queried on the different entity domains it 630 supports. 632 This document explains how the IRD capabilities of a Property Map 633 resource unambiguously expose what properties a Client can query on a 634 given entity domain. 636 o a field named "mappings" lists the names of the entity domains 637 supported by the Property Map, 639 o for each listed entity domain, a list of the names of the 640 applicable properties is provided. 642 An example is provided in Section 10.4. The "mappings" field 643 associates entity domains and properties that can be resource- 644 agnostic or resource-specific. This allows a Client to formulate 645 compact and unambiguous entity property queries, possibly relating to 646 one or more information resources. In particular: 648 o it avoids a Client to query a property on entity domains on which 649 it is not defined, 651 o it allows a Client to query, for an entity E, values for a 652 property P that are defined in different information resources, 654 o it allows a Client to query a property P on entities that are 655 defined in different information resources. 657 Further specifications are provided in Section 7.4. 659 4.6. Defining Information Resource 661 A Client willing to query properties on entities belonging to a 662 domain needs to know how to retrieve these entities. To this end, he 663 Client can look up the "mappings" field exposed in IRD capabilities 664 of a property map, see Section 4.5. This field, in its keys, exposes 665 all the entity domains supported by the property map. The syntax of 666 the entity domain identifier specified in Section 5.1.2 allows the 667 client to infer whether the entity domain is resource-specific or 668 not. The Client can extract, if applicable, the identifier of the 669 specific resource, query the resource and retrieve the entities. For 670 example: 672 o an entity domain named "netmap1.ipv4" includes the IPv4 addresses 673 that appear in the "ipv4" field of the endpoint address group of 674 each PID in the network map "netmap1", and that cannot be 675 recognized outside "netmap1", for instance because these are local 676 non routable addresses, 678 o an entity domain named "netmap1.pid" includes the PIDs listed in 679 network map "netmap1". 681 o an entity domain named "ipv4" is resource-agnostic and covers all 682 the routable IPv4 addresses. 684 Besides, it is also necessary to inform a Client about which 685 associations of specific resources and entity domain types are 686 allowed, because it is not possible to prevent a Server from exposing 687 inappropriate associations. An informed Client will just ignore 688 inappropriate associations exposed by a Server and avoid error-prone 689 transactions with the Server. 691 For example, the association "costmap3.pid" is not allowed for the 692 following reason: although a cost map exposes PID identifiers, it 693 does not define them, that is, the set of addresses included in this 694 PID. Neither does a cost map list all the PIDs on which properties 695 can be queried, because a cost map only exposes PID pairs on which a 696 queried cost type is defined. The resource "costmap3" therefore does 697 not enable a Client to extract information on the existing PID 698 entities or on the addresses they contain. 700 Instead, the cost map uses a network map, that lists all the PIDs 701 used in a cost map, together with the addresses contained by the 702 PIDs. This network map is qualified in this document as the Defining 703 Information Resource for the entity domain "pid" and this concept is 704 explained in Section 4.6.1. 706 4.6.1. Defining Information Resource and Media Type 708 For the reasons explained in the previous section, this document 709 indroduces the concept of defining information resource and media 710 type. 712 A defining information resource for an entity domain D is the 713 information resource where entities of D are defined. That is, all 714 the information on the entities of D can be retrieved in this 715 resource. This concept applies to resource specific domains. This 716 is useful for entity domain types that are by essence domain- 717 specific, such as "pid" and "ane" domain types. It is also useful 718 for resource-specific entity domains constructed from resource- 719 agnostic domain types, such as for example, network map specific 720 domains of local IPv4 addresses. 722 The defining information resource of an entity domain D has the 723 following specificities: 725 o it has an entry in the IRD, 727 o it defines the entities of D, 729 o it does not use another information resource that defines these 730 entities, 732 o it defines and exposes entity identifiers that are all persistent. 734 o its media type is unique and equal to the one that is specified 735 for the defining information resource of an entity domain type. 737 A fundamental attribute of a defining information resource is its 738 media type. There is a unique association of an entity domain type 739 with the media type of its defining information resources. If an 740 entity domain type allows defining information resources, their media 741 type is specified in the document that defines this entity domain 742 type and in the document that requests the registration of this 743 domain type at the IANA. 745 When the Client wants to use a resource-specific entity domain, it 746 needs to be cognizant of the media-type of its defining information 747 resource. If the Server exposes resources a resource specific entity 748 domain with a non compliant media type for the domain type, the 749 Client can avoid transaction errors by ignoring them. 751 4.6.2. Examples of specific resources media-types 753 Here are some examples of specific information resources types 754 associated to entity domain types and their media type. 756 o For entity domain type "pid": the media type of the specific 757 resource is "application/alto-networkmap+json", because PIDs are 758 defined in network map resources. 760 o For entity domain types "ipv4" and "ipv6": the media type of the 761 specific resource is "application/alto-networkmap+json", because 762 IPv4 and IPv6 addresses covered by the Server are defined in 763 network map resources. 765 o For entity domain type "ane", defined in 766 [I-D.ietf-alto-path-vector]: a specific property map resource can 767 be associated to ANEs that have a persistent identifier and have 768 an entry in the IRD. ANEs that have a persistent identifier are 769 defined in a property map that is indicated in the IRD, therefore 770 the media type associated with entity domain type "ane" is 771 "application/alto-propmap+json". 773 4.7. Defining Information Resource for Resource-Specific Property 774 Values 776 As explained in Section 4.3, a property type may take values that are 777 resource specific. This is the case for example for property type 778 "pid", whose values are by essence defined relatively to a specific 779 network map. The PID value for an IPv4 address differ in different 780 network maps or not be defined for some of them. Property values may 781 be specific to different types of information resources. For 782 example: the value for property "pid" is specific to a network map. 783 The value for property type "cdnifci-capab" is specific to the 784 information resource "cdnifci-map", defined in [draft-ietf-alto-cdni- 785 request-routing-alto], while network maps do not define property 786 "fci-capability" for ipv4 addresses and a cdnifci-map does not define 787 "pid" values for IPv4 addresses. 789 Thus, similarly to resource specific entity domains, the Client needs 790 to be aware of aware of appropriate associations of information 791 resource and property types. 793 4.7.1. Examples of defining resources media-types for properties 795 Here are some examples of specific information resources types 796 associated to entity property types and their media type. 798 o For property type "pid": the media type of the specific resource 799 is "application/alto-networkmap+json", because PIDs are defined in 800 network map resources. 802 o For property type "cdni-fci-capability": the media type of the 803 specific resource is "application/alto-cdnifci+json" 805 5. Protocol Specification: Basic Data Type 807 5.1. Entity Domain 808 5.1.1. Entity Domain Type 810 An entity domain has a type, which is uniquely identified by a string 811 that MUST be no more than 64 characters, and MUST NOT contain 812 characters other than US-ASCII alphanumeric characters 813 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), hyphen ("-", 814 U+002D), and low line ("_", U+005F). The ?.? separator MUST NOT be 815 used unless specifically indicated in a further extension document. 817 For example, the strings "ipv4", "ipv6", and "pid" are valid entity 818 domain types. "ipv4.anycast" and "pid.local" are invalid. 820 The type EntityDomainType is used in this document to denote a JSON 821 string meeting the preceding requirement. 823 An entity domain type defines the semantics of a type of entity, 824 indenpendently of any specifying resource. Each entity domain type 825 MUST be registered with the IANA. The format of the entity 826 identifiers (see Section 5.1.3) in that type of entity domains, as 827 well as any hierarchical or inheritance rules (see Section 5.1.4) for 828 those entities, MUST be specified at the same time. 830 5.1.2. Entity Domain Name 832 This document distinguishes three categories of entity domains: 833 resource-specific entity domains, resource-agnostic entity domains 834 and self-defined entity domains. Their entity domain names are 835 constructed as specified in the following sub-sections. 837 Each entity domain is identified by a unique entity domain name which 838 is a string of the following format: 840 EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType 842 Where the presence and construction of component: 844 "[ [ ResourceID ] '.' ]" 846 depends on the category of entity domain. 848 Note that the '.' separator is not allowed in EntityDomainType and 849 hence there is no ambiguity on whether an entity domain name refers 850 to a resource-agnostic entity domain or a resource-specific entity 851 domain. 853 Note also that the resource ID format definition in Section 10.1 of 854 [RFC7285] specifies that: "the '.' separator is reserved for future 855 use and MUST NOT be used unless specifically indicated in this 856 document, or an extension document". The present extension keeps the 857 format specification of [RFC7285], hence the '.' separator MUST NOT 858 be used in an information resources ID. 860 5.1.2.1. Resource-specific Entity Domain 862 A resource-specific entity domain is identified by an entity domain 863 name constructed as follows. It MUST start with a resource ID using 864 the ResourceID type defined in Section 10.2 of [RFC7285], followed by 865 the '.' separator (U+002E), followed by an string of the type 866 EntityDomainType specified in Section 5.1.1. 868 For example, if an ALTO server provides two network maps "netmap-1" 869 and "netmap-2", these network maps can define two resource-specific 870 domains of type "pid", respectively identified by "netmap-1.pid" and 871 "netmap-2.pid". 873 5.1.2.2. Resource-agnostic Entity Domain 875 A resource-agnostic entity domain contains entities that are 876 identified independently of any information resource. Hence, the 877 identifier of a resource-agnostic entity domain is simply the 878 identifier of its entity domain type. For example, "ipv4" and "ipv6" 879 identify the two resource-agnostic Internet address entity domains 880 defined in Section 6.1. 882 5.1.2.3. Self-defined Entity Domain 884 A property map can define properties on entities that are neither 885 resource-specific nor resource-agnostic but are instead defined 886 within the property map itself. This may be the case when an ALTO 887 Server provides information on a set of entities that is specific to 888 this property map would not be relevant for another one and that does 889 not depend on a specific resource. 891 For example: a specialised property map may define a domain of type 892 "ane", defined in [I-D.ietf-alto-path-vector], that contains a set of 893 ANEs with a persistent identifier that are relevant only for this 894 property map. 896 In this case, the entity domain is qualified as "self-defined". The 897 identifier of a self-defined entity domain can be of the format: 899 EntityDomainName ::= .EntityDomainType 901 where '.' indicates that the entity domain only exists within the 902 property map resource using it. 904 A self-defined entity domain can be viewed as a particular case of 905 resource-specific entity domain, where the specific resource is the 906 current resource that uses this entity domain. In that case, for the 907 sake of simplification, the component "ResourceID" SHOULD be omitted 908 in its entity domain name. 910 5.1.3. Entity Identifier 912 Entities in an entity domain are identified by entity identifiers 913 (EntityID) of the following format: 915 EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID 917 Examples from the Internet address entity domains include individual 918 IP addresses such as "net1.ipv4:192.0.2.14" and 919 "net1.ipv6:2001:db8::12", as well as address blocks such as 920 "net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::1/48". 922 The format of the second part of an entity identifier depends on the 923 entity domain type, and MUST be specified when defining a new entity 924 domain type and registering it with the IANA. Identifiers MAY be 925 hierarchical, and properties MAY be inherited based on that 926 hierarchy. The rules defining any hierarchy or inheritance MUST be 927 defined when the entity domain type is registered. 929 The type EntityID is used in this document to denote a JSON string 930 representing an entity identifier in this format. 932 Note that two entity identifiers with different valid textual 933 representations may refer to the same entity, for a given entity 934 domain. For example, the strings "net1.ipv6:2001:db8::1" and 935 "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the 936 "ipv6" entity domain. 938 5.1.4. Hierarchy and Inheritance 940 To simplify the representation, some types of entity domains allow 941 the ALTO Client and Server to use a hierarchical entity identifier 942 format to represent a block of individual entities. For instance, in 943 an IPv4 domain "net1.ipv4", a CIDR "net1.ipv4:192.0.2.0/26" covers 64 944 individual IPv4 entities. In this case, the corresponding property 945 inheritance rule MUST be defined for the entity domain type. The 946 hierarchy and inheritance rule MUST have no ambiguity. 948 5.2. Entity Property 950 Each entity property has a type to indicate the encoding and the 951 semantics of the value of this entity property, and has a name to 952 identify it. 954 5.2.1. Entity Property Type 956 The type EntityPropertyType is used in this document to indicate a 957 string denoting an entity property type. The string MUST be no more 958 than 32 characters, and it MUST NOT contain characters other than US- 959 ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 960 U+0061-U+007A), the hyphen ("-", U+002D), the colon (":", U+003A), or 961 the low line ('_', U+005F). Note that the ?.? separator is not 962 allowed because it is reserved to separate an entity property type 963 and an information resource identifier when an entity property is 964 resource-specific. 966 Each entity property type MUST be registered with the IANA. The 967 intended semantics of the entity property type MUST be specified at 968 the same time. 970 Identifiers prefixed with "priv:" are reserved for Private Use 971 [RFC5226] without a need to register with IANA. All other 972 identifiers for entity property types appearing in an HTTP request or 973 response with an "application/alto-*" media type MUST be registered 974 in the "ALTO Entity Property Type Registry", defined in Section 12.3. 975 For an entity property identifier with the "priv:" prefix, an 976 additional string (e.g., company identifier or random string) MUST 977 follow (i.e., "priv:" only is not a valid endpoint property 978 identifier) to reduce potential collisions. 980 To distinguish with the endpoint property type, the entity property 981 type has the following features. 983 o Some entity property types may be applicable to entities in only 984 particular types of entity domains, not all. For example, the 985 "pid" property is not applicable to entities in a "pid" typed 986 entity domain, but is applicable to entities in the "ipv4" or 987 "ipv6" domains. 989 o The intended semantics of the value of an entity property may also 990 depend on the entity domain type of this entity. For example, 991 suppose that the "geo-location" property is defined as the 992 coordinates of a point, encoded as (say) "latitude longitude 993 [altitude]." When applied to an entity that represents a specific 994 host computer, identified by an address in the "ipv4" or "ipv6" 995 entity domain, the property defines the host's location. However, 996 when applied to an entity in a "pid" domain, the property would 997 indicate the location of the center of all hosts in this "pid" 998 entity. 1000 5.2.2. Entity Property Name 1002 Each entity property is identified by an entity property name, which 1003 is a string of the following format: 1005 EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType 1007 Similar to the endpoint property type defined in Section 10.8 of 1008 [RFC7285], each entity property may be defined by either the property 1009 map itself (self-defined) or some other specific information resource 1010 (resource-specific). 1012 The entity property name of a resource-specific entity property 1013 starts with a string of the type ResourceID defined in [RFC7285], 1014 followed by the "." separator (U+002E) and a EntityDomainType typed 1015 string. For example, the "pid" properties of an "ipv4" entity 1016 defined by two different maps "net-map-1" and "net-map-2" are 1017 identified by "net-map-1.pid" and "net-map-2.pid" respectively. 1019 When the associated information resource of the entity property is 1020 the current information resource itself, the ResourceID in the 1021 property name SHOULD be ignored. For example, the ".asn" property of 1022 an "ipv4" entity indicates the AS number of the AS which this IPv4 1023 address is owned by. 1025 5.2.3. Format for Entity Property Value 1027 [RFC7285] in Section 11.4.1.6, specifies that an implementation of 1028 the Endpoint Property Service specified in [RFC7285] SHOULD assume 1029 that the property value is a JSONString and fail to parse if it is 1030 not. The present document first, extends the property service to 1031 Entities. Second it extends the format of a property value by 1032 allowing it to be a JSONValue instead of just a JSONString. 1034 6. Entity Domain Types Defined in this Document 1036 This document requires the definition of each entity domain type MUST 1037 include (1) the entity domain type name and (2) domain-specific 1038 entity identifiers, and MAY include (3) hierarchy and inheritance 1039 semantics optionally. This document defines three initial entity 1040 domain types as follows. 1042 6.1. Internet Address Domain Types 1044 The document defines two entity domain types (IPv4 and IPv6) for 1045 Internet addresses. Both types are resource-agnostic entity domain 1046 types and hence define corresponding resource-agnostic entity domains 1047 as well. Since the two domains use the same hierarchy and 1048 inheritance semantics, we define the semantics together, instead of 1049 repeating for each. 1051 6.1.1. IPv4 Domain 1053 6.1.1.1. Entity Domain Type 1055 ipv4 1057 6.1.1.2. Domain-Specific Entity Identifiers 1059 Individual addresses are strings as specified by the IPv4Addresses 1060 rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are 1061 prefix-match strings as specified in Section 3.1 of [RFC4632]. To 1062 define properties, an individual Internet address and the 1063 corresponding full-length prefix are considered aliases for the same 1064 entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 1065 equivalent. 1067 6.1.2. IPv6 Domain 1069 6.1.2.1. Entity Domain Type 1071 ipv6 1073 6.1.2.2. Domain-Specific Entity Identifiers 1075 Individual addresses are strings as specified by Section 4 of 1076 [RFC5952]; Hierarchical addresses are prefix-match strings as 1077 specified in Section 7 of [RFC5952]. To define properties, an 1078 individual Internet address and the corresponding 128-bit prefix are 1079 considered aliases for the same entity. That is, "ipv6:2001:db8::1" 1080 and "ipv6:2001:db8::1/128" are equivalent, and have the same set of 1081 properties. 1083 6.1.3. Hierarchy and Inheritance of Internet Address Domains 1085 Both Internet address domains allow property values to be inherited. 1086 Specifically, if a property P is not defined for a specific Internet 1087 address I, but P is defined for a a hierarchical Internet address C 1088 which prefix-matches I, then the address I inherits the value of P 1089 defined for the hierarchical address C. If more than one such 1090 hierarchical addresses define a value for P, I inherits the value of 1091 P in the hierarchical address with the longest prefix. Note that 1092 this longest prefix rule ensures no multiple inheritances, and hence 1093 no ambiguity. 1095 Hierarchical addresses can also inherit properties: if a property P 1096 is not defined for the hierarchical address C, but is defined for 1097 another hierarchical address C' which covers all IP addresses in C, 1098 and C' has a shorter prefix length than C, then C MAY inherits the 1099 property from C'. If there are multiple such hierarchical addresses 1100 like C', C MUST inherit from the hierarchical address having the 1101 longest prefix length. 1103 As an example, suppose that a server defines a property P for the 1104 following entities: 1106 ipv4:192.0.2.0/26: P=v1 1107 ipv4:192.0.2.0/28: P=v2 1108 ipv4:192.0.2.0/30: P=v3 1109 ipv4:192.0.2.0: P=v4 1111 Figure 1: Defined Property Values. 1113 Then the following entities have the indicated values: 1115 ipv4:192.0.2.0: P=v4 1116 ipv4:192.0.2.1: P=v3 1117 ipv4:192.0.2.16: P=v1 1118 ipv4:192.0.2.32: P=v1 1119 ipv4:192.0.2.64: (not defined) 1120 ipv4:192.0.2.0/32: P=v4 1121 ipv4:192.0.2.0/31: P=v3 1122 ipv4:192.0.2.0/29: P=v2 1123 ipv4:192.0.2.0/27: P=v1 1124 ipv4:192.0.2.0/25: (not defined) 1126 Figure 2: Inherited Property Values. 1128 An ALTO server MAY explicitly indicate a property as not having a 1129 value for a particular entity. That is, a server MAY say that 1130 property P of entity X is "defined to have no value", instead of 1131 "undefined". To indicate "no value", a server MAY perform different 1132 behaviours: 1134 o If that entity would inherit a value for that property, then the 1135 ALTO server MUST return a "null" value for that property. In this 1136 case, the ALTO client MUST recognize a "null" value as "no value" 1137 and "do not apply the inheritance rules for this property." 1139 o If the entity would not inherit a value, then the ALTO server MAY 1140 return "null" or just omit the property. In this case, the ALTO 1141 client cannot infer the value for this property of this entity 1142 from the Inheritance rules. So the client MUST interpret that 1143 this property has no value. 1145 If the ALTO server does not define any properties for an entity, then 1146 the server MAY omit that entity from the response. 1148 6.1.4. Defining Information Resource Media Type for domain types IPv4 1149 and IPv6 1151 Entity domain types "ipv4" and "ipv6" both allow to define resource 1152 specific entity domains. When resource specific domains are defined 1153 with entities of domain type "ipv4" or "ipv6", the defining 1154 information resource for an entity domain of type "ipv4" or "ipv6" 1155 MUST be a Network Map. The media type of a defining information 1156 resource is therefore: 1158 application/alto-networkmap+json 1160 6.2. PID Domain 1162 The PID domain associates property values with the PIDs in a network 1163 map. Accordingly, this entity domain always depends on a network 1164 map. 1166 6.2.1. Entity Domain Type 1168 pid 1170 6.2.2. Domain-Specific Entity Identifiers 1172 The entity identifiers are the PID names of the associated network 1173 map. 1175 6.2.3. Hierarchy and Inheritance 1177 There is no hierarchy or inheritance for properties associated with 1178 PIDs. 1180 6.2.4. Defining Information Resource Media Type for Domain Type PID 1182 The entity domain type "pid" allows to define resource specific 1183 entity domains. When resource specific domains are defined with 1184 entities of domain type "pid", the defining information resource for 1185 entity domain type "pid" MUST be a Network Map. The media type of a 1186 defining information resource is therefore: 1188 application/alto-networkmap+json 1190 6.2.5. Relationship To Internet Addresses Domains 1192 The PID domain and the Internet address domains are completely 1193 independent; the properties associated with a PID have no relation to 1194 the properties associated with the prefixes or endpoint addresses in 1195 that PID. An ALTO server MAY choose to assign some or all properties 1196 of a PID to the prefixes in that PID. 1198 For example, suppose "PID1" consists of the prefix 1199 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 1200 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in 1201 the IPv4 domain MAY have a value for the property "P", and if they 1202 do, it is not necessarily "v1". 1204 6.3. Internet Address Properties vs. PID Properties 1206 Because the Internet address and PID domains are completely separate, 1207 the question may arise as to which entity domain is the best for a 1208 property. In general, the Internet address domains are RECOMMENDED 1209 for properties that are closely related to the Internet address, or 1210 are associated with, and inherited through, hierarchical addresses. 1212 The PID domain is RECOMMENDED for properties that arise from the 1213 definition of the PID, rather than from the Internet address prefixes 1214 in that PID. 1216 For example, because Internet addresses are allocated to service 1217 providers by blocks of prefixes, an "ISP" property would be best 1218 associated with the Internet address domain. On the other hand, a 1219 property that explains why a PID was formed, or how it relates to a 1220 provider's network, would best be associated with the PID domain. 1222 7. Property Map 1224 A property map returns the properties defined for all entities in one 1225 or more domains, e.g., the "location" property of entities in "pid" 1226 domain, and the "ASN" property of entities in "ipv4" and "ipv6" 1227 domains. 1229 Section 10.5 gives an example of a property map request and its 1230 response. 1232 7.1. Media Type 1234 The media type of a property map is "application/alto-propmap+json". 1236 7.2. HTTP Method 1238 The property map is requested using the HTTP GET method. 1240 7.3. Accept Input Parameters 1242 None. 1244 7.4. Capabilities 1246 The capabilities are defined by an object of type 1247 PropertyMapCapabilities: 1249 object { 1250 EntityPropertyMapping mappings; 1251 } PropertyMapCapabilities; 1253 object-map { 1254 EntityDomainName -> EntityPropertyName<1..*>; 1255 } EntityPropertyMapping 1257 with fields: 1259 mappings: A JSON object whose keys are names of entity domains and 1260 values are the supported entity properties of the corresponding 1261 entity domains. 1263 7.5. Uses 1265 The "uses" field of a property map resource in an IRD entry specifies 1266 dependent resources of this property map. It is an array of the 1267 resource ID(s) of the resource(s). 1269 7.6. Response 1271 If the entity domains in this property map depend on other resources, 1272 the "dependent-vtags" field in the "meta" field of the response MUST 1273 be an array that includes the version tags of those resources, and 1274 the order MUST be consistent with the "uses" field of this property 1275 map resource. The data component of a property map response is named 1276 "property-map", which is a JSON object of type PropertyMapData, 1277 where: 1279 object { 1280 PropertyMapData property-map; 1281 } InfoResourceProperties : ResponseEntityBase; 1283 object-map { 1284 EntityID -> EntityProps; 1285 } PropertyMapData; 1287 object { 1288 EntityPropertyName -> JSONValue; 1289 } EntityProps; 1291 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 1293 Specifically, a PropertyMapData object has one member for each entity 1294 in the property map. The entity's properties are encoded in the 1295 corresponding EntityProps object. EntityProps encodes one name/value 1296 pair for each property, where the property names are encoded as 1297 strings of type PropertyName. A protocol implementation SHOULD 1298 assume that the property value is either a JSONString or a JSON 1299 "null" value, and fail to parse if it is not, unless the 1300 implementation is using an extension to this document that indicates 1301 when and how property values of other data types are signaled. 1303 For each entity in the property map: 1305 o If the entity is in a resource-specific entity domain, the ALTO 1306 server SHOULD only return self-defined properties and resource- 1307 specific properties which depend on the same resource as the 1308 entity does. The ALTO client SHOULD ignore the resource-specific 1309 property in this entity if their mapping is not registered in the 1310 ALTO Resource Entity Property Transfer Registry of the type of the 1311 corresponding resource. 1313 o If the entity is in a shared entity domain, the ALTO server SHOULD 1314 return self-defined properties and all resource-specific 1315 properties defined for all resource-specific entities which have 1316 the same domain-specific entity identifier as this entity does. 1318 For efficiency, the ALTO server SHOULD omit property values that are 1319 inherited rather than explicitly defined; if a client needs inherited 1320 values, the client SHOULD use the entity domain's inheritance rules 1321 to deduce those values. 1323 8. Filtered Property Map 1325 A filtered property map returns the values of a set of properties for 1326 a set of entities selected by the client. 1328 Section 10.6, Section 10.7, Section 10.8 and Section 10.9 give 1329 examples of filtered property map requests and responses. 1331 8.1. Media Type 1333 The media type of a property map resource is "application/alto- 1334 propmap+json". 1336 8.2. HTTP Method 1338 The filtered property map is requested using the HTTP POST method. 1340 8.3. Accept Input Parameters 1342 The input parameters for a filtered property map request are supplied 1343 in the entity body of the POST request. This document specifies the 1344 input parameters with a data format indicated by the media type 1345 "application/alto-propmapparams+json", which is a JSON object of type 1346 ReqFilteredPropertyMap: 1348 object { 1349 EntityID entities<1..*>; 1350 EntityPropertyName properties<1..*>; 1351 } ReqFilteredPropertyMap; 1353 with fields: 1355 entities: List of entity identifiers for which the specified 1356 properties are to be returned. The ALTO server MUST interpret 1357 entries appearing multiple times as if they appeared only once. 1358 The domain of each entity MUST be included in the list of entity 1359 domains in this resource's "capabilities" field (see Section 8.4). 1361 properties: List of properties to be returned for each entity. Each 1362 specified property MUST be included in the list of properties in 1363 this resource's "capabilities" field (see Section 8.4). The ALTO 1364 server MUST interpret entries appearing multiple times as if they 1365 appeared only once. 1367 Note that the "entities" and "properties" fields MUST have at 1368 least one entry each. 1370 8.4. Capabilities 1372 The capabilities are defined by an object of type 1373 PropertyMapCapabilities, as defined in Section 7.4. 1375 8.5. Uses 1377 Same to the "uses" field of the Property Map resource (see 1378 Section 7.5). 1380 8.6. Response 1382 The response MUST indicate an error, using ALTO protocol error 1383 handling, as defined in Section 8.5 of [RFC7285], if the request is 1384 invalid. 1386 Specifically, a filtered property map request can be invalid as 1387 follows: 1389 o An entity identifier in "entities" in the request is invalid if: 1391 * The domain of this entity is not defined in the "entity- 1392 domains" capability of this resource in the IRD; 1394 * The entity identifier is an invalid identifier in the entity 1395 domain. 1397 A valid entity identifier is never an error, even if this filtered 1398 property map resource does not define any properties for it. 1400 If an entity identifier in "entities" in the request is invalid, 1401 the ALTO server MUST return an "E_INVALID_FIELD_VALUE" error 1402 defined in Section 8.5.2 of [RFC7285], and the "value" field of 1403 the error message SHOULD indicate this entity identifier. 1405 o A property name in "properties" in the request is invalid if this 1406 property name is not defined in the "properties" capability of 1407 this resource in the IRD. 1409 It is not an error that a filtered property map resource does not 1410 define a requested property's value for a particular entity. In 1411 this case, the ALTO server MUST omit that property from the 1412 response for that endpoint. 1414 If a property name in "properties" in the request is invalid, the 1415 ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined 1416 in Section 8.5.2 of [RFC7285]. The "value" field of the error 1417 message SHOULD indicate the property name. 1419 The response to a valid request is the same as for the Property Map 1420 (see Section 7.6), except that: 1422 o If the requested entities include entities in the shared entity 1423 domain, the "dependent-vtags" field in its "meta" field MUST 1424 include version tags of all dependent resources appearing in the 1425 "uses" field. 1427 o If the requested entities only include entities in resource- 1428 specific entity domains, the "dependent-vtags" field in its "meta" 1429 field MUST include version tags of resources which requested 1430 resource-specific entity domains and requested resource-specific 1431 properties are dependent on. 1433 o The response only includes the entities and properties requested 1434 by the client. If an entity in the request is identified by a 1435 hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the 1436 response MUST cover properties for all identifiers in this 1437 hierarchical identifier. 1439 It is important that the filtered property map response MUST include 1440 all inherited property values for the requested entities and all the 1441 entities which are able to inherit property values from them. To 1442 achieve this goal, the ALTO server MAY follow three rules: 1444 o If a property for a requested entity is inherited from another 1445 entity not included in the request, the response SHOULD include 1446 this property for the requested entity. For example, A full 1447 property map may skip a property P for an entity A (e.g., 1448 ipv4:192.0.2.0/31) if P can be derived using inheritance from 1449 another entity B (e.g., ipv4:192.0.2.0/30). A filtered property 1450 map request may include only A but not B. In such a case, the 1451 property P SHOULD be included in the response for A. 1453 o If there are entities covered by a requested entity but having 1454 different values for the requested properties, the response SHOULD 1455 include all those entities and the different property values for 1456 them. For example, considering a request for property P of entity 1457 A (e.g., ipv4:192.0.2.0/31), if P has value v1 for 1458 A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the 1459 response SHOULD include A1 and A2. 1461 o If an entity in the response is already covered by some other 1462 entities in the same response, it SHOULD be removed from the 1463 response for compactness. For example, in the previous example, 1464 the entity A=ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2 1465 cover all the addresses in A. 1467 An ALTO client should be aware that the entities in the response MAY 1468 be different from the entities in its request. 1470 8.7. Entity property type defined in this document 1472 This document defines the entity property type "pid" 1474 The intended semantics are the same as in [RFC7285] 1476 The defining information resource for property type MUST be a network 1477 map. 1479 The media type of a defining information resource is therefore: 1481 application/alto-networkmap+json 1483 This document requests a IANA registration for this property 1485 9. Impact on Legacy ALTO Servers and ALTO Clients 1487 9.1. Impact on Endpoint Property Service 1489 Since the property map and the filtered property map defined in this 1490 document provide the functionality of the Endpoint Property Service 1491 (EPS) defined in Section 11.4 of [RFC7285], it is RECOMMENDED that 1492 the EPS be deprecated in favor of Property Map and Filtered Property 1493 Map. However, ALTO servers MAY provide an EPS for the benefit of 1494 legacy clients. 1496 9.2. Impact on Resource-Specific Properties 1498 Section 10.8 of [RFC7285] defines two categories of endpoint 1499 properties: "resource-specific" and "global". Resource-specific 1500 property names are prefixed with the ID of the resource they depend 1501 upon, while global property names have no such prefix. The property 1502 map and the filtered property map defined in this document defines 1503 the similar categories for entity properties. The difference is that 1504 there is no "global" entity properties but the "self-defined" entity 1505 properties as the special case of the "resource-specific" entity 1506 properties instead. 1508 9.3. Impact on Other Properties 1510 In general, there should be little or no impact on other previously 1511 defined properties. The only consideration is that properties can 1512 now be defined on hierarchical entity identifiers, rather than just 1513 individual entity identifiers, which might change the semantics of a 1514 property. 1516 10. Examples 1518 10.1. Network Map 1520 The examples in this section use a very simple default network map: 1522 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1523 pid1: ipv4:192.0.2.0/25 1524 pid2: ipv4:192.0.2.0/27 1525 pid3: ipv4:192.0.3.0/28 1526 pid4: ipv4:192.0.3.16/28 1528 Figure 3: Example Default Network Map 1530 And another simple alternative network map: 1532 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1533 pid1: ipv4:192.0.2.0/27 1534 pid2: ipv4:192.0.3.0/27 1536 Figure 4: Example Alternative Network Map 1538 10.2. Property Definitions 1540 Beyond "pid", the examples in this section use four additional 1541 properties for Internet address domains, "ISP", "ASN", "country" and 1542 "state", with the following values: 1544 ISP ASN country state 1545 ipv4:192.0.2.0/23: BitsRus - us - 1546 ipv4:192.0.2.0/28: - 12345 - NJ 1547 ipv4:192.0.2.16/28: - 12345 - CT 1548 ipv4:192.0.2.1: - - - PA 1549 ipv4:192.0.3.0/28: - 12346 - TX 1550 ipv4:192.0.3.16/28: - 12346 - MN 1552 Figure 5: Example Property Values for Internet Address Domains 1554 And the examples in this section use the property "region" for the 1555 PID domain of the default network map with the following values: 1557 region 1558 pid:defaultpid: - 1559 pid:pid1: us-west 1560 pid:pid2: us-east 1561 pid:pid3: us-south 1562 pid:pid4: us-north 1564 Figure 6: Example Property Values for Default Network Map's PID 1565 Domain 1567 Note that "-" means the value of the property for the entity is 1568 "undefined". So the entity would inherit a value for this property 1569 by the inheritance rule if possible. For example, the value of the 1570 "ISP" property for "ipv4:192.0.2.1" is "BitsRus" because of 1571 "ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid" 1572 has no value because no entity from which it can inherit. 1574 Similar to the PID domain of the default network map, the examples in 1575 this section use the property "ASN" for the PID domain of the 1576 alternative network map with the following values: 1578 ASN 1579 pid:defaultpid: - 1580 pid:pid1: 12345 1581 pid:pid2: 12346 1583 Figure 7: Example Property Values for Alternative Network Map's PID 1584 Domain 1586 10.3. Properties for Abstract Network Elements 1588 Additionally, the examples in this section consider a facilitated 1589 entity domain: "ane" (Abstract Network Element). Abstract network 1590 elements allow ALTO clients to discover information beyond the end- 1591 to-end routing costs. Examples of abstract network elements include: 1593 Forwarding elements: Forwarding elements include optical wires, 1594 physical layer links, IP tunnels, etc. Forwarding elements share 1595 the common property "maxresbw". 1597 Value-added services: Value-added services include HTTP caches, 5G 1598 UPF nodes, mobile edge computing, etc. Value-added services share 1599 the common property "persistent-entities", which contains 1600 information that points to the entry point of the service. 1601 Different value-added services may have specific properties, e.g., 1602 an abstract network element of a mobile edge may provide a list of 1603 flavors to the client. 1605 maxresbw persistent-entities mec-flavors 1606 ane:L001 100 Mbps 1607 ane:L002 100 Mbps 1608 ane:CACHE1 http-proxy:192.0.2.1 1609 ane:MEC01 mec:192.0.2.1 {gpu:2G, ssd:128G} 1610 ane:MEC02 mec:192.0.2.2 {gpu:1G, ssd:128G} 1612 The "ane" entities are usually not used alone, but associated with 1613 other ALTO resources, e.g., cost maps. It means that the ALTO server 1614 may not define a property map resource to provide properties of "ane" 1615 entities. The property map payload for "ane" entities may be 1616 provided in the response of other ALTO resources in some way. 1618 10.4. Information Resource Directory (IRD) 1620 The following IRD defines the relevant resources of the ALTO server. 1621 It provides two property maps, one for the "ISP" and "ASN" 1622 properties, and another for the "country" and "state" properties. 1623 The server could have provided a single property map for all four 1624 properties, but did not, presumably because the organization that 1625 runs the ALTO server believes any given client is not interested in 1626 all four properties. 1628 The server provides two filtered property maps. The first returns 1629 all four properties, and the second just returns the "pid" property 1630 for the default network map. 1632 The filtered property maps for the "ISP", "ASN", "country" and 1633 "state" properties do not depend on the default network map (it does 1634 not have a "uses" capability), because the definitions of those 1635 properties do not depend on the default network map. The Filtered 1636 Property Map for the "pid" property does have a "uses" capability for 1637 the default network map, because that defines the values of the "pid" 1638 property. 1640 Note that for legacy clients, the ALTO server provides an Endpoint 1641 Property Service for the "pid" property for the default network map. 1643 The server also provides a facilitated ALTO resource which accepts 1644 the filtered cost map request but returns a multipart message 1645 including a cost map and an associated property map for "ane" 1646 entities. 1648 "meta" : { 1649 ... 1650 "default-alto-network-map" : "default-network-map" 1651 }, 1652 "resources" : { 1653 "default-network-map" : { 1654 "uri" : "http://alto.example.com/networkmap/default", 1655 "media-type" : "application/alto-networkmap+json" 1656 }, 1657 "alt-network-map" : { 1658 "uri" : "http://alto.example.com/networkmap/alt", 1659 "media-type" : "application/alto-networkmap+json" 1660 }, 1661 .... property map resources .... 1662 "ia-property-map" : { 1663 "uri" : "http://alto.example.com/propmap/full/inet-ia", 1664 "media-type" : "application/alto-propmap+json", 1665 "uses": [ "default-network-map", "alt-network-map" ], 1666 "capabilities" : { 1667 "mappings": { 1668 "ipv4": [ ".ISP", ".ASN" ], 1669 "ipv6": [ ".ISP", ".ASN" ] 1670 } 1671 } 1672 }, 1673 "iacs-property-map" : { 1674 "uri" : "http://alto.example.com/propmap/lookup/inet-iacs", 1675 "media-type" : "application/alto-propmap+json", 1676 "accepts": "application/alto-propmapparams+json", 1677 "uses": [ "default-network-map", "alt-network-map" ], 1678 "capabilities" : { 1679 "mappings": { 1680 "ipv4": [ ".ISP", ".ASN", ".country", ".state" ], 1681 "ipv6": [ ".ISP", ".ASN", ".country", ".state" ] 1682 } 1683 } 1684 }, 1685 "region-property-map": { 1686 "uri": "http://alto.example.com/propmap/lookup/region", 1687 "media-type": "application/alto-propmap+json", 1688 "accepts": "application/alto-propmapparams+json", 1689 "uses" : [ "default-network-map", "alt-network-map" ], 1690 "capabilities": { 1691 "mappings": { 1692 "default-network-map.pid": [ ".region" ], 1693 "alt-network-map.pid": [ ".ASN" ], 1694 } 1695 } 1696 }, 1697 "ip-pid-property-map" : { 1698 "uri" : "http://alto.example.com/propmap/lookup/pid", 1699 "media-type" : "application/alto-propmap+json", 1700 "accepts" : "application/alto-propmapparams+json", 1701 "uses" : [ "default-network-map", "alt-network-map" ], 1702 "capabilities" : { 1703 "mappings": { 1704 "ipv4": [ "default-network-map.pid", 1705 "alt-network-map.pid" ], 1706 "ipv6": [ "default-network-map.pid", 1707 "alt-network-map.pid" ] 1708 } 1709 } 1710 }, 1711 "legacy-endpoint-property" : { 1712 "uri" : "http://alto.example.com/legacy/eps-pid", 1713 "media-type" : "application/alto-endpointprop+json", 1714 "accepts" : "application/alto-endpointpropparams+json", 1715 "capabilities" : { 1716 "properties" : [ "default-network-map.pid", 1717 "alt-network-map.pid" ] 1718 } 1719 }, 1720 "ane-dc-property-map": { 1721 "uri" : "http://alto.example.com/propmap/lookup/ane-dc", 1722 "media-type" : "application/alto-propmap+json", 1723 "accepts": "application/alto-propmapparams+json", 1724 "capabilities": { 1725 "mappings": { 1726 ".ane" : [ "storage-capacity", "ram", "cpu" ] 1727 } 1728 }, 1729 } 1730 } 1732 Figure 8: Example IRD 1734 10.5. Full Property Map Example 1736 The following example uses the properties and IRD defined above in 1737 Section 10.4 to retrieve a Property Map for entities with the "ISP" 1738 and "ASN" properties. 1740 Note that, to be compact, the response does not include the entity 1741 "ipv4:192.0.2.0", because values of all those properties for this 1742 entity are inherited from other entities. 1744 Also note that the entities "ipv4:192.0.2.0/28" and 1745 "ipv4:192.0.2.16/28" are merged into "ipv4:192.0.2.0/27", because 1746 they have the same value of the "ASN" property. The same rule 1747 applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". 1748 Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value 1749 for the "ISP" property, because it is inherited from 1750 "ipv4:192.0.2.0/23". 1752 GET /propmap/full/inet-ia HTTP/1.1 1753 Host: alto.example.com 1754 Accept: application/alto-propmap+json,application/alto-error+json 1756 HTTP/1.1 200 OK 1757 Content-Length: ### 1758 Content-Type: application/alto-propmap+json 1760 { 1761 "meta": { 1762 "dependent-vtags": [ 1763 {"resource-id": "default-network-map", 1764 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1765 {"resource-id": "alt-network-map", 1766 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1767 ] 1768 }, 1769 "property-map": { 1770 "ipv4:192.0.2.0/23": {".ISP": "BitsRus"}, 1771 "ipv4:192.0.2.0/27": {".ASN": "12345"}, 1772 "ipv4:192.0.3.0/27": {".ASN": "12346"} 1773 } 1774 } 1776 10.6. Filtered Property Map Example #1 1778 The following example uses the filtered property map resource to 1779 request the "ISP", "ASN" and "state" properties for several IPv4 1780 addresses. 1782 Note that the value of "state" for "ipv4:192.0.2.0" is the only 1783 explicitly defined property; the other values are all derived by the 1784 inheritance rules for Internet address entities. 1786 POST /propmap/lookup/inet-iacs HTTP/1.1 1787 Host: alto.example.com 1788 Accept: application/alto-propmap+json,application/alto-error+json 1789 Content-Length: ### 1790 Content-Type: application/alto-propmapparams+json 1792 { 1793 "entities" : [ "ipv4:192.0.2.0", 1794 "ipv4:192.0.2.1", 1795 "ipv4:192.0.2.17" ], 1796 "properties" : [ ".ISP", ".ASN", ".state" ] 1797 } 1799 HTTP/1.1 200 OK 1800 Content-Length: ### 1801 Content-Type: application/alto-propmap+json 1803 { 1804 "meta": { 1805 "dependent-vtags": [ 1806 {"resource-id": "default-network-map", 1807 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1808 {"resource-id": "alt-network-map", 1809 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1810 ] 1811 }, 1812 "property-map": { 1813 "ipv4:192.0.2.0": 1814 {".ISP": "BitsRus", ".ASN": "12345", ".state": "PA"}, 1815 "ipv4:192.0.2.1": 1816 {".ISP": "BitsRus", ".ASN": "12345", ".state": "NJ"}, 1817 "ipv4:192.0.2.17": 1818 {".ISP": "BitsRus", ".ASN": "12345", ".state": "CT"} 1819 } 1820 } 1822 10.7. Filtered Property Map Example #2 1824 The following example uses the filtered property map resource to 1825 request the "ASN", "country" and "state" properties for several IPv4 1826 prefixes. 1828 Note that the property values for both entities "ipv4:192.0.2.0/26" 1829 and "ipv4:192.0.3.0/26" are not explicitly defined. They are 1830 inherited from the entity "ipv4:192.0.2.0/23". 1832 Also note that some entities like "ipv4:192.0.2.0/28" and 1833 "ipv4:192.0.2.16/28" in the response are not listed in the request 1834 explicitly. The response includes them because they are refinements 1835 of the requested entities and have different values for the requested 1836 properties. 1838 The entity "ipv4:192.0.4.0/26" is not included in the response, 1839 because there are neither entities which it is inherited from, nor 1840 entities inherited from it. 1842 POST /propmap/lookup/inet-iacs HTTP/1.1 1843 Host: alto.example.com 1844 Accept: application/alto-propmap+json,application/alto-error+json 1845 Content-Length: ### 1846 Content-Type: application/alto-propmapparams+json 1848 { 1849 "entities" : [ "ipv4:192.0.2.0/26", 1850 "ipv4:192.0.3.0/26", 1851 "ipv4:192.0.4.0/26" ], 1852 "properties" : [ ".ASN", ".country", ".state" ] 1853 } 1855 HTTP/1.1 200 OK 1856 Content-Length: ### 1857 Content-Type: application/alto-propmap+json 1859 { 1860 "meta": { 1861 "dependent-vtags": [ 1862 {"resource-id": "default-network-map", 1863 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1864 {"resource-id": "alt-network-map", 1865 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1866 ] 1867 }, 1868 "property-map": { 1869 "ipv4:192.0.2.0/26": {".country": "us"}, 1870 "ipv4:192.0.2.0/28": {".ASN": "12345", 1871 ".state": "NJ"}, 1872 "ipv4:192.0.2.16/28": {".ASN": "12345", 1873 ".state": "CT"}, 1874 "ipv4:192.0.2.0": {".state": "PA"}, 1875 "ipv4:192.0.3.0/26": {".country": "us"}, 1876 "ipv4:192.0.3.0/28": {".ASN": "12345", 1877 ".state": "TX"}, 1878 "ipv4:192.0.3.16/28": {".ASN": "12345", 1879 ".state": "MN"} 1880 } 1881 } 1883 10.8. Filtered Property Map Example #3 1885 The following example uses the filtered property map resource to 1886 request the "default-network-map.pid" property and the "alt-network- 1887 map.pid" property for a set of IPv4 addresses and prefixes. 1889 Note that the entity "ipv4:192.0.3.0/27" is decomposed into two 1890 entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have 1891 different "default-network-map.pid" property values. 1893 POST /propmap/lookup/pid HTTP/1.1 1894 Host: alto.example.com 1895 Accept: application/alto-propmap+json,application/alto-error+json 1896 Content-Length: ### 1897 Content-Type: application/alto-propmapparams+json 1899 { 1900 "entities" : [ 1901 "ipv4:192.0.2.128", 1902 "ipv4:192.0.2.0/27", 1903 "ipv4:192.0.3.0/27" ], 1904 "properties" : [ "default-network-map.pid", 1905 "alt-network-map.pid ] 1906 } 1907 HTTP/1.1 200 OK 1908 Content-Length: ### 1909 Content-Type: application/alto-propmap+json 1911 { 1912 "meta": { 1913 "dependent-vtags": [ 1914 {"resource-id": "default-network-map", 1915 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1916 {"resource-id": "alt-network-map", 1917 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1918 ] 1919 }, 1920 "property-map": { 1921 "ipv4:192.0.2.128": {"default-network-map.pid": "defaultpid", 1922 "alt-network-map.pid": "defaultpid"}, 1923 "ipv4:192.0.2.0/27": {"default-network-map.pid": "pid2", 1924 "alt-network-map.pid": "pid1"}, 1925 "ipv4:192.0.3.0/28": {"default-network-map.pid": "pid3", 1926 "alt-network-map.pid": "pid2"}, 1927 "ipv4:192.0.3.16/28": {"default-network-map.pid": "pid4", 1928 "alt-network-map.pid": "pid2"} 1929 } 1930 } 1932 10.9. Filtered Property Map Example #4 1934 The following example uses the filtered property map resource to 1935 request the "region" property for several PIDs defined in "default- 1936 network-map". The value of the "region" property for each PID is not 1937 defined by "default-network-map", but the reason why the PID is 1938 defined by the network operator. 1940 POST /propmap/lookup/region HTTP/1.1 1941 Host: alto.example.com 1942 Accept: application/alto-propmap+json,application/alto-error+json 1943 Content-Length: ### 1944 Content-Type: application/alto-propmapparams+json 1946 { 1947 "entities" : ["default-network-map.pid:pid1", 1948 "default-network-map.pid:pid2"], 1949 "properties" : [ ".region" ] 1950 } 1951 HTTP/1.1 200 OK 1952 Content-Length: ### 1953 Content-Type: application/alto-propmap+json 1955 { 1956 "meta" : { 1957 "dependent-vtags" : [ 1958 {"resource-id": "default-network-map", 1959 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1960 ] 1961 }, 1962 "property-map": { 1963 "default-network-map.pid:pid1": { 1964 ".region": "us-west" 1965 }, 1966 "default-network-map.pid:pid2": { 1967 ".region": "us-east" 1968 } 1969 } 1970 } 1972 10.10. Filtered Property Map for ANEs Example #5 1974 The following example uses the filtered property map resource "ane- 1975 dc-property-map" to request properties "storage-capacity" and "cpu" 1976 on several ANEs defined in this property map. 1978 POST /propmap/lookup/ane-dc HTTP/1.1 1979 Host: alto.example.com 1980 Accept: application/alto-propmap+json,application/alto-error+json 1981 Content-Length: ### 1982 Content-Type: application/alto-propmapparams+json 1984 { 1985 "entities" : [".ane:dc21", ".ane:dc45.srv9", ".ane:dc6.srv-cluster8"] 1986 "properties" : [ "storage-capacity", "cpu"] 1987 } 1988 HTTP/1.1 200 OK 1989 Content-Length: ### 1990 Content-Type: application/alto-propmap+json 1992 { 1993 "meta" : { 1994 }, 1995 "property-map": { 1996 ".ane:dc21": 1997 {"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores}, 1998 ".ane:dc45.srv9": 1999 {"storage-capacity" : 100 Gbytes, "cpu" : 20 Cores}, 2000 ".ane:dc6.srv-cluster8": 2001 {"storage-capacity" : 6000 Gbytes, "cpu" : 100 Cores}, 2002 } 2003 } 2005 11. Security Considerations 2007 Both Property Map and Filtered Property Map defined in this document 2008 fit into the architecture of the ALTO base protocol, and hence the 2009 Security Considerations (Section 15 of [RFC7285]) of the base 2010 protocol fully apply: authenticity and integrity of ALTO information 2011 (i.e., authenticity and integrity of Property Maps), potential 2012 undesirable guidance from authenticated ALTO information (e.g., 2013 potentially imprecise or even wrong value of a property such as geo- 2014 location), confidentiality of ALTO information (e.g., exposure of a 2015 potentially sensitive entity property such as geo-location), privacy 2016 for ALTO users, and availability of ALTO services should all be 2017 considered. 2019 A particular fundamental security consideration when an ALTO server 2020 provides a Property Map is to define precisely the policies on who 2021 can access what properties for which entities. Security mechanisms 2022 such as authentication and confidentiality mechanisms then should be 2023 applied to enforce the policy. For example, a policy can be that a 2024 property P can be accessed only by its owner (e.g., the customer who 2025 is allocated a given IP address). Then, the ALTO server will need to 2026 deploy corresponding mechanisms to realize the policy. The policy 2027 may allow non-owners to access a coarse-grained value of the property 2028 P. In such a case, the ALTO server may provide a different URI to 2029 provide the information. 2031 12. IANA Considerations 2033 This document defines additional application/alto-* media types, and 2034 extends the ALTO endpoint property registry. 2036 12.1. application/alto-* Media Types 2038 This document registers two additional ALTO media types, listed in 2039 Table 1. 2041 +--------------+--------------------------+------------------------+ 2042 | Type | Subtype | Specification | 2043 +--------------+--------------------------+------------------------+ 2044 | application | alto-propmap+json | Section 7.1 | 2045 | application | alto-propmapparams+json | Section 8.3 | 2046 +--------------+--------------------------+------------------------+ 2048 Table 1: Additional ALTO Media Types. 2050 Type name: application 2052 Subtype name: This document registers multiple subtypes, as listed 2053 in Table 1. 2055 Required parameters: n/a 2057 Optional parameters: n/a 2059 Encoding considerations: Encoding considerations are identical to 2060 those specified for the "application/json" media type. See 2061 [RFC7159]. 2063 Security considerations: Security considerations related to the 2064 generation and consumption of ALTO Protocol messages are discussed 2065 in Section 15 of [RFC7285]. 2067 Interoperability considerations: This document specifies formats of 2068 conforming messages and the interpretation thereof. 2070 Published specification: This document is the specification for 2071 these media types; see Table 1 for the section documenting each 2072 media type. 2074 Applications that use this media type: ALTO servers and ALTO clients 2075 either stand alone or are embedded within other applications. 2077 Additional information: 2079 Magic number(s): n/a 2081 File extension(s): This document uses the mime type to refer to 2082 protocol messages and thus does not require a file extension. 2084 Macintosh file type code(s): n/a 2086 Person & email address to contact for further information: See 2087 Authors' Addresses section. 2089 Intended usage: COMMON 2091 Restrictions on usage: n/a 2093 Author: See Authors' Addresses section. 2095 Change controller: Internet Engineering Task Force 2096 (mailto:iesg@ietf.org). 2098 12.2. ALTO Entity Domain Type Registry 2100 This document requests IANA to create and maintain the "ALTO Entity 2101 Domain Type Registry", listed in Table 2. 2103 +-------------+---------------------------+-------------------------+ 2104 | Identifier | Entity Identifier | Hierarchy & Inheritance | 2105 | | Encoding | | 2106 +-------------+---------------------------+-------------------------+ 2107 | ipv4 | See Section 6.1.1 | See Section 6.1.3 | 2108 | ipv6 | See Section 6.1.2 | See Section 6.1.3 | 2109 | pid | See Section 6.2 | None | 2110 +-------------+---------------------------+-------------------------+ 2112 Table 2: ALTO Entity Domains. 2114 This registry serves two purposes. First, it ensures uniqueness of 2115 identifiers referring to ALTO entity domains. Second, it states the 2116 requirements for allocated entity domains. 2118 12.2.1. Consistency Procedure between ALTO Address Type Registry and 2119 ALTO Entity Domain Type Registry 2121 One potential issue of introducing the "ALTO Entity Domain Type 2122 Registry" is its relationship with the "ALTO Address Types Registry" 2123 already defined in Section 14.4 of [RFC7285]. In particular, the 2124 entity identifier of a type of an entity domain registered in the 2125 "ALTO Entity Domain Type Registry" MAY match an address type defined 2126 in "ALTO Address Type Registry". It is necessary to precisely define 2127 and guarantee the consistency between "ALTO Address Type Registry" 2128 and "ALTO Entity Domain Registry". 2130 We define that the ALTO Entity Domain Type Registry is consistent 2131 with ALTO Address Type Registry if two conditions are satisfied: 2133 o When an address type is already or able to be registered in the 2134 ALTO Address Type Registry [RFC7285], the same identifier MUST be 2135 used when a corresponding entity domain type is registered in the 2136 ALTO Entity Domain Type Registry. 2138 o If an ALTO entity domain type has the same identifier as an ALTO 2139 address type, their addresses encoding MUST be compatible. 2141 To achieve this consistency, the following items MUST be checked 2142 before registering a new ALTO entity domain type in a future 2143 document: 2145 o Whether the ALTO Address Type Registry contains an address type 2146 that can be used as an entity identifier for the candidate domain 2147 identifier. This has been done for the identifiers "ipv4" and 2148 "ipv6" in Table 2. 2150 o Whether the candidate entity identifier of the type of the entity 2151 domain is able to be an endpoint address, as defined in Sections 2152 2.1 and 2.2 of [RFC7285]. 2154 When a new ALTO entity domain type is registered, the consistency 2155 with the ALTO Address Type Registry MUST be ensured by the following 2156 procedure: 2158 o Test: Do corresponding entity identifiers match a known "network" 2159 address type? 2161 * If yes (e.g., cell, MAC or socket addresses): 2163 + Test: Is such an address type present in the ALTO Address 2164 Type Registry? 2166 - If yes: Set the new ALTO entity domain type identifier to 2167 be the found ALTO address type identifier. 2169 - If no: Define a new ALTO entity domain type identifier 2170 and use it to register a new address type in the ALTO 2171 Address Type Registry following Section 14.4 of 2172 [RFC7285]. 2174 + Use the new ALTO entity domain type identifier to register a 2175 new ALTO entity domain type in the ALTO Entity Domain Type 2176 Registry following Section 12.2.2 of this document. 2178 * If no (e.g., pid name, ane name or country code): Proceed with 2179 the ALTO Entity Domain Type registration as described in 2180 Section 12.2.2. 2182 12.2.2. ALTO Entity Domain Type Registration Process 2184 New ALTO entity domain types are assigned after IETF Review [RFC5226] 2185 to ensure that proper documentation regarding the new ALTO entity 2186 domain types and their security considerations has been provided. 2187 RFCs defining new entity domain types SHOULD indicate how an entity 2188 in a registered type of domain is encoded as an EntityID, and, if 2189 applicable, the rules defining the entity hierarchy and property 2190 inheritance. Updates and deletions of ALTO entity domains follow the 2191 same procedure. 2193 Registered ALTO entity domain type identifiers MUST conform to the 2194 syntactical requirements specified in Section 5.1.2. Identifiers are 2195 to be recorded and displayed as strings. 2197 Requests to the IANA to add a new value to the registry MUST include 2198 the following information: 2200 o Identifier: The name of the desired ALTO entity domain type. 2202 o Entity Identifier Encoding: The procedure for encoding the 2203 identifier of an entity of the registered type as an EntityID (see 2204 Section 5.1.3). If corresponding entity identifiers of an entity 2205 domain match a known "network" address type, the Entity Identifier 2206 Encoding of this domain identifier MUST include both Address 2207 Encoding and Prefix Encoding of the same identifier registered in 2208 the ALTO Address Type Registry [RFC7285]. For the purpose of 2209 defining properties, an individual entity identifier and the 2210 corresponding full-length prefix MUST be considered aliases for 2211 the same entity. 2213 o Hierarchy: If the entities form a hierarchy, the procedure for 2214 determining that hierarchy. 2216 o Inheritance: If entities can inherit property values from other 2217 entities, the procedure for determining that inheritance. 2219 o Media type of defining information resource: some entity domain 2220 types allow their entity domain type name to be combined with an 2221 information resource name to define a resource-specific entity 2222 domain. Such an information resource is called "defining 2223 information resource". In this case, the authorized media type of 2224 specific information resources MUST be specified in the document 2225 defining the entity domain type. When this entity domain type 2226 allows combinations with defining resources, this must be 2227 indicated and the conditions fully specified in the document. The 2228 defining information resource for an entity domain type is the one 2229 that: 2231 * has an entry in the IRD, 2233 * defines these entities, 2235 * does not use another information resource that defines these 2236 entities, 2238 * defines and exposes entity identifiers that are all persistent. 2240 * has a unique media type equal to the one specified in the 2241 document defining the entity domain type. 2243 This information is useful when Servers indicate resource specific 2244 entity domains in the property map capabilities. Clients need to 2245 know if the combination of information resource type and entity 2246 domain type is allowed. See also, Section 4.6 and Section 5.1 for 2247 more information. 2249 o Mapping to ALTO Address Type: A boolean value to indicate if the 2250 entity domain type can be mapped to the ALTO address type with the 2251 same identifier. 2253 o Security Considerations: In some usage scenarios, entity 2254 identifiers carried in ALTO Protocol messages may reveal 2255 information about an ALTO client or an ALTO service provider. 2256 Applications and ALTO service providers using addresses of the 2257 registered type should be made aware of how (or if) the addressing 2258 scheme relates to private information and network proximity. 2260 This specification requests registration of the identifiers "ipv4", 2261 "ipv6" and "pid", as shown in Table 2. 2263 12.3. ALTO Entity Property Type Registry 2265 This document requests IANA to create and maintain the "ALTO Entity 2266 Property Type Registry", listed in Table 3. 2268 This registry extends the "ALTO Endpoint Property Type Registry" 2269 created by [RFC7285] in that a property is defined on one or more 2270 entity domains, rather than just on the IPv4 and IPv6 Internet 2271 address domains. entry in this registry is an ALTO entity property 2272 type defined in Section 5.2.1. Thus, registered ALTO entity property 2273 type identifier MUST conform to the syntactical requirements 2274 specified in that section. 2276 +-------------+---------------------------------+ 2277 | Identifier | Intended Semantics | 2278 +-------------+---------------------------------+ 2279 | pid | See Section 7.1.1 of [RFC7285] | 2280 +-------------+---------------------------------+ 2282 Table 3: ALTO Entity Property Types. 2284 Requests to the IANA to add a new value to the registry MUST include 2285 the following information: 2287 o Identifier: The unique id for the desired ALTO entity property 2288 type. The format MUST be as defined in Section 5.2.1 of this 2289 document. It includes the information of the applied ALTO entity 2290 domain and the property name. 2292 o Intended Semantics: ALTO entity properties carry with them 2293 semantics to guide their usage by ALTO clients. Hence, a document 2294 defining a new type SHOULD provide guidance to both ALTO service 2295 providers and applications utilizing ALTO clients as to how values 2296 of the registered ALTO entity property should be interpreted. 2298 o Security Considerations: ALTO entity properties expose information 2299 to ALTO clients. ALTO service providers should be made aware of 2300 the security ramifications related to the exposure of an entity 2301 property. 2303 In security considerations, the request should also discuss the 2304 sensitivity of the information, and why such sensitive information is 2305 required for ALTO-based operations. Regarding this discussion, the 2306 request SHOULD follow the recommendations of Section 14.3. ALTO 2307 Endpoint Property Type Registry in [RFC7285]. 2309 This document requests registration of the identifier "pid", listed 2310 in Table 3. Semantics for this property are documented in 2311 Section (TODO: add ref) and security considerations are documented in 2312 Section TODO:ref. 2314 13. Acknowledgments 2316 The authors would like to thank discussions with Kai Gao, Qiao Xiang, 2317 Shawn Lin, Xin Wang, Danny Perez, and Vijay Gurbani. The authors 2318 thank Dawn Chen (Tongji University), and Shenshen Chen (Tongji/Yale 2319 University) for their contributions to earlier drafts. 2321 14. References 2323 14.1. Normative References 2325 [ISO3166-1] 2326 The International Organization for Standardization, "Codes 2327 for the representation of names of countries and their 2328 subdivisions -- Part 1: Country codes, ISO 3166-1:2013", 2329 2013. 2331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2332 Requirement Levels", BCP 14, RFC 2119, 2333 DOI 10.17487/RFC2119, March 1997, 2334 . 2336 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2337 Resource Identifier (URI): Generic Syntax", STD 66, 2338 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2339 . 2341 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2342 (CIDR): The Internet Address Assignment and Aggregation 2343 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2344 2006, . 2346 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2347 IANA Considerations Section in RFCs", RFC 5226, 2348 DOI 10.17487/RFC5226, May 2008, 2349 . 2351 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2352 Address Text Representation", RFC 5952, 2353 DOI 10.17487/RFC5952, August 2010, 2354 . 2356 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2357 "Specification of the IP Flow Information Export (IPFIX) 2358 Protocol for the Exchange of Flow Information", STD 77, 2359 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2360 . 2362 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2363 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2364 2014, . 2366 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 2367 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 2368 "Application-Layer Traffic Optimization (ALTO) Protocol", 2369 RFC 7285, DOI 10.17487/RFC7285, September 2014, 2370 . 2372 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 2373 Nadeau, "An Architecture for the Interface to the Routing 2374 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 2375 . 2377 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 2378 R., and K. Ma, "Content Delivery Network Interconnection 2379 (CDNI) Request Routing: Footprint and Capabilities 2380 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 2381 . 2383 14.2. Informative References 2385 [draft-ietf-alto-cdni-request-routing-alto] 2386 Roome, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang, 2387 "Content Delivery Network Interconnection (CDNI) Request 2388 Routing: CDNI Footprint and Capabilities Advertisement 2389 using ALTO (work in progress)", 2020. 2391 [I-D.ietf-alto-path-vector] 2392 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 2393 "ALTO Extension: Path Vector", draft-ietf-alto-path- 2394 vector-09 (work in progress), November 2019, 2395 . 2398 Appendix A. Scope of Property Map 2400 Using entity domains to organize entities, an ALTO property map 2401 resource can be regarded as given sets of properties for given entity 2402 domains. If we ignore the resource-agnostic entity domains, we can 2403 regard an ALTO property map resource as a set of (ri, di) => (ro, po) 2404 mappings, where (ri, di) means a resource-specific entity domain of 2405 type di defined by the information resource ri, and (ro, po) means a 2406 resource-specific entity property po defined by the information 2407 resource ro. 2409 For each (ri, di) => (ro, po) mapping, the scope of an ALTO property 2410 map resource must be one of the cases in the following diagram: 2412 domain.resource domain.resource 2413 (ri) = r (ri) = this 2414 +-----------------|-----------------+ 2415 prop.resource | Export | Non-exist | 2416 (ro) = r | | | 2417 +-----------------|-----------------+ 2418 prop.resource | Extend | Define | 2419 (ro) = this | | | 2420 +-----------------|-----------------+ 2422 where "this" represents the resulting property map resource, and "r" 2423 represents an existing ALTO information resource other the resulting 2424 property map resource. 2426 o ri = ro = r ("export" mode): the property map resource just 2427 transforms the property mapping di => po defined by r into the 2428 unified representation format and exports it. For example: r = 2429 "netmap1", di = "ipv4", po = "pid". The property map resource 2430 exports the "ipv4 => pid" mapping defined by "netmap1". 2432 o ri = r, ro = this ("extend" mode): the property map extends 2433 properties of entities in the entity domain (r, di) and defines a 2434 new property po on them. For example: the property map resource 2435 ("this") defines a "geolocation" property on domain "netmap1.pid". 2437 o ri = ro = this ("define" mode): the property map defines a new 2438 intrinsic entity domain and defines property po for each entity in 2439 this domain. For example: the property map resource ("this") 2440 defines a new entity domain "asn" and defines a property 2441 "ipprefixes" on this domain. 2443 o ri = this, ro = r: in the scope of a property map resource, it 2444 does not make sense that another existing ALTO information 2445 resource defines a property for this property map resource. 2447 A.1. Example Property Map 2449 The following figure shows an example property map called Property 2450 Map 1, which depends on two network maps and provides three sets of 2451 mappings by 2453 o exporting a mapping from ipv4 entities to PIDs defined by two 2454 different network maps, 2456 o extending geo-location properties to ipv4 entities defined by 2457 Network Map 1, 2459 o and defining a new mapping from ASNs to traffic load properties. 2461 (Define) 2462 +----------+ +-------------+ 2463 ->| Property |<---------------------------+--------| asn | load | 2464 / | Map 1 | | |-------------| 2465 / +----------+ | | 1234 | 95% | 2466 | ^ | | 5678 | 70% | 2467 | | \ +-------------+ 2468 | | (Export) \ (Extend) 2469 | +---------+ +------------------------+ \ +--------------+ 2470 | | Network |----| ipv4 | pid | -----| geo-location | 2471 | | Map 1 | |------------------------| +--------------+ 2472 | +---------+ | 192.168.0.0/24 | pid1 | - - -> | New York | 2473 | | 192.168.1.0/24 | pid2 | - - -> | Shanghai | 2474 | +------------------------+ +--------------+ 2475 | (Export) 2476 \ +---------+ +------------------------+ 2477 ---| Network |----| ipv4 | pid | 2478 | Map 2 | |------------------------| 2479 +---------+ | 192.168.0.0/24 | Paris | 2480 | ... | ... | 2481 +------------------------+ 2483 More detailed examples are shown in Section 10. 2485 Authors' Addresses 2487 Wendy Roome 2488 Nokia Bell Labs (Retired) 2489 124 Burlington Rd 2490 Murray Hill, NJ 07974 2491 USA 2493 Phone: +1-908-464-6975 2494 Email: wendy@wdroome.com 2496 Sabine Randriamasy 2497 Nokia Bell Labs 2498 Route de Villejust 2499 NOZAY 91460 2500 FRANCE 2502 Email: Sabine.Randriamasy@nokia-bell-labs.com 2503 Y. Richard Yang 2504 Yale University 2505 51 Prospect Street 2506 New Haven, CT 06511 2507 USA 2509 Phone: +1-203-432-6400 2510 Email: yry@cs.yale.edu 2512 Jingxuan Jensen Zhang 2513 Tongji University 2514 4800 Caoan Road 2515 Shanghai 201804 2516 China 2518 Email: jingxuan.n.zhang@gmail.com 2520 Kai Gao 2521 Sichuan University 2522 Chengdu 610000 2523 China 2525 Email: kaigao@scu.edu.cn