idnits 2.17.1 draft-gao-alto-fcs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 449 has weird spacing: '...DFilter pids;...' == Line 450 has weird spacing: '...DFilter pid-f...' == Line 493 has weird spacing: '...NString addre...' == Line 494 has weird spacing: '...SONBool flo...' == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In practice, a flow with endpoint addresses with different types MAY NOT be valid. For example, a source endpoint with an IPv4 address CANNOT establish a network connection with a destination endpoint with an IPv6 address. Neither can a source with a TCP socket address and a destination with a UDP socket address. -- The document date (March 5, 2018) is 2236 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: 'TODO' is mentioned on line 552, but not defined == Missing Reference: 'TBD' is mentioned on line 674, but not defined == Unused Reference: 'RFC2732' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'OF15' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'OPENFLOW' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 852, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG J. Zhang 3 Internet-Draft Tongji University 4 Intended status: Standards Track K. Gao 5 Expires: September 6, 2018 Tsinghua University 6 J. Wang 7 Tongji University 8 Q. Xiang 9 Tongji/Yale University 10 Y. Yang 11 Yale University 12 March 5, 2018 14 ALTO Extension: Flow-based Cost Query 15 draft-gao-alto-fcs-05.txt 17 Abstract 19 ALTO cost maps and endpoint cost services map a source-destination 20 pair into a cost value. However, current filter specifications, 21 which define the set of source-destination pairs in an ALTO query, 22 have two limitations: 1) Only very limited address types are 23 supported (IPv4 and IPv6), which is not sufficient to uniquely 24 identify a flow in networks with fine-grained routing, such as the 25 emerging Software Defined Networks. 2) The base ALTO protocol only 26 defines filters enumerating all sources and all destinations, leading 27 to redundant information in the response. To address these two 28 issues, this document extends the base ALTO protocol with a more 29 fine-grained filter type which allows ALTO clients to select only the 30 concerned source-destination pairs, and a more expressive address 31 space which allows ALTO clients to make queries beyond the limited IP 32 addresses. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 6, 2018. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Overview of Approaches . . . . . . . . . . . . . . . . . . . 4 78 3.1. Extended Endpoint Address . . . . . . . . . . . . . . . . 5 79 3.2. Flow-based Filter . . . . . . . . . . . . . . . . . . . . 5 80 4. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 5 81 5. Extended Endpoint Address . . . . . . . . . . . . . . . . . . 6 82 5.1. Address Type . . . . . . . . . . . . . . . . . . . . . . 7 83 5.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . 7 84 5.2.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 7 85 5.2.2. Domain Name . . . . . . . . . . . . . . . . . . . . . 8 86 5.2.3. IPv4 Socket Address . . . . . . . . . . . . . . . . . 8 87 5.2.4. IPv6 Socket Address . . . . . . . . . . . . . . . . . 8 88 5.3. Address Type Compatibility . . . . . . . . . . . . . . . 8 89 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 90 6. Extended Cost Query Filters . . . . . . . . . . . . . . . . . 9 91 6.1. Filtered Cost Map Extension . . . . . . . . . . . . . . . 9 92 6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 9 93 6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 10 94 6.2. Endpoint Cost Service Extension . . . . . . . . . . . . . 10 95 6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 96 6.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 11 97 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 98 6.3.1. Information Resource Directory . . . . . . . . . . . 12 99 6.3.2. Flow-based Filtered Cost Map Service . . . . . . . . 13 100 6.3.3. Flow-based Endpoint Cost Service Example . . . . . . 14 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 103 8.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 16 104 8.2. ALTO Address Type Compatibility Registry . . . . . . . . 16 105 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 17 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 108 10.2. Informative References . . . . . . . . . . . . . . . . . 18 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 111 1. Introduction 113 ALTO cost query services (Filtered Cost Map and Endpoint Cost 114 Service) can be regarded as functions transforming a given subset of 115 a specific query space into a network view abstract. However, the 116 current specification has some limitations. 118 First, in the base ALTO protocol [RFC7285], the endpoint cost filter 119 only contains the source and destination IP addresses. In practice, 120 both Internet Service Providers (ISP) and local network 121 administrators MAY conduct policy-based routing, e.g., P2P traffic 122 may be constrained and has a smaller bandwidth than HTTP traffic. 123 Also, web services with different QoS requirements may be hosted on 124 the same machine and have the same IP address but different paths 125 with different QoS metrics. 127 Second, in the base ALTO protocol [RFC7285], the query space is 128 defined by the lists of sources and destinations. For a query with N 129 sources and M destinations, the response contains NM entries. While 130 such a query schema is well suited for peer-to-peer (P2P) 131 applications where files of the same seed are stored on all hosts, it 132 may lead to a lot of redundancy in use cases such as modern data 133 analytics systems where replicas of the same dataset are stored on 134 only a small subset of servers. Consider a system where the number 135 of replicas is 3 (the default in HDFS), jointly scheduling N 136 concurrent transfers only needs a maximum of 3N entries but the base 137 ALTO protocol MAY return up to N^2 entries. 139 Thus, we can conclude that the following additional requirements (AR) 140 MUST be satisfied to allow ALTO clients make more accurate and 141 efficient cost queries. 143 AR-1: ALTO clients SHOULD be able to specify accurate query space in 144 cost query services. 146 The base ALTO protocol only includes IPv4 and IPv6 addresses as 147 endpoint address types, which may not be sufficient to accurately 148 identify an endpoint with emerging flow-based routing mechanisms. 149 ALTO clients MAY suffer from suboptimal decisions because of such 150 inaccuracy. Thus, the ALTO protocol SHOULD be extended so that 151 clients CAN be able to specify accurate query space, i.e., with 152 more fine-grained endpoint address types. 154 AR-2: ALTO clients SHOULD be able to specify only the essential 155 query space in cost query services. 157 Existing PIDFilter (see Sec 11.3.2.3 in [RFC7285]) and 158 EndpointFilter (see Sec 11.5.1.3 in [RFC7285]) represent the 159 cross-product of sources and destinations, and can introduce a lot 160 of redundancy in certain use cases. This limitation CAN greatly 161 harm the scalability of the ALTO protocol. Thus, the ALTO 162 protocol SHOULD be extended so that ALTO clients CAN specify only 163 the essential cost query space, i.e., the concerned source- 164 destination pairs. 166 In this document, we describe an ALTO extension specifying flow-based 167 cost queries. The rest of this document is organized as follows. 168 Section 5 introduces several new address types that extend the query 169 space of ALTO cost services. Section 6 describes the extended schema 170 on Filtered Cost Map (FCM) and Endpoint Cost Service (ECS) to support 171 cost queries of arbitrary source-destination combinations. Section 7 172 and Section 8 discuss security and IANA considerations. 174 2. Terminology 176 This document uses the same terms as defined in [RFC7285] and 177 [RFC8189] with the following additional term: 179 2.1. Flow 181 In this document, a flow refers to all communications between two 182 endpoints. A flow is valid if and only if there CAN be valid 183 communications between the two endpoints, which oftentimes requires 184 that that two endpoint addresses have compatible address types. 186 3. Overview of Approaches 188 This section presents a non-normative overview of the extension to 189 support flow-based cost query. It assumes the readers are familiar 190 with Filtered Cost Map and Endpoint Cost Service defined in [RFC7285] 191 and their extensions defined in [RFC8189]. 193 3.1. Extended Endpoint Address 195 To allow ALTO clients specify accurate query space in cost query 196 services (AR-1), this document defines several new endpoint address 197 types. An endpoint address with a new type is referred to as an 198 extended endpoint address. 200 Since the address types of both the source and the destination 201 correspond to the same network flow, they MUST NOT conflict. This 202 document defines an address type conflict table to indicate 203 conflicts. If some source and destination address types in a query 204 conflict with each others, ALTO servers SHOULD return the 205 corresponding error. 207 3.2. Flow-based Filter 209 To allow ALTO clients specify only the essential query space in cost 210 query services (AR-2), both PIDFilter and EndpointFilter in the base 211 protocol MUST be extended. The extended filters are referred to as 212 flow-based filters. 214 A straight-forward way of satisfying AR-1 is to have an ALTO client 215 list all its concerned flows. Despite its simplicity, it MAY be too 216 large in size, especially when many flows have common sources or 217 common destinations in the query. Also from the implementation's 218 perspective, it cannot reuse the functionality to parse a PIDFilter/ 219 EndpointFilter. 221 Thus, the flow-based filters defined in this document allow ALTO 222 clients to include multiple PIDFilter/EndpointFilter objects in the 223 same query. Apparently, if we replace each PIDFilter/EndpointFilter 224 of N sources and M destinations with NM filters that have exactly one 225 source and destination, the two representations refer to the same set 226 of flows. As a result, one can aggregate flows with common sources 227 or destinations in one PIDFilter/EndpointFilter object without 228 introducing redundant flows. 230 From the implementation's perspective, one MAY reuse an ALTO library 231 which parses PIDFilter/EndpointFilter and/or converts them into a set 232 of source-destination pairs. 234 4. Changes Since Version -01 236 Note to Editor: Please remove this section prior to publication. 238 This section records the change logs of the draft updates. 240 Changes since -04 revision: 242 o Improve the clarity of the document by explicitly stating the 243 problems. 245 o Keep only flow in the terminology section. 247 o Move section 6 Advanced Flow-based Query out of this document. 249 o Change ALTO Address Type Conflicts Registry to ALTO Address Type 250 Compatibility Registry. 252 Changes since older versions: 254 Since -03 revision: 256 o Remove some irrelevant content from the draft. 258 o Improve the description of the new endpoint address type 259 identifier registry. And add a new registry to declare the 260 conflicting address type identifiers. 262 Since -02 revision: 264 o Change "EndpointURI" to "AddressType::EndpointAddr" for 265 consistency. 267 o Replace Cost Confidence by Cost Statistics for compatibility. 269 Since -01 revision: 271 o Define the basic flow-based query extensions for Filtered Cost Map 272 and Endpoint Cost service. The basic flow-based query is downward 273 compatible with the legacy ALTO service. It does not introduce 274 any new media types. 276 o Move the service of media-type application/alto-flowcost+json to 277 the advanced flow-based query extension. It will ask ALTO server 278 to support the new media type. 280 Since -00 revision: 282 o Change the schema of pid-flows and endpoint-flows fields from pair 283 list to pair mesh list. 285 5. Extended Endpoint Address 287 This document registers new address types and defines the 288 corresponding formats for endpoint addresses of each new address 289 type. 291 5.1. Address Type 293 The new AddressType identifiers defined in this document are as 294 follows: 296 eth: An endpoint address with type eth is the address of an Ethernet 297 interface. It is used to uniquely identify an endpoint in the 298 data link layer. 300 domain: An endpoint address with type domain is the domain name of a 301 web service. It is used to uniquely identify a web service which 302 MAY be translated to one or more IPv4 address(es). 304 domain6: An endpoint address with type domain6 is the domain name of 305 a web service. It is used to uniquely identify a web service 306 which MAY be translated to one or more IPv6 address(es). 308 tcp: An endpoint address with type tcp is the address of a TCP 309 socket. It is used to uniquely identify an IPv4 TCP socket in the 310 transport layer. 312 tcp6: An endpoint address with type tcp6 is the address of a TCP 313 socket. It is used to uniquely identify an IPv6 TCP socket in the 314 transport layer. 316 udp: An endpoint address with type udp is the address of a UDP 317 socket. It is used to uniquely identify an IPv4 UDP socket in the 318 transport layer. 320 udp6: An endpoint address with type udp6 is the address of a UDP 321 socket. It is used to uniquely identify an IPv6 UDP socket in the 322 transport layer. 324 5.2. Endpoint Address 326 This document defines EndpointAddr when AddressType is in 327 Section 8.1. 329 5.2.1. MAC Address 331 An Endpoint Address of type eth is encoded as a MAC address, whose 332 format is encoded as specified by either format EUI-48 in [EUI48] or 333 EUI-64 in [EUI64]. 335 5.2.2. Domain Name 337 An Endpoint Address of type domain or domain6 is encoded as a domain 338 name, as specified in Section 11 of [RFC2181]. It MUST have at least 339 one corresponding A (domain) or AAAA (domain6) record in the DNS. 341 5.2.3. IPv4 Socket Address 343 An Endpoint Address of type tcp or udp is encoded as an IPv4 socket 344 address. It is encoded as a string of the format Host:Port with the 345 : character as a separator. The Host component of an IPv4 socket 346 address is encoded as specified by either an IPv4 address (see 347 Section 10.4.3.1 of [RFC7285]) or an IPv4-compatible domain name (see 348 Section 5.2.2). The Port component of an IPv4 socket address is 349 encoded as an integer between 1 and 65535. 351 5.2.4. IPv6 Socket Address 353 An Endpoint Address of type tcp6 or udp6 is encoded as an IPv6 socket 354 address. It is also encoded as a string of the format Host:Port with 355 the : character as a separator. The Host component of an IPv6 socket 356 address is encoded as specified by either an IPv6 address (see 357 Section 10.4.3.2 of [RFC7285]) enclosed in the [" and "] characters 358 or an IPv6-compatible domain name (see Section 5.2.2). The Port 359 component of IPv6 socket address is encoded as an integer between 1 360 and 65535. 362 5.3. Address Type Compatibility 364 In practice, a flow with endpoint addresses with different types MAY 365 NOT be valid. For example, a source endpoint with an IPv4 address 366 CANNOT establish a network connection with a destination endpoint 367 with an IPv6 address. Neither can a source with a TCP socket address 368 and a destination with a UDP socket address. 370 Thus, to explicitly define the compatibility between AddressType 371 identifiers, every ALTO AddressType identifier MUST provide a list of 372 AddressType identifiers that are compatible with it in the ALTO 373 Address Type Compatibility Registry Section 8.2. For all sources and 374 destinations in a PIDFilter/EndpointFilter, if the AddressType 375 identifiers of a given pair DO NOT appear in the ALTO Address Type 376 Compatibility Registry, an ALTO server MUST return an ALTO error 377 response with the error code "E_INVALID_FIELD_VALUE" with optional 378 information to help diagnose the incompatibility. 380 5.4. Examples 382 Some valid endpoint addresses are demonstrated as follows: 384 "eth:98-e0-d9-9c-df-81" 385 "domain:www.example.com" 386 "tcp:198.51.100.34:5123" 387 "udp6:[2000::1:2345:6789:abcd]:8080" 389 6. Extended Cost Query Filters 391 This section describes extensions to [RFC7285] and [RFC8189] to 392 support flow-based cost queries. 394 This document uses the notation rules specified in Section 8.2 of 395 [RFC7285] and also the notation rule for optional fields in Section 4 396 of [RFC8189]. 398 6.1. Filtered Cost Map Extension 400 This document extends the Filtered Cost Map as defined in 401 Section 11.3.2 of [RFC7285] and Section 4.1 of [RFC8189], by adding a 402 new capability and input parameters. 404 The media type, HTTP method, and uses specifications (described in 405 Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively) 406 are unchanged. 408 The response is the same as defined in Section 4.1.3 of [RFC8189]. 410 6.1.1. Capabilities 412 The Filtered Cost Map capabilities are extended with a new member: 414 o flow-based-filter 416 The capability flow-based-filter indicates whether this resource 417 supports flow-based cost queries. The FilteredCostMapCapabilities 418 object in Section 4.1.1 of [RFC8189] is extended as follows: 420 object { 421 JSONString cost-type-names<1..*>; 422 [JSONBool cost-constraints;] 423 [JSONNumber max-cost-types;] 424 [JSONString testable-cost-type-names<1..*>;] 425 [JSONBool flow-based-filter;] 426 } FilteredCostMapCapabilities; 428 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 429 of [RFC7285]. 431 max-cost-types and testable-cost-type-names: As defined in 432 Section 4.1.1 of [RFC8189]. 434 flow-based-filter: If true, an ALTO Server allows a field pid-flows 435 to be included in the requests. If not present, this field MUST 436 be interpreted as if it is false. 438 6.1.2. Accept Input Parameters 440 The ReqFilteredCostMap object in Section 4.1.2 of [RFC8189] is 441 extended as follows: 443 object { 444 [CostType cost-type;] 445 [CostType multi-cost-types<1..*>;] 446 [CostType testable-cost-types<1..*>;] 447 [JSONString constraints<0..*>;] 448 [JSONString or-constraints<1..*><1..*>;] 449 [PIDFilter pids;] 450 [PIDFilter pid-flows<1..*>;] 451 } ReqFilteredCostMap; 453 cost-type, multi-cost-types, testable-cost-types, constraints, or- 454 constraints: As defined in Section 4.1.2 of [RFC8189]. 456 pids: As defined in Section 11.3.2.3 of [RFC7285]. 458 pid-flows: Defined as a list of PIDFilter objects. The ALTO server 459 MUST interpret PID pairs appearing in multiple PIDFilter objects 460 as if they appeared only once. 462 An ALTO client MUST include either pids or pid-flows in a query but 463 MUST NOT include both at the same time. 465 6.2. Endpoint Cost Service Extension 467 This document extends the Endpoint Cost Service as defined in 468 Section 11.5.1 of [RFC7285] and Section 4.2 of [RFC8189], by adding a 469 new capability and input parameters. 471 The media type, HTTP method, and uses specifications (described in 472 Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively) 473 are unchanged. 475 The response is the same as defined in Section 4.2.3 of [RFC8189]. 477 6.2.1. Capabilities 479 The extension to EndpointCostCapabilities includes two new members: 481 o address-types 483 o flow-based-filter 485 Only if the capability "flow-based-filter" is present and its value 486 is "true", the ALTO server supports the flow-based extension for this 487 endpoint cost service. The capability "address-types" indicates 488 which endpoint address types are supported by this resource, it MUST 489 NOT be included if "flow-based-filter" is absent or the value is 490 false. 492 object { 493 [JSONString address-types<0..*>;] 494 [JSONBool flow-based-filter;] 495 } EndpointCostCapabilities : FilteredCostMapCapabilities; 497 flow-based-filter: If true, an ALTO Server MUST accept field 498 "endpoint-flows" in the requests. If not present, this field MUST 499 be interpreted as if it is specified false. 501 address-types: Defines a list of AddressType identifiers encoded as 502 a JSONArray of JSONString. All AddressType identifiers MUST be 503 registered in the "ALTO Address Type Registry" (see Section 14.4 504 of [RFC7285]). An ALTO server SHOULD NOT claim "ipv4" and "ipv6" 505 in this field explicitly, because they are supported by default. 506 If not present, this field MUST be interpreted as if it is an 507 empty array, i.e., the ALTO server only supports the default 508 "ipv4" and "ipv6" address types. 510 6.2.2. Accept Input Parameters 512 The ReqEndpointCostMap object in Section 4.2.2 of [RFC8189] is 513 extended as follows: 515 object { 516 [CostType cost-type;] 517 [CostType multi-cost-types<1..*>;] 518 [CostType testable-cost-types<1..*>;] 519 [JSONString constraints<0..*>;] 520 [JSONString or-constraints<1..*><1..*>;] 521 [EndpointFilter endpoints;] 522 [EndpointFilter endpoint-flows<1..*>;] 523 } ReqEndpointCostMap; 525 cost-type, multi-cost-types, testable-cost-types, constraints, or- 526 constraints: 527 As defined in Section 4.1.2 of [RFC8189]. 529 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 531 endpoint-flows: Defined as a list of EndpointFilter objects. The 532 ALTO server MUST interpret endpoint pairs appearing in multiple 533 EndpointFilter objects as if they appeared only once. 535 If the AddressType of the source and destination in the same 536 EndpointFilter do NOT conform the compatibility rule defined in 537 Table 1 of Section 8.1, an ALTO server MUST return an ALTO error 538 response with the error code "E_INVALID_FIELD_VALUE". 540 An ALTO client MUST specify either "endpoints" or "endpoint-flows", 541 but MUST NOT specify both in the same query. 543 6.3. Examples 545 6.3.1. Information Resource Directory 547 GET /directory HTTP/1.1 548 Host: alto.example.com 549 Accept: application/alto-directory+json,application/alto-error+json 551 HTTP/1.1 200 OK 552 Content-Length: [TODO] 553 Content-Type: application/alto-directory+json 554 { 555 "meta" : { 556 "default-alto-network-map" : "my-default-network-map", 557 "cost-types" : { 558 "num-routingcost" : { 559 "cost-mode" : "numerial", 560 "cost-metric" : "routingcost"}, 561 "ord-routingcost" : { 562 "cost-mode" : "ordinal", 563 "cost-metric" : "routingcost"} 564 }, 565 ..... 566 Other ALTO cost types as described in RFC7285 567 ..... 568 }, 569 "resources" : { 570 "my-default-network-map" : { 571 "uri" : "http://alto.example.com/networkmap", 572 "media-type" : "application/alto-networkmap+json" 574 }, 575 "basic-flow-based-cost-map" : { 576 "uri" : "http://alto.example.com/costmap/multi/filtered", 577 "media-type" : "application/alto-costmap+json", 578 "accepts" : "application/alto-costmapfilter+json", 579 "uses" : [ "my-default-network-map" ], 580 "capabilities" : { 581 "max-cost-types" : 2, 582 "flow-based-filter" : true, 583 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 584 } 585 }, 586 "basic-flow-based-endpoint-cost" : { 587 "uri" : "http://alto.example.com/endpointcost/lookup", 588 "media-type" : "application/alto-endpointcost+json", 589 "accepts" : "application/alto-endpointcostparams+json", 590 "capabilities" : { 591 "protocols": ["tcp", "http"], 592 "flow-based-filter" : true, 593 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 594 } 595 }, 596 "flow-cost-map": { 597 "uri" : "http://alto.example.com/flowcost/lookup", 598 "media-type" : "application/alto-flowcost+json", 599 "accepts" : "application/alto-flowcostparams+json", 600 "capabilities" : { 601 "or-required" : [ [ "ethernet:destination" ], 602 [ "ipv4:destination" ] ], 603 "optional" : [ "ethernet:source", "ethernet:destination", 604 "ipv4:source", "ipv4:destination", 605 "tcp:source", "tcp:destination"] 606 } 607 } 608 } 609 } 611 6.3.2. Flow-based Filtered Cost Map Service 612 POST /costmap/multi/filtered HTTP/1.1 613 Host: alto.example.com 614 Accept: application/alto-costmap+json,application/alto-error+json 615 Content-Length: [TBD] 616 Content-Type: application/alto-costmapfilter+json 618 { 619 "cost-type": { 620 "cost-mode": "numerical", 621 "cost-metric": "routingcost" 622 }, 623 "pid-flows": [ 624 { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, 625 { "srcs": ["PID3"], "dsts": ["PID4"] } 626 ] 627 } 629 HTTP/1.1 200 OK 630 Content-Length: [TBD] 631 Content-Type: application/alto-costmap+json 633 { 634 "meta": { 635 "dependent-vtags": [ 636 { 637 "resource-id": "my-default-network-map", 638 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 639 } 640 ], 641 "cost-type": { 642 "cost-mode": "numerical", 643 "cost-metric": "routingcost" 644 } 645 }, 646 "cost-map": { 647 "PID1": { "PID2": 100 }, 648 "PID1": { "PID3": 20 }, 649 "PID3": { "PID4": 80 } 650 } 651 } 653 6.3.3. Flow-based Endpoint Cost Service Example 654 POST /endpointcost/lookup HTTP/1.1 655 Host: alto.example.com 656 Accept: application/alto-endpointcost+json,application/alto-error+json 657 Content-Length: [TBD] 658 Content-Type: application/alto-endpointcostparams+json 660 { 661 "cost-type": { 662 "cost-mode": "numerical", 663 "cost-metric": "hopcount" 664 }, 665 "endpoint-flows": [ 666 { "srcs": ["ipv4:192.0.2.2"], 667 "dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] }, 668 { "srcs": ["tcp:203.0.113.45:54321"], 669 "dsts": ["http:cdn1.example.com"] } 670 ] 671 } 673 HTTP/1.1 200 OK 674 Content-Length: [TBD] 675 Content-Type: application/alto-endpointcost+json 677 { 678 "meta": { 679 "cost-type": { 680 "cost-mode": "numerical", 681 "cost-metric": "hopcount" 682 } 683 }, 684 "endpoint-cost-map": { 685 "ipv4:192.0.2.2": { 686 "ipv4:192.0.2.89": 3, 687 "http:cdn1.example.com": 6 688 }, 689 "tcp:203.0.113.45:54321": { 690 "http:cdn1.example.com": 10 691 } 692 } 693 } 695 7. Security Considerations 697 As discussed in Section 15.4 of [RFC7285], an ALTO server or a third 698 party who is able to intercept the flow-based cost query messages MAY 699 store and process the obtained information in order to analyze user 700 behaviors and communication patterns. Since flow-based cost queries 701 MAY potentially provide more accurate information, an ALTO client 702 should be cognizant about the trade-off between redundancy and 703 privacy. 705 8. IANA Considerations 707 This document defines new address types to be registered to an 708 existing ALTO registry, and a new registry for their compatible 709 address types. 711 8.1. ALTO Address Type Registry 713 This document defines several new address types to be registered to 714 ALTO Address Type Registry, listed in Table 1. 716 +------------+--------------------+-------------+-------------------+ 717 | Identifier | Address Encoding | Prefix | Mapping to/from | 718 | | | Encoding | IPv4/v6 | 719 +------------+--------------------+-------------+-------------------+ 720 | eth | See Section 5.2.1 | None | Mapping to/from | 721 | | | | IPv4 by [RFC0903] | 722 | | | | and [RFC0826]; | 723 | | | | Mapping to/from | 724 | | | | IPv6 by [RFC3122] | 725 | | | | and [RFC4861] | 726 | domain | See Section 5.2.2 | None | Mapping to/from | 727 | | | | IPv4 by [RFC1034] | 728 | domain6 | See Section 5.2.2 | None | Mapping to/from | 729 | | | | IPv6 by [RFC3596] | 730 | tcp | See Section 5.2.3 | None | No mapping | 731 | tcp6 | See Section 5.2.4 | None | No mapping | 732 | upd | See Section 5.2.3 | None | No mapping | 733 | udp6 | See Section 5.2.4 | None | No mapping | 734 +------------+--------------------+-------------+-------------------+ 736 Table 1: ALTO Address Type Registry 738 8.2. ALTO Address Type Compatibility Registry 740 This document proposes to create a new registry called ALTO Address 741 Type Compatibility Registry, whose purpose is stated in Section 5.3. 743 The compatible address type identifiers of the ones registered in the 744 ALTO Address Type Registry are listed in Table 2. 746 +-------------+-------------------------+ 747 | Identifier | Compatible Identifiers | 748 +-------------+-------------------------+ 749 | eth | ipv4, ipv6 | 750 | domain | eth, ipv4 | 751 | domain6 | eth, ipv6 | 752 | tcp | eth, ipv4, domain | 753 | tcp6 | eth, ipv6, domain6 | 754 | udp | eth, ipv4, domain | 755 | udp6 | eth, ipv6, domain6 | 756 +-------------+-------------------------+ 758 Table 2: ALTO Address Type Compatibility Registry 760 The entry of an address type identifier SHOULD only include the 761 identifiers registered before it. The compatibility between address 762 types are bidirectional. For example, although "eth" does not 763 register "tcp" as its compatible identifier, an ALTO server MUST 764 recognize them as compatible because eth is registered as a 765 compatible identifier of "tcp". 767 Any new ALTO address type identifier registered after this document 768 MUST register their compatible identifiers in this registry 769 simultaneously. 771 9. Acknowledgment 773 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 774 Randriamasy and Wendy Roome for their fruitful discussions and 775 feedback on this document. Shawn Lin also gave substantial review 776 feedback and suggestions on the protocol design. 778 10. References 780 10.1. Normative References 782 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 783 Converting Network Protocol Addresses to 48.bit Ethernet 784 Address for Transmission on Ethernet Hardware", STD 37, 785 RFC 826, DOI 10.17487/RFC0826, November 1982, 786 . 788 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 789 Reverse Address Resolution Protocol", STD 38, RFC 903, 790 DOI 10.17487/RFC0903, June 1984, . 793 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 794 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 795 . 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, 799 DOI 10.17487/RFC2119, March 1997, . 802 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 803 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 804 . 806 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 807 Literal IPv6 Addresses in URL's", RFC 2732, 808 DOI 10.17487/RFC2732, December 1999, . 811 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 812 Inverse Discovery Specification", RFC 3122, 813 DOI 10.17487/RFC3122, June 2001, . 816 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 817 "DNS Extensions to Support IP Version 6", STD 88, 818 RFC 3596, DOI 10.17487/RFC3596, October 2003, 819 . 821 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 822 Resource Identifier (URI): Generic Syntax", STD 66, 823 RFC 3986, DOI 10.17487/RFC3986, January 2005, 824 . 826 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 827 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 828 DOI 10.17487/RFC4861, September 2007, . 831 10.2. Informative References 833 [EUI48] IEEE, , "Guidelines for use of a 48-bit Extended Unique 834 Identifier (EUI-48)", 2012, 835 . 837 [EUI64] IEEE, , "Guidelines for use of a 64-bit Extended Unique 838 Identifier (EUI-64)", November 2012, 839 . 841 [OF15] Foundation, O., "OpenFlow Switch Specification v1.5.0", 842 2014, 843 . 847 [OPENFLOW] 848 McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 849 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 850 "OpenFlow: enabling innovation in campus networks", 2008. 852 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 853 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 854 2014, . 856 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 857 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 858 "Application-Layer Traffic Optimization (ALTO) Protocol", 859 RFC 7285, DOI 10.17487/RFC7285, September 2014, 860 . 862 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 863 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 864 DOI 10.17487/RFC8189, October 2017, . 867 Authors' Addresses 869 Jingxuan Jensen Zhang 870 Tongji University 871 4800 Cao'an Hwy 872 Shanghai 201804 873 China 875 Email: jingxuan.n.zhang@gmail.com 877 Kai Gao 878 Tsinghua University 879 30 Shuangqinglu Street 880 Beijing 100084 881 China 883 Email: gaok12@mails.tsinghua.edu.cn 884 Junzhuo Austin Wang 885 Tongji University 886 4800 Cao'an Hwy, Jiading District 887 Shanghai 888 China 890 Email: wangjunzhuo200@gmail.com 892 Qiao Xiang 893 Tongji/Yale University 894 51 Prospect Street 895 New Haven, CT 896 USA 898 Email: qiao.xiang@cs.yale.edu 900 Y. Richard Yang 901 Yale University 902 51 Prospect St 903 New Haven CT 904 USA 906 Email: yry@cs.yale.edu