idnits 2.17.1 draft-gao-alto-fcs-06.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 534 has weird spacing: '...DFilter pid-f...' == Line 605 has weird spacing: '...SONBool flo...' == Line 606 has weird spacing: '...NString addre...' == Line 607 has weird spacing: '...NString flow-...' == Line 639 has weird spacing: '...tFilter end...' == 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 (July 2, 2018) is 2123 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: 'TBD' is mentioned on line 917, but not defined == Unused Reference: 'RFC2732' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 1103, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-03 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 13 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: January 3, 2019 Tsinghua University 6 J. Wang 7 Tongji University 8 Q. Xiang 9 Tongji/Yale University 10 Y. Yang 11 Yale University 12 July 2, 2018 14 ALTO Extension: Flow-based Cost Query 15 draft-gao-alto-fcs-06.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; 3) Cannot distinguish 28 transmission types of flows in the query, which makes the server hard 29 to respond the accurate resource consumption. To address these three 30 issues, this document extends the base ALTO protocol with a more 31 fine-grained filter type which allows ALTO clients to select only the 32 concerned source-destination pairs and announce the flow-specific 33 information like data transmission type, and a more expressive 34 address space which allows ALTO clients to make queries beyond the 35 limited IP addresses. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 3, 2019. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2.2. Data Transmission Type . . . . . . . . . . . . . . . . . 5 81 3. Overview of Approaches . . . . . . . . . . . . . . . . . . . 5 82 3.1. Extended Endpoint Address . . . . . . . . . . . . . . . . 5 83 3.2. Flow-based Filter . . . . . . . . . . . . . . . . . . . . 6 84 3.3. Flow-specific Announcement . . . . . . . . . . . . . . . 6 85 4. Change Logs . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 5. Extended Endpoint Address . . . . . . . . . . . . . . . . . . 8 87 5.1. Address Type . . . . . . . . . . . . . . . . . . . . . . 8 88 5.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . 9 89 5.2.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 9 90 5.2.2. Internet Domain Name . . . . . . . . . . . . . . . . 9 91 5.2.3. IPv4 Socket Address . . . . . . . . . . . . . . . . . 9 92 5.2.4. IPv6 Socket Address . . . . . . . . . . . . . . . . . 9 93 5.3. Address Type Compatibility . . . . . . . . . . . . . . . 10 94 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 95 6. Extended Cost Query Filters . . . . . . . . . . . . . . . . . 10 96 6.1. Filtered Cost Map Extension . . . . . . . . . . . . . . . 10 97 6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 98 6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 11 99 6.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 100 6.3. Endpoint Cost Service Extension . . . . . . . . . . . . . 12 101 6.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 13 102 6.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 14 103 6.4. Response . . . . . . . . . . . . . . . . . . . . . . . . 15 104 6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 105 6.5.1. Information Resource Directory . . . . . . . . . . . 15 106 6.5.2. Flow-based Filtered Cost Map Example . . . . . . . . 17 107 6.5.3. Flow-based Endpoint Cost Service Example #1 . . . . . 18 108 6.5.4. Flow-based Endpoint Cost Service Example #2 . . . . . 19 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 111 8.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 22 112 8.2. ALTO Address Type Compatibility Registry . . . . . . . . 22 113 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 23 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 116 10.2. Informative References . . . . . . . . . . . . . . . . . 24 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 119 1. Introduction 121 Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] 122 defines several cost query services, like Filtered Cost Map and 123 Endpoint Cost Service, to allow applications to query path costs. 124 Generally, ALTO cost query services can be regarded as functions 125 transforming a given subset of a specific query space into a network 126 view abstract. However, the current specification has some 127 limitations. 129 First, in the base ALTO protocol [RFC7285], the endpoint cost filter 130 only contains the source and destination IP addresses. In practice, 131 both Internet Service Providers (ISP) and local network 132 administrators may conduct policy-based routing, e.g., P2P traffic 133 may be constrained and has a smaller bandwidth than HTTP traffic. 134 Also, web services with different QoS requirements may be hosted on 135 the same machine and have the same IP address but different paths 136 with different QoS metrics. 138 Second, in the base ALTO protocol [RFC7285], the query space is 139 defined by the lists of sources and destinations. For a query with N 140 sources and M destinations, the response contains N*M entries. While 141 such a query schema is well suited for peer-to-peer (P2P) 142 applications where files of the same seed are stored on all hosts, it 143 may lead to a lot of redundancy in use cases such as modern data 144 analytics systems where replicas of the same dataset are stored on 145 only a small subset of servers. Consider a system where the number 146 of replicas is 3 (the default in HDFS), jointly scheduling N 147 concurrent transfers only needs a maximum of 3N entries but the base 148 ALTO protocol may return up to N^2 entries. 150 Third, in the base ALTO protocol [RFC7285], the query does not 151 distinguish among the different transmission types like unicast and 152 multicast. For some use cases like the multi-flow scheduling 153 demonstrated by [I-D.ietf-alto-path-vector], the data transmission 154 between endpoints could be beyond unicast. And in those cases, 155 different transmission types may affect the network resource 156 consumption. If applications can receive the path costs 157 distinguishing the different transmission types, it can help 158 applications perform their data transmission decision better. 160 Thus, we conclude that the following additional requirements (AR) 161 MUST be satisfied to allow ALTO clients make more accurate and 162 efficient cost queries. 164 AR-1: The ALTO server SHOULD allow the ALTO client to specify 165 accurate query space in cost query services. 167 The base ALTO protocol only includes IPv4 and IPv6 addresses as 168 endpoint address types, which may not be sufficient to accurately 169 identify an endpoint with emerging flow-based routing mechanisms. 170 ALTO clients MAY suffer from suboptimal decisions because of such 171 inaccuracy. Thus, the ALTO protocol SHOULD be extended so that 172 clients are able to specify accurate query space, i.e., with more 173 fine-grained endpoint address types. 175 AR-2: The ALTO server SHOULD allow the ALTO client to specify only 176 the essential query space in cost query services. 178 Existing PIDFilter (see Sec 11.3.2.3 in [RFC7285]) and 179 EndpointFilter (see Sec 11.5.1.3 in [RFC7285]) represent the 180 cross-product of sources and destinations, and can introduce a lot 181 of redundancy in certain use cases. This limitation greatly harms 182 the scalability of the ALTO protocol. Thus, the ALTO protocol 183 SHOULD be extended so that ALTO clients are able to specify only 184 the essential cost query space, i.e., the concerned source- 185 destination pairs. 187 AR-3: The ALTO server SHOULD allow the ALTO client to specify 188 different data transmission types for transimissions in the query 189 space. 191 The input parameters of existing ALTO cost query services only 192 allow the ALTO client to specify the queried transmissions by 193 sources and destinations. The transmission between each source 194 and destination will always be considered as the unicast. This 195 limitaiton may make the ALTO client lose the accurate available 196 resources. Thus, the ALTO protocol SHOULD be extended so that 197 ALTO clients are able to speicfy different transmission types. 199 In this document, we describe an ALTO extension specifying flow-based 200 cost queries. The rest of this document is organized as follows. 201 Section 5 introduces several new address types that extend the query 202 space of ALTO cost services. Section 6 describes the extended schema 203 on Filtered Cost Map (FCM) and Endpoint Cost Service (ECS) to support 204 cost queries of arbitrary source-destination combinations with the 205 optional flow-specific information. Section 7 and Section 8 discuss 206 security and IANA considerations. 208 2. Terminology 210 This document uses the same terms as defined in [RFC7285] and 211 [RFC8189] with the following additional term: 213 2.1. Flow 215 In this document, a flow refers to all communications between two 216 endpoints. A flow is "valid" if and only if there CAN be valid 217 communications between the two endpoints, which oftentimes requires 218 that that two endpoint addresses have compatible address types. 220 2.2. Data Transmission Type 222 This document use the term "Data Transmission Type" or "Transmission 223 Type" to indicate the method of applications send the network flows. 224 It can be unicast, broadcast or multicast. 226 3. Overview of Approaches 228 This section presents a non-normative overview of the extension to 229 support flow-based cost query. It assumes the readers are familiar 230 with Filtered Cost Map and Endpoint Cost Service defined in [RFC7285] 231 and their extensions defined in [RFC8189]. 233 3.1. Extended Endpoint Address 235 To allow ALTO clients specify accurate query space in cost query 236 services (AR-1), this document defines several new endpoint address 237 types. An endpoint address with a new type is referred to as an 238 extended endpoint address. 240 Since the address types of both the source and the destination 241 correspond to the same network flow, they MUST NOT conflict. This 242 document defines an address type conflict table to indicate 243 conflicts. If some source and destination address types in a query 244 conflict with each others, ALTO servers SHOULD return the 245 corresponding error. 247 3.2. Flow-based Filter 249 To allow ALTO clients specify only the essential query space in cost 250 query services (AR-2), both PIDFilter and EndpointFilter in the base 251 protocol MUST be extended. The extended filters are referred to as 252 flow-based filters. 254 A straight-forward way of satisfying AR-1 is to have an ALTO client 255 list all its concerned flows. Despite its simplicity, it MAY be too 256 large in size, especially when many flows have common sources or 257 common destinations in the query. Also from the implementation's 258 perspective, it cannot reuse the functionality to parse a PIDFilter/ 259 EndpointFilter. 261 Thus, the flow-based filters defined in this document allow ALTO 262 clients to include multiple PIDFilter/EndpointFilter objects in the 263 same query. Apparently, if we replace each PIDFilter/EndpointFilter 264 of N sources and M destinations with NM filters that have exactly one 265 source and destination, the two representations refer to the same set 266 of flows. As a result, one can aggregate flows with common sources 267 or destinations in one PIDFilter/EndpointFilter object without 268 introducing redundant flows. 270 From the implementation's perspective, one MAY reuse an ALTO library 271 which parses PIDFilter/EndpointFilter and/or converts them into a set 272 of source-destination pairs. 274 3.3. Flow-specific Announcement 276 Some informations are flow-specific and hard to be encoded into 277 endpoints, e.g., the data transmission type of a flow. These 278 informations may help the ALTO client get more accurate costs. 280 To allow the ALTO client to specify these informations (AR-3), this 281 document introduces an extensible field in the flow-based filter. 282 The ALTO client can announce the flow-specific information in this 283 field. The announcement can be transmission type, equal cost 284 multipath assumption and other kinds of flow-specific information. 286 This document adopts an extensible design for this announcement 287 field. Although only the data transmission type is defined in this 288 document, more supported information in the announcement can be 289 defined in the future documents. And how to interpret those 290 informations depends on the implementation. It is not in the scope 291 of this document. 293 4. Change Logs 295 Note to Editor: Please remove this section prior to publication. 297 This section records the change logs of the draft updates. 299 Changes since -05 revision: 301 o Add flow-specific information announcement in the flow-based 302 filter. 304 o Modify examples and add descriptions to Make them clear. 306 o Rename the address type "Domain Name" to "Internet Domain Name" to 307 distinguish it with the "Domain Name" in the unified properties 308 draft. 310 Changes since older versions: 312 Changes since -04 revision: 314 o Improve the clarity of the document by explicitly stating the 315 problems. 317 o Keep only "flow" in the terminology section. 319 o Move section 6 "Advanced Flow-based Query" out of this document. 321 o Change "ALTO Address Type Conflicts Registry" to "ALTO Address 322 Type Compatibility Registry". 324 Since -03 revision: 326 o Remove some irrelevant content from the draft. 328 o Improve the description of the new endpoint address type 329 identifier registry. And add a new registry to declare the 330 conflicting address type identifiers. 332 Since -02 revision: 334 o Change "EndpointURI" to "AddressType::EndpointAddr" for 335 consistency. 337 o Replace "Cost Confidence" by "Cost Statistics" for compatibility. 339 Since -01 revision: 341 o Define the basic flow-based query extensions for Filtered Cost Map 342 and Endpoint Cost service. The basic flow-based query is downward 343 compatible with the legacy ALTO service. It does not introduce 344 any new media types. 346 o Move the service of media-type "application/alto-flowcost+json" to 347 the advanced flow-based query extension. It will ask ALTO server 348 to support the new media type. 350 Since -00 revision: 352 o Change the schema of "pid-flows" and "endpoint-flows" fields from 353 pair list to pair mesh list. 355 5. Extended Endpoint Address 357 This document registers new address types and defines the 358 corresponding formats for endpoint addresses of each new address 359 type. 361 5.1. Address Type 363 The new AddressType identifiers defined in this document are as 364 follows: 366 eth: An endpoint address with type "eth" is the address of an 367 Ethernet interface. It is used to uniquely identify an endpoint 368 in the data link layer. 370 domain: An endpoint address with type "domain" is the domain name of 371 a web service. It is used to uniquely identify a web service 372 which MAY be translated to one or more IPv4 address(es). 374 domain6: An endpoint address with type "domain6" is the domain name 375 of a web service. It is used to uniquely identify a web service 376 which MAY be translated to one or more IPv6 address(es). 378 tcp: An endpoint address with type "tcp" is the address of a TCP 379 socket. It is used to uniquely identify an IPv4 TCP socket in the 380 transport layer. 382 tcp6: An endpoint address with type "tcp6" is the address of a TCP 383 socket. It is used to uniquely identify an IPv6 TCP socket in the 384 transport layer. 386 udp: An endpoint address with type "udp" is the address of a UDP 387 socket. It is used to uniquely identify an IPv4 UDP socket in the 388 transport layer. 390 udp6: An endpoint address with type "udp6" is the address of a UDP 391 socket. It is used to uniquely identify an IPv6 UDP socket in the 392 transport layer. 394 5.2. Endpoint Address 396 This document defines EndpointAddr when AddressType is in 397 Section 8.1. 399 5.2.1. MAC Address 401 An Endpoint Address of type "eth" is encoded as a MAC address, whose 402 format is encoded as specified by either format EUI-48 in [EUI48] or 403 EUI-64 in [EUI64]. 405 5.2.2. Internet Domain Name 407 An Endpoint Address of type "domain" or "domain6" is encoded as a 408 domain name in the Internet, as specified in Section 11 of [RFC2181]. 409 It MUST have at least one corresponding A ("domain") or AAAA 410 ("domain6") record in the DNS. 412 5.2.3. IPv4 Socket Address 414 An Endpoint Address of type "tcp" or "udp" is encoded as an IPv4 415 socket address. It is encoded as a string of the format Host:Port 416 with the ":" character as a separator. The Host component of an IPv4 417 socket address is encoded as specified by either an IPv4 address (see 418 Section 10.4.3.1 of [RFC7285]) or an IPv4-compatible domain name (see 419 Section 5.2.2). The Port component of an IPv4 socket address is 420 encoded as an integer between 1 and 65535. 422 5.2.4. IPv6 Socket Address 424 An Endpoint Address of type "tcp6" or "udp6" is encoded as an IPv6 425 socket address. It is also encoded as a string of the format 426 Host:Port with the ":" character as a separator. The Host component 427 of an IPv6 socket address is encoded as specified by either an IPv6 428 address (see Section 10.4.3.2 of [RFC7285]) enclosed in the "[" and 429 "]" characters or an IPv6-compatible domain name (see Section 5.2.2). 430 The Port component of IPv6 socket address is encoded as an integer 431 between 1 and 65535. 433 5.3. Address Type Compatibility 435 In practice, a flow with endpoint addresses with different types MAY 436 NOT be valid. For example, a source endpoint with an IPv4 address 437 CANNOT establish a network connection with a destination endpoint 438 with an IPv6 address. Neither can a source with a TCP socket address 439 and a destination with a UDP socket address. 441 Thus, to explicitly define the compatibility between AddressType 442 identifiers, every ALTO AddressType identifier MUST provide a list of 443 AddressType identifiers that are compatible with it in the "ALTO 444 Address Type Compatibility Registry" Section 8.2. For all sources 445 and destinations in a PIDFilter/EndpointFilter, if the AddressType 446 identifiers of a given pair DO NOT appear in the ALTO Address Type 447 Compatibility Registry, an ALTO server MUST return an ALTO error 448 response with the error code "E_INVALID_FIELD_VALUE" with optional 449 information to help diagnose the incompatibility. 451 5.4. Examples 453 Some valid endpoint addresses are demonstrated as follows: 455 "eth:98-e0-d9-9c-df-81" 456 "domain:www.example.com" 457 "tcp:198.51.100.34:5123" 458 "udp6:[2000::1:2345:6789:abcd]:8080" 460 6. Extended Cost Query Filters 462 This section describes extensions to [RFC7285] and [RFC8189] to 463 support flow-based cost queries. 465 This document uses the notation rules specified in Section 8.2 of 466 [RFC7285] and also the notation rule for optional fields in Section 4 467 of [RFC8189]. 469 6.1. Filtered Cost Map Extension 471 This document extends the Filtered Cost Map as defined in 472 Section 11.3.2 of [RFC7285] and Section 4.1 of [RFC8189], by adding a 473 new capability and input parameters. 475 The media type, HTTP method, and "uses" specifications (described in 476 Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively) 477 are unchanged. 479 The format of the response is the same as defined in Section 4.1.3 of 480 [RFC8189]. But this document recommends how to generate the response 481 based on the extended input parameters. 483 6.1.1. Capabilities 485 The Filtered Cost Map capabilities are extended with two additional 486 members: 488 o flow-based-filter 490 o flow-spec-announce 492 The capability "flow-based-filter" indicates whether this resource 493 supports flow-based cost queries, and the capability "flow-spec- 494 announce" indicates which flow-specific announcements are supported. 495 The FilteredCostMapCapabilities object in Section 4.1.1 of [RFC8189] 496 is extended as follows: 498 object { 499 JSONString cost-type-names<1..*>; 500 [JSONBool cost-constraints;] 501 [JSONNumber max-cost-types;] 502 [JSONString testable-cost-type-names<1..*>;] 503 [JSONBool flow-based-filter;] 504 [JSONString flow-spec-announce<1..*>;] 505 } FilteredCostMapCapabilities; 507 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 508 of [RFC7285]. 510 max-cost-types and testable-cost-type-names: As defined in 511 Section 4.1.1 of [RFC8189]. 513 flow-based-filter: If true, an ALTO Server allows a field "pid- 514 flows" to be included in the requests. If not present, this field 515 MUST be interpreted as if it is false. 517 flow-spec-announce: It MUST NOT be present if "flow-based-filter" is 518 not true. If present, the value is the an array of supported flow 519 specific announcement field. In this document, only 520 "transmission-type" is defined. 522 6.1.2. Accept Input Parameters 524 The ReqFilteredCostMap object in Section 4.1.2 of [RFC8189] is 525 extended as follows: 527 object { 528 [CostType cost-type;] 529 [CostType multi-cost-types<1..*>;] 530 [CostType testable-cost-types<1..*>;] 531 [JSONString constraints<0..*>;] 532 [JSONString or-constraints<1..*><1..*>;] 533 [PIDFilter pids;] 534 [ExtPIDFilter pid-flows<1..*>;] 535 } ReqFilteredCostMap; 537 object { 538 [JSONObject flow-spec-announce;] 539 } ExtPIDFilter : PIDFilter; 541 cost-type, multi-cost-types, testable-cost-types, constraints, or- 542 constraints: As defined in Section 4.1.2 of [RFC8189]. 544 pids: As defined in Section 11.3.2.3 of [RFC7285]. 546 pid-flows: Defined as a list of ExtPIDFilter objects. The ALTO 547 server MUST interpret PID pairs appearing in multiple ExtPIDFilter 548 objects as if they appeared only once. If the capability "flow- 549 spec-announce" is present, the "flow-spec-announce" input 550 parameter can be specified. The value of this field is a 551 JSONObject. Each key of this JSONObject MUST be chosen from the 552 list specified by the capability "flow-spec-announce", and the 553 value of each key depends on the key itself. 555 An ALTO client MUST include either "pids" or "pid-flows" in a query 556 but MUST NOT include both at the same time. 558 6.2. Response 560 This document does not change the format of the response entity. But 561 the ALTO server responds the request with "pid-flows" filter as 562 follows: 564 The ALTO server MUST include the path costs of pairs in each 565 ExtPIDFilter in the "pid-flows" filter. If the "flow-spec-announce" 566 field is specified in some ExtPIDFilter, the path costs for flows in 567 this ExtPIDFilter SHOULD respond the flow-specific information 568 announced by this field. 570 6.3. Endpoint Cost Service Extension 572 This document extends the Endpoint Cost Service as defined in 573 Section 11.5.1 of [RFC7285] and Section 4.2 of [RFC8189], by adding a 574 new capability and input parameters. 576 The media type, HTTP method, and "uses" specifications (described in 577 Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively) 578 are unchanged. 580 The format of the response is the same as defined in Section 4.2.3 of 581 [RFC8189]. But this document recommends how to generate the response 582 based on the extended input parameters. 584 6.3.1. Capabilities 586 The extension to EndpointCostCapabilities includes three additional 587 members: 589 o flow-based-filter 591 o address-types 593 o flow-spec-announce 595 Only if the capability "flow-based-filter" is present and its value 596 is "true", the ALTO server supports the flow-based extension for this 597 endpoint cost service. The capability "address-types" indicates 598 which endpoint address types are supported by this resource, it MUST 599 NOT be specified if "flow-based-filter" is absent or the value is 600 false. The capability "flow-spec-announce" indicates which flow- 601 specific announcements are supported, just like it works in the 602 Filtered Cost Map resource. 604 object { 605 [JSONBool flow-based-filter;] 606 [JSONString address-types<0..*>;] 607 [JSONString flow-spec-announce<1..*>;] 608 } EndpointCostCapabilities : FilteredCostMapCapabilities; 610 flow-based-filter: If true, an ALTO Server MUST accept field 611 "endpoint-flows" in the requests. If not present, this field MUST 612 be interpreted as if it is specified false. 614 address-types: Defines a list of AddressType identifiers encoded as 615 a JSONArray of JSONString. All AddressType identifiers MUST be 616 registered in the "ALTO Address Type Registry" (see Section 14.4 617 of [RFC7285]). An ALTO server SHOULD NOT claim "ipv4" and "ipv6" 618 in this field explicitly, because they are supported by default. 619 If not present, this field MUST be interpreted as if it is an 620 empty array, i.e., the ALTO server only supports the default 621 "ipv4" and "ipv6" address types. 623 flow-spec-announce: It MUST NOT be present if "flow-based-filter" is 624 not true. If present, the value is the an array of supported flow 625 specific announcement field. In this document, only 626 "transmission-type" is defined. 628 6.3.2. Accept Input Parameters 630 The ReqEndpointCostMap object in Section 4.2.2 of [RFC8189] is 631 extended as follows: 633 object { 634 [CostType cost-type;] 635 [CostType multi-cost-types<1..*>;] 636 [CostType testable-cost-types<1..*>;] 637 [JSONString constraints<0..*>;] 638 [JSONString or-constraints<1..*><1..*>;] 639 [EndpointFilter endpoints;] 640 [ExtEndpointFilter endpoint-flows<1..*>;] 641 } ReqEndpointCostMap; 643 object { 644 [JSONObject flow-spec-announce;] 645 } ExtEndpointFilter : EndpiontFilter; 647 cost-type, multi-cost-types, testable-cost-types, constraints, or- 648 constraints: 649 As defined in Section 4.1.2 of [RFC8189]. 651 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 653 endpoint-flows: Defined as a list of ExtEndpointFilter objects. The 654 ALTO server MUST interpret endpoint pairs appearing in multiple 655 ExtEndpointFilter objects as if they appeared only once. If the 656 capability "flow-spec-announce" is present, the "flow-spec- 657 announce" input parameter can be specified. The value of this 658 field is a JSONObject. Each key of this JSONObject MUST be chosen 659 from the list specified by the capability "flow-spec-announce", 660 and the value of each key depends on the key itself. 662 If the AddressType of the source and destination in the same 663 EndpointFilter do not conform the compatibility rule defined in 664 Table 1 of Section 8.1, an ALTO server MUST return an ALTO error 665 response with the error code "E_INVALID_FIELD_VALUE". 667 An ALTO client MUST specify either "endpoints" or "endpoint-flows", 668 but MUST NOT specify both in the same query. 670 6.4. Response 672 This document does not change the format of the response entity. But 673 the ALTO server responds the request with "pid-flows" filter as 674 follows: 676 The ALTO server MUST include the path costs of pairs in each 677 ExtPIDFilter in the "pid-flows" filter. If the "flow-spec-announce" 678 field is specified in some ExtPIDFilter, the path costs for flows in 679 this ExtPIDFilter SHOULD respond the flow-specific information 680 announced by this field. Especially, if "transmission-type" is 681 specified as "multicast", the ALTO server SHOULD expose all the 682 destination address as a multicast group address, and append the 683 shared trees to the multicast destination addresses into the response 684 if possible. 686 6.5. Examples 688 6.5.1. Information Resource Directory 690 The following is an example of IRD with relevant resources of the 691 ALTO server. It provides a default network map, a property map of 692 "ane" domain, a filtered cost map and two endpoint cost resources. 693 All of three cost query resources (filtered cost map and endpoint 694 cost resources) support "flow-based-filter". One endpoint cost 695 resource support "flow-spec-announce" and the compound query 696 extension defined in . 698 Examples followed this section use the same IRD in this document. 700 GET /directory HTTP/1.1 701 Host: alto.example.com 702 Accept: application/alto-directory+json, 703 application/alto-error+json 705 HTTP/1.1 200 OK 706 Content-Length: [TBD] 707 Content-Type: application/alto-directory+json 709 { 710 "meta" : { 711 "default-alto-network-map" : "my-default-network-map", 712 "cost-types" : { 713 "num-hopcount" : { 714 "cost-mode" : "numerial", 715 "cost-metric" : "hopcount"}, 716 "num-routingcost" : { 717 "cost-mode" : "numerial", 718 "cost-metric" : "routingcost"}, 719 "ord-routingcost" : { 720 "cost-mode" : "ordinal", 721 "cost-metric" : "routingcost"}, 722 "path-vector" : { 723 "cost-mode" : "array", 724 "cost-metric" : "ane-path"} 725 }, 726 ..... 727 Other ALTO cost types as described in RFC7285 728 ..... 729 }, 730 "resources" : { 731 "my-default-network-map" : { 732 "uri" : "http://alto.example.com/networkmap", 733 "media-type" : "application/alto-networkmap+json" 734 }, 735 "propmap-availbw": { 736 "uri": "http://alto.exmaple.com/propmap/ane-prop", 737 "media-type": "application/alto-propmap+json", 738 "accepts": "application/alto-propmapparams+json", 739 "capabilities": { 740 "domain-types": [ "ane" ], 741 "prop-types": [ "availbw" ] 742 }, 743 "uses": [ "path-vector-endpoint-cost" ] 744 } 745 "flow-based-cost-map" : { 746 "uri" : "http://alto.example.com/costmap/multi/filtered", 747 "media-type" : "application/alto-costmap+json", 748 "accepts" : "application/alto-costmapfilter+json", 749 "uses" : [ "my-default-network-map" ], 750 "capabilities" : { 751 "max-cost-types" : 2, 752 "flow-based-filter" : true, 753 "cost-type-names" : [ "num-hopcount", 754 "num-routingcost" ] 755 } 756 }, 757 "flow-based-endpoint-cost" : { 758 "uri" : "http://alto.example.com/endpointcost/lookup", 759 "media-type" : "application/alto-endpointcost+json", 760 "accepts" : "application/alto-endpointcostparams+json", 761 "capabilities" : { 762 "address-types": ["tcp", "udp"], 763 "flow-based-filter" : true, 764 "cost-type-names" : [ "ord-routingcost", 765 "num-routingcost" ] 767 } 768 }, 769 "path-vector-endpoint-cost" : { 770 "uri" : "http://alto.example.com/pathvector/lookup", 771 "media-type" : "application/alto-endpointcost+json", 772 "accepts" : "application/alto-endpointcostparams+json", 773 "capabilities" : { 774 "address-types": ["tcp", "tcp6"], 775 "flow-based-filter" : true, 776 "cost-type-names" : [ "path-vector" ], 777 "flow-spec-announce" : [ "transmission-type" ], 778 "dependent-property-map" : "propmap-availbw", 779 "allow-compound-response" : true 780 } 781 } 782 } 783 } 785 6.5.2. Flow-based Filtered Cost Map Example 787 This example shows how an ALTO client requests a filtered cost map 788 using the "pid-flows" filter. In this case, the ALTO client receives 789 a sparse cost map, which cuts 50% useless cost values from the full 790 mesh. 792 POST /costmap/multi/filtered HTTP/1.1 793 Host: alto.example.com 794 Accept: application/alto-costmap+json, 795 application/alto-error+json 796 Content-Length: [TBD] 797 Content-Type: application/alto-costmapfilter+json 799 { 800 "cost-type": { 801 "cost-mode": "numerical", 802 "cost-metric": "routingcost" 803 }, 804 "pid-flows": [ 805 { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, 806 { "srcs": ["PID3"], "dsts": ["PID4"] } 807 ] 808 } 809 HTTP/1.1 200 OK 810 Content-Length: [TBD] 811 Content-Type: application/alto-costmap+json 813 { 814 "meta": { 815 "dependent-vtags": [ 816 { 817 "resource-id": "my-default-network-map", 818 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 819 } 820 ], 821 "cost-type": { 822 "cost-mode": "numerical", 823 "cost-metric": "hopcount" 824 } 825 }, 826 "cost-map": { 827 "PID1": { "PID2": 6 }, 828 "PID1": { "PID3": 2 }, 829 "PID3": { "PID4": 1 } 830 } 831 } 833 6.5.3. Flow-based Endpoint Cost Service Example #1 835 This example shows how the ALTO client requests endpoint cost using 836 "flow-based-filter" and extended endpoint addresses. In this case, 837 the ALTO client specifies tcp socket address to get more accurate 838 path cost. 840 POST /endpointcost/lookup HTTP/1.1 841 Host: alto.example.com 842 Accept: application/alto-endpointcost+json, 843 application/alto-error+json 844 Content-Length: [TBD] 845 Content-Type: application/alto-endpointcostparams+json 847 { 848 "cost-type": { 849 "cost-mode": "numerical", 850 "cost-metric": "hopcount" 851 }, 852 "endpoint-flows": [ 853 { "srcs": ["ipv4:192.0.2.2"], 854 "dsts": ["ipv4:192.0.2.89", "tcp:cdn1.example.com:21"] }, 855 { "srcs": ["tcp:203.0.113.45:54321"], 856 "dsts": ["tcp:cdn1.example.com:21"] } 857 ] 858 } 860 HTTP/1.1 200 OK 861 Content-Length: [TBD] 862 Content-Type: application/alto-endpointcost+json 864 { 865 "meta": { 866 "cost-type": { 867 "cost-mode": "numerical", 868 "cost-metric": "routingcost" 869 } 870 }, 871 "endpoint-cost-map": { 872 "ipv4:192.0.2.2": { 873 "ipv4:192.0.2.89": 100, 874 "tcp:cdn1.example.com:21": 20 875 }, 876 "tcp:203.0.113.45:54321": { 877 "tcp:cdn1.example.com:21": 80 878 } 879 } 880 } 882 6.5.4. Flow-based Endpoint Cost Service Example #2 884 This example shows the integration of the path vector extension and 885 the flow-based query. And in this example, the ALTO client specifies 886 the flow from "tcp6:203.0.113.45:54321" to 887 "tcp6:group1.example.com:21" is multicast. So the ALTO server will 888 expose the destination IP as a multicast group IP, and find the 889 multicast destinations "fe80::40e:9594:da3d:34b" and 890 "fe80::826:daff:feb8:1bb". Then the ALTO server will append the cost 891 for the shared tree into the "endpoint-cost-map". 893 POST /endpointcost/lookup HTTP/1.1 894 Host: alto.example.com 895 Accept: application/alto-endpointcost+json, 896 application/alto-error+json 897 Content-Length: [TBD] 898 Content-Type: application/alto-endpointcostparams+json 900 { 901 "cost-type": { 902 "cost-mode": "array", 903 "cost-metric": "ane-path" 904 }, 905 "endpoint-flows": [ 906 { "srcs": ["ipv4:192.0.2.2"], 907 "dsts": ["tcp:192.0.2.89:21", 908 "tcp:cdn1.example.com:21"] }, 909 { "srcs": ["tcp6:203.0.113.45:54321"], 910 "dsts": ["tcp6:group1.example.com:21"], 911 "flow-spec-announce": { 912 "transmission-type": "multicast" } } 913 ], 914 "properties": ["availbw"] 915 } 916 HTTP/1.1 200 OK 917 Content-Length: [TBD] 918 Content-Type: application/alto-endpointcost+json 920 { 921 "meta": { 922 "cost-type": { 923 "cost-mode": "numerical", 924 "cost-metric": "routingcost" 925 } 926 }, 927 "endpoint-cost-map": { 928 "ipv4:192.0.2.2": { 929 "tcp:192.0.2.89:21": [ "ane:S1", "ane:D1" ], 930 "tcp:cdn1.example.com:21": [ "ane:S1", "ane:D2", "ane:D3" ] 931 }, 932 "tcp6:203.0.113.45:54321": { 933 "tcp6:group1.example.com:21": [ "ane:S2", "ane:D3" ] 934 }, 935 "tcp6:group1.example.com:21": { 936 "tcp6:[fe80::40e:9594:da3d:34b]:21": [ "ane:G1" ], 937 "tcp6:[fe80::826:daff:feb8:1bb]:21": [ "ane:G2" ], 938 } 939 }, 940 "property-map": { 941 "ane:S1": { "availbw": 100 }, 942 "ane:S2": { "availbw": 100 }, 943 "ane:D1": { "availbw": 150 }, 944 "ane:D2": { "availbw": 80 }, 945 "ane:D3": { "availbw": 150 }, 946 "ane:G1": { "availbw": 100 }, 947 "ane:G2": { "availbw": 100 } 948 } 949 } 951 7. Security Considerations 953 As discussed in Section 15.4 of [RFC7285], an ALTO server or a third 954 party who is able to intercept the flow-based cost query messages MAY 955 store and process the obtained information in order to analyze user 956 behaviors and communication patterns. Since flow-based cost queries 957 MAY potentially provide more accurate information, an ALTO client 958 should be cognizant about the trade-off between redundancy and 959 privacy. 961 8. IANA Considerations 963 This document defines new address types to be registered to an 964 existing ALTO registry, and a new registry for their compatible 965 address types. 967 8.1. ALTO Address Type Registry 969 This document defines several new address types to be registered to 970 "ALTO Address Type Registry", listed in Table 1. 972 +------------+--------------------+-------------+-------------------+ 973 | Identifier | Address Encoding | Prefix | Mapping to/from | 974 | | | Encoding | IPv4/v6 | 975 +------------+--------------------+-------------+-------------------+ 976 | eth | See Section 5.2.1 | None | Mapping to/from | 977 | | | | IPv4 by [RFC0903] | 978 | | | | and [RFC0826]; | 979 | | | | Mapping to/from | 980 | | | | IPv6 by [RFC3122] | 981 | | | | and [RFC4861] | 982 | domain | See Section 5.2.2 | None | Mapping to/from | 983 | | | | IPv4 by [RFC1034] | 984 | domain6 | See Section 5.2.2 | None | Mapping to/from | 985 | | | | IPv6 by [RFC3596] | 986 | tcp | See Section 5.2.3 | None | No mapping | 987 | tcp6 | See Section 5.2.4 | None | No mapping | 988 | upd | See Section 5.2.3 | None | No mapping | 989 | udp6 | See Section 5.2.4 | None | No mapping | 990 +------------+--------------------+-------------+-------------------+ 992 Table 1: ALTO Address Type Registry 994 8.2. ALTO Address Type Compatibility Registry 996 This document proposes to create a new registry called "ALTO Address 997 Type Compatibility Registry", whose purpose is stated in Section 5.3. 999 The compatible address type identifiers of the ones registered in the 1000 ALTO Address Type Registry are listed in Table 2. 1002 +-------------+-------------------------+ 1003 | Identifier | Compatible Identifiers | 1004 +-------------+-------------------------+ 1005 | eth | ipv4, ipv6 | 1006 | domain | eth, ipv4 | 1007 | domain6 | eth, ipv6 | 1008 | tcp | eth, ipv4, domain | 1009 | tcp6 | eth, ipv6, domain6 | 1010 | udp | eth, ipv4, domain | 1011 | udp6 | eth, ipv6, domain6 | 1012 +-------------+-------------------------+ 1014 Table 2: ALTO Address Type Compatibility Registry 1016 The entry of an address type identifier SHOULD only include the 1017 identifiers registered before it. The compatibility between address 1018 types are bidirectional. For example, although "eth" does not 1019 register "tcp" as its compatible identifier, an ALTO server MUST 1020 recognize them as compatible because "eth" is registered as a 1021 compatible identifier of "tcp". 1023 Any new ALTO address type identifier registered after this document 1024 MUST register their compatible identifiers in this registry 1025 simultaneously. 1027 9. Acknowledgment 1029 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 1030 Randriamasy and Wendy Roome for their fruitful discussions and 1031 feedback on this document. Shawn Lin also gave substantial review 1032 feedback and suggestions on the protocol design. 1034 10. References 1036 10.1. Normative References 1038 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 1039 Converting Network Protocol Addresses to 48.bit Ethernet 1040 Address for Transmission on Ethernet Hardware", STD 37, 1041 RFC 826, DOI 10.17487/RFC0826, November 1982, 1042 . 1044 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1045 Reverse Address Resolution Protocol", STD 38, RFC 903, 1046 DOI 10.17487/RFC0903, June 1984, . 1049 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1050 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1051 . 1053 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1054 Requirement Levels", BCP 14, RFC 2119, 1055 DOI 10.17487/RFC2119, March 1997, . 1058 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1059 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1060 . 1062 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 1063 Literal IPv6 Addresses in URL's", RFC 2732, 1064 DOI 10.17487/RFC2732, December 1999, . 1067 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 1068 Inverse Discovery Specification", RFC 3122, 1069 DOI 10.17487/RFC3122, June 2001, . 1072 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1073 "DNS Extensions to Support IP Version 6", STD 88, 1074 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1075 . 1077 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1078 Resource Identifier (URI): Generic Syntax", STD 66, 1079 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1080 . 1082 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1083 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1084 DOI 10.17487/RFC4861, September 2007, . 1087 10.2. Informative References 1089 [EUI48] IEEE, , "Guidelines for use of a 48-bit Extended Unique 1090 Identifier (EUI-48)", 2012, 1091 . 1093 [EUI64] IEEE, , "Guidelines for use of a 64-bit Extended Unique 1094 Identifier (EUI-64)", November 2012, 1095 . 1097 [I-D.ietf-alto-path-vector] 1098 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 1099 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 1100 Vector Cost Type", draft-ietf-alto-path-vector-03 (work in 1101 progress), March 2018. 1103 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1104 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1105 2014, . 1107 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1108 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1109 "Application-Layer Traffic Optimization (ALTO) Protocol", 1110 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1111 . 1113 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1114 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1115 DOI 10.17487/RFC8189, October 2017, . 1118 Authors' Addresses 1120 Jingxuan Jensen Zhang 1121 Tongji University 1122 4800 Cao'an Hwy 1123 Shanghai 201804 1124 China 1126 Email: jingxuan.n.zhang@gmail.com 1128 Kai Gao 1129 Tsinghua University 1130 30 Shuangqinglu Street 1131 Beijing 100084 1132 China 1134 Email: gaok12@mails.tsinghua.edu.cn 1136 Junzhuo Austin Wang 1137 Tongji University 1138 4800 Cao'an Hwy, Jiading District 1139 Shanghai 1140 China 1142 Email: wangjunzhuo200@gmail.com 1143 Qiao Xiang 1144 Tongji/Yale University 1145 51 Prospect Street 1146 New Haven, CT 1147 USA 1149 Email: qiao.xiang@cs.yale.edu 1151 Y. Richard Yang 1152 Yale University 1153 51 Prospect St 1154 New Haven CT 1155 USA 1157 Email: yry@cs.yale.edu