idnits 2.17.1 draft-gao-alto-fcs-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 329 has weird spacing: '...DFilter pids;...' == Line 330 has weird spacing: '...DFilter pid-f...' == Line 463 has weird spacing: '...NString addre...' == Line 464 has weird spacing: '...SONBool flo...' == Line 614 has weird spacing: '...erField requi...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Some header fields may have conflicts. For example, IPv4 fields and IPv6 fields can never appear in the same packet, nor can TCP and UDP ports. These header fields MUST not be included in the same flow filter. Otherwise, the ALTO server MUST return an ALTO error response with the error code "E_INVALID_FIELD_VALUE". As specified in Section 8.5.2 of [RFC7285], the ALTO server MAY include the "field" and the "value" in the "meta" field. In this case, the ALTO server MUST use the flow ID as the "field" and the flow filter as the "value". However, the RECOMMENDED approach is to use the FlowCostErrorMap, where the server can provide the conflicting typed header fields in the "conflicts" field of the FlowFilterError associated with the corresponding flow ID. -- The document date (December 13, 2017) is 2319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 738, but not defined == Missing Reference: 'TBD' is mentioned on line 859, but not defined -- Looks like a reference, but probably isn't: '1' on line 1230 -- Looks like a reference, but probably isn't: '4094' on line 1230 -- Looks like a reference, but probably isn't: '0' on line 1235 -- Looks like a reference, but probably isn't: '65535' on line 1235 == Unused Reference: 'RFC3986' is defined on line 1159, but no explicit reference was found in the text == Unused Reference: 'OPENFLOW' is defined on line 1185, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 6 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: June 16, 2018 Tsinghua University 6 J. Wang 7 Tongji University 8 Q. Xiang 9 Tongji/Yale University 10 Y. Yang 11 Yale University 12 December 13, 2017 14 ALTO Extension: Flow-based Cost Query 15 draft-gao-alto-fcs-04.txt 17 Abstract 19 The ALTO cost query service maps a source-destination pair into a 20 cost value, which provides a network view abstract based on a subset 21 of the 2-dimension address space. Given that the emergence of new 22 networking optimization requirements, such a query space is not 23 sufficient to uniquely identify a flow. To address the limitations 24 of the network information query space provided by the legacy ALTO 25 protocol, this document introduces two extensions: extending the 26 existing ALTO cost query services with fine-grained semantics, and 27 enabling a new flow-based query service named Flow Cost Service. 28 These extensions move ALTO to a more flexible and expressive network 29 information query space. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 16, 2018. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Overview of Approaches . . . . . . . . . . . . . . . . . . . 5 74 3.1. Flexible Flow-based Filter . . . . . . . . . . . . . . . 5 75 3.2. Extended Endpoint Address . . . . . . . . . . . . . . . . 5 76 3.3. Mapping Flow Attributes to Cost . . . . . . . . . . . . . 5 77 4. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 6 78 5. ALTO Flow Cost Specification: Basic Flow-based Query . . . . 6 79 5.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 7 80 5.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 7 81 5.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 7 82 5.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 83 5.2. Extended Endpoint Address Encoding . . . . . . . . . . . 8 84 5.2.1. Address Type . . . . . . . . . . . . . . . . . . . . 8 85 5.2.2. Address Type Conflict . . . . . . . . . . . . . . . . 9 86 5.2.3. Endpoint Address . . . . . . . . . . . . . . . . . . 9 87 5.2.4. Extended Endpoint Address Examples . . . . . . . . . 10 88 5.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 10 89 5.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 10 90 5.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 11 91 5.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 11 92 6. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 11 93 6.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 12 94 6.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 12 95 6.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 12 96 6.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 12 97 6.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 12 98 6.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 12 99 6.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 12 100 6.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 13 101 6.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 14 102 6.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 14 103 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 7.1. Information Resource Directory . . . . . . . . . . . . . 16 105 7.2. Flow-based Filtered Cost Map Service Example . . . . . . 17 106 7.3. Flow-based Endpoint Cost Service Example . . . . . . . . 18 107 7.4. Flow Cost Service Example #1 . . . . . . . . . . . . . . 19 108 7.5. Flow Cost Service Example #2 . . . . . . . . . . . . . . 21 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 111 9.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 22 112 9.2. ALTO Address Type Conflict Registry . . . . . . . . . . . 23 113 9.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 24 114 9.4. Header Field . . . . . . . . . . . . . . . . . . . . . . 25 115 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 118 11.2. Informative References . . . . . . . . . . . . . . . . . 26 119 Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 27 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 122 1. Introduction 124 An ALTO cost query service (Filtered Cost Map or Endpoint Cost 125 Service) can be regarded as a function transforming a given subset of 126 a specific query space into a network view abstract. For the legacy 127 ALTO protocol defined in [RFC7285], the query space is the 128 2-dimension address space where each flow can be uniquely identified 129 using a source-destination pair. ALTO clients can send a query with 130 source-destination pairs to an ALTO server and receive a view 131 containing the end-to-end cost for each pair. 133 Such a query schema might be sufficient for peer-to-peer (P2P) 134 applications to determine the preferred peer selection in a 135 traditional network. However, as networks are becoming more and more 136 flexible in the coming networking evolution, the limited 2-dimension 137 address space is no longer sufficient as the query space to end-to- 138 end connections. To make ALTO servers provide more accurate and 139 efficient network information, the following additional requirements 140 must be considered: 142 Req. FAR-1: ALTO servers SHOULD provide a view for a more flexible 143 flow set query space. 145 New network architectures such as Software Defined Networking 146 (SDN) collect a global network view that enables more complex 147 control functions, e.g., access control list, flow-level traffic 148 scheduling, etc. In order to adapt to such architectures, ALTO 149 servers need to support flow space queries. 151 Req. FAR-2: ALTO servers SHOULD provide a view for a more expressive 152 flow attributes space. 154 With the emerging data plane technologies, multiple header fields 155 can be used to determine the forwarding path. As a consequence, 156 networks are moving to more flexible routing mechanisms beyond the 157 simple destination-based routing. Thus, the source-destination 158 query space is no longer sufficient to provide accurate cost 159 information. ALTO servers need to support queries of network 160 information in an extended packet header space. 162 This document addresses the following issues in providing fine- 163 grained flow-based cost query services in a more flexible query 164 space: (1) the compatibility with the legacy ALTO services; (2) the 165 support for fine-grained routing system; and (3) the redundancy 166 trade-off between query and response. 168 In this document, we describe two extensions of ALTO to provide the 169 flow-based cost query. The rest of this document is organized as 170 follows. Section 5 describes the extended schema on Filtered Cost 171 Map (FCM) and Endpoint Cost Service (ECS) to support cost queries of 172 arbitrary source-destination combinations. For networks using a more 173 generic flow concept such as Software-Defined Networks, Section 6 174 defines a new ALTO service called Flow Cost Service (FCS), which 175 supports the cost query of the flow-based routing. Section 8 and 176 Section 9 discuss security and IANA considerations. 178 2. Terminology 180 This document uses the same terms as defined in [RFC7285] and 181 [RFC8189] with the following additional terms: 183 o Protocol: In this document, a protocol means a network protocol in 184 the OSI model. 186 o Application-layer protocol: In this document, an application-layer 187 protocol indicates a network protocol above layer 4 in the OSI 188 model. 190 o Port: A port means a valid TCP or UDP port number in this 191 document. 193 o Flow: A flow indicates a set of packets with similar attributes. 194 A typical definition of a flow is by a 5-tuple (protocol, source/ 195 destination addresses and ports). In this document, a flow MAY be 196 a set of packets matching a given packet header pattern. 198 3. Overview of Approaches 200 This section presents a non-normative overview of flow-based cost 201 query extensions. It assumes the readers are familiar with Filtered 202 Cost Map and Endpoint Cost Service defined in [RFC7285] and their 203 extensions defined in [RFC8189]. 205 3.1. Flexible Flow-based Filter 207 The legacy ALTO server based on [RFC7285] can provide two types of 208 flow cost query services: Filtered Cost Map and Endpoint Cost 209 Service. But both of them only support the query space in the mesh 210 shape. It can not satisfy the requirement of providing the view for 211 the flexible flow set query space. 213 This document extends the filter schema of Filtered Cost Map and 214 Endpoint Cost Service. The extended filter allows ALTO clients to 215 send multiple source-destination cross products in the same query. 216 In this way, the ALTO client can query any combinations of flow sets. 217 Also, the responses of such extended services are backward compatible 218 with legacy ALTO services. 220 3.2. Extended Endpoint Address 222 In order to support the requirement of providing the view for the 223 expressive packet header space, this document defines more types of 224 endpoint addresses to represent a flow. These extended address types 225 indicate the protocol information of flows besides encoding formats 226 of endpoint addresses. 228 Since the address types of both the source and the destination 229 specify a flow protocol, they MUST NOT conflict. This document 230 defines an address type dependency table to identify conflicts. If 231 the source and destination address types are different but do no 232 conflict, ALTO servers MUST specify the more accurate one as the flow 233 protocol. 235 3.3. Mapping Flow Attributes to Cost 237 In the emerging software-defined networks, the network control tends 238 to be based on more fine-grained flow attributes. Some advanced 239 requirements, such as the cost query for flows with endpoint- 240 independent attributes, are proposed by such use cases. However, 241 those requirements cannot be fulfilled by the extension above. To 242 support the flow-based cost query in more flexible network 243 information space, this document defines Flow Cost Service, which 244 enables ALTO clients to customize flows by specifying OpenFlow packet 245 header match fields. 247 4. Changes Since Version -01 249 Note to Editor: Please remove this section prior to publication. 251 This section records the change logs of the draft updates. 253 o Remove some irrelevant content from the draft. 255 o Improve the description of the new endpoint address type 256 identifier registry. And add a new registry to declare the 257 conflicting address type identifiers. 259 Changes since older versions: 261 Since -03 revision: 263 o Change "EndpointURI" to "AddressType::EndpointAddr" for 264 consistency. 266 o Replace Cost Confidence by Cost Statistics for compatibility. 268 Since -02 revision: 270 o Define the basic flow-based query extensions for Filtered Cost Map 271 and Endpoint Cost service. The basic flow-based query is downward 272 compatible with the legacy ALTO service. It does not introduce 273 any new media types. 275 o Move the service of media-type application/alto-flowcost+json to 276 the advanced flow-based query extension. It will ask ALTO server 277 to support the new media type. 279 Since -01 revision: 281 o Change the schema of pid-flows and endpoint-flows fields from pair 282 list to pair mesh list. 284 5. ALTO Flow Cost Specification: Basic Flow-based Query 286 This section describes backward compatible extensions for Filtered 287 Cost Map and Endpoint Cost Service to support flow-based query. 289 5.1. Flow-based Filtered Cost Map 291 5.1.1. Capabilities 293 The Filtered Cost Map capabilities are extended with a new member: 294 flow-based-filter. 296 The capability flow-based-filter indicates whether this resource 297 supports flow-based query. The FilteredCostMapCapabilities object in 298 Section 4.1.1 of [RFC8189] is extended as follows: 300 object { 301 JSONString cost-type-names<1..*>; 302 [JSONBool cost-constraints;] 303 [JSONNumber max-cost-types;] 304 [JSONString testable-cost-type-names<1..*>;] 305 [JSONBool flow-based-filter;] 306 } FilteredCostMapCapabilities; 308 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 309 of [RFC7285]. 311 max-cost-types and testable-cost-type-names: As defined in 312 Section 4.1.1 of [RFC8189]. 314 flow-based-filter: If true, a ALTO Server allows pid-flows to be 315 included in the requests. If not present, this field MUST be 316 interpreted as if it is specified false. 318 5.1.2. Accept Input Parameters 320 The ReqFilteredCostMap object in Section 4.1.2 of [RFC8189] is 321 extended as follows: 323 object { 324 [CostType cost-type;] 325 [CostType multi-cost-types<1..*>;] 326 [CostType testable-cost-types<1..*>;] 327 [JSONString constraints<0..*>;] 328 [JSONString or-constraints<1..*><1..*>;] 329 [PIDFilter pids;] 330 [PIDFilter pid-flows<1..*>;] 331 } ReqFilteredCostMap; 333 cost-type, multi-cost-types, testable-cost-types, constraints, or- 334 constraints: As defined in Section 4.1.2 of . 336 pids: As defined in Section 11.3.2.3 of [RFC7285]. 338 pid-flows: Defined as a list of PIDFilter objects defined in 339 Section 11.3.2.3 of [RFC7285]. The ALTO server MUST interpret PID 340 pairs appearing in all objects multiple times as if they appeared 341 only once. An ALTO client MUST include either pids or pid-flows 342 in a query but MUST NOT include them both at the same time. 344 5.1.3. Response 346 The response is the same as defined in Section 4.1.3 of [RFC8189]. 348 5.2. Extended Endpoint Address Encoding 350 This section extends the encoding format of endpoint addresses, 351 TypedEndpointAddr, which is defined in Section 10.4 of [RFC7285]. 352 The type TypedEndpointAddr is made up of two components: AddressType 353 and EndpointAddr. [RFC7285] only defines two address types, ipv4 and 354 ipv6", which represent IPv4 and IPv6 addresses respectively. 355 However, the flow-based ECS requires a more expressive endpoint 356 address encoding, which means more address types are required. This 357 document registers new address types and defines new formats of 358 endpoint addresses to support flow-based ECS query. 360 5.2.1. Address Type 362 This document defines new AddressType identifiers as follows: 364 eth: Indicates the ethernet interface of the host, which refers to 365 the Media-Access-Control (MAC) address. 367 domain: Indicates the host located by the domain name, which refers 368 to the the host name which can be translated to the IPv4 address. 370 domain6: Indicates the host located by the domain name, which refers 371 to the the host name which can be translated to the IPv6 address. 373 tcp: Indicates the application working on TCP on IPv4, which refers 374 to the IPv4 address or the host name which can be translated to 375 the IPv4 address with the tcp port. 377 tcp6: Indicates the application working on TCP on IPv6, which refers 378 to the IPv6 address or the host name which can be translated to 379 the IPv6 address with the tcp port. 381 udp: Indicates the application working on UDP on IPv4, which refers 382 to the IPv4 address or the host name which can be translated to 383 the IPv4 address with the tcp port. 385 udp6: Indicates the application working on UDP on IPv4, which refers 386 to the IPv4 address or the host name which can be translated to 387 the IPv4 address with the tcp port. 389 See Table 1 in Section 9.1 for a list of new AddressType identifiers 390 to be registered in the ALTO Address Type Registry. 392 5.2.2. Address Type Conflict 394 Different AddressTypes MAY conflict with each others. For example, a 395 source endpoint of an "ipv4" address cannot establish a network 396 connection with a destination endpoint of an "ipv6" address. Neither 397 the "tcp" typed source and the "udp" typed destination. It means the 398 conflicting AddressType identifiers MUST NOT appear in associated 399 source and destination endpoint addresses. So every new registered 400 ALTO AddressType identifier MUST indicate its conflicts with existing 401 address types in the ALTO Address Type Registry. 403 The AddressType identifier conflicts defined in this document are 404 listed in Section 9.2. 406 5.2.3. Endpoint Address 408 This document defines new formats of EndpointAddr as follows for the 409 new AddressType registered in Section 9.1. 411 5.2.3.1. MAC Address 413 When AddressType is eth, the EndpointAddr MUST be a MAC address, 414 which are encoded as specified by one of format EUI-48 in [EUI48] and 415 EUI-64 in [EUI64]. 417 5.2.3.2. Host Name 419 Host names are encoded as specified in Section 11 of [RFC2181]. 421 5.2.3.3. Address with Port 423 When AddressType is a layer 4 or application-layer protocol, the 424 EndpointAddr MUST be one of an IPv4/IPv6 address, a host name or an 425 address with port. An address with port is encoded as a string of 426 the format Addr:Port, with the : character as a separator. The Addr 427 component of EndpointAddr MUST be an IPv4/IPv6 address or a host 428 name. The Port component of EndpointAddr MUST be an integer between 429 1 and 65535. If the Addr component of EndpontAddr is an IPv6 430 address, the address MUST be enclosed in [" and "] characters, as 431 recommended in [RFC2732]. 433 When AddressType is an application-layer protocol and the 434 EndpointAddr is not an address with port, ALTO servers MUST use the 435 default port. The default ports of some well-known AddressType 436 identifiers are defined in Table 1 in Section 9.1. 438 5.2.4. Extended Endpoint Address Examples 440 Some valid endpoint addresses based on the above extension look like 441 follows: 443 "eth:98-e0-d9-9c-df-81" 444 "domain:www.example.com" 445 "tcp:198.51.100.34:5123" 446 "udp6:[2000::1:2345:6789:abcd]:8080" 448 5.3. Flow-based Endpoint Cost Service 450 5.3.1. Capabilities 452 The extensions of EndpointCostCapabilities are based on 453 FilteredCostMapCapabilities in Section 5.1.1 but with a new member: 454 protocols. 456 The capability address-types indicates which endpoint address types 457 are supported to be queried by this resource. For the capability 458 flow-based-filter, the true value means the ALTO server allows 459 requests to have endpoint-flows field. If not present, this field 460 MUST be interpreted as if it is specified false. 462 object { 463 [JSONString address-types<0..*>;] 464 [JSONBool flow-based-filter;] 465 } EndpointCostCapabilities : FilteredCostMapCapabilities; 467 address-types: Defines a list of JSONString indicating the supported 468 AddressType identifiers of TypedEndpointAddr in the request. All 469 the AddressType identifiers MUST be registered in the ALTO Address 470 Type Registry (see Section 14.4 of [RFC7285]). The ALTO server 471 SHOULD NOT claim ipv4 and ipv6 in this field explicitly, because 472 they are supported by default. If not present, this field MUST be 473 interpreted as if it specifies the default supported AddressType 474 ipv4 and ipv6. 476 flow-based-filter: If true, the ALTO Server allows endpoint-flows to 477 be queried in the requests. If not present, this field MUST be 478 interpreted as if it is specified false. 480 5.3.2. Accept Input Parameters 482 The ReqEndpointCostMap object in Section 4.2.2 of [RFC8189] is 483 extended as follows: 485 object { 486 [CostType cost-type;] 487 [CostType multi-cost-types<1..*>;] 488 [CostType testable-cost-types<1..*>;] 489 [JSONString constraints<0..*>;] 490 [JSONString or-constraints<1..*><1..*>;] 491 [EndpointFilter endpoints;] 492 [EndpointFilter endpoint-flows<1..*>;] 493 } ReqEndpointCostMap; 495 cost-type, multi-cost-types, testable-cost-types, constraints, or- 496 constraints: 497 As defined in Section 4.1.2 of [RFC8189]. 499 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 501 endpoint-flows: Defined as a list of EndpointFilter objects in which 502 each object is as defined in Section 11.5.1.3 of [RFC7285]. The 503 ALTO server MUST interpret endpoint pairs appearing multiple times 504 in all EndpointFilter objects as if they appeared only once. 506 If the AddressType of the source and destination in the same 507 EndpointFilter do not conform the dependencies defined in Table 1 of 508 Section 9.1, the ALTO server MUST return an ALTO error response with 509 the error code "E_INVALID_FIELD_VALUE". 511 The additional requirement is that the ALTO client MUST specify 512 either endpoints or endpoint-flows, but MUST NOT specify both. 514 5.3.3. Response 516 The response is the same as defined in Section 4.2.3 of [RFC8189]. 518 6. ALTO Flow Cost Specification: Advanced Flow-based Query 520 The basic flow-based query extends the ECS service to support 521 querying the cost of flows. However, it only supports the cost query 522 of flows defined by the 5-tuple of protocol, source/destination 523 address (host name, IP address or MAC address) and ports. In the 524 emerging software-defined networking, the concept of flow is not 525 confined by this 5-tuple anymore. Instead, [OF15] has defined 38 526 header match fields that could define a flow. This document next 527 introduces an advanced flow-based cost query service, which is called 528 Flow Cost Service, to support the flow-based cost queries for such a 529 generic context of flows. 531 6.1. Basic Data Types 533 The Flow Cost Service introduces some new basic data types, as 534 defined below. 536 6.1.1. Flow ID 538 A flow ID has the same format as a PIDName, as defined in 539 Section 10.1 of [RFC7285]. It is used to uniquely identify a flow in 540 a flow cost service request. 542 6.1.2. Typed Header Field 544 A typed header field represents a particular field in a network 545 protocol that can be obtained at the application layer. It is 546 represented by the protocol name and the field name, concatenated by 547 the colon (:, U+003A). The typed header fields are case insensitive. 548 For example, "ipv4:source" and "IPv4:source" both represent the 549 source address field used in IPv4 and "tcp:destination" represents 550 the destination port for a TCP connection. 552 See Table 4 for a list of proposed typed header fields. 554 6.2. Flow Cost Service 556 The Flow Cost Service provides cost information for each individual 557 flow specified in a request. 559 6.2.1. Media Type 561 The media type of the flow cost service is "application/alto- 562 flowcost+json". 564 6.2.2. HTTP Method 566 The flow cost service is requested using the HTTP POST method. 568 6.2.3. Accept Input Parameters 570 The input parameters of the flow cost service MUST be encoded as a 571 JSON object of type FlowCostRequest in the body of an HTTP POST 572 request. The media type of the request MUST be application/alto- 573 flowcostparams+json. 575 object { 576 FlowFilterMap flows; 577 } FlowCostRequest : MultiCostRequestBase; 579 object { 580 [CostType cost-type;] 581 [CostType multi-cost-types<1..*>;] 582 [CostType testable-cost-types<1..*>;] 583 [JSONString constraints<0..*>;] 584 [JSONString or-constraints<0..*><0..*>;] 585 } MultiCostRequestBase; 587 object-map { 588 FlowId -> FlowFilter; 589 } FlowFilterMap; 591 object-map { 592 TypedHeaderField -> JSONValue; 593 } FlowFilter; 595 flows: A map of flow filters for which path costs are to be 596 returned. Each flow filter is identified by a unique FlowId, as 597 defined in Section 6.1.1. The value type of a field is protocol- 598 specific, see Table 5 for the value type associated with typed 599 header fields in Table 4. 601 cost-type: The same as defined in Section 4.2.2 of [RFC8189]. 603 multi-cost-types: The same as defined in Section 4.2.2 of [RFC8189]. 605 testable-cost-types, constraints, or-constraints: The same as 606 defined in Section 4.2.2 of [RFC8189]. 608 6.2.4. Capabilities 610 The capabilities of the flow cost service is a JSON object of type 611 FlowCostCapabilities: 613 object { 614 [TypedHeaderField required<1..*>;] 615 [TypedHeaderField or-required<1..*><1..*>;] 616 [TypedHeaderField optional<1..*>;] 617 } FlowCostCapabilities : FilteredCostMapCapabilities; 619 with fields: 621 required: A list of required TypedHeaderFields. These 622 TypedHeaderFields are essential to find the path cost for a given 623 flow and MUST be provided in a flow filter. The "required" field 624 MUST be present if "or-required" field is not present. 626 or-required: A list of TypedHeaderField list, where each 627 TypedHeaderField list defines a combination of required 628 TypedHeaderFields. The "or-required" field claims that at least 629 one of the combination in this list MUST be provided in a flow 630 filter. As an example, a valid "or-requried" field value is 631 [[ipv4:source, ipv4:destination], [ipv6:source, 632 ipv6:destination]]. This is equivalent to the validation: For 633 each flow, assert (ipv4:source in flow AND ipv4:destination in 634 flow) OR (ipv6:soruce in flow AND ipv6:destination in flow). This 635 field MUST be present if "required" field is not present. 637 optional: A list of optional TypedHeaderFields. The ALTO server MAY 638 leverage the values of the optional TypedHeaderFields to find more 639 accurate costs. 641 6.2.5. Response 643 The "meta" field of a flow cost response MUST contain the same cost 644 type information as defined in Section 4.2.3 of [RFC8189]. 646 The data component of a flow cost service is named "flow-cost-map", 647 which is a JSON object of type FlowCostMap: 649 object { 650 FlowCostMap flow-cost-map; 651 } FlowCostResponse : ResponseEntityBase; 653 object-map { 654 FlowId -> JSONValue; 655 } FlowCostMap; 657 flow-cost-map: A dictionary map with each key (flow ID) representing 658 a flow specified in the request. For each flow, the cost MUST 659 follow the format defined in Section 4.2.3 of [RFC8189]. 661 6.2.6. Errors 663 The ALTO servers can provide more information to the clients when 664 requests have errors. The FlowCostErrorMap below can provide basic 665 information about three most common errors for the flow cost service. 666 The ALTO servers MAY include it as the data component of an ALTO 667 error response. If multiple errors are identified, the ALTO server 668 MUST return exactly one error code according to Section 8.5.2 of 669 [RFC7285] . 671 object-map { 672 FlowId -> FlowCostError; 673 } FlowCostErrorMap; 675 object { 676 [TypedHeaderField conflicts<2..*>;] 677 [TypedHeaderField missing<1..*>;] 678 [TypedHeaderField unsupported<1..*>;] 679 } FlowFilterError; 681 conflicts: A list of conflicting typed header fields. See 682 Section 6.2.6.1 for details. 684 missing: A list of missing typed header fields. See Section 6.2.6.2 685 for details. 687 unsupported: A list of unsupported typed header fields. See 688 Section 6.2.6.3 for details. 690 6.2.6.1. Conflicts 692 Some header fields may have conflicts. For example, IPv4 fields and 693 IPv6 fields can never appear in the same packet, nor can TCP and UDP 694 ports. These header fields MUST not be included in the same flow 695 filter. Otherwise, the ALTO server MUST return an ALTO error 696 response with the error code "E_INVALID_FIELD_VALUE". As specified 697 in Section 8.5.2 of [RFC7285], the ALTO server MAY include the 698 "field" and the "value" in the "meta" field. In this case, the ALTO 699 server MUST use the flow ID as the "field" and the flow filter as the 700 "value". However, the RECOMMENDED approach is to use the 701 FlowCostErrorMap, where the server can provide the conflicting typed 702 header fields in the "conflicts" field of the FlowFilterError 703 associated with the corresponding flow ID. 705 6.2.6.2. Missing Fields 707 The "E_MISSING_FIELD" error code is originally designed to report the 708 absence of required JSON fields. In the flow cost service, the 709 required typed header fields are implementation-specific and the ALTO 710 servers MUST declare the required fields in the capabilities. If any 711 required header field is missing, the ALTO server MUST return an ALTO 712 error response, with the error code "E_MISSING_FIELD". The ALTO 713 server can follow the steps defined in Section 8.5.2 of [RFC7285] to 714 indicate the location of the missing field. An alternative approach 715 which is also RECOMMENDED, is that the server provides the missing 716 typed header fields in the "missing" field of the FlowFilterError 717 associated with the corresponding flow ID. 719 6.2.6.3. Unsupported Fields 721 If a query contains unsupported typed header fields, e.g., those not 722 in the "required" nor the "optional" capabilities, the ALTO server 723 MUST return an ALTO error response, with the error code 724 "E_INVALID_FIELD_VALUE". Like how the conflicting header fields are 725 handled in Section 6.2.6.1, the ALTO servers can report unsupported 726 typed header fields in the "unsupported" field associated with the 727 corresponding flow ID. 729 7. Examples 731 7.1. Information Resource Directory 733 GET /directory HTTP/1.1 734 Host: alto.example.com 735 Accept: application/alto-directory+json,application/alto-error+json 737 HTTP/1.1 200 OK 738 Content-Length: [TODO] 739 Content-Type: application/alto-directory+json 740 { 741 "meta" : { 742 "default-alto-network-map" : "my-default-network-map", 743 "cost-types" : { 744 "num-routingcost" : { 745 "cost-mode" : "numerial", 746 "cost-metric" : "routingcost"}, 747 "ord-routingcost" : { 748 "cost-mode" : "ordinal", 749 "cost-metric" : "routingcost"} 750 }, 751 ..... 752 Other ALTO cost types as described in RFC7285 753 ..... 754 }, 755 "resources" : { 756 "my-default-network-map" : { 757 "uri" : "http://alto.example.com/networkmap", 758 "media-type" : "application/alto-networkmap+json" 759 }, 760 "basic-flow-based-cost-map" : { 761 "uri" : "http://alto.example.com/costmap/multi/filtered", 762 "media-type" : "application/alto-costmap+json", 763 "accepts" : "application/alto-costmapfilter+json", 764 "uses" : [ "my-default-network-map" ], 765 "capabilities" : { 766 "max-cost-types" : 2, 767 "flow-based-filter" : true, 768 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 769 } 770 }, 771 "basic-flow-based-endpoint-cost" : { 772 "uri" : "http://alto.example.com/endpointcost/lookup", 773 "media-type" : "application/alto-endpointcost+json", 774 "accepts" : "application/alto-endpointcostparams+json", 775 "capabilities" : { 776 "protocols": ["tcp", "http"], 777 "flow-based-filter" : true, 778 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 779 } 780 }, 781 "flow-cost-map": { 782 "uri" : "http://alto.example.com/flowcost/lookup", 783 "media-type" : "application/alto-flowcost+json", 784 "accepts" : "application/alto-flowcostparams+json", 785 "capabilities" : { 786 "or-required" : [ [ "ethernet:destination" ], 787 [ "ipv4:destination" ] ], 788 "optional" : [ "ethernet:source", "ethernet:destination", 789 "ipv4:source", "ipv4:destination", 790 "tcp:source", "tcp:destination"] 791 } 792 } 793 } 794 } 796 7.2. Flow-based Filtered Cost Map Service Example 797 POST /costmap/multi/filtered HTTP/1.1 798 Host: alto.example.com 799 Accept: application/alto-costmap+json,application/alto-error+json 800 Content-Length: [TBD] 801 Content-Type: application/alto-costmapfilter+json 803 { 804 "cost-type": { 805 "cost-mode": "numerical", 806 "cost-metric": "routingcost" 807 }, 808 "pid-flows": [ 809 { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, 810 { "srcs": ["PID3"], "dsts": ["PID4"] } 811 ] 812 } 814 HTTP/1.1 200 OK 815 Content-Length: [TBD] 816 Content-Type: application/alto-costmap+json 818 { 819 "meta": { 820 "dependent-vtags": [ 821 { 822 "resource-id": "my-default-network-map", 823 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 824 } 825 ], 826 "cost-type": { 827 "cost-mode": "numerical", 828 "cost-metric": "routingcost" 829 } 830 }, 831 "cost-map": { 832 "PID1": { "PID2": 100 }, 833 "PID1": { "PID3": 20 }, 834 "PID3": { "PID4": 80 } 835 } 836 } 838 7.3. Flow-based Endpoint Cost Service Example 839 POST /endpointcost/lookup HTTP/1.1 840 Host: alto.example.com 841 Accept: application/alto-endpointcost+json,application/alto-error+json 842 Content-Length: [TBD] 843 Content-Type: application/alto-endpointcostparams+json 845 { 846 "cost-type": { 847 "cost-mode": "numerical", 848 "cost-metric": "hopcount" 849 }, 850 "endpoint-flows": [ 851 { "srcs": ["ipv4:192.0.2.2"], 852 "dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] }, 853 { "srcs": ["tcp:203.0.113.45:54321"], 854 "dsts": ["http:cdn1.example.com"] } 855 ] 856 } 858 HTTP/1.1 200 OK 859 Content-Length: [TBD] 860 Content-Type: application/alto-endpointcost+json 862 { 863 "meta": { 864 "cost-type": { 865 "cost-mode": "numerical", 866 "cost-metric": "hopcount" 867 } 868 }, 869 "endpoint-cost-map": { 870 "ipv4:192.0.2.2": { 871 "ipv4:192.0.2.89": 3, 872 "http:cdn1.example.com": 6 873 }, 874 "tcp:203.0.113.45:54321": { 875 "http:cdn1.example.com": 10 876 } 877 } 878 } 880 7.4. Flow Cost Service Example #1 881 POST /flowcost/lookup HTTP/1.1 882 HOST: alto.example.com 883 Content-Length: 521 884 Content-Type: application/alto-flowcostparams+json 885 Accept: application/alto-flowcost+json,application/alto-error+json 887 { 888 "cost-type": { 889 "cost-mode": "numerical", 890 "cost-metric": "routingcost" 891 }, 892 "flows": { 893 "l3-flow": { 894 "ipv4:source": "192.168.1.1", 895 "ipv4:destination": "192.168.1.2" 896 }, 897 "optional-l2-flow": { 898 "ethernet:source": "12:34:56:78:00:01", 899 "ethernet:destination": "12:34:56:78:00:02" 900 }, 901 "l3-flow-aggr": { 902 "ipv4:source": "192.168.1.0/24", 903 "ipv4:destination": "192.168.2.0/24" 904 } 905 } 906 } 908 HTTP/1.1 200 OK 909 Content-Length: 312 910 Content-Type: application/alto-flowcost+json 912 { 913 "meta": { 914 "cost-type": { 915 "cost-mode": "numerical", 916 "cost-metric": "routingcost" 917 } 918 }, 919 "flow-cost-map": { 920 "l3-flow": 10, 921 "l3-flow-aggr": 50, 922 "optional-l3-flow": 5 923 } 924 } 926 7.5. Flow Cost Service Example #2 928 POST /flowcost/lookup HTTP/1.1 929 HOST: alto.example.com 930 Content-Length: 521 931 Content-Type: application/alto-flowcostparams+json 932 Accept: application/alto-flowcost+json,application/alto-error+json 934 { 935 "cost-type": { 936 "cost-mode": "ordinal", 937 "cost-metric": "hopcount" 938 }, 939 "flows": { 940 "missing-dest-flow": { 941 "ipv4:source": "192.168.1.100" 942 }, 943 "conflict-flow": { 944 "ipv4:source": "192.168.1.101", 945 "ipv6:destination": "2000::1:2345:6789:abcd" 946 }, 947 "unsupported-flow": { 948 "ipv4:source": "192.168.1.102", 949 "ipv6:destination": "192.168.2.102", 950 "ethernet:vlan-id": 1024 951 } 952 } 953 } 954 HTTP/1.1 200 OK 955 Content-Length: 312 956 Content-Type: application/alto-error+json 958 { 959 "meta": { 960 "code": "E_INVALID_FIELD_VALUE" 961 } 962 "flow-error-map": { 963 "missing-dest-flow-flow": { 964 "missing": ["ipv4:destination"] 965 }, 966 "conflict-flow": { 967 "conflicts": ["ipv4:source", "ipv6:destination"] 968 }, 969 "unsupported-flow": { 970 "unsupported": ["ethernet:vlan-id"] 971 } 972 } 973 } 975 8. Security Considerations 977 An ALTO client can send flow-based queries to the Flow Cost Service. 978 However, the ALTO server or a third party who is able to intercept 979 such messages can store and process obtained information in order to 980 analyze user behaviors and communication patterns, which has been 981 discussed in Section 15.4 of [RFC7285]. Since the fine-grained flow- 982 based query provides more information, an ALTO client should be 983 cognizant about the trade-off between redundancy and privacy. 985 9. IANA Considerations 987 This document defines two new entries to be registered to 988 application/alto-* media types. 990 9.1. ALTO Address Type Registry 992 This document defines several new address types to be registered to 993 ALTO Address Type Registry, listed in Table 1. 995 +------------+--------------------+-------------+-------------------+ 996 | Identifier | Address Encoding | Prefix | Mapping to/from | 997 | | | Encoding | IPv4/v6 | 998 +------------+--------------------+-------------+-------------------+ 999 | eth | See | None | Mapping to/from | 1000 | | Section 5.2.3.1 | | IPv4 by [RFC0903] | 1001 | | | | and [RFC0826]; | 1002 | | | | Mapping to/from | 1003 | | | | IPv6 by [RFC3122] | 1004 | | | | and [RFC4861] | 1005 | domain | See | None | Mapping to/from | 1006 | | Section 5.2.3.2 | | IPv4 by [RFC1034] | 1007 | domain6 | See | None | Mapping to/from | 1008 | | Section 5.2.3.2 | | IPv6 by [RFC3596] | 1009 | tcp | See | None | No mapping | 1010 | | Section 5.2.3.3 | | | 1011 | tcp6 | See | None | No mapping | 1012 | | Section 5.2.3.3 | | | 1013 | upd | See | None | No mapping | 1014 | | Section 5.2.3.3 | | | 1015 | udp6 | See | None | No mapping | 1016 | | Section 5.2.3.3 | | | 1017 +------------+--------------------+-------------+-------------------+ 1019 Table 1: ALTO Address Type Registry 1021 9.2. ALTO Address Type Conflict Registry 1023 This document proposes to create a new registry called ALTO Address 1024 Type Conflict Registry. The purpose of this registry is stated in 1025 Section 5.2.2. The conflicts of all existing address type 1026 identifiers and new identifiers registered in this document are 1027 listed in Table 2. 1029 +-------------+--------------------------+ 1030 | Identifier | Conflicting Identifiers | 1031 +-------------+--------------------------+ 1032 | ipv6 | ipv4 | 1033 | eth | None | 1034 | domain | ipv6 | 1035 | domain6 | ipv4, domain | 1036 | tcp | ipv6, domain6 | 1037 | tcp6 | ipv4, domain, tcp | 1038 | udp | ipv6, domain6, tcp6 | 1039 | udp6 | ipv4, domain, tcp, udp | 1040 +-------------+--------------------------+ 1042 Table 2: ALTO Address Type Conflict Registry 1044 Every address type identifier SHOULD only indicate its conflicts with 1045 the identifiers registered before it. But the conflicts in this 1046 registry MUST be followed as the bidirectional. For example, 1047 although "tcp" does not register "tcp6" as its conflicting 1048 identifier, the ALTO server MUST identify this conflict because of 1049 the registered conflicting identifiers of "tcp6". 1051 Any new ALTO address type identifier registered after this document 1052 MUST indicate their conflicting identifiers in this registry 1053 simultaneously. 1055 9.3. Media Types 1057 This document registers two media types listed in Table 3. 1059 +--------------+--------------------------+----------------+ 1060 | Type | Subtype | Specification | 1061 +--------------+--------------------------+----------------+ 1062 | application | alto-flowcost+json | Section 5.1.3 | 1063 | application | alto-flowcostparam+json | Section 5.3.2 | 1064 +--------------+--------------------------+----------------+ 1066 Table 3: ALTO FCS Media Types 1068 Type name: application 1070 Subtype name: This document registers two subtypes, as listed in 1071 Table 3. 1073 Required parameters: n/a 1075 Optional parameters: n/a 1077 Encoding considerations: Encoding considerations are identical to 1078 those specified for the "applicatoin/json" media type. See 1079 [RFC7159]. 1081 Security considerations: Security considerations are identical to 1082 those specified in Section 15 of [RFC7285]. 1084 Interoperability considerations: n/a 1086 Published specification: This document is the specification for 1087 these media types. See Table 3 for the section documenting each 1088 media type. 1090 Applications that use this media type: ALTO servers and ALTO clients 1091 with the extension to support the flow cost service, either 1092 standalone or embedded within other applications. 1094 Additional information: n/a 1096 Person & email address to contact for further information: See 1097 Authors' Addresses. 1099 Intended usage: COMMON 1101 Restrictions on usage: n/a 1103 Author: See Authors' Addresses. 1105 9.4. Header Field 1107 TBD: Create the "ALTO Header Field Name Registry". 1109 10. Acknowledgement 1111 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 1112 Randriamasy and Wendy Roome for fruitful discussions and feedback on 1113 this document. Shawn Lin provided substantial review feedback and 1114 suggestions to the protocol design. 1116 11. References 1118 11.1. Normative References 1120 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1121 Converting Network Protocol Addresses to 48.bit Ethernet 1122 Address for Transmission on Ethernet Hardware", STD 37, 1123 RFC 826, DOI 10.17487/RFC0826, November 1982, 1124 . 1126 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1127 Reverse Address Resolution Protocol", STD 38, RFC 903, 1128 DOI 10.17487/RFC0903, June 1984, . 1131 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1132 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1133 . 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, 1137 DOI 10.17487/RFC2119, March 1997, . 1140 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1141 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1142 . 1144 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 1145 Literal IPv6 Addresses in URL's", RFC 2732, 1146 DOI 10.17487/RFC2732, December 1999, . 1149 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 1150 Inverse Discovery Specification", RFC 3122, 1151 DOI 10.17487/RFC3122, June 2001, . 1154 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1155 "DNS Extensions to Support IP Version 6", STD 88, 1156 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1157 . 1159 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1160 Resource Identifier (URI): Generic Syntax", STD 66, 1161 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1162 . 1164 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1165 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1166 DOI 10.17487/RFC4861, September 2007, . 1169 11.2. Informative References 1171 [EUI48] IEEE, , "Guidelines for use of a 48-bit Extended Unique 1172 Identifier (EUI-48)", 2012, 1173 . 1175 [EUI64] IEEE, , "Guidelines for use of a 64-bit Extended Unique 1176 Identifier (EUI-64)", November 2012, 1177 . 1179 [OF15] Foundation, O., "OpenFlow Switch Specification v1.5.0", 1180 2014, 1181 . 1185 [OPENFLOW] 1186 McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 1187 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 1188 "OpenFlow: enabling innovation in campus networks", 2008. 1190 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1191 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1192 2014, . 1194 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1195 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1196 "Application-Layer Traffic Optimization (ALTO) Protocol", 1197 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1198 . 1200 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1201 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1202 DOI 10.17487/RFC8189, October 2017, . 1205 Appendix A. Tables 1207 +------------+--------------+------------------------------+ 1208 | Protocol | Field Name | Description | 1209 +------------+--------------+------------------------------+ 1210 | Ethernet | source | The source MAC address | 1211 | | destination | The destination MAC address | 1212 | | vlan-id | VLAN-ID from 802.1Q header | 1213 | IPv4 | source | IPv4 source address | 1214 | | destination | IPv4 destination address | 1215 | IPv6 | source | IPv6 source address | 1216 | | destination | IPv6 destination address | 1217 | TCP | source | TCP source port | 1218 | | destination | TCP destination port | 1219 | UDP | source | UDP source port | 1220 | | destination | UDP destination port | 1221 +------------+--------------+------------------------------+ 1223 Table 4: Protocols and Field Names. 1225 +-----------------------+-------------------------------------------+ 1226 | Typed Header Field | Acceptable Value Type | 1227 +-----------------------+-------------------------------------------+ 1228 | ethernet:source | JSONString as MAC address | 1229 | ethernet:destination | | 1230 | ethernet:vlan-id | JSONNumber in the range of [1, 4094] | 1231 | ipv4:source | JSONString as IPv4 address or IPv4 prefix | 1232 | ipv4:destination | | 1233 | ipv6:source | JSONString as IPv6 address or IPv6 prefix | 1234 | ipv6:destination | | 1235 | tcp:source | JSONNumber in the range of [0, 65535] | 1236 | tcp:destination | 0 serves as a wildcard value | 1237 | udp:source | | 1238 | udp:destination | | 1239 +-----------------------+-------------------------------------------+ 1241 Table 5: Value Types for Typed Header Fields 1243 Authors' Addresses 1245 Jingxuan Jensen Zhang 1246 Tongji University 1247 4800 Cao'an Hwy 1248 Shanghai 201804 1249 China 1251 Email: jingxuan.n.zhang@gmail.com 1253 Kai Gao 1254 Tsinghua University 1255 30 Shuangqinglu Street 1256 Beijing 100084 1257 China 1259 Email: gaok12@mails.tsinghua.edu.cn 1261 Junzhuo Austin Wang 1262 Tongji University 1263 4800 Cao'an Hwy, Jiading District 1264 Shanghai 1265 China 1267 Email: wangjunzhuo200@gmail.com 1268 Qiao Xiang 1269 Tongji/Yale University 1270 51 Prospect Street 1271 New Haven, CT 1272 USA 1274 Email: qiao.xiang@cs.yale.edu 1276 Y. Richard Yang 1277 Yale University 1278 51 Prospect St 1279 New Haven CT 1280 USA 1282 Email: yry@cs.yale.edu