idnits 2.17.1 draft-gao-alto-fcs-07.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 500 has weird spacing: '...DFilter pid-f...' == Line 575 has weird spacing: '...SONBool flo...' == Line 576 has weird spacing: '...NString addre...' == Line 608 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 (15 March 2020) is 1496 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 875, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI48' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-alto-path-vector (ref. 'I-D.ietf-alto-path-vector') -- Obsolete informational reference (is this intentional?): RFC 2732 (Obsoleted by RFC 3986) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO J. Zhang 3 Internet-Draft Tongji University 4 Intended status: Standards Track K. Gao 5 Expires: 16 September 2020 Sichuan University 6 J. Wang 8 Q. Xiang 9 Y.R. Yang 10 Yale University 11 15 March 2020 13 ALTO Extension: Flow-based Cost Query 14 draft-gao-alto-fcs-07 16 Abstract 18 ALTO cost maps and endpoint cost services map a source-destination 19 pair into a cost value. However, current filter specifications, 20 which define the set of source-destination pairs in an ALTO query, 21 have two limitations: 1) Only very limited address types are 22 supported (IPv4 and IPv6), which is not sufficient to uniquely 23 identify a flow in networks with fine-grained routing, such as the 24 emerging Software Defined Networks; 2) The base ALTO protocol only 25 defines filters enumerating all sources and all destinations, leading 26 to redundant information in the response; 3) Cannot distinguish 27 transmission types of flows in the query, which makes the server hard 28 to respond the accurate resource consumption. To address these three 29 issues, this document extends the base ALTO protocol with a more 30 fine-grained filter type which allows ALTO clients to select only the 31 concerned source-destination pairs and announce the flow-specific 32 information like data transmission type, and a more expressive 33 address space which allows ALTO clients to make queries beyond the 34 limited IP addresses. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 16 September 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 5 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.2.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2.2. Data Transmission Type . . . . . . . . . . . . . . . 5 74 2. Overview of Approaches . . . . . . . . . . . . . . . . . . . 5 75 2.1. Extended Endpoint Address . . . . . . . . . . . . . . . . 6 76 2.2. Flow-based Filter . . . . . . . . . . . . . . . . . . . . 6 77 2.3. Flow-specific Announcement . . . . . . . . . . . . . . . 6 78 3. Extended Endpoint Address . . . . . . . . . . . . . . . . . . 7 79 3.1. Address Type . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . 8 81 3.2.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 8 82 3.2.2. Internet Domain Name . . . . . . . . . . . . . . . . 8 83 3.2.3. IPv4 Socket Address . . . . . . . . . . . . . . . . . 8 84 3.2.4. IPv6 Socket Address . . . . . . . . . . . . . . . . . 8 85 3.3. Address Type Compatibility . . . . . . . . . . . . . . . 9 86 3.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4. Flow-specific Announcement . . . . . . . . . . . . . . . . . 9 88 4.1. Flow-specific Announcement Type . . . . . . . . . . . . . 9 89 4.2. Data Transmission Type Announcement . . . . . . . . . . . 10 90 5. Extended Cost Query Filters . . . . . . . . . . . . . . . . . 10 91 5.1. Filtered Cost Map Extension . . . . . . . . . . . . . . . 10 92 5.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 10 93 5.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 11 94 5.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 95 5.3. Endpoint Cost Service Extension . . . . . . . . . . . . . 12 96 5.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12 97 5.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 13 98 5.4. Response . . . . . . . . . . . . . . . . . . . . . . . . 14 99 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 100 5.5.1. Information Resource Directory . . . . . . . . . . . 15 101 5.5.2. Flow-based Filtered Cost Map Example . . . . . . . . 17 102 5.5.3. Flow-based Endpoint Cost Service Example #1 . . . . . 18 103 5.5.4. Flow-based Endpoint Cost Service Example #2 . . . . . 19 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 106 7.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 21 107 7.2. ALTO Address Type Compatibility Registry . . . . . . . . 22 108 7.3. ALTO Flow-specific Announcement Registry . . . . . . . . 23 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 111 8.2. Informative References . . . . . . . . . . . . . . . . . 24 112 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 25 113 Appendix B. Change Logs . . . . . . . . . . . . . . . . . . . . 25 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 116 1. Introduction 118 Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] 119 defines several cost query services, like Filtered Cost Map and 120 Endpoint Cost Service, to allow applications to query path costs. 121 Generally, an ALTO cost query service can be regarded as a function 122 transforming a given subset of a specific query space into a network 123 view abstract, where the subset is specified by a PID filter or an 124 endpoint filter. However, the current specification has some 125 limitations. 127 First, in the base ALTO protocol [RFC7285], the endpoint filter only 128 contains the source and destination IP addresses. In practice, both 129 Internet Service Providers (ISP) and local network administrators may 130 conduct policy-based routing, e.g., P2P traffic may be constrained 131 and has a smaller bandwidth than HTTP traffic. Also, web services 132 with different QoS requirements may be hosted on the same machine 133 with the same IP address but different paths with different QoS 134 metrics. 136 Second, in the base ALTO protocol [RFC7285], the query space is 137 defined by a source list and a destination list. For a query with N 138 sources and M destinations, the response contains N*M entries. While 139 such a query schema is well suited for peer-to-peer (P2P) 140 applications where files of the same seed are stored on all hosts, it 141 may lead to a lot of redundancy in use cases such as modern data 142 analytics systems where replicas of the same dataset are stored on 143 only a small subset of servers. Consider a system where the number 144 of replicas is 3 (the default in HDFS), jointly scheduling N 145 concurrent transfers only needs a maximum of 3N entries but the base 146 ALTO protocol may return up to N^2 entries. 148 Third, in the base ALTO protocol [RFC7285], the query does not 149 distinguish among the different transmission types like unicast and 150 multicast. For some use cases like the multi-flow scheduling 151 demonstrated by [I-D.ietf-alto-path-vector], the data transmission 152 between endpoints could be beyond unicast. And in those cases, 153 different transmission types may affect the network resource 154 consumption. If applications can receive the path costs 155 distinguishing the different transmission types, it can help 156 applications perform their data transmission decision better. 158 Thus, we conclude that the following additional requirements (AR) 159 MUST be satisfied to allow ALTO clients make more accurate and 160 efficient cost queries. 162 AR-1: The ALTO server SHOULD allow the ALTO client to specify 163 accurate query space in cost query services. 165 The base ALTO protocol only includes IPv4 and IPv6 addresses as 166 endpoint address types, which may not be sufficient to accurately 167 identify an endpoint with emerging flow-based routing mechanisms. 168 ALTO clients MAY suffer from suboptimal decisions because of such 169 inaccuracy. Thus, the ALTO protocol SHOULD be extended so that 170 clients are able to specify accurate query space, i.e., using more 171 fine-grained endpoint address types. 173 AR-2: The ALTO server SHOULD allow the ALTO client to specify only 174 the essential query space. 176 Existing PIDFilter (see Sec 11.3.2.3 in [RFC7285]) and 177 EndpointFilter (see Sec 11.5.1.3 in [RFC7285]) represent the 178 cross-product of sources and destinations, and can introduce a lot 179 of redundancy in certain use cases. This limitation greatly harms 180 the scalability of the ALTO protocol. Thus, the ALTO protocol 181 SHOULD be extended so that ALTO clients are able to specify only 182 the essential cost query space, i.e., the concerned source- 183 destination pairs. 185 AR-3: The ALTO server SHOULD allow the ALTO client to specify 186 different data transmission types for transimissions in the query 187 space. 189 The input parameters of existing ALTO cost query services only 190 allow the ALTO client to specify the queried transmissions by 191 sources and destinations. The transmission between each source 192 and destination will always be considered as the unicast. This 193 limitaiton may make the ALTO client lose the accurate available 194 resources. Thus, the ALTO protocol SHOULD be extended so that 195 ALTO clients are able to speicfy different transmission types. 197 In this document, we describe an ALTO extension specifying flow-based 198 cost queries. The rest of this document is organized as follows. 199 Section 3 introduces several new address types that extend the query 200 space of ALTO cost services. Section 5 describes the extended schema 201 on Filtered Cost Map (FCM) and Endpoint Cost Service (ECS) to support 202 cost queries of arbitrary source-destination combinations with the 203 optional flow-specific information. Section 6 and Section 7 discuss 204 security and IANA considerations. 206 1.1. Requirement Language 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 1.2. Terminology 214 This document uses the same terms as defined in [RFC7285] and 215 [RFC8189] with the following additional term: 217 1.2.1. Flow 219 In this document, a flow refers to all communications between two 220 endpoints. A flow is "valid" if and only if there CAN be valid 221 communications between the two endpoints, which oftentimes requires 222 that that two endpoint addresses have compatible address types. 224 1.2.2. Data Transmission Type 226 This document use the term "Data Transmission Type" or "Transmission 227 Type" to indicate how an application sends the network flows. See 228 Section 4.2. 230 2. Overview of Approaches 232 This section presents a non-normative overview of the extension to 233 support flow-based cost query. It assumes the readers are familiar 234 with Filtered Cost Map and Endpoint Cost Service defined in [RFC7285] 235 and their extensions defined in [RFC8189]. 237 2.1. Extended Endpoint Address 239 To allow ALTO clients specify accurate query space in cost query 240 services (AR-1), this document defines several new endpoint address 241 types. An endpoint address with a new type is referred to as an 242 extended endpoint address. 244 Since the address types of both the source and the destination 245 correspond to the same network flow, they MUST NOT conflict. This 246 document defines an address type conflict table to indicate 247 conflicts. If some source and destination address types in a query 248 conflict with each others, an ALTO server MUST return the 249 corresponding error. 251 2.2. Flow-based Filter 253 To allow ALTO clients specify only the essential query space in cost 254 query services (AR-2), both PIDFilter and EndpointFilter in the base 255 protocol MUST be extended. The extended filters are referred to as 256 flow-based filters. 258 A straight-forward way of satisfying AR-2 is to have an ALTO client 259 list all its concerned flows. Despite its simplicity, it MAY be too 260 large in size, especially when many flows have common sources or 261 common destinations in the query. Also from the implementation's 262 perspective, it cannot reuse the functionality to parse a PIDFilter/ 263 EndpointFilter. 265 Thus, the flow-based filters defined in this document allow ALTO 266 clients to include multiple PIDFilter/EndpointFilter objects in the 267 same query. Apparently, if we replace each PIDFilter/EndpointFilter 268 of N sources and M destinations with NM filters that have exactly one 269 source and destination, the two representations refer to the same set 270 of flows. As a result, one can aggregate flows with common sources 271 or destinations in one PIDFilter/EndpointFilter object without 272 introducing redundant flows. 274 From the implementation's perspective, one MAY reuse an ALTO library 275 which parses PIDFilter/EndpointFilter and/or converts them into a set 276 of source-destination pairs. 278 2.3. Flow-specific Announcement 280 Some properties are only related to the transmission and cannot be 281 encoded into endpoints, e.g., the data transmission type of a flow. 282 However, these properties may help the ALTO client get more accurate 283 costs. 285 To allow the ALTO client to specify these flow-specific properties 286 (AR-3), this document introduces an extensible field in the flow- 287 based filter. The ALTO client can announce the flow-specific 288 information in this field. An announcement, whose type is encoded as 289 a FlowSpecAnnounceType (Section 4.1), can represent transmission 290 type, equal cost multipath assumption and other kinds of flow- 291 specific information. 293 This document adopts an extensible design for this announcement 294 field. Although only the data transmission type is defined in this 295 document, other announcement properties can be defined in future 296 documents and are not in the scope of this document. 298 3. Extended Endpoint Address 300 This document registers new address types and defines the 301 corresponding formats for endpoint addresses of each new address 302 type. 304 3.1. Address Type 306 The new AddressType identifiers defined in this document are as 307 follows: 309 eth: An endpoint address with type "eth" is the address of an 310 Ethernet interface. It is used to uniquely identify an endpoint 311 in the data link layer. 313 domain: An endpoint address with type "domain" is the domain name of 314 a web service. It is used to uniquely identify a web service 315 which MAY be translated to one or more IPv4 address(es). 317 domain6: An endpoint address with type "domain6" is the domain name 318 of a web service. It is used to uniquely identify a web service 319 which MAY be translated to one or more IPv6 address(es). 321 tcp: An endpoint address with type "tcp" is the address of a TCP 322 socket. It is used to uniquely identify an IPv4 TCP socket in the 323 transport layer. 325 tcp6: An endpoint address with type "tcp6" is the address of a TCP 326 socket. It is used to uniquely identify an IPv6 TCP socket in the 327 transport layer. 329 udp: An endpoint address with type "udp" is the address of a UDP 330 socket. It is used to uniquely identify an IPv4 UDP socket in the 331 transport layer. 333 udp6: An endpoint address with type "udp6" is the address of a UDP 334 socket. It is used to uniquely identify an IPv6 UDP socket in the 335 transport layer. 337 3.2. Endpoint Address 339 This document defines EndpointAddr when AddressType is in 340 Section 7.1. 342 3.2.1. MAC Address 344 An Endpoint Address of type "eth" is encoded as a MAC address, whose 345 format is encoded as specified by either format EUI-48 in [EUI48] or 346 EUI-64 in [EUI64]. 348 3.2.2. Internet Domain Name 350 An Endpoint Address of type "domain" or "domain6" is encoded as a 351 domain name in the Internet, as specified in Section 11 of [RFC2181]. 352 It MUST have at least one corresponding A ("domain") or AAAA 353 ("domain6") record in the DNS. 355 3.2.3. IPv4 Socket Address 357 An Endpoint Address of type "tcp" or "udp" is encoded as an IPv4 358 socket address. It is encoded as a string of the format Host:Port 359 with the ":" character as a separator. The Host component of an IPv4 360 socket address is encoded as specified by either an IPv4 address (see 361 Section 10.4.3.1 of [RFC7285]) or an IPv4-compatible domain name (see 362 Section 3.2.2). The Port component of an IPv4 socket address is 363 encoded as an integer between 1 and 65535. 365 3.2.4. IPv6 Socket Address 367 An Endpoint Address of type "tcp6" or "udp6" is encoded as an IPv6 368 socket address. It is also encoded as a string of the format 369 Host:Port with the ":" character as a separator. The Host component 370 of an IPv6 socket address is encoded as specified by either an IPv6 371 address (see Section 10.4.3.2 of [RFC7285]) enclosed in the "[" and 372 "]" characters as recommended in [RFC2732] or an IPv6-compatible 373 domain name (see Section 3.2.2). The Port component of IPv6 socket 374 address is encoded as an integer between 1 and 65535. 376 3.3. Address Type Compatibility 378 In practice, a flow with endpoint addresses with different types MAY 379 NOT be valid. For example, a source endpoint with an IPv4 address 380 CANNOT establish a network connection with a destination endpoint 381 with an IPv6 address. Neither can a source with a TCP socket address 382 and a destination with a UDP socket address. 384 Thus, to explicitly define the compatibility between AddressType 385 identifiers, every ALTO AddressType identifier MUST provide a list of 386 AddressType identifiers that are compatible with it in the "ALTO 387 Address Type Compatibility Registry" Section 7.2. For all sources 388 and destinations in a PIDFilter/EndpointFilter, if the AddressType 389 identifiers of a given pair DO NOT appear in the ALTO Address Type 390 Compatibility Registry, an ALTO server MUST return an ALTO error 391 response with the error code "E_INVALID_FIELD_VALUE" with optional 392 information to help diagnose the incompatibility. 394 3.4. Examples 396 Some valid endpoint addresses are demonstrated as follows: 398 "eth:98-e0-d9-9c-df-81" 399 "domain:www.example.com" 400 "tcp:198.51.100.34:5123" 401 "udp6:[2000::1:2345:6789:abcd]:8080" 403 4. Flow-specific Announcement 405 Each flow-specific announcement refers to a property of the traffic 406 between a set of source and destination pairs. The interpretation of 407 a property, however, depends on the meaning, i.e., the type, of the 408 property. This document uses flow-specific announcement type as an 409 indicator of the "type" information, and requires the flow-specific 410 announcement types be registered in an IANA registry called "ALTO 411 Flow-specific Announcement Registry". 413 4.1. Flow-specific Announcement Type 415 It is encoded as a JSONString and has the same format as a PID Name 416 defined in Section 10.1 in [RFC7285]. The type FlowSpecAnnounceType 417 is used in this document to indicate a string of that format. 419 4.2. Data Transmission Type Announcement 421 This document defines a flow-specific announcement called the data 422 transmission type. The type of this announcement is indicated by the 423 string "transmission-type", and the value of this announcement is a 424 JSONString of either "unicast", "anycast", "broadcast" or 425 "multicast". 427 5. Extended Cost Query Filters 429 This section describes extensions to [RFC7285] and [RFC8189] to 430 support flow-based cost queries. 432 This document uses the notation rules specified in Section 8.2 of 433 [RFC7285] and also the notation rules for optional fields in 434 Section 4 of [RFC8189]. 436 5.1. Filtered Cost Map Extension 438 This document extends the Filtered Cost Map as defined in 439 Section 11.3.2 of [RFC7285] and Section 4.1 of [RFC8189], by adding a 440 new capability and new input parameters. 442 The media type, HTTP method, and "uses" specifications (described in 443 Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively) 444 are not changed. 446 The format of the response is the same as defined in Section 4.1.3 of 447 [RFC8189]. But this document recommends how to generate the response 448 based on the extended input parameters. 450 5.1.1. Capabilities 452 The Filtered Cost Map capabilities are extended with two additional 453 members: 455 * flow-based-filter 457 * flow-spec-announce 459 The capability "flow-based-filter" indicates whether this resource 460 supports flow-based cost queries, and the capability "flow-spec- 461 announce" indicates which flow-specific announcements are supported. 462 The FilteredCostMapCapabilities object in Section 4.1.1 of [RFC8189] 463 is extended as follows: 465 object { 466 JSONString cost-type-names<1..*>; 467 [JSONBool cost-constraints;] 468 [JSONNumber max-cost-types;] 469 [JSONString testable-cost-type-names<1..*>;] 470 [JSONBool flow-based-filter;] 471 [FlowSpecAnnounceType flow-spec-announce<1..*>;] 472 } FilteredCostMapCapabilities; 474 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 475 of [RFC7285]. 477 max-cost-types and testable-cost-type-names: As defined in 478 Section 4.1.1 of [RFC8189]. 480 flow-based-filter: If true, an ALTO Server allows a field "pid- 481 flows" to be included in the requests. If not present, this field 482 MUST be interpreted as if it is false. 484 flow-spec-announce: It MUST NOT be present if "flow-based-filter" is 485 not true. If present, the value is the an array of supported 486 flow-specific announcement types. 488 5.1.2. Accept Input Parameters 490 The ReqFilteredCostMap object in Section 4.1.2 of [RFC8189] is 491 extended as follows: 493 object { 494 [CostType cost-type;] 495 [CostType multi-cost-types<1..*>;] 496 [CostType testable-cost-types<1..*>;] 497 [JSONString constraints<0..*>;] 498 [JSONString or-constraints<1..*><1..*>;] 499 [PIDFilter pids;] 500 [ExtPIDFilter pid-flows<1..*>;] 501 } ReqFilteredCostMap; 503 object { 504 [FlowSpecAnnounceMap flow-spec-announce;] 505 } ExtPIDFilter : PIDFilter; 507 object-map { 508 FlowSpecAnnounceType -> JSONValue; 509 } FlowSpecAnnounceMap; 511 cost-type, multi-cost-types, testable-cost-types, constraints, or- 512 constraints: As defined in Section 4.1.2 of [RFC8189]. 514 pids: As defined in Section 11.3.2.3 of [RFC7285]. 516 pid-flows: Defined as a list of ExtPIDFilter objects. The ALTO 517 server MUST interpret PID pairs appearing in multiple ExtPIDFilter 518 objects as if they appeared only once. If the capability "flow- 519 spec-announce" is present, the "flow-spec-announce" input 520 parameter can be specified. The value of this field is of type 521 FlowSpecAnnounceMap, which maps a FlowSpecAnnounceType to its 522 corresponding value. The interpretation of the value MUST follow 523 the definition of the flow-specific announcement in the ALTO Flow- 524 specific Announcement Registry. 526 An ALTO client MUST include either "pids" or "pid-flows" in a query 527 but MUST NOT include both at the same time. 529 5.2. Response 531 This document does not change the format of the response entity. But 532 the ALTO server responds the request with "pid-flows" filter as 533 follows: 535 The ALTO server MUST include the path costs of pairs in each 536 ExtPIDFilter in the "pid-flows" filter. If the "flow-spec-announce" 537 field is specified in some ExtPIDFilter, the path costs for flows in 538 this ExtPIDFilter SHOULD respond the flow-specific information 539 announced by this field. 541 5.3. Endpoint Cost Service Extension 543 This document extends the Endpoint Cost Service as defined in 544 Section 11.5.1 of [RFC7285] and Section 4.2 of [RFC8189], by adding a 545 new capability and input parameters. 547 The media type, HTTP method, and "uses" specifications (described in 548 Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively) 549 are unchanged. 551 The format of the response is the same as defined in Section 4.2.3 of 552 [RFC8189]. But this document recommends how to generate the response 553 based on the extended input parameters. 555 5.3.1. Capabilities 557 The extension to EndpointCostCapabilities includes three additional 558 members: 560 * flow-based-filter 561 * address-types 563 * flow-spec-announce 565 Only if the capability "flow-based-filter" is present and its value 566 is "true", the ALTO server supports the flow-based extension for this 567 endpoint cost service. The capability "address-types" indicates 568 which endpoint address types are supported by this resource, it MUST 569 NOT be specified if "flow-based-filter" is absent or the value is 570 false. The capability "flow-spec-announce" indicates which flow- 571 specific announcements are supported, just like it works in the 572 Filtered Cost Map resource. 574 object { 575 [JSONBool flow-based-filter;] 576 [JSONString address-types<0..*>;] 577 [FlowSpecAnnounceType flow-spec-announce<1..*>;] 578 } EndpointCostCapabilities : FilteredCostMapCapabilities; 580 flow-based-filter: If true, an ALTO Server MUST accept field 581 "endpoint-flows" in the requests. If not present, this field MUST 582 be interpreted as if it is specified false. 584 address-types: Defines a list of AddressType identifiers encoded as 585 a JSONArray of JSONString. All AddressType identifiers MUST be 586 registered in the "ALTO Address Type Registry" (see Section 14.4 587 of [RFC7285]). An ALTO server SHOULD NOT claim "ipv4" and "ipv6" 588 in this field explicitly, because they are supported by default. 589 If not present, this field MUST be interpreted as if it is an 590 empty array, i.e., the ALTO server only supports the default 591 "ipv4" and "ipv6" address types. 593 flow-spec-announce: It MUST NOT be present if "flow-based-filter" is 594 not true. If present, the value is the an array of supported 595 flow-specific announcement types. 597 5.3.2. Accept Input Parameters 599 The ReqEndpointCostMap object in Section 4.2.2 of [RFC8189] is 600 extended as follows: 602 object { 603 [CostType cost-type;] 604 [CostType multi-cost-types<1..*>;] 605 [CostType testable-cost-types<1..*>;] 606 [JSONString constraints<0..*>;] 607 [JSONString or-constraints<1..*><1..*>;] 608 [EndpointFilter endpoints;] 609 [ExtEndpointFilter endpoint-flows<1..*>;] 610 } ReqEndpointCostMap; 612 object { 613 [FlowSpecAnnounceMap flow-spec-announce;] 614 } ExtEndpointFilter : EndpiontFilter; 616 cost-type, multi-cost-types, testable-cost-types, constraints, or- 617 constraints: 618 As defined in Section 4.1.2 of [RFC8189]. 620 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 622 endpoint-flows: Defined as a list of ExtEndpointFilter objects. The 623 ALTO server MUST interpret endpoint pairs appearing in multiple 624 ExtEndpointFilter objects as if they appeared only once. If the 625 capability "flow-spec-announce" is present, the "flow-spec- 626 announce" input parameter can be specified. The interpretation of 627 this field is the same as in Section 5.1.2. 629 If the AddressType of the source and destination in the same 630 EndpointFilter do not conform the compatibility rule defined in 631 Table 1 of Section 7.1, an ALTO server MUST return an ALTO error 632 response with the error code "E_INVALID_FIELD_VALUE". 634 An ALTO client MUST specify either "endpoints" or "endpoint-flows", 635 but MUST NOT specify both in the same query. 637 5.4. Response 639 This document does not change the format of the response entity. But 640 the ALTO server responds the request with "pid-flows" filter as 641 follows: 643 The ALTO server MUST include the path costs of pairs in each 644 ExtPIDFilter in the "pid-flows" filter. If the "flow-spec-announce" 645 field is specified in some ExtPIDFilter, the path costs for flows in 646 this ExtPIDFilter SHOULD respond the flow-specific information 647 announced by this field. Especially, if "transmission-type" is 648 specified as "multicast", the ALTO server SHOULD expose all the 649 destination address as a multicast group address, and append the 650 shared trees to the multicast destination addresses into the response 651 if possible. 653 5.5. Examples 655 5.5.1. Information Resource Directory 657 The following is an example of IRD with relevant resources of the 658 ALTO server. It provides a default network map, a property map of 659 "ane" domain, a filtered cost map and two endpoint cost resources. 660 All of three cost query resources (filtered cost map and endpoint 661 cost resources) support "flow-based-filter". One endpoint cost 662 resource support "flow-spec-announce" and the compound query 663 extension defined in I-D.ietf-alto-path-vector. 665 Examples followed this section use the same IRD in this document. 667 GET /directory HTTP/1.1 668 Host: alto.example.com 669 Accept: application/alto-directory+json, 670 application/alto-error+json 672 HTTP/1.1 200 OK 673 Content-Length: [TBD] 674 Content-Type: application/alto-directory+json 676 { 677 "meta" : { 678 "default-alto-network-map" : "my-default-network-map", 679 "cost-types" : { 680 "num-hopcount" : { 681 "cost-mode" : "numerial", 682 "cost-metric" : "hopcount"}, 683 "num-routingcost" : { 684 "cost-mode" : "numerial", 685 "cost-metric" : "routingcost"}, 686 "ord-routingcost" : { 687 "cost-mode" : "ordinal", 688 "cost-metric" : "routingcost"}, 689 "path-vector" : { 690 "cost-mode" : "array", 691 "cost-metric" : "ane-path"} 692 }, 693 ..... 694 Other ALTO cost types as described in RFC7285 695 ..... 696 }, 697 "resources" : { 698 "my-default-network-map" : { 699 "uri" : "http://alto.example.com/networkmap", 700 "media-type" : "application/alto-networkmap+json" 701 }, 702 "flow-based-cost-map" : { 703 "uri" : "http://alto.example.com/costmap/multi/filtered", 704 "media-type" : "application/alto-costmap+json", 705 "accepts" : "application/alto-costmapfilter+json", 706 "uses" : [ "my-default-network-map" ], 707 "capabilities" : { 708 "max-cost-types" : 2, 709 "flow-based-filter" : true, 710 "cost-type-names" : [ "num-hopcount", 711 "num-routingcost" ] 712 } 713 }, 714 "flow-based-endpoint-cost" : { 715 "uri" : "http://alto.example.com/endpointcost/lookup", 716 "media-type" : "application/alto-endpointcost+json", 717 "accepts" : "application/alto-endpointcostparams+json", 718 "capabilities" : { 719 "address-types": ["tcp", "udp"], 720 "flow-based-filter" : true, 721 "cost-type-names" : [ "ord-routingcost", 722 "num-routingcost" ] 723 } 724 }, 725 "path-vector-endpoint-cost" : { 726 "uri" : "http://alto.example.com/pathvector/lookup", 727 "media-type": "multipart/related; 728 type=application/alto-costmap+json", 729 "accepts" : "application/alto-endpointcostparams+json", 730 "capabilities" : { 731 "address-types": ["tcp", "tcp6"], 732 "flow-based-filter" : true, 733 "flow-spec-announce" : [ "transmission-type" ] 734 "cost-type-names" : [ "path-vector" ], 735 "ane-property-names": [ "maxresbw" ], 736 } 737 } 738 } 739 } 741 5.5.2. Flow-based Filtered Cost Map Example 743 This example shows how an ALTO client requests a filtered cost map 744 using the "pid-flows" filter. In this case, the ALTO client receives 745 a sparse cost map, which cuts 50% useless cost values from the full 746 mesh. 748 POST /costmap/multi/filtered HTTP/1.1 749 Host: alto.example.com 750 Accept: application/alto-costmap+json, 751 application/alto-error+json 752 Content-Length: [TBD] 753 Content-Type: application/alto-costmapfilter+json 755 { 756 "cost-type": { 757 "cost-mode": "numerical", 758 "cost-metric": "routingcost" 759 }, 760 "pid-flows": [ 761 { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, 762 { "srcs": ["PID3"], "dsts": ["PID4"] } 763 ] 764 } 766 HTTP/1.1 200 OK 767 Content-Length: [TBD] 768 Content-Type: application/alto-costmap+json 770 { 771 "meta": { 772 "dependent-vtags": [ 773 { 774 "resource-id": "my-default-network-map", 775 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 776 } 777 ], 778 "cost-type": { 779 "cost-mode": "numerical", 780 "cost-metric": "hopcount" 781 } 782 }, 783 "cost-map": { 784 "PID1": { "PID2": 6, "PID3": 2 }, 785 "PID3": { "PID4": 1 } 786 } 787 } 789 5.5.3. Flow-based Endpoint Cost Service Example #1 791 This example shows how the ALTO client requests endpoint cost using 792 "flow-based-filter" and extended endpoint addresses. In this case, 793 the ALTO client specifies tcp socket address to get more accurate 794 path cost. 796 POST /endpointcost/lookup HTTP/1.1 797 Host: alto.example.com 798 Accept: application/alto-endpointcost+json, 799 application/alto-error+json 800 Content-Length: [TBD] 801 Content-Type: application/alto-endpointcostparams+json 803 { 804 "cost-type": { 805 "cost-mode": "numerical", 806 "cost-metric": "hopcount" 807 }, 808 "endpoint-flows": [ 809 { "srcs": ["ipv4:192.0.2.2"], 810 "dsts": ["ipv4:192.0.2.89", "tcp:cdn1.example.com:21"] }, 811 { "srcs": ["tcp:203.0.113.45:54321"], 812 "dsts": ["tcp:cdn1.example.com:21"] } 813 ] 814 } 816 HTTP/1.1 200 OK 817 Content-Length: [TBD] 818 Content-Type: application/alto-endpointcost+json 820 { 821 "meta": { 822 "cost-type": { 823 "cost-mode": "numerical", 824 "cost-metric": "routingcost" 825 } 826 }, 827 "endpoint-cost-map": { 828 "ipv4:192.0.2.2": { 829 "ipv4:192.0.2.89": 100, 830 "tcp:cdn1.example.com:21": 20 831 }, 832 "tcp:203.0.113.45:54321": { 833 "tcp:cdn1.example.com:21": 80 834 } 835 } 836 } 838 5.5.4. Flow-based Endpoint Cost Service Example #2 840 This example shows the integration of the path vector extension and 841 the flow-based query. And in this example, the ALTO client specifies 842 the flow from "tcp6:203.0.113.45:54321" to 843 "tcp6:group1.example.com:21" is multicast. So the ALTO server will 844 expose the destination IP as a multicast group IP, and find the 845 multicast destinations "fe80::40e:9594:da3d:34b" and 846 "fe80::826:daff:feb8:1bb". Then the ALTO server will append the cost 847 for the shared tree into the "endpoint-cost-map". 849 POST /pathvector/lookup HTTP/1.1 850 Host: alto.example.com 851 Accept: multipart/related; 852 type=application/alto-endpointcost+json, 853 application/alto-error+json 854 Content-Length: [TBD] 855 Content-Type: application/alto-endpointcostparams+json 857 { 858 "cost-type": { 859 "cost-mode": "array", 860 "cost-metric": "ane-path" 861 }, 862 "endpoint-flows": [ 863 { "srcs": ["ipv4:192.0.2.2"], 864 "dsts": ["tcp:192.0.2.89:21", 865 "tcp:cdn1.example.com:21"] }, 866 { "srcs": ["tcp6:203.0.113.45:54321"], 867 "dsts": ["tcp6:group1.example.com:21"], 868 "flow-spec-announce": { 869 "transmission-type": "multicast" } } 870 ], 871 "ane-property-names": ["maxresbw"] 872 } 874 HTTP/1.1 200 OK 875 Content-Length: [TBD] 876 Content-Type: multipart/related; boundary=example; 877 type=application/alto-endpointcost+json 879 --example 880 Resource-Id: ecs 881 Content-Type: application/alto-endpointcost+json 883 { 884 "meta": { 885 "vtags": { 886 "resource-id": "path-vector-endpoint-cost.ecs", 887 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 888 }, 889 "cost-type": { 890 "cost-mode": "array", 891 "cost-metric": "ane-path" 892 } 893 }, 894 "endpoint-cost-map": { 895 "ipv4:192.0.2.2": { 896 "tcp:192.0.2.89:21": [ "ane:S1", "ane:D1" ], 897 "tcp:cdn1.example.com:21": [ "ane:S1", "ane:D2", "ane:D3" ] 898 }, 899 "tcp6:203.0.113.45:54321": { 900 "tcp6:group1.example.com:21": [ "ane:S2", "ane:D3" ] 901 }, 902 "tcp6:group1.example.com:21": { 903 "tcp6:[fe80::40e:9594:da3d:34b]:21": [ "ane:G1" ], 904 "tcp6:[fe80::826:daff:feb8:1bb]:21": [ "ane:G2" ], 905 } 906 } 907 } 909 --example 910 Resource-Id: propmap 911 Content-Type: application/alto-propmap+json 913 { 914 "meta": { 915 "dependent-vtags": [ 916 { 917 "resource-id": "path-vector-endpoint-cost.ecs", 918 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 919 } 920 ] 921 }, 922 "property-map": { 923 "ane:S1": { "maxresbw": 100 }, 924 "ane:S2": { "maxresbw": 100 }, 925 "ane:D1": { "maxresbw": 150 }, 926 "ane:D2": { "maxresbw": 80 }, 927 "ane:D3": { "maxresbw": 150 }, 928 "ane:G1": { "maxresbw": 100 }, 929 "ane:G2": { "maxresbw": 100 } 930 } 931 } 933 6. Security Considerations 935 As discussed in Section 15.4 of [RFC7285], an ALTO server or a third 936 party who is able to intercept the flow-based cost query messages MAY 937 store and process the obtained information in order to analyze user 938 behaviors and communication patterns. Since flow-based cost queries 939 MAY potentially provide more accurate information, an ALTO client 940 should be cognizant about the trade-off between redundancy and 941 privacy. 943 7. IANA Considerations 945 This document defines new address types to be registered to an 946 existing ALTO registry, and a new registry for their compatible 947 address types. 949 7.1. ALTO Address Type Registry 951 This document defines several new address types to be registered to 952 "ALTO Address Type Registry", listed in Table 1. 954 +------------+----------+----------+--------------------------+ 955 | Identifier | Address | Prefix | Mapping to/from IPv4/v6 | 956 | | Encoding | Encoding | | 957 +============+==========+==========+==========================+ 958 | eth | See | None | Mapping to/from IPv4 by | 959 | | Section | | [RFC0903] and [RFC0826]; | 960 | | 3.2.1 | | Mapping to/from IPv6 by | 961 | | | | [RFC3122] and [RFC4861] | 962 +------------+----------+----------+--------------------------+ 963 | domain | See | None | Mapping to/from IPv4 by | 964 | | Section | | [RFC1034] | 965 | | 3.2.2 | | | 966 +------------+----------+----------+--------------------------+ 967 | domain6 | See | None | Mapping to/from IPv6 by | 968 | | Section | | [RFC3596] | 969 | | 3.2.2 | | | 970 +------------+----------+----------+--------------------------+ 971 | tcp | See | None | No mapping | 972 | | Section | | | 973 | | 3.2.3 | | | 974 +------------+----------+----------+--------------------------+ 975 | tcp6 | See | None | No mapping | 976 | | Section | | | 977 | | 3.2.4 | | | 978 +------------+----------+----------+--------------------------+ 979 | upd | See | None | No mapping | 980 | | Section | | | 981 | | 3.2.3 | | | 982 +------------+----------+----------+--------------------------+ 983 | udp6 | See | None | No mapping | 984 | | Section | | | 985 | | 3.2.4 | | | 986 +------------+----------+----------+--------------------------+ 988 Table 1: ALTO Address Type Registry 990 7.2. ALTO Address Type Compatibility Registry 992 This document proposes to create a new registry called "ALTO Address 993 Type Compatibility Registry", whose purpose is stated in Section 3.3. 995 The compatible address type identifiers of the ones registered in the 996 ALTO Address Type Registry are listed in Table 2. 998 +------------+------------------------+ 999 | Identifier | Compatible Identifiers | 1000 +============+========================+ 1001 | eth | ipv4, ipv6 | 1002 +------------+------------------------+ 1003 | domain | eth, ipv4 | 1004 +------------+------------------------+ 1005 | domain6 | eth, ipv6 | 1006 +------------+------------------------+ 1007 | tcp | eth, ipv4, domain | 1008 +------------+------------------------+ 1009 | tcp6 | eth, ipv6, domain6 | 1010 +------------+------------------------+ 1011 | udp | eth, ipv4, domain | 1012 +------------+------------------------+ 1013 | udp6 | eth, ipv6, domain6 | 1014 +------------+------------------------+ 1016 Table 2: ALTO Address Type 1017 Compatibility Registry 1019 The entry of an address type identifier SHOULD only include the 1020 identifiers registered before it. The compatibility between address 1021 types are bidirectional. For example, although "eth" does not 1022 register "tcp" as its compatible identifier, an ALTO server MUST 1023 recognize them as compatible because "eth" is registered as a 1024 compatible identifier of "tcp". 1026 Any new ALTO address type identifier registered after this document 1027 MUST register their compatible identifiers in this registry 1028 simultaneously. 1030 7.3. ALTO Flow-specific Announcement Registry 1032 This document proposes to create a new registry called "ALTO Flow- 1033 specific Announcement Registry", whose purpose is stated in 1034 Section 4. An initial registry entry is also documented as shown in 1035 Table 3. 1037 +-------------------+-----------------+ 1038 | Type | Interpretation | 1039 +===================+=================+ 1040 | transmission-type | See Section 4.2 | 1041 +-------------------+-----------------+ 1043 Table 3: ALTO Flow-specific 1044 Announcement Registry 1046 8. References 1048 8.1. Normative References 1050 [EUI48] IEEE, ., "Guidelines for use of a 48-bit Extended Unique 1051 Identifier (EUI-48)", 2012. 1053 [EUI64] IEEE, ., "Guidelines for use of a 64-bit Extended Unique 1054 Identifier (EUI-64)", 2012. 1056 [I-D.ietf-alto-path-vector] 1057 Gao, K., Randriamasy, S., Yang, Y., and J. Zhang, "ALTO 1058 Extension: Path Vector", Work in Progress, Internet-Draft, 1059 draft-ietf-alto-path-vector-10, 9 March 2020, 1060 . 1063 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1064 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1065 "Application-Layer Traffic Optimization (ALTO) Protocol", 1066 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1067 . 1069 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1070 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1071 DOI 10.17487/RFC8189, October 2017, 1072 . 1074 8.2. Informative References 1076 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 1077 Converting Network Protocol Addresses to 48.bit Ethernet 1078 Address for Transmission on Ethernet Hardware", STD 37, 1079 RFC 826, DOI 10.17487/RFC0826, November 1982, 1080 . 1082 [RFC0903] Finlayson, R., Mann, T., Mogul, J.C., and M. Theimer, "A 1083 Reverse Address Resolution Protocol", STD 38, RFC 903, 1084 DOI 10.17487/RFC0903, June 1984, 1085 . 1087 [RFC1034] Mockapetris, P.V., "Domain names - concepts and 1088 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 1089 November 1987, . 1091 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1092 Requirement Levels", BCP 14, RFC 2119, 1093 DOI 10.17487/RFC2119, March 1997, 1094 . 1096 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1097 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1098 . 1100 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 1101 Literal IPv6 Addresses in URL's", RFC 2732, 1102 DOI 10.17487/RFC2732, December 1999, 1103 . 1105 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 1106 Inverse Discovery Specification", RFC 3122, 1107 DOI 10.17487/RFC3122, June 2001, 1108 . 1110 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1111 "DNS Extensions to Support IP Version 6", STD 88, 1112 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1113 . 1115 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1116 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1117 DOI 10.17487/RFC4861, September 2007, 1118 . 1120 Appendix A. Acknowledgment 1122 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 1123 Randriamasy and Wendy Roome for their fruitful discussions and 1124 feedback on this document. Shawn Lin also gave substantial review 1125 feedback and suggestions on the protocol design. 1127 Appendix B. Change Logs 1129 Note to Editor: Please remove this section prior to publication. 1131 This section records the change logs of the draft updates. 1133 Changes since -06 versions: 1135 * Clarify the type of "flow-spec-announcement" in both the request 1136 and the response 1138 * Modify examples to be compatible with the latest path vector 1139 document 1141 * Add a new registry for flow-specific announcements 1143 * Fix some typos 1145 Changes since -05 versions: 1147 * Add flow-specific information announcement in the flow-based 1148 filter. 1150 * Modify examples and add descriptions to Make them clear. 1152 * Rename the address type "Domain Name" to "Internet Domain Name" to 1153 distinguish it with the "Domain Name" in the unified properties 1154 draft. 1156 Changes since older versions: 1158 Changes since -04 revision: 1160 * Improve the clarity of the document by explicitly stating the 1161 problems. 1163 * Keep only "flow" in the terminology section. 1165 * Move section 6 "Advanced Flow-based Query" out of this document. 1167 * Change "ALTO Address Type Conflicts Registry" to "ALTO Address 1168 Type Compatibility Registry". 1170 Since -03 revision: 1172 * Remove some irrelevant content from the draft. 1174 * Improve the description of the new endpoint address type 1175 identifier registry. And add a new registry to declare the 1176 conflicting address type identifiers. 1178 Since -02 revision: 1180 * Change "EndpointURI" to "AddressType::EndpointAddr" for 1181 consistency. 1183 * Replace "Cost Confidence" by "Cost Statistics" for compatibility. 1185 Since -01 revision: 1187 * Define the basic flow-based query extensions for Filtered Cost Map 1188 and Endpoint Cost service. The basic flow-based query is downward 1189 compatible with the legacy ALTO service. It does not introduce 1190 any new media types. 1192 * Move the service of media-type "application/alto-flowcost+json" to 1193 the advanced flow-based query extension. It will ask ALTO server 1194 to support the new media type. 1196 Since -00 revision: 1198 * Change the schema of "pid-flows" and "endpoint-flows" fields from 1199 pair list to pair mesh list. 1201 Authors' Addresses 1203 Jingxuan Jensen Zhang 1204 China 1205 201804 1206 Shanghai 1207 4800 Caoan Road 1208 Tongji University 1210 Email: jingxuan.n.zhang@gmail.com 1212 Kai Gao 1213 China 1214 610000 1215 Chengdu 1216 No.24 South Section 1, Yihuan Road 1217 Sichuan University 1219 Email: kaigao@scu.edu.cn 1221 Junzhuo Wang 1223 Qiao Xiang 1224 Yale University 1225 51 Prospect Street 1226 New Haven, CT 1227 United States of America 1229 Email: qiao.xiang@cs.yale.edu 1231 Yang Richard Yang 1232 Yale University 1233 51 Prospect Street 1234 New Haven, CT 1235 United States of America 1237 Email: yry@cs.yale.edu