idnits 2.17.1 draft-gao-alto-fcs-03.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 5 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 320 has weird spacing: '...DFilter pids;...' == Line 321 has weird spacing: '...DFilter pid-f...' == Line 436 has weird spacing: '...NString proto...' == Line 437 has weird spacing: '...SONBool flo...' == Line 675 has weird spacing: '...NNumber valu...' == (6 more instances...) == 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 (July 4, 2017) is 2478 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 499, but not defined == Missing Reference: 'TBD' is mentioned on line 609, but not defined -- Looks like a reference, but probably isn't: '1' on line 1107 -- Looks like a reference, but probably isn't: '4094' on line 1107 -- Looks like a reference, but probably isn't: '0' on line 1112 -- Looks like a reference, but probably isn't: '65535' on line 1112 == Unused Reference: 'RFC3986' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-alto-ecs-flows' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'OPENFLOW' is defined on line 1067, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) == Outdated reference: A later version (-10) exists of draft-ietf-alto-multi-cost-05 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG K. Gao 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track J. Zhang 5 Expires: January 5, 2018 J. Wang 6 Tongji University 7 Q. Xiang 8 Tongji/Yale University 9 Y. Yang 10 Yale University 11 July 4, 2017 13 ALTO Extension: Flow-based Cost Query 14 draft-gao-alto-fcs-03.txt 16 Abstract 18 The Endpoint Cost Service maps a source-destination pair into a cost 19 value, which provides an abstract network view based on a subset of 20 the 2-dimension address space. Given that the emergence of new 21 networking datapath capabilities has substantially increased the 22 routing flexibility, such a query space is not sufficient to uniquely 23 identify a flow. To address the limitations of the network 24 information query space provided by the legacy ALTO protocol, this 25 document takes two approaches: extending the existing ALTO cost query 26 services with fine-grained semantics, and enabling a new flow-based 27 query service named Flow Cost Service. These extensions move ALTO to 28 a more flexible and expressive network information query space. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 January 5, 2018. 53 Copyright Notice 55 Copyright (c) 2017 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 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Overview of Approaches . . . . . . . . . . . . . . . . . . . 5 73 3.1. Backward Compatible Flow-based Filter . . . . . . . . . . 5 74 3.2. Extended Endpoint Address . . . . . . . . . . . . . . . . 5 75 3.3. Flow Cost Service for Advanced Query . . . . . . . . . . 5 76 4. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 6 77 5. ALTO Flow Cost Specification: Basic Flow-based Query . . . . 6 78 5.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 6 79 5.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 6 80 5.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 7 81 5.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 82 5.2. Extended Endpoint Address Encoding . . . . . . . . . . . 8 83 5.2.1. Address Type . . . . . . . . . . . . . . . . . . . . 8 84 5.2.2. Endpoint Address . . . . . . . . . . . . . . . . . . 8 85 5.2.3. Extended Endpoint Address Examples . . . . . . . . . 9 86 5.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 9 87 5.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 9 88 5.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 10 89 5.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 11 90 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 91 5.4.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 11 92 5.4.2. Flow-based Filtered Cost Map Service Example . . . . 12 93 5.4.3. Flow-based Endpoint Cost Service Example . . . . . . 13 94 6. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 14 95 6.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 15 96 6.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 15 97 6.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 15 98 6.1.3. Cost Statistics . . . . . . . . . . . . . . . . . . . 15 99 6.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 16 100 6.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 16 101 6.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 16 102 6.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 16 103 6.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 17 104 6.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 17 105 6.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 18 106 6.3. Flow Cost Service Example . . . . . . . . . . . . . . . . 19 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 109 8.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 21 110 8.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 22 111 8.3. Header Field . . . . . . . . . . . . . . . . . . . . . . 23 112 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 114 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 115 10.2. Informative References . . . . . . . . . . . . . . . . . 24 116 Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 25 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 119 1. Introduction 121 The nature of ALTO Endpoint Cost Service can be regarded as a 122 function transforming a given subset of a specific query space into 123 an abstract network view. For the legacy ALTO protocol defined in 124 [RFC7285], the query space is the 2-dimension address space where 125 each flow can be uniquely identified using a source-destination pair. 126 ALTO clients can send a query with source-destination pairs to an 127 ALTO server and receive a view containing the end-to-end cost for 128 each pair. 130 Such a query schema might be sufficient for peer-to-peer (P2P) 131 applications to determine the preferred peer selection in a 132 traditional network. However, as networks are becoming more and more 133 flexible in the coming networking evolution, the limited 2-dimension 134 address space is no longer sufficient as the query space to end-to- 135 end connections. To make ALTO more accurate and efficient, the 136 following additional requirements must be fulfilled: 138 Req. FAR-1: ALTO servers SHOULD provide a view for a more flexible 139 flow set query space. 141 New network architectures such as Software Defined Networking 142 (SDN) collect a global network view that enables more complex 143 control functions, e.g., access control list, flow-level traffic 144 scheduling, etc. In order to adapt to such architectures, ALTO 145 servers need to support flow space queries. 147 Req. FAR-2: ALTO servers SHOULD provide a view for a more expressive 148 packet header space. 150 With the emerging data plane technologies, multiple header fields 151 can be used to determine the forwarding path. As a consequence, 152 networks are moving to more flexible routing mechanisms beyond the 153 simple destination-based routing. Thus, the source-destination 154 query space is no longer sufficient to provide accurate cost 155 information. ALTO servers need to support queries of network 156 information in an extended packet header space. 158 This document addresses the following issues in providing fine- 159 grained flow-based cost query services in a more flexible query 160 space: (1) the compatibility with the legacy ALTO services; (2) the 161 support for emerging network architectures such as Software Defined 162 Networking; and 3) the redundancy trade-off between query and 163 response. 165 In this document, we describe two extensions of ALTO to provide the 166 flow-based cost query. The rest of this document is organized as 167 follows. Section 5 describes the extended schema on Filtered Cost 168 Map (FCM) and Endpoint Cost Service (ECS) to support cost queries of 169 arbitrary source-destination combinations. For networks using a more 170 generic flow concept such as Software-Defined Networks, Section 6 171 defines a flow-based novel ALTO service named the Flow Cost Service 172 (FCS), which supports the query of any fine-grained routing cost and 173 satisfies the growing demand of obtaining accurate costs in a network 174 using flow-based routing. Section 7 and Section 8 discuss security 175 and IANA considerations. 177 2. Terminology 179 This document uses the same terms as defined in [RFC7285] and 180 [I-D.ietf-alto-multi-cost] with the following additional terms: 182 o Protocol: In this document, a protocol means a network protocol in 183 the OSI model. 185 o Application-layer protocol: In this document, an application-layer 186 protocol indicates a network protocol above layer 4 in the OSI 187 model. 189 o Port: A port means a valid TCP or UDP port number in this 190 document. 192 o Flow: A flow indicates a set of packets with similar attributes. 193 A typical definition of a flow is by a 5-tuple (protocol, source/ 194 destination addresses and ports). In this document, a flow MAY be 195 a set of packets matching a given packet header pattern. 197 3. Overview of Approaches 199 This section presents a non-normative overview of flow-based query 200 extensions. It assumes the readers are familiar with Filtered Cost 201 Map and Endpoint Cost Service defined in [RFC7285] and their 202 extensions defined in [I-D.ietf-alto-multi-cost]. 204 3.1. Backward Compatible Flow-based Filter 206 The legacy ALTO server based on [RFC7285] can provide two types of 207 flow cost query services: Filtered Cost Map and Endpoint Cost 208 Service. But both of them only support the query space in the mesh 209 shape. It can not satisfy the requirement of providing the view for 210 the flexible flow set query space. 212 This document extends the filter schema of Filtered Cost Map and 213 Endpoint Cost Service. The extended filter allows ALTO clients to 214 send multiple source-destination cross products in the same query. 215 In this way, the ALTO client can query any combinations of flow sets. 216 Also, the responses of such extended services are backward compatible 217 with legacy ALTO services. 219 3.2. Extended Endpoint Address 221 In order to support the requirement of providing the view for the 222 expressive packet header space, this document defines more types of 223 endpoint addresses to represent a flow. These extended address types 224 indicate the protocol information of flows besides encoding formats 225 of endpoint addresses. 227 Since the address types of both the source and the destination 228 specify a flow protocol, they MUST NOT conflict. This document 229 defines an address type dependency table to identify conflicts. If 230 the source and destination address types are different but do no 231 conflict, ALTO servers MUST specify the more accurate one as the flow 232 protocol. 234 3.3. Flow Cost Service for Advanced Query 236 In the emerging software-defined networks, the network control tends 237 to be based on more fine-grained flow attributes. Some advanced 238 requirements, such as the cost query for flows with endpoint- 239 independent attributes, are proposed by such use cases. However, 240 those requirements cannot be fulfilled by the extension above. To 241 support the flow-based cost query in more flexible network 242 information space, this document defines Flow Cost Service, which 243 enables ALTO clients to customize flows by specifying OpenFlow packet 244 header match fields. 246 4. Changes Since Version -01 248 Note to Editor: Please remove this section prior to publication. 250 This section records the change logs of the draft updates. 252 o Change "EndpointURI" to "AddressType::EndpointAddr" for 253 consistency. 255 o Replace "Cost Confidence" by "Cost Statistics" for compatibility. 257 Changes since older versions: 259 Since -01 revision: 261 o Change the schema of "pid-flows" and "endpoint-flows" fields from 262 pair list to pair mesh list. 264 Since -02 revision: 266 o Define the basic flow-based query extensions for Filtered Cost Map 267 and Endpoint Cost service. The basic flow-based query is downward 268 compatible with the legacy ALTO service. It does not introduce 269 any new media types. 271 o Move the service of media-type "application/alto-flowcost+json" to 272 the advanced flow-based query extension. It will ask ALTO server 273 to support the new media type. 275 5. ALTO Flow Cost Specification: Basic Flow-based Query 277 This section describes backward compatible extensions for Filtered 278 Cost Map and Endpoint Cost Service to support flow-based query. 280 5.1. Flow-based Filtered Cost Map 282 5.1.1. Capabilities 284 The Filtered Cost Map capabilities are extended with a new member: 285 flow-based-filter. 287 The capability "flow-based-filter" indicates whether this resource 288 supports flow-based query. The FilteredCostMapCapabilities object in 289 Section 4.1.1 of [I-D.ietf-alto-multi-cost] is extended as follows: 291 object { 292 JSONString cost-type-names<1..*>; 293 [JSONBool cost-constraints;] 294 [JSONNumber max-cost-types;] 295 [JSONString testable-cost-type-names<1..*>;] 296 [JSONBool flow-based-filter;] 297 } FilteredCostMapCapabilities; 299 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 300 of [RFC7285]. 302 max-cost-types and testable-cost-type-names: As defined in 303 Section 4.1.1 of [I-D.ietf-alto-multi-cost]. 305 flow-based-filter: If true, a ALTO Server allows pid-flows to be 306 included in the requests. If not present, this field MUST be 307 interpreted as if it is specified false. 309 5.1.2. Accept Input Parameters 311 The ReqFilteredCostMap object in Section 4.1.2 of 312 [I-D.ietf-alto-multi-cost] is extended as follows: 314 object { 315 [CostType cost-type;] 316 [CostType multi-cost-types<1..*>;] 317 [CostType testable-cost-types<1..*>;] 318 [JSONString constraints<0..*>;] 319 [JSONString or-constraints<1..*><1..*>;] 320 [PIDFilter pids;] 321 [PIDFilter pid-flows<1..*>;] 322 } ReqFilteredCostMap; 324 cost-type, multi-cost-types, testable-cost-types, constraints, or- 325 constraints: As defined in Section 4.1.2 of 326 [I-D.ietf-alto-multi-cost]. 328 pids: As defined in Section 11.3.2.3 of [RFC7285]. 330 pid-flows: Defined as a list of PIDFilter objects defined in 331 Section 11.3.2.3 of [RFC7285]. The ALTO server MUST interpret PID 332 pairs appearing in all objects multiple times as if they appeared 333 only once. An ALTO client MUST include either "pids" or "pid- 334 flows" in a query but MUST NOT include them both at the same time. 336 5.1.3. Response 338 The response is the same as defined in Section 4.1.3 of 339 [I-D.ietf-alto-multi-cost]. 341 5.2. Extended Endpoint Address Encoding 343 This section extends the encoding format of endpoint addresses, 344 TypedEndpointAddr, which is defined in Section 10.4 of [RFC7285]. 345 The type TypedEndpointAddr is made up of two components: AddressType 346 and EndpointAddr. [RFC7285] only defines two address types, "ipv4" 347 and "ipv6"", which represent IPv4 and IPv6 addresses respectively. 348 However, the flow-based ECS requires a more expressive endpoint 349 address encoding, which means more address types are required. This 350 document registers new address types and defines new formats of 351 endpoint addresses to support flow-based ECS query. 353 5.2.1. Address Type 355 This document defines three new categories of address type values for 356 AddressType: 358 Layer 2 (L2) protocol: The value of AddressType can be a layer 2 359 protocol, e.g. "eth", which refers to MAC addresses. 361 Layer 4 (L4) protocol: The value of AddressType can be a layer 4 362 protocol, e.g. "tcp" and "udp", which can refer to IPv4/IPv6 363 addresses and host names, with optional tcp/udp ports. 365 Application-layer protocol: The value of AddressType can be an 366 application-layer protocol, e.g. "ftp", "http", etc., which can 367 refer to IPv4/IPv6 addresses and host names, with optional tcp/udp 368 ports. 370 See Table 1 in Section 8.1 for a list of new AddressType identifiers 371 to be registered in the "ALTO Address Type Registry". 373 Because protocols in different layers conform some type-length-value 374 (TLV) dependencies, the AddressType identifiers missing the 375 dependencies MUST NOT appear in associated source and destination 376 endpoint addresses. The AddressType identifier dependencies defined 377 in this document are also defined in Section 8.1. 379 5.2.2. Endpoint Address 381 This document defines new formats of EndpointAddr as follows for the 382 new AddressType registered in Section 8.1. 384 5.2.2.1. MAC Address 386 When AddressType is "eth", the EndpointAddr MUST be a MAC address, 387 which are encoded as specified by one of format EUI-48 in [EUI48] and 388 EUI-64 in [EUI64]. 390 5.2.2.2. Host Name 392 Host names are encoded as specified in Section 11 of [RFC2181]. 394 5.2.2.3. Address with Port 396 When AddressType is a layer 4 or application-layer protocol, the 397 EndpointAddr MUST be one of an IPv4/IPv6 address, a host name or an 398 address with port. An address with port is encoded as a string of 399 the format Addr:Port, with the ':' character as a separator. The 400 Addr component of EndpointAddr MUST be an IPv4/IPv6 address or a host 401 name. The Port component of EndpointAddr MUST be an integer between 402 1 and 65535. If the Addr component of EndpontAddr is an IPv6 403 address, the address MUST be enclosed in "[" and "]" characters, as 404 recommended in [RFC2732]. 406 When AddressType is an application-layer protocol and the 407 EndpointAddr is not an address with port, ALTO servers MUST use the 408 default port. The default ports of some well-known AddressType 409 identifiers are defined in Table 1 in Section 8.1. 411 5.2.3. Extended Endpoint Address Examples 413 Some valid endpoint addresses based on the above extension look like 414 follows: 416 "eth:98-e0-d9-9c-df-81" 417 "http:www.example.com" 418 "ftp:198.51.100.34:5123" 419 "tcp:[2000::1:2345:6789:abcd]:8080" 421 5.3. Flow-based Endpoint Cost Service 423 5.3.1. Capabilities 425 The extensions of EndpointCostCapabilities are based on 426 FilteredCostMapCapabilities in Section 5.1.1 but with a new member: 427 protocols. 429 The capability "protocols" indicates which protocols are supported to 430 be queried by this resource. For the capability "flow-based-filter", 431 the true value means the ALTO server allows requests to have 432 "endpoint-flows" field. If not present, this field MUST be 433 interpreted as if it is specified false. 435 object { 436 [JSONString protocols<0..*>;] 437 [JSONBool flow-based-filter;] 438 } EndpointCostCapabilities : FilteredCostMapCapabilities; 440 protocols: Defines a list of JSONString indicating the supported 441 AddressType identifiers of TypedEndpointAddr in the request. The 442 ALTO server SHOULD NOT claim "ipv4" and "ipv6" in this field 443 explicitly, because they are supported by default. If not 444 present, this field MUST be interpreted as if it specifies the 445 default supported AddressType "ipv4" and "ipv6". 447 flow-based-filter: If true, the ALTO Server allows endpoint-flows to 448 be queried in the requests. If not present, this field MUST be 449 interpreted as if it is specified false. 451 5.3.2. Accept Input Parameters 453 The ReqEndpointCostMap object in Section 4.2.2 of 454 [I-D.ietf-alto-multi-cost] is extended as follows: 456 object { 457 [CostType cost-type;] 458 [CostType multi-cost-types<1..*>;] 459 [CostType testable-cost-types<1..*>;] 460 [JSONString constraints<0..*>;] 461 [JSONString or-constraints<1..*><1..*>;] 462 [EndpointFilter endpoints;] 463 [EndpointFilter endpoint-flows<1..*>;] 464 } ReqEndpointCostMap; 466 cost-type, multi-cost-types, testable-cost-types, constraints, or- 467 constraints: 468 As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost]. 470 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 472 endpoint-flows: Defined as a list of EndpointFilter objects in which 473 each object is as defined in Section 11.5.1.3 of [RFC7285]. The 474 ALTO server MUST interpret endpoint pairs appearing multiple times 475 in all EndpointFilter objects as if they appeared only once. 477 If the AddressType of the source and destination in the same 478 EndpointFilter do not conform the dependencies defined in Table 1 of 479 Section 8.1, the ALTO server MUST return an ALTO error response with 480 the error code "E_INVALID_FIELD_VALUE". 482 The additional requirement is that the ALTO client MUST specify 483 either "endpoints" or "endpoint-flows", but MUST NOT specify both. 485 5.3.3. Response 487 The response is the same as defined in Section 4.2.3 of 488 [I-D.ietf-alto-multi-cost]. 490 5.4. Examples 492 5.4.1. IRD Example 494 GET /directory HTTP/1.1 495 Host: alto.example.com 496 Accept: application/alto-directory+json,application/alto-error+json 498 HTTP/1.1 200 OK 499 Content-Length: [TODO] 500 Content-Type: application/alto-directory+json 501 { 502 "meta" : { 503 "default-alto-network-map" : "my-default-network-map", 504 "cost-types" : { 505 "num-routingcost" : { 506 "cost-mode" : "numerial", 507 "cost-metric" : "routingcost"}, 508 "ord-routingcost" : { 509 "cost-mode" : "ordinal", 510 "cost-metric" : "routingcost"} 511 }, 512 ..... 513 Other ALTO cost types as described in RFC7285 514 ..... 515 }, 516 "resources" : { 517 "my-default-network-map" : { 518 "uri" : "http://alto.example.com/networkmap", 519 "media-type" : "application/alto-networkmap+json" 520 }, 521 "basic-flow-based-cost-map" : { 522 "uri" : "http://alto.example.com/costmap/multi/filtered", 523 "media-type" : "application/alto-costmap+json", 524 "accepts" : "application/alto-costmapfilter+json", 525 "uses" : [ "my-default-network-map" ], 526 "capabilities" : { 527 "max-cost-types" : 2, 528 "flow-based-filter" : true, 529 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 530 } 531 }, 532 "basic-flow-based-endpoint-cost" : { 533 "uri" : "http://alto.example.com/endpointcost/lookup", 534 "media-type" : "application/alto-endpointcost+json", 535 "accepts" : "application/alto-endpointcostparams+json", 536 "uses" : [ "my-default-network-map" ], 537 "capabilities" : { 538 "protocols": ["tcp", "http"], 539 "flow-based-filter" : true, 540 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 541 } 542 } 543 } 544 } 546 5.4.2. Flow-based Filtered Cost Map Service Example 547 POST /costmap/multi/filtered HTTP/1.1 548 Host: alto.example.com 549 Accept: application/alto-costmap+json,application/alto-error+json 550 Content-Length: [TBD] 551 Content-Type: application/alto-costmapfilter+json 553 { 554 "cost-type": { 555 "cost-mode": "numerical", 556 "cost-metric": "routingcost" 557 }, 558 "pid-flows": [ 559 { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, 560 { "srcs": ["PID3"], "dsts": ["PID4"] } 561 ] 562 } 564 HTTP/1.1 200 OK 565 Content-Length: [TBD] 566 Content-Type: application/alto-costmap+json 568 { 569 "meta": { 570 "dependent-vtags": [ 571 { 572 "resource-id": "my-default-network-map", 573 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 574 } 575 ], 576 "cost-type": { 577 "cost-mode": "numerical", 578 "cost-metric": "routingcost" 579 } 580 }, 581 "cost-map": { 582 "PID1": { "PID2": 100 }, 583 "PID1": { "PID3": 20 }, 584 "PID3": { "PID4": 80 } 585 } 586 } 588 5.4.3. Flow-based Endpoint Cost Service Example 589 POST /endpointcost/lookup HTTP/1.1 590 Host: alto.example.com 591 Accept: application/alto-endpointcost+json,application/alto-error+json 592 Content-Length: [TBD] 593 Content-Type: application/alto-endpointcostparams+json 595 { 596 "cost-type": { 597 "cost-mode": "numerical", 598 "cost-metric": "hopcount" 599 }, 600 "endpoint-flows": [ 601 { "srcs": ["ipv4:192.0.2.2"], 602 "dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] }, 603 { "srcs": ["tcp:203.0.113.45:54321"], 604 "dsts": ["http:cdn1.example.com"] } 605 ] 606 } 608 HTTP/1.1 200 OK 609 Content-Length: [TBD] 610 Content-Type: application/alto-endpointcost+json 612 { 613 "meta": { 614 "cost-type": { 615 "cost-mode": "numerical", 616 "cost-metric": "hopcount" 617 } 618 }, 619 "endpoint-cost-map": { 620 "ipv4:192.0.2.2": { 621 "ipv4:192.0.2.89": 3, 622 "http:cdn1.example.com": 6 623 }, 624 "tcp:203.0.113.45:54321": { 625 "http:cdn1.example.com": 10 626 } 627 } 628 } 630 6. ALTO Flow Cost Specification: Advanced Flow-based Query 632 The basic flow-based query extends the ECS service to support 633 querying the cost of flows. However, it only supports the cost query 634 of flows defined by the 5-tuple of protocol, source/destination 635 address (host name, IP address or MAC address) and ports. In the 636 emerging software-defined networking, the concept of flow is not 637 confined by this 5-tuple anymore. Instead, [OF15] has defined 38 638 header match fields that could define a flow. This document next 639 introduces an advanced flow-based cost query service, which is called 640 Flow Cost Service, to support the flow-based cost queries for such a 641 generic context of flows. 643 6.1. Basic Data Types 645 The Flow Cost Service introduces some new basic data types, as 646 defined below. 648 6.1.1. Flow ID 650 A flow ID has the same format as a PIDName, as defined in 651 Section 10.1 of [RFC7285]. It is used to uniquely identify a flow in 652 a flow cost service request. 654 6.1.2. Typed Header Field 656 A typed header field represents a particular field in a network 657 protocol that can be obtained at the application layer. It is 658 represented by the protocol name and the field name, concatenated by 659 the colon (':', U+003A). The typed header fields are case 660 insensitive. For example, "ipv4:source" and "IPv4:source" both 661 represent the source address field used in IPv4 and "tcp:destination" 662 represents the destination port for a TCP connection. 664 See Table 3 for a list of proposed typed header fields. 666 6.1.3. Cost Statistics 668 This document defines a new cost mode, "statistical", for those 669 frequently updated cost metrics. This cost mode indicates that the 670 cost values represent statistics of the actual costs in some 671 duration. The values are specified as the CostStatistics object, 672 which is defined as follows: 674 object { 675 JSONNumber value; 676 [JSONNumber min;] 677 [JSONNumber max;] 678 [JSONNumber average;] 679 [JSONNumber variance;] 680 [JSONNumber duration;] 681 } CostStatistics; 683 value: The current value of the cost estimation. 685 min: The minimum cost value in the estimated duration. 687 max: The maximum cost value in the estimated duration. 689 avarage: The average cost value in the estimated duration. 691 variance: The variance of the historical cost values in the 692 estimated duration. 694 duration: The length of the estimated duration. 696 6.2. Flow Cost Service 698 The Flow Cost Service provides cost information for each individual 699 flow specified in a request. 701 6.2.1. Media Type 703 The media type of the flow cost service is "application/alto- 704 flowcost+json". 706 6.2.2. HTTP Method 708 The flow cost service is requested using the HTTP POST method. 710 6.2.3. Accept Input Parameters 712 The input parameters of the flow cost service MUST be encoded as a 713 JSON object of type FlowCostRequest in the body of an HTTP POST 714 request. The media type of the request MUST be "application/alto- 715 flowcostparams+json". 717 object { 718 FlowFilterMap flows; 719 } FlowCostRequest : MultiCostRequestBase; 721 object { 722 [CostType cost-type;] 723 [CostType multi-cost-types<1..*>;] 724 [CostType testable-cost-types<1..*>;] 725 [JSONString constraints<0..*>;] 726 [JSONString or-constraints<0..*><0..*>;] 727 } MultiCostRequestBase; 729 object-map { 730 FlowId -> FlowFilter; 731 } FlowFilterMap; 732 object-map { 733 TypedHeaderField -> JSONValue; 734 } FlowFilter; 736 flows: A map of flow filters for which path costs are to be 737 returned. Each flow filter is identified by a unique FlowId, as 738 defined in Section 6.1.1. The value type of a field is protocol- 739 specific, see Table 4 for the value type associated with typed 740 header fields in Table 3. 742 cost-type: The same as defined in Section 4.2.2 of 743 [I-D.ietf-alto-multi-cost]. 745 multi-cost-types: The same as defined in Section 4.2.2 of 746 [I-D.ietf-alto-multi-cost]. 748 testable-cost-types, constraints, or-constraints: The same as 749 defined in Section 4.2.2 of [I-D.ietf-alto-multi-cost]. 751 6.2.4. Capabilities 753 The capabilities of the flow cost service is a JSON object of type 754 FlowCostCapabilities: 756 object { 757 TypedHeaderField required<1..*>; 758 [TypedHeaderField optional<1..*>;] 759 } FlowCostCapabilities : FilteredCostMapCapabilities; 761 with fields: 763 required: A list of required typed header fields. These fields are 764 essential to find the path cost for a given flow and MUST be 765 provided in a flow filter. 767 optional: A list of optional typed header fields. The ALTO server 768 MAY leverage the values of the optional fields to find more 769 accurate costs. 771 6.2.5. Response 773 The "meta" field of a flow cost response MUST contain the same cost 774 type information as defined in Section 4.2.3 of 775 [I-D.ietf-alto-multi-cost]. 777 The data component of a flow cost service is named "flow-cost-map", 778 which is a JSON object of type FlowCostMap: 780 object { 781 FlowCostMap flow-cost-map; 782 } FlowCostResponse : ResponseEntityBase; 784 object-map { 785 FlowId -> JSONValue; 786 } FlowCostMap; 788 flow-cost-map: A dictionary map with each key (flow ID) representing 789 a flow specified in the request. For each flow, the cost MUST 790 follow the format defined in Section 4.2.3 of 791 [I-D.ietf-alto-multi-cost]. 793 6.2.6. Errors 795 The ALTO servers can provide more information to the clients when 796 requests have errors. The FlowCostErrorMap below can provide basic 797 information about two most common errors for the flow cost service. 798 The ALTO servers MAY include it as the data component of an ALTO 799 error response. If multiple errors are identified, the ALTO server 800 MUST return exactly one error code according to Section 8.5.2 of 801 [RFC7285] . 803 object-map { 804 FlowId -> FlowCostError; 805 } FlowCostErrorMap; 807 object { 808 [TypedHeaderField conflicts<2..*>;] 809 [TypedHeaderField missing<2..*>;] 810 [TypedHeaderField unsupported<1..*>;] 811 } FlowFilterError; 813 conflicts: A list of conflicting typed header fields. See 814 Section 6.2.6.1 for details. 816 missing: A list of missing typed header fields. See Section 6.2.6.2 817 for details. 819 unsupported: A list of unsupported typed header fields. See 820 Section 6.2.6.3 for details. 822 6.2.6.1. Conflicts 824 Some header fields may have conflicts. For example, IPv4 fields and 825 IPv6 fields can never appear in the same packet, nor can TCP and UDP 826 ports. These header fields MUST not be included in the same flow 827 filter. Otherwise, the ALTO server MUST return an ALTO error 828 response with the error code "E_INVALID_FIELD_VALUE". As specified 829 in Section 8.5.2 of [RFC7285], the ALTO server MAY include the 830 "field" and the "value" in the "meta" field. In this case, the ALTO 831 server MUST use the flow ID as the "field" and the flow filter as the 832 "value". However, the recommended approach is to use the 833 FlowCostErrorMap, where the server can provide the conflicting typed 834 header fields in the "conflicts" field of the FlowFilterError 835 associated with the corresponding flow ID. 837 6.2.6.2. Missing Fields 839 The "E_MISSING_FIELD" error code is originally designed to report the 840 absence of required JSON fields. In the flow cost service, the 841 required typed header fields are implementation-specific and the ALTO 842 servers MUST declare the required fields in the capabilities. If any 843 required header field is missing, the ALTO server MUST return an ALTO 844 error response, with the error code "E_MISSING_FIELD". The ALTO 845 server can follow the steps defined in Section 8.5.2 of [RFC7285] to 846 indicate the location of the missing field. An alternative approach 847 which is also recommended, is that the server provide the missing 848 typed header fields in the "missing" field of the FlowFilterError 849 associated with the corresponding flow ID. 851 6.2.6.3. Unsupported Fields 853 If a query contains unsupported typed header fields, e.g., those not 854 in the "required" nor the "optional" capabilities, the ALTO server 855 MUST return an ALTO error response, with the error code 856 "E_INVALID_FIELD_VALUE". Like how the conflicting header fields are 857 handled in Section 6.2.6.1, the ALTO servers can report unsupported 858 typed header fields in the "unsupported" field associated with the 859 corresponding flow ID. 861 6.3. Flow Cost Service Example 862 POST /flowcost/lookup HTTP/1.1 863 HOST: alto.example.com 864 Content-Length: 521 865 Content-Type: application/alto-flowcostparams+json 866 Accept: application/alto-flowcost+json,application/alto-error+json 868 { 869 "cost-type": { 870 "cost-mode": "statistical", 871 "cost-metric": "routingcost" 872 }, 873 "flows": { 874 "l3-flow": { 875 "ipv4:source": "192.168.1.1", 876 "ipv4:destination": "192.168.1.2" 877 }, 878 "optional-l2-flow": { 879 "ethernet:source": "12:34:56:78:00:01", 880 "ethernet:destination": "12:34:56:78:00:02" 881 }, 882 "l3-flow-aggr": { 883 "ipv4:source": "192.168.1.0/24", 884 "ipv4:destination": "192.168.2.0/24" 885 } 886 } 887 } 889 HTTP/1.1 200 OK 890 Content-Length: 312 891 Content-Type: application/alto-flowcost+json 893 { 894 "meta": { 895 "cost-type": { 896 "cost-mode": "statistical", 897 "cost-metric": "routingcost" 898 } 899 }, 900 "flow-cost-map": { 901 "l3-flow": {"value": 10, "average": 15}, 902 "l3-flow-aggr": {"value": 50, "average": 45}, 903 "optional-l3-flow": {"value": 5, "average": 5} 904 } 905 } 907 7. Security Considerations 909 An ALTO client can send flow-based queries to the Flow Cost Service. 910 However, the ALTO server or a third party who is able to intercept 911 such messages can store and process obtained information in order to 912 analyze user behaviors and communication patterns, which has been 913 discussed in Section 15.4 of [RFC7285]. Since the fine-grained flow- 914 based query provides more information, an ALTO client should be 915 cognizant about the trade-off between redundancy and privacy. 917 8. IANA Considerations 919 This document defines two new entries to be registered to 920 application/alto-* media types. 922 8.1. ALTO Address Type Registry 924 This document defines five new address types as follows to be 925 registered to "ALTO Address Type Registry". 927 The AddressType dependencies are defined as a equivalence relation. 928 The dependencies shown in Table 1 only contain a part of the 929 AddressType dependencies. The complete dependencies SHOULD be 930 inferred by properties of the equivalence relation. 932 +------------+-------------+--------------+----------+--------------+ 933 | Identifier | Category | Address | Default | Dependencies | 934 | | | Encoding | Port | | 935 +------------+-------------+--------------+----------+--------------+ 936 | eth | Layer 2 | See Section | None | ipv4, ipv6 | 937 | | | 5.2.2.1 | | | 938 | tcp | Layer 4 | See Section | None | ipv4, ipv6 | 939 | | | 5.2.2.2 and | | | 940 | | | Section 5.2. | | | 941 | | | 2.3 | | | 942 | udp | Layer 4 | See Section | None | ipv4, ipv6 | 943 | | | 5.2.2.2 and | | | 944 | | | Section 5.2. | | | 945 | | | 2.3 | | | 946 | ftp | Application | See Section | 21 | tcp | 947 | | Layer | 5.2.2.2 and | | | 948 | | | Section 5.2. | | | 949 | | | 2.3 | | | 950 | http | Application | See Section | 80 | tcp | 951 | | Layer | 5.2.2.2 and | | | 952 | | | Section 5.2. | | | 953 | | | 2.3 | | | 954 +------------+-------------+--------------+----------+--------------+ 956 Table 1: ALTO Address Type Registry 958 8.2. Media Types 960 This document registers two media types listed in Table 2. 962 +--------------+--------------------------+----------------+ 963 | Type | Subtype | Specification | 964 +--------------+--------------------------+----------------+ 965 | application | alto-flowcost+json | Section 5.1.3 | 966 | application | alto-flowcostparam+json | Section 5.3.2 | 967 +--------------+--------------------------+----------------+ 969 Table 2: ALTO FCS Media Types 971 Type name: application 973 Subtype name: This document registers two subtypes, as listed in 974 Table 2. 976 Required parameters: n/a 978 Optional parameters: n/a 979 Encoding considerations: Encoding considerations are identical to 980 those specified for the "applicatoin/json" media type. See 981 [RFC7159]. 983 Security considerations: Security considerations are identical to 984 those specified in Section 15 of [RFC7285]. 986 Interoperability considerations: n/a 988 Published specification: This document is the specification for 989 these media types. See Table 2 for the section documenting each 990 media type. 992 Applications that use this media type: ALTO servers and ALTO clients 993 with the extension to support the flow cost service, either 994 standalone or embedded within other applications. 996 Additional information: n/a 998 Person & email address to contact for further information: See 999 Authors' Addresses. 1001 Intended usage: COMMON 1003 Restrictions on usage: n/a 1005 Author: See Authors' Addresses. 1007 8.3. Header Field 1009 TBD: Create the "ALTO Header Field Name Registry". 1011 9. Acknowledgement 1013 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 1014 Randriamasy and Wendy Roome for fruitful discussions and feedback on 1015 this document. Shawn Lin provided substantial review feedback and 1016 suggestions to the protocol design. 1018 10. References 1020 10.1. Normative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, 1024 DOI 10.17487/RFC2119, March 1997, 1025 . 1027 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1028 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1029 . 1031 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 1032 Literal IPv6 Addresses in URL's", RFC 2732, 1033 DOI 10.17487/RFC2732, December 1999, 1034 . 1036 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1037 Resource Identifier (URI): Generic Syntax", STD 66, 1038 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1039 . 1041 10.2. Informative References 1043 [EUI48] IEEE, , "Guidelines for use of a 48-bit Extended Unique 1044 Identifier (EUI-48)", 2012, 1045 . 1047 [EUI64] IEEE, , "Guidelines for use of a 64-bit Extended Unique 1048 Identifier (EUI-64)", November 2012, 1049 . 1051 [I-D.ietf-alto-multi-cost] 1052 Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1053 ALTO", draft-ietf-alto-multi-cost-05 (work in progress), 1054 February 2017. 1056 [I-D.wang-alto-ecs-flows] 1057 Shen, X., Zhang, J., Wang, J., and Q. Xiang, "ALTO 1058 Extension: Endpoint Cost Service for Flows", draft-wang- 1059 alto-ecs-flows-01 (work in progress), April 2016. 1061 [OF15] Foundation, O., "OpenFlow Switch Specification v1.5.0", 1062 2014, 1063 . 1067 [OPENFLOW] 1068 McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 1069 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 1070 "OpenFlow: enabling innovation in campus networks", 2008. 1072 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1073 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1074 2014, . 1076 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1077 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1078 "Application-Layer Traffic Optimization (ALTO) Protocol", 1079 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1080 . 1082 Appendix A. Tables 1084 +------------+--------------+------------------------------+ 1085 | Protocol | Field Name | Description | 1086 +------------+--------------+------------------------------+ 1087 | Ethernet | source | The source MAC address | 1088 | | destination | The destination MAC address | 1089 | | vlan-id | VLAN-ID from 802.1Q header | 1090 | IPv4 | source | IPv4 source address | 1091 | | destination | IPv4 destination address | 1092 | IPv6 | source | IPv6 source address | 1093 | | destination | IPv6 destination address | 1094 | TCP | source | TCP source port | 1095 | | destination | TCP destination port | 1096 | UDP | source | UDP source port | 1097 | | destination | UDP destination port | 1098 +------------+--------------+------------------------------+ 1100 Table 3: Protocols and Field Names. 1102 +-----------------------+-------------------------------------------+ 1103 | Typed Header Field | Acceptable Value Type | 1104 +-----------------------+-------------------------------------------+ 1105 | ethernet:source | JSONString as MAC address | 1106 | ethernet:destination | | 1107 | ethernet:vlan-id | JSONNumber in the range of [1, 4094] | 1108 | ipv4:source | JSONString as IPv4 address or IPv4 prefix | 1109 | ipv4:destination | | 1110 | ipv6:source | JSONString as IPv6 address or IPv6 prefix | 1111 | ipv6:destination | | 1112 | tcp:source | JSONNumber in the range of [0, 65535] | 1113 | tcp:destination | 0 serves as a wildcard value | 1114 | udp:source | | 1115 | udp:destination | | 1116 +-----------------------+-------------------------------------------+ 1118 Table 4: Value Types for Typed Header Fields 1120 Authors' Addresses 1122 Kai Gao 1123 Tsinghua University 1124 30 Shuangqinglu Street 1125 Beijing 100084 1126 China 1128 Email: gaok12@mails.tsinghua.edu.cn 1130 Jingxuan Jensen Zhang 1131 Tongji University 1132 4800 Cao'an Hwy 1133 Shanghai 201804 1134 China 1136 Email: jingxuan.n.zhang@gmail.com 1138 Junzhuo Austin Wang 1139 Tongji University 1140 4800 Cao'an Hwy, Jiading District 1141 Shanghai 1142 China 1144 Email: wangjunzhuo200@gmail.com 1146 Qiao Xiang 1147 Tongji/Yale University 1148 51 Prospect Street 1149 New Haven, CT 1150 USA 1152 Email: qiao.xiang@cs.yale.edu 1154 Y. Richard Yang 1155 Yale University 1156 51 Prospect St 1157 New Haven CT 1158 USA 1160 Email: yry@cs.yale.edu