idnits 2.17.1 draft-ietf-alto-unified-props-new-01.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 610 has weird spacing: '...rtyName prop...' == Line 733 has weird spacing: '...country stat...' -- The document date (December 17, 2017) is 2321 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-alto-path-vector (ref. 'I-D.ietf-alto-path-vector') Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG W. Roome 3 Internet-Draft Nokia Bell Labs 4 Intended status: Standards Track S. Chen 5 Expires: June 20, 2018 X. Wang 6 Tongji University 7 Y. Yang 8 Yale University 9 J. Zhang 10 Tongji University 11 December 17, 2017 13 Extensible Property Maps for the ALTO Protocol 14 draft-ietf-alto-unified-props-new-01 16 Abstract 18 This document extends the Application-Layer Traffic Optimization 19 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 20 properties" to other entity domains, and by presenting those 21 properties as maps, similar to the network and cost maps in ALTO. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 20, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4 65 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Domain . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.4. Entity Address . . . . . . . . . . . . . . . . . . . . . 5 69 2.5. Property Name . . . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 6 71 2.7. Relationship with Other ALTO Resources . . . . . . . . . 6 72 3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. Internet Address Domains . . . . . . . . . . . . . . . . 7 74 3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 7 75 3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 8 76 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 8 77 3.1.4. Relationship to Network Maps . . . . . . . . . . . . 9 78 3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 80 3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 81 3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 10 82 3.2.4. Relationship To Internet Addresses Domains . . . . . 10 83 3.3. Internet Address Properties vs. PID Properties . . . . . 10 84 3.4. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.4.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 11 86 3.4.2. Domain-Specific Entity Addresses . . . . . . . . . . 11 87 3.4.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 11 88 4. Property Map Resource . . . . . . . . . . . . . . . . . . . . 11 89 4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 11 92 4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 12 93 4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 95 5. Filtered Property Map Resource . . . . . . . . . . . . . . . 13 96 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13 97 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13 98 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13 99 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 100 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 14 102 6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 14 103 6.1. Impact on Endpoint Property Service . . . . . . . . . . . 14 104 6.2. Impact on Resource-Specific Properties . . . . . . . . . 15 105 6.3. Impact on the "pid" Property . . . . . . . . . . . . . . 15 106 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 16 107 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 108 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 16 109 7.2. Property Definitions . . . . . . . . . . . . . . . . . . 16 110 7.3. Information Resource Directory (IRD) . . . . . . . . . . 16 111 7.4. Property Map Example . . . . . . . . . . . . . . . . . . 18 112 7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 19 113 7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 20 114 7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 21 115 7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 22 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 118 9.1. application/alto-* Media Types . . . . . . . . . . . . . 24 119 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 25 120 9.3. ALTO Endpoint Property Type Registry . . . . . . . . . . 26 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 124 1. Introduction 126 The ALTO protocol [RFC7285] introduced the concept of "properties" 127 attached to "endpoint addresses", and defined the Endpoint Property 128 Service (EPS) to allow clients to retrieve those properties. While 129 useful, the EPS, as defined in RFC7285, has at least two limitations. 131 First, it only allows properties to be associated with a particular 132 domain of entities, namely individual IP addresses. It is reasonable 133 to think that collections of endpoints, as defined by CIDRs 134 ([RFC4632]) or PIDs, may also have properties. Furthermore, a recent 135 proposal ([I-D.ietf-alto-path-vector]) has suggested new classes of 136 entities (ANE) with properties. The EPS cannot be extended to new 137 entity domains. Instead, new services, with new request and response 138 messages, would have to be defined for each new entity domain. 140 Second, the EPS is only defined as a POST-mode service. Clients must 141 request the properties for an explicit set of addresses. By 142 contrast, [RFC7285] defines a GET-mode Cost Map resource which 143 returns all available costs, so a client can get a full set of costs 144 once, and then processes costs lookup without querying the ALTO 145 server. RFC7285 does not define an equivalent service for endpoint 146 properties. And it is unlikely a property will be defined for every 147 possible address. It is very likely that properties will only be 148 defined for a subset of addresses, and that subset would be small 149 enough to enumerate. This is particularly true if blocks of 150 addresses with a common prefix (e.g., a CIDR) have the same value for 151 a property. Furthermore, entities in other domains may very well be 152 enumerable. 154 This document proposes a new approach to retrieve ALTO properties. 155 Specifically, it defines two new resource types, namely Property Maps 156 (see Section 4) and Filtered Property Maps (see Section 5). The 157 former are GET-mode resources which return the property values for 158 all entities in a domain, and are analogous to the ALTO's Network 159 Maps and Cost Maps. The latter are POST-mode resources which return 160 the values for a set of properties and entities requested by the 161 client, and are analogous to the ALTO's Filtered Network Maps and 162 Filtered Cost Maps. 164 Entity domains and property names are extensible. New domains can be 165 defined without revising the messages defined in this document, in 166 the same way that new cost metrics and new endpoint properties can be 167 defined without revising the messages defined by the ALTO protocol. 169 This proposal would subsume the Endpoint Property Service defined in 170 RFC7285, although that service may be retained for legacy clients 171 (see Section 6). 173 2. Definitions and Concepts 175 2.1. Entity 177 An entity is an object with a (possibly empty) set of properties. 178 Every entity is in a domain, such as the IPv4 and IPv6 domains, and 179 has a unique address. 181 2.2. Domain 183 A domain is a family of entities. Two examples are the Internet 184 address and PID domain (see Section 3.1 and Section 3.2) that this 185 document will define. An additional example is the proposed domain 186 of Abstract Network Elements associated with topology and routing, as 187 suggested by [I-D.ietf-alto-path-vector]. 189 2.3. Domain Name 191 Each domain has a unique name. A domain name MUST be no more than 32 192 characters, and MUST NOT contain characters other than US-ASCII 193 alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 194 U+0061-U+007A), hyphen ('-', U+002D), and low line ('_', U+005F). 195 For example, the names "ipv4" and "ipv6" identify objects in the 196 Internet address domain (Section 3.1). 198 The type DomainName is used in this document to denote a JSON string 199 with a domain name in this format. 201 Domain names MUST be registered with the IANA, and the format of the 202 entity addresses in that domain, as well as any hierarchical or 203 inheritance rules for those entities, MUST be specified at the same 204 time. 206 2.4. Entity Address 208 Each entity has a unique address of the format: 210 domain-name : domain-specific-entity-address 212 Examples from the IP domain include individual addresses such as 213 "ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks 214 such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48". 216 The type EntityAddr is used in this document to denote a JSON string 217 with an entity address in this format. 219 The format of the second part of an entity address depends on the 220 domain, and MUST be specified when registering a new domain. 221 Addresses MAY be hierarchical, and properties MAY be inherited based 222 on that hierarchy. Again, the rules defining any hierarchy or 223 inheritance MUST be defined when the domain is registered. 225 Note that entity addresses MAY have different textual 226 representations, for a given domain. For example, the strings 227 "ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same 228 entity. 230 2.5. Property Name 232 The space of property names associated with entities defined by this 233 document is the same as, and is shared with, the endpoint property 234 names defined by [RFC7285]. Thus entity property names are as 235 defined in Section 10.8.2 of that document, and must be registered 236 with the "ALTO Endpoint Property Type Registry" defined in 237 Section 9.3 of that document. The type PropertyName denotes a JSON 238 string with a property name in this format. 240 This document defines uniform property names specified in a single 241 property name sapce rather than being scoped by a specific domain, 242 although some properties may only be applicable for particular 243 domains. This design decision is to enforce a design so that similar 244 properties are named similarly. The interpretation of the value of a 245 property, howerver, may depend on the domain. For example, suppose 246 the "geo-location" property is defined as the coordinates of a point, 247 encoded as (say) "latitude longitude [altitude]." When applied to an 248 entity that represents a specific host computer, such as an Internet 249 address, the property defines the host's location. When applied to 250 an entity that represents a set of computers, such as a CIDR, the 251 property would be the location of the center of that set. If it is 252 necessary to represent the bounding box of a set of hosts, another 253 property, such as "geo-region", should be defined. 255 2.6. Hierarchy and Inheritance 257 Entities in a given domain MAY form hierarchy based on entity 258 address. Each domain MUST define its own hierarchy and inheritance 259 rules when registered. The hierarchy and inheritance rule makes it 260 possible for an entity to inherit a property value from another 261 entity in the same domain. If and only if the property of an entity 262 is undefined, the hierarchy and inheritance rules are applied. 264 2.7. Relationship with Other ALTO Resources 266 [RFC7285] recognizes that some properties MAY be specific to another 267 ALTO resource, such as a network map. Accordingly [RFC7285] defines 268 the concept of "resource-specific endpoint properties" 269 (Section 10.8.1), and indicates that dependency by prefixing the 270 property name with the ID of the resource on which it depends. That 271 document defines one resource-specific property, namely the "pid" 272 property, whose value is the name of the PID containing that endpoint 273 in the associated network map. 275 This document takes a different approach. Instead of defining the 276 dependency by qualifying the property name, this document attaches 277 the dependency to the domains. Thus all properties of a specific 278 domain depend on the same resource, the properties of another domain 279 may depend on another resource. For example, entities in the PID 280 domain depends on a network map, entities in the ANE domain depends 281 on a cost map or a endpoint cost map. 283 The "uses" field in an IRD entry defines the dependencies of a 284 property map resource, and the "dependent-vtags" field in a property 285 map response defines the dependencies of that map. These fields are 286 defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively. 288 The "uses" field in an IRD entry MUST NOT include two dependent 289 resources with the same media type. This is similar to how RFC7285 290 handles dependencies between cost maps and network maps. Recall that 291 cost maps present the costs between PIDs, and PID names depend on a 292 network map. If an ALTO server provides the "routingcost" metric for 293 the network maps "net1" and "net2", then the server defines two 294 separate cost maps, one for "net1" and the other for "net2". 296 According to [RFC7285], a legacy ALTO server with two network maps, 297 with resource IDs "net1" and "net2", could offer a single Endpoint 298 Property Service for the two properties "net1.pid" and "net2.pid". 299 An ALTO server which supports the extensions defined in this 300 document, would, instead, offer two different Property Maps for the 301 "pid" property, one depending on "net1", the other on "net2". 303 3. Entity Domains 305 This document defines the following entity domains. For the 306 definition of each domain, it includes the following template: domain 307 name, domain-specific addresses, and hierarchy and inheritance 308 semantics. 310 3.1. Internet Address Domains 312 The document defines two domains (IPv4 and IPv6) for Internet 313 addresses. Both domains include individual addresses and blocks of 314 addresses. 316 3.1.1. IPv4 Domain 318 3.1.1.1. Domain Name 320 ipv4 322 3.1.1.2. Domain-Specific Entity Addresses 324 Individual addresses are strings as specified by the IPv4Addresses 325 rule of Section 3.2.2 of [RFC3986]. Blocks of addresses are prefix- 326 match strings as specified in Section 3.1 of [RFC4632]. For the 327 purpose of defining properties, an individual Internet address and 328 the corresponding full-length prefix are considered aliases for the 329 same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 330 equivalent. 332 3.1.2. IPv6 Domain 334 3.1.2.1. Domain Name 336 ipv6 338 3.1.2.2. Domain-Specific Entity Addresses 340 Individual addresses are strings as specified by Section 4 of 341 [RFC5952]. Blocks of addresses are prefix-match strings as specified 342 in Section 7 of [RFC5952]. For the purpose of defining properties, 343 an individual Internet address and the corresponding 128-bit prefix 344 are considered aliases for the same entity. That is, 345 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and 346 have the same set of properties. 348 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains 350 Both domains allow property values to be inherited. Specifically, if 351 a property P is not defined for a specific Internet address I, but P 352 is defined for some block C which prefix-matches I, then the address 353 I inherits the value of P defined for block C. If more than one such 354 block defines a value for P, I inherits the value of P in the block 355 with the longest prefix. It is important to notice that this longest 356 prefix rule will ensure no multiple inheritance, and hence no 357 ambiguity. 359 Address blocks can also inherit properties: if property P is not 360 defined for a block C, but is defined for some block C' prefix- 361 matches C, and C' has a shorter mask than C, then block C inherits 362 the property from C'. If there are several such blocks C', C 363 inherits from the block with the longest prefix. 365 As an example, suppose that a server defines the property P for the 366 following entities: 368 ipv4:192.0.2.0/26: P=v1 369 ipv4:192.0.2.0/28: P=v2 370 ipv4:192.0.2.0/30: P=v3 371 ipv4:192.0.2.0: P=v4 373 Figure 1: Defined Property Values. 375 Then the following entities have the indicated values: 377 ipv4:192.0.2.0: P=v4 378 ipv4:192.0.2.1: P=v3 379 ipv4:192.0.2.16: P=v1 380 ipv4:192.0.2.32: P=v1 381 ipv4:192.0.2.64: (not defined) 382 ipv4:192.0.2.0/32: P=v4 383 ipv4:192.0.2.0/31: P=v3 384 ipv4:192.0.2.0/29: P=v2 385 ipv4:192.0.2.0/27: P=v1 386 ipv4:192.0.2.0/25: (not defined) 388 Figure 2: Inherited Property Values. 390 An ALTO Server MAY explicitly indicate a property as not having a 391 value for a particular entity. That is, a server MAY say that 392 property A of entity X is "defined to have no value", instead of 393 "undefined". To indicate "no value", a server MAY perform different 394 behaviours: 396 o If that entity would inherit a value for that property, then the 397 ALTO server MUST return a "null" value for that property. In this 398 case, the ALTO client MUST recognize a "null" value as "no value" 399 and "do not apply the inheritance rules for this property." 401 o If the entity would not inherit a value, then the ALTO server MAY 402 return "null" or just omit the property. In this case, the ALTO 403 client cannot infer the value for this property of this entity 404 from the Inheritance rules. So the client MUST interpret this 405 property has "no value". 407 If the ALTO Server does not define any properties for an entity, then 408 the server MAY omit that entity from the response. 410 3.1.4. Relationship to Network Maps 412 An Internet address domain MAY be associated with an ALTO network map 413 resource. Logically, there is a map of Internet address entities to 414 property values for each network map defined by the ALTO server, plus 415 an additional property map for Internet address entities which are 416 not associated with a network map. So, if there is n network maps, 417 the server can provide n+1 maps of Internet address entities to 418 property values. These maps are separate from each other. The 419 prefixes in the property map do not have to correspond to the 420 prefixes defining the network map's PIDs. For example, the property 421 map for a network map MAY assign properties to "ipv4:192.0.2.0/24" 422 even if that prefix is not associated with any PID in the network 423 map. 425 3.2. PID Domain 427 The PID domain associates property values with the PIDs in a network 428 map. Accordingly, this domain always depends on a network map. 430 3.2.1. Domain Name 432 pid 434 3.2.2. Domain-Specific Entity Addresses 436 The entity addresses are the PID names of the associated network map. 438 3.2.3. Hierarchy and Inheritance 440 There is no hierarchy or inheritance for properties associated with 441 PIDs. 443 3.2.4. Relationship To Internet Addresses Domains 445 The PID domain and the Internet address domains are completely 446 independent; the properties associated with a PID have no relation to 447 the properties associated with the prefixes or endpoint addresses in 448 that PID. An ALTO server MAY choose to assign some or all properties 449 of a PID to the prefixes in that PID. 451 For example, suppose "PID1" consists of the prefix 452 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 453 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", 454 in the IPv4 domain MAY have a value for the property "P", and if they 455 do, it is not necessarily "v1". 457 3.3. Internet Address Properties vs. PID Properties 459 Because the Internet address and PID domains are completely separate, 460 the question may arise as to which domain is best for a property. In 461 general, the Internet address domain is RECOMMENDED for properties 462 that are closely related to the Internet address, or are associated 463 with, and inherited through, blocks of addresses. 465 The PID domain is RECOMMENDED for properties that arise from the 466 definition of the PID, rather than from the Internet address prefixes 467 in that PID. 469 For example, because Internet addresses are allocated to service 470 providers by blocks of prefixes, an "ISP" property would be best 471 associated with the Internet address domain. On the other hand, a 472 property that explains why a PID was formed, or how it relates the a 473 provider's network, would best be associated with the PID domain. 475 3.4. ANE Domain 477 3.4.1. Domain Name 479 ane 481 3.4.2. Domain-Specific Entity Addresses 483 The entity address of ane domain is encoded as a JSON string. The 484 string MUST be no more than 64 characters, and it MUST NOT contain 485 characters other than US-ASCII alphanumeric characters 486 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', 487 U+002D), the colon (':', U+003A), the at sign ('@', code point 488 U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). 489 The '.' separator is reserved for future use and MUST NOT be used 490 unless specifically indicated in this document, or an extension 491 document. 493 3.4.3. Hierarchy and Inheritance 495 There is no hierarchy or inheritance for properties associated with 496 ANEs. 498 4. Property Map Resource 500 A Property Map returns the properties defined for all entities in one 501 or more domains. 503 Section 7.4 gives an example of a property map request and its 504 response. 506 4.1. Media Type 508 The media type of an ALTO Property Map resource is "application/alto- 509 propmap+json". 511 4.2. HTTP Method 513 An ALTO Property Map resource is requested using the HTTP GET method. 515 4.3. Accept Input Parameters 517 None. 519 4.4. Capabilities 521 The capabilities are defined by an object of type 522 PropertyMapCapabilities: 524 object { 525 DomainName domain-types<1..*>; 526 PropertyName prop-types<1..*>; 527 } PropertyMapCapabilities; 529 where "domain-types" is an array with the domains of the entities in 530 this property map, and "prop-types" is an array with the names of the 531 properties returned for entities in those domains. 533 4.5. Uses 535 An array with the resource ID(s) of resource(s) with which the 536 domains in this map are associated. In most cases, this array will 537 have at most one ID, for example, for a network map resource. 538 However, the "uses" field MUST NOT contain two resources of the same 539 resource type. For example, if a property map depends on network map 540 resource, the "uses" field MUST include exactly one network map 541 resource. 543 4.6. Response 545 If the domains in this property map depend on other resources, the 546 "dependent-vtags" field in the "meta" field of the response MUST be 547 an array that includes the version tags of those resources. The data 548 component of a Property Map response is named "property-map", which 549 is a JSON object of type PropertyMapData, where: 551 object { 552 PropertyMapData property-map; 553 } InfoResourceProperties : ResponseEntityBase; 555 object-map { 556 EntityAddr -> EntityProps; 557 } PropertyMapData; 559 object { 560 PropertyName -> JSONValue; 561 } EntityProps; 563 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 565 Specifically, a PropertyMapData object has one member for each entity 566 in the Property Map. The entity's properties are encoded in the 567 corresponding EntityProps object. EntityProps encodes one name/value 568 pair for each property, where the property names are encoded as 569 strings of type PropertyName. A protocol implementation SHOULD 570 assume that the property value is either a JSONString or a JSON 571 "null" value, and fail to parse if it is not, unless the 572 implementation is using an extension to this document that indicates 573 when and how property values of other data types are signaled. 575 For each entity in the Property Map, the ALTO Server returns the 576 value defined for each of the properties specified in this resource's 577 "capabilities" list. For efficiency, the ALTO Server SHOULD omit 578 property values that are inherited rather than explicitly defined; if 579 a client needs inherited values, the client SHOULD use the domain's 580 inheritance rules to deduce those values. 582 5. Filtered Property Map Resource 584 A Filtered Property Map returns the values of a set of properties for 585 a set of entities selected by the client. 587 Section 7.5, Section 7.6 and Section 7.7 give examples of filtered 588 property map requests and responses. 590 5.1. Media Type 592 The media type of an ALTO Property Map resource is "application/alto- 593 propmap+json". 595 5.2. HTTP Method 597 An ALTO Filtered Property Map resource is requested using the HTTP 598 POST method. 600 5.3. Accept Input Parameters 602 The input parameters for a Filtered Property Map request are supplied 603 in the entity body of the POST request. This document specifies the 604 input parameters with a data format indicated by the media type 605 "application/alto-propmapparams+json", which is a JSON object of type 606 ReqFilteredPropertyMap: 608 object { 609 EntityAddr entities<1..*>; 610 PropertyName properties<1..*>; 611 } ReqFilteredPropertyMap; 613 with fields: 615 entities: List of entity addresses for which the specified 616 properties are to be returned. The ALTO server MUST interpret 617 entries appearing multiple times as if they appeared only once. 618 The domain of each entity MUST be included in the list of domains 619 in this resource's "capabilities" field (Section 5.4). 621 properties: List of properties to be returned for each entity. Each 622 specified property MUST be included in the list of properties in 623 this resource's "capabilities" field (Section 5.4). The ALTO 624 server MUST interpret entries appearing multiple times as if they 625 appeared only once. 627 Note that the "entities" and "properties" fields MUST have at 628 least one entry each. 630 5.4. Capabilities 632 The capabilities are defined by an object of type 633 PropertyMapCapabilities, as defined in Section 4.4. 635 5.5. Uses 637 An array with the resource ID(s) of resource(s) with which the 638 domains in this map are associated. In most cases, this array will 639 have at most one ID, and it will be for a network map resource. 641 5.6. Response 643 The response is the same as for the property map (Section 4.6), 644 except that it only includes the entities and properties requested by 645 the client. 647 Also, the Filtered Property Map response MUST include all inherited 648 property values for the specified entities (unlike the Full Property 649 Map, the Filtered Property Map response does not include enough 650 information for the client to calculate the inherited values). 652 6. Impact on Legacy ALTO Servers and ALTO Clients 654 6.1. Impact on Endpoint Property Service 656 The Property Maps defined in this document provide the same 657 functionality as the Endpoint Property Service (EPS) defined in 658 Section 11.4 of [RFC7285]. Accordingly, it is RECOMMENDED that the 659 EPS be deprecated in favor of Property Maps. However, ALTO servers 660 MAY provide an EPS for the benefit of legacy clients. 662 6.2. Impact on Resource-Specific Properties 664 Section 10.8 of [RFC7285] defines two categories of endpoint 665 properties: "resource-specific" and "global". Resource-specific 666 property names are prefixed with the ID of the resource they depend 667 upon, while global property names have no such prefix. The property 668 map resources defined in this document do not distinguish between 669 those two types of properties. Instead, if there is a dependency, it 670 is indicated by the "uses" capability of a property map, and is 671 shared by all properties and entity domains in that map. 672 Accordingly, it is RECOMMENDED that resource-specific endpoint 673 properties be deprecated, and no new resource-specific endpoint 674 properties be defined. 676 6.3. Impact on the "pid" Property 678 Section 7.1.1 of [RFC7285] defines the resource-specific endpoint 679 property "pid", whose value is the name of the PID containing that 680 endpoint. For compatibility with legacy clients, an ALTO server 681 which provides the "pid" property via the Endpoint Property Service 682 MUST use that definition, and that syntax, in the EPS resource. 684 However, when used with Property Maps, this document amends the 685 definition of the "pid" property as follows. 687 First, the name of the property is simply "pid"; the name is not 688 prefixed with the resource ID of a network map. The "uses" 689 capability of the property map resource indicates the associated 690 network map. This implies that a property map can only return the 691 "pid" property for one network map; if an ALTO server provides 692 several network maps, it MUST provide a property map resource for 693 each one. 695 Second, a client MAY request the "pid" property for a block of 696 addresses. An ALTO server determines the value of "pid" for an 697 address block C as follows. Let CS be the set of all address blocks 698 in the network map. If C is in CS, then the value of "pid" is the 699 name of the PID associated with C. Otherwise, find the longest block 700 C' in CS such that C' prefix-matches C, but is shorter than C. If 701 there is such a block C', the value of "pid" is the name of the PID 702 associated with C'. If not, then "pid" has no value for block C. 704 Note that although an ALTO server MAY provide a GET-mode property map 705 resource which returns the entire map for the "pid" property, there 706 is no need to do so, because that map is simply the inverse of the 707 network map. 709 6.4. Impact on Other Properties 711 In general, there should be little or no impact on other previously 712 defined properties. The only consideration is that properties can 713 now be defined on blocks of addresses, rather than just individual 714 addresses, which might change the semantics of a property. 716 7. Examples 718 7.1. Network Map 720 The examples in this section use a very simple default network map: 722 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 723 pid1: ipv4:192.0.2.0/25 724 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 726 Figure 3: Example Network Map 728 7.2. Property Definitions 730 The examples in this section use four additional properties, "ISP", 731 "ASN", "country" and "state", with the following values: 733 ISP ASN country state 734 ipv4:192.0.2.0/24: BitsRus - us - 735 ipv4:192.0.2.0/28: - 12345 - NJ 736 ipv4:192.0.2.16/28: - 12345 - CT 737 ipv4:192.0.2.0: - - - PA 739 Figure 4: Example Property Values 741 7.3. Information Resource Directory (IRD) 743 The following IRD defines the relevant resources of the ALTO server. 744 It provides two Property Map resources, one for the "ISP" and "ASN" 745 properties, and another for the "country" and "state" properties. 746 The server could have provided a Property Map resource for all four 747 properties, but did not, presumably because the organization that 748 runs the ALTO server believes any given client is not interested in 749 all four properties. 751 The server provides two Filtered Property Maps. The first returns 752 all four properties, and the second just returns the "pid" property 753 for the default network map. 755 The Filtered Property Maps for the "ISP", "ASN", "country" and 756 "state" properties do not depend on the default network map (it does 757 not have a "uses" capability), because the definitions of those 758 properties do not depend on the default network map. The Filtered 759 Property Map for the "pid" property does have a "uses" capability for 760 the default network map, because that defines the values of the "pid" 761 property. 763 Note that for legacy clients, the ALTO server provides an Endpoint 764 Property Service for the "pid" property for the default network map. 766 "meta": { ... }, 767 "resources" : { 768 "default-network-map" : { 769 "uri" : "http://alto.example.com/networkmap", 770 "media-type" : "application/alto-networkmap+json" 771 }, 772 .... property map resources .... 773 "country-state-property-map" : { 774 "uri" : "http://alto.example.com/propmap/full/inet-cs", 775 "media-type" : "application/alto-propmap+json", 776 "capabilities" : { 777 "domain-types": [ "ipv4", "ipv6" ], 778 "prop-types" : [ "country", "state" ] 779 } 780 }, 781 "isp-asn-property-map" : { 782 "uri" : "http://alto.example.com/propmap/full/inet-ia", 783 "media-type" : "application/alto-propmap+json", 784 "capabilities" : { 785 "domain-types": [ "ipv4", "ipv6" ], 786 "prop-types" : [ "ISP", "ASN" ] 787 } 788 }, 789 "iacs-property-map" : { 790 "uri" : "http://alto.example.com/propmap/lookup/inet-iacs", 791 "media-type" : "application/alto-propmap+json", 792 "accepts" : "application/alto-propmapparams+json", 793 "capabilities" : { 794 "domain-types": [ "ipv4", "ipv6" ], 795 "prop-types" : [ "ISP", "ASN", "country", "state" ] 796 } 797 }, 798 "pid-property-map" : { 799 "uri" : "http://alto.example.com/propmap/lookup/pid", 800 "media-type" : "application/alto-propmap+json", 801 "accepts" : "application/alto-propmapparams+json", 802 "uses" : [ "default-network-map" ] 803 "capabilities" : { 804 "domain-types" : [ "ipv4", "ipv6" ], 805 "prop-types" : [ "pid" ] 806 } 807 }, 808 "availbw-property-map" : { 809 "uri" : "http://alto.example.com/propmap/lookup/availbw", 810 "media-type" : "application/alto-propmap+json", 811 "accepts" : "application/alto-propmapparams+json", 812 "capabilities" : { 813 "domain-types" : [ "ane" ], 814 "prop-types" : [ "availbw", "delay" ] 815 } 816 }, 817 "legacy-pid-property-map" : { 818 "uri" : "http://alto.example.com/legacy/eps-pid", 819 "media-type" : "application/alto-endpointprop+json", 820 "accepts" : "application/alto-endpointpropparams+json", 821 "capabilities" : { 822 "prop-types" : [ "default-network-map.pid" ] 823 } 824 } 825 } 827 Figure 5: Example IRD 829 7.4. Property Map Example 831 The following example uses the properties and IRD defined above to 832 retrieve a property map for entities with the "ISP" and "ASN" 833 properties. Note that the response does not include the entity 834 "ipv4:192.0.2.0", because it does not have a value for either of 835 those properties. Also note that the entities "ipv4:192.0.2.0/28" 836 and "ipv4:192.0.2.16/28" are refinements of "ipv4:192.0.2.0/24", and 837 hence inherit its value for "ISP" property. But because that value 838 is inherited, it is not explicitly listed in the property map. 840 GET /propmap/full/inet-ia HTTP/1.1 841 Host: alto.example.com 842 Accept: application/alto-propmap+json,application/alto-error+json 844 HTTP/1.1 200 OK 845 Content-Length: ### 846 Content-Type: application/alto-propmap+json 848 { 849 "property-map": { 850 "ipv4:192.0.2.0/24": {"ISP: "BitsRus"}, 851 "ipv4:192.0.2.0/28": {"ASN": "12345"}, 852 "ipv4:192.0.2.16/28": {"ASN": "12345"} 853 } 854 } 856 7.5. Filtered Property Map Example #1 858 The following example uses the Filtered Property Map resource to 859 request the "ISP", "ASN" and "state" properties for several IPv4 860 addresses. Note that the value of "state" for "ipv4:192.0.2.0" is 861 the only explicitly defined property; the other values are all 862 derived by the inheritance rules for Internet address entities. 864 POST /propmap/lookup/inet-iacs HTTP/1.1 865 Host: alto.example.com 866 Accept: application/alto-propmap+json,application/alto-error+json 867 Content-Length: ### 868 Content-Type: application/alto-propmapparams+json 870 { 871 "entities" : [ "ipv4:192.0.2.0", 872 "ipv4:192.0.2.1", 873 "ipv4:192.0.2.17" ], 874 "properties" : [ "ISP", "ASN", "state" ] 875 } 877 HTTP/1.1 200 OK 878 Content-Length: ### 879 Content-Type: application/alto-propmap+json 881 { 882 "property-map": { 883 "ipv4:192.0.2.0": 884 {"ISP": "BitsRus", "ASN": "12345", "state": "PA"}, 885 "ipv4:192.0.2.1": 886 {"ISP": "BitsRus", "ASN": "12345", "state": "NJ"}, 887 "ipv4:192.0.2.17": 888 {"ISP": "BitsRus", "ASN": "12345", "state": "CT"} 889 } 890 } 892 7.6. Filtered Property Map Example #2 894 The following example uses the Filtered Property Map resource to 895 request the "ASN", "country" and "state" properties for several IPv4 896 prefixes. Note that none of the returned property values is 897 explicitly defined; all values are derived by the inheritance rules 898 for Internet address entities. 900 Also note the "ASN" property has the value "12345" for both the 901 blocks "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28", so every address 902 in the block "ipv4:192.0.2.0/27" has that property value. However 903 the block "ipv4:192.0.2.0/27" itself does not have a value for "ASN": 904 address blocks cannot inherit properties from blocks with longer 905 prefixes, even if every such block has the same value. 907 POST /propmap/lookup/inet-iacs HTTP/1.1 908 Host: alto.example.com 909 Accept: application/alto-propmap+json,application/alto-error+json 910 Content-Length: ### 911 Content-Type: application/alto-propmapparams+json 913 { 914 "entities" : [ "ipv4:192.0.2.0/26", 915 "ipv4:192.0.2.0/27", 916 "ipv4:192.0.2.0/28" ], 917 "properties" : [ "ASN", "country", "state" ] 918 } 920 HTTP/1.1 200 OK 921 Content-Length: ### 922 Content-Type: application/alto-propmap+json 924 { 925 "property-map": { 926 "ipv4:192.0.2.0/26": {"country": "us"}, 927 "ipv4:192.0.2.0/27": {"country": "us"}, 928 "ipv4:192.0.2.0/28": {"ASN": "12345", 929 "country": "us", 930 "state": "NJ"} 931 } 932 } 934 7.7. Filtered Property Map Example #3 936 The following example uses the Filtered Property Map resource to 937 request the "pid" property for several IPv4 addresses and prefixes. 939 Note that the value of "pid" for the prefix "ipv4:192.0.2.0/26" is 940 "pid1", even though all addresses in that block are in "pid2", 941 because "ipv4:192.0.2.0/25" is the longest prefix in the network map 942 which prefix-matches "ipv4:192.0.2.0/26", and that prefix is in 943 "pid1". 945 POST /propmap/lookup/pid HTTP/1.1 946 Host: alto.example.com 947 Accept: application/alto-propmap+json,application/alto-error+json 948 Content-Length: ### 949 Content-Type: application/alto-propmapparams+json 951 { 952 "entities" : [ 953 "ipv4:192.0.2.0", 954 "ipv4:192.0.2.16", 955 "ipv4:192.0.2.64", 956 "ipv4:192.0.2.128", 957 "ipv4:192.0.2.0/26", 958 "ipv4:192.0.2.0/30" ], 959 "properties" : [ "pid" ] 960 } 962 HTTP/1.1 200 OK 963 Content-Length: ### 964 Content-Type: application/alto-propmap+json 966 { 967 "meta" : { 968 "dependent-vtags" : [ 969 {"resource-id": "default-network-map", 970 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 971 ] 972 }, 973 "property-map": { 974 "ipv4:192.0.2.0": {"pid": "pid2"}, 975 "ipv4:192.0.2.16": {"pid": "pid2"}, 976 "ipv4:192.0.2.64": {"pid": "pid1"}, 977 "ipv4:192.0.2.128": {"pid": "defaultpid"}, 978 "ipv4:192.0.2.0/26": {"pid": "pid1"}, 979 "ipv4:192.0.2.0/30": {"pid": "pid2"} 980 } 981 } 983 7.8. Filtered Property Map Example #4 985 The following example uses the Filtered Property Map resource to 986 request the "availbw" property for several abstract network elements. 988 POST /propmap/lookup/availbw HTTP/1.1 989 Host: alto.example.com 990 Accept: application/alto-propmap+json,application/alto-error+json 991 Content-Length: ### 992 Content-Type: application/alto-propmapparams+json 994 { 995 "entities" : [ 996 "ane:L001", 997 "ane:Lae0", 998 "ane:L3eb ], 999 "properties" : [ "availbw" ] 1000 } 1002 HTTP/1.1 200 OK 1003 Content-Length: ### 1004 Content-Type: application/alto-propmap+json 1006 { 1007 "property-map": { 1008 "ane:L001": {"availbw": "55"}, 1009 "ane:Lae0": {"availbw": "70"}, 1010 "ane:L3eb": {"availbw": "40"} 1011 } 1012 } 1014 8. Security Considerations 1016 As discussed in Section 15 of [RFC7285], properties MAY have 1017 sensitive customer-specific information. If this is the case, an 1018 ALTO Server MAY limit access to those properties by providing several 1019 different Property Maps. For non-sensitive properties, the ALTO 1020 Server would provide a URI which accepts requests from any client. 1021 Sensitive properties, on the other hand, would only be available via 1022 a secure URI which would require client authentication. 1024 Also, while technically this document does not introduce any security 1025 risks not inherent in the Endpoint Property Service defined by 1026 [RFC7285], the GET-mode property map resource defined in this 1027 document does make it easier for a client to download large numbers 1028 of property values. Accordingly, an ALTO Server SHOULD limit GET- 1029 mode Property Maps to properties which do not contain sensitive data. 1031 9. IANA Considerations 1033 This document defines additional application/alto-* media types, and 1034 extends the ALTO endpoint property registry. 1036 9.1. application/alto-* Media Types 1038 This document registers two additional ALTO media types, listed in 1039 Table 1. 1041 +--------------+--------------------------+-----------------------+ 1042 | Type | Subtype | Specification | 1043 +--------------+--------------------------+-----------------------+ 1044 | application | alto-propmap+json | Section 4.1 | 1045 | application | alto-propmapparams+json | Section 5.3 | 1046 +--------------+--------------------------+-----------------------+ 1048 Table 1: Additional ALTO Media Types. 1050 Type name: application 1052 Subtype name: This document registers multiple subtypes, as listed 1053 in Table 1. 1055 Required parameters: n/a 1057 Optional parameters: n/a 1059 Encoding considerations: Encoding considerations are identical to 1060 those specified for the "application/json" media type. See 1061 [RFC7159]. 1063 Security considerations: Security considerations related to the 1064 generation and consumption of ALTO Protocol messages are discussed 1065 in Section 15 of [RFC7285]. 1067 Interoperability considerations: This document specifies formats of 1068 conforming messages and the interpretation thereof. 1070 Published specification: This document is the specification for 1071 these media types; see Table 1 for the section documenting each 1072 media type. 1074 Applications that use this media type: ALTO servers and ALTO clients 1075 either stand alone or are embedded within other applications. 1077 Additional information: ~ Magic number(s): ~ n/a File extension(s): ~ 1078 This document uses the mime type to refer to protocol messages and 1079 thus does not require a file extension. Macintosh file type code(s): 1080 ~ n/a 1082 Person & email address to contact for further information: See 1083 Authors' Addresses section. 1085 Intended usage: COMMON 1087 Restrictions on usage: n/a 1089 Author: See Authors' Addresses section. 1091 Change controller: Internet Engineering Task Force 1092 (mailto:iesg@ietf.org). 1094 9.2. ALTO Entity Domain Registry 1096 This document requests IANA to create and maintain the "ALTO Entity 1097 Domain Registry", listed in Table 2. 1099 +-------------+--------------------------+--------------------------+ 1100 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1101 +-------------+--------------------------+--------------------------+ 1102 | ipv4 | See Section 3.1.1 | See Section 3.1.3 | 1103 | ipv6 | See Section 3.1.2 | See Section 3.1.3 | 1104 | pid | See Section 3.2 | None | 1105 | ane | See Section 3.4 | None | 1106 +-------------+--------------------------+--------------------------+ 1108 Table 2: ALTO Entity Domain Names. 1110 This registry serves two purposes. First, it ensures uniqueness of 1111 identifiers referring to ALTO entity domains. Second, it states the 1112 requirements for allocated domain names. 1114 New ALTO entity domains are assigned after IETF Review [RFC5226] to 1115 ensure that proper documentation regarding the new ALTO entity 1116 domains and their security considerations has been provided. RFCs 1117 defining new entity domains SHOULD indicate how an entity in a 1118 registered domain is encoded as an EntityName, and, if applicable, 1119 the rules defining the entity hierarchy and property inheritance. 1120 Updates and deletions of ALTO entity domains follow the same 1121 procedure. 1123 Registered ALTO entity domain identifiers MUST conform to the 1124 syntactical requirements specified in Section 2.3. Identifiers are 1125 to be recorded and displayed as strings. 1127 It is RECOMMANDED that a new ALTO entity domain be registered when 1128 the corresponding address type is registered based on ALTO Address 1129 Type Registry [RFC7285]. 1131 Requests to add a new value to the registry MUST include the 1132 following information: 1134 o Identifier: The name of the desired ALTO entity domain. 1136 o Entity Address Encoding: The procedure for encoding the address of 1137 an entity of the registered type as an EntityAddr (see 1138 Section 2.4). 1140 o Hierarchy: If the entities form a hierarchy, the procedure for 1141 determining that hierarchy. 1143 o Inheritance: If entities can inherit property values from other 1144 entities, the procedure for determining that inheritance. 1146 o Security Considerations: In some usage scenarios, entity addresses 1147 carried in ALTO Protocol messages MAY reveal information about an 1148 ALTO client or an ALTO service provider. Applications and ALTO 1149 service providers using addresses of the registered type SHOULD be 1150 made aware of how (or if) the addressing scheme relates to private 1151 information and network proximity. 1153 This specification requests registration of the identifiers "ipv4", 1154 "ipv6" and "pid", as shown in Table 2. 1156 9.3. ALTO Endpoint Property Type Registry 1158 The ALTO Endpoint Property Type Registry was created by [RFC7285]. 1159 If possible, the name of that registry SHOULD be changed to "ALTO 1160 Entity Property Type Registry", to indicate that it is not restricted 1161 to Endpoint Properties. If it is not feasible to change the name, 1162 the description MUST be amended to indicate that it registers 1163 properties in all domains, rather than just the Internet address 1164 domain. 1166 10. References 1168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1169 Requirement Levels", BCP 14, RFC 2119, 1170 DOI 10.17487/RFC2119, March 1997, . 1173 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1174 Resource Identifier (URI): Generic Syntax", STD 66, 1175 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1176 . 1178 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1179 (CIDR): The Internet Address Assignment and Aggregation 1180 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1181 2006, . 1183 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1184 IANA Considerations Section in RFCs", RFC 5226, 1185 DOI 10.17487/RFC5226, May 2008, . 1188 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1189 Address Text Representation", RFC 5952, 1190 DOI 10.17487/RFC5952, August 2010, . 1193 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1194 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1195 2014, . 1197 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1198 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1199 "Application-Layer Traffic Optimization (ALTO) Protocol", 1200 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1201 . 1203 [I-D.ietf-alto-path-vector] 1204 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 1205 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 1206 Vector Cost Mode", draft-ietf-alto-path-vector-00 (work in 1207 progress), May 2017. 1209 Authors' Addresses 1211 Wendy Roome 1212 Nokia Bell Labs 1213 600 Mountain Ave, Rm 3B-324 1214 Murray Hill, NJ 07974 1215 USA 1217 Phone: +1-908-582-7974 1218 Email: wendy@roome.com 1219 Shiwei Dawn Chen 1220 Tongji University 1221 4800 Caoan Road 1222 Shanghai 201804 1223 China 1225 Email: dawn_chen_f@hotmail.com 1227 Xin (Tony) Wang 1228 Tongji University 1229 4800 CaoAn Road 1230 Shanghai 210000 1231 China 1233 Email: xinwang2014@hotmail.com 1235 Y. Richard Yang 1236 Yale University 1237 51 Prospect Street 1238 New Haven, CT 06511 1239 USA 1241 Phone: +1-203-432-6400 1242 Email: yry@cs.yale.edu 1244 Jingxuan Jensen Zhang 1245 Tongji University 1246 4800 Caoan Road 1247 Shanghai 201804 1248 China 1250 Email: jingxuan.n.zhang@gmail.com