idnits 2.17.1 draft-wang-alto-ecs-flows-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 134 has weird spacing: '...tFilter end...' -- The document date (April 21, 2016) is 2926 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 489, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group X. Shen 3 Internet-Draft J. Zhang 4 Intended status: Standards Track J. Wang 5 Expires: October 23, 2016 Tongji University 6 Q. Xiang 7 Tongji/Yale University 8 April 21, 2016 10 ALTO Extension: Endpoint Cost Service for Flows 11 draft-wang-alto-ecs-flows-01 13 Abstract 15 The Endpoint Cost Service (ECS) has limitations to illustrate the 16 network condition and to work with the OpenFlow protocol. This 17 document extends ECS to improve the Application-Layer Traffic 18 Optimization (ALTO) protocol by (1) defining more types of endpoint 19 address such as port number, protocol type, domain and etc; (2) 20 adding flow constraints. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 23, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.3. Changes Since Version -00 . . . . . . . . . . . . . . . . 3 60 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Extend Endpoint Abstraction . . . . . . . . . . . . . . . 6 63 3.2. Strategy for Multi-Path . . . . . . . . . . . . . . . . . 7 64 3.3. Compatibility with Legacy Clients . . . . . . . . . . . . 8 65 3.4. Endpoint Cost Resources . . . . . . . . . . . . . . . . . 8 66 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Path Oblivious Principle . . . . . . . . . . . . . . . . 8 68 4.2. Full Relationship Principle . . . . . . . . . . . . . . . 9 69 5. Protocol Extension for Flow-Extended ECS . . . . . . . . . . 9 70 5.1. Endpoint Cost Service Extensions . . . . . . . . . . . . 9 71 5.1.1. Accepted Input Parameters . . . . . . . . . . . . . . 9 72 5.2. ALTO Address Type Registry Extensions . . . . . . . . . . 10 73 6. Interoperation and Exception Handling . . . . . . . . . . . . 10 74 6.1. Feedback when Multi-Path Detected . . . . . . . . . . . . 10 75 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Information Resource Directory . . . . . . . . . . . . . 11 77 7.2. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 12 78 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.1. Endpoint Cost Service vs. Flow Cost Service . . . . . . . 14 80 8.2. The Same Purpose Principle . . . . . . . . . . . . . . . 14 81 8.3. Integration with Incremental Update . . . . . . . . . . . 14 82 8.4. Automatic Exploring Fine-Grained Path . . . . . . . . . . 15 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 10. Privacy And Security Considerations . . . . . . . . . . . . . 15 85 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 ECS is a basic service of the ALTO services defined in [RFC7285]. 91 Based on the simple host model when defining endpoints, ECS defined 92 in [RFC7285] may not work well in an emerging settings such as 93 Software Defined Networking (SDN) based settings, where network 94 routing decisions can be flow based. In this document, we present an 95 extended ECS for such new settings. 97 1.1. Terminology 99 This document uses terms defined as follows: 101 o {1.2.3}: References of this form are to sections in the ALTO 102 protocol specification [RFC7285]. 104 o And other terms defined in {8.2} of [RFC7285]. 106 1.2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 1.3. Changes Since Version -00 114 o Change the format of API for clients' request. This design is 115 more concise and has better compatibility. It does not modify the 116 IRD of ECS. Section 3.1 introduces a new abstraction for Endpoint 117 which defines the ConnectionURI to represent an endpoint. And a 118 specific flow can be determined by a pair of ConnectionURI. 120 o Add some design principles in section 4. 122 o Give two strategies to solve the multi-path problem and handle 123 fine-grained path error in section 6. One option is to introduce 124 feedback mechanism, the other option is to implement exploring. 126 2. Motivations 128 Below is the acceptable input parameters of ECS in {11.5.1.3} of 129 [RFC7285]. 131 object { 132 CostType cost-type; 133 [JSONString constraints<0..*>;] 134 EndpointFilter endpoints; 135 } ReqEndpointCostMap; 137 object { 138 [TypedEndpointAddr srcs<0..*>;] 139 [TypedEndpointAddr dsts<0..*>;] 140 } EndpointFilter; 142 Hence, the granularity is TypedEndpointAddr, which is defined in 143 {10.4.1} of [RFC7285]. In particular, [RFC7285] defines two address 144 types: ipv4 and ipv6. This, however, may limit the usage of ECS in 145 multiple settings. Below we give some use cases. 147 Use case 1: 149 ECS is not compatible with virtual host technology, a popular on the 150 Internet, which allows different hosts to share the same IP address. 151 For example, a reverse proxy p1 hosts three sites shown in Figure 1. 152 These sites share the same public network address: 202.180.1.11. 153 Suppose the link in the private network from p1 to server s1 is busy, 154 but the link to server s2 is free. It will cost client c1 more to 155 access www.a.com than www.b.com. Suppose c1 wants to know the cost 156 to www.a.com. Because ECS only supports IP addresses, it will query 157 the DNS server to transfer the domain name to IP address. Therefore, 158 c1 can only obtain the cost to p1. 160 As a result, c1 will get the same result to three different domain 161 names because ECS is only capable of measuring the cost between IP 162 addresses. 164 +---------------------------------+ 165 | | 166 | Private +-----------------+ | 167 | Network | s1 | | 168 | +--> www.a.com | | 169 | | | 192.168.1.10 | | 170 | | | | | 171 | | +-----------------+ | 172 | | | 173 +-----------------+ +--------+--------+ | +-----------------+ | 174 | c1 | | p1 | | | s2 | | 175 | Web Browser +------> Reverse Proxy +-+--> www.b.com | | 176 | 60.20.100.11 | | 202.180.1.11 | | | 192.168.1.11 | | 177 | | | 192.168.1.20 | | | | | 178 +-----------------+ +--------+--------+ | +-----------------+ | 179 | | | 180 | | +-----------------+ | 181 | | | s3 | | 182 | +--> www.c.com | | 183 | | 192.168.1.12 | | 184 | | | | 185 | +-----------------+ | 186 | | 187 +---------------------------------+ 189 Figure 1: Using reverse proxy to operate virtual hosts. 191 Use case 2: 193 ECS is not compatible with port-based or protocol-based routing 194 systems. For example, the OpenFlow protocol can forward packets to 195 different destinations by the port in TCP/IP protocols. A simple 196 topology is shown in Figure 2, the link between switch sw1 and switch 197 sw2 has a low speed but a low latency, while sw3 is a high speed but 198 high latency switch. And there are two services running on host h2, 199 SSH and FTP, using port 22 and port 20, respectively. An efficient 200 flow configuration supported by OpenFlow, is to use a low latency 201 link to transfer SSH packets and a high speed route to transfer 202 files. So sw1 and sw2 will exchange the SSH flows with each other to 203 achieve a lower latency and forward FTP flows to sw3 to achieve a 204 higher bandwidth. 206 In this case, the SDN network uses suitable links to transfer 207 different packets, so the cost between IP addresses is protocol or 208 port related. However, ECS cannot use this information to give a 209 precise result. 211 +-----------------+ +-----------------+ 212 | h1 | | h2 | 213 | SSH client | | SSH service: 22 | 214 | FTP client | | FTP service: 20 | 215 | | | | 216 +-------^---------+ +---------^-------+ 217 | | 218 | | 219 +--v---+ +---v--+ 220 | | Low Speed | | 221 | sw 1 <-----------------> sw 2 | 222 | | Low Latency | | 223 +--^---+ +---^--+ 224 | | 225 | | 226 +--v-------------------------v--+ 227 | sw 3 | 228 | High Speed | 229 | High Latency | 230 +-------------------------------+ 232 Figure 2: A simple example of protocol or port based routing. 234 Use case 3: 236 ECS is not compatible with other addresses such as MAC addresses or 237 physical connectors. For example, some protocols such as ARP send 238 packets by MAC addresses. ECS is unable to measure the cost between 239 two NICs without IP addresses. The ALTO, as an information source, 240 cannot compute the cost between two physic ports, either. These 241 knowledge seems useless for the Internet users, but useful for ISPs. 243 3. Overview Of Approach 245 This section contains the non-normative overview of the ECS extension 246 for flows defined in this document. It assumes that the readers are 247 familiar with the ALTO Protocol ([RFC7285]). 249 3.1. Extend Endpoint Abstraction 251 The typed endpoint address used by ECS is defined in {10.4} of 252 [RFC7285]. That section only defines two address types: ipv4 and 253 ipv6 to express IPv4 addresses and IPv6 addresses respectively. 254 However, the flow-extended ECS may contain MAC addresses, domain 255 names and port numbers to give a cost between hosts. 257 Therefore, this document transform the typed endpoint address to 258 ConnectionURI to measure the cost more precisely. This URI must 259 conform to the syntax for URI defined in [RFC3986], in particular 260 with respect to character encoding. The ConnectionURI may have one 261 of the following form: 263 "protocol:name-or-address:port" 264 "protocol:name-or-address" 266 And this ConnectionURI is defined in [OpenFlow1.5], and it is used to 267 identify a controller connection. To extend endpoint abstraction, we 268 use ConnectionURI to specify a flow with fields: 270 protocol: The protocol field is REQUIRED. It contains many kinds of 271 protocols, the protocol can be layer two protocols (like PPP, ARP) 272 and layer three protocols (like IPv4, IPv6), it can also be upper- 273 layer protocols (like UDP, TCP, HTTP, FTP). And for different kinds 274 of protocols, there are some provisions. Firstly, if the protocol 275 field is layer two or layer three protocol, client's query can not 276 fill in the port field in ConnectionURI, because the port is 277 unnecessary. Secondly, when the protocol is upper-layer protocol, 278 and if client do not indicate the port, for some special protocol, we 279 will use the default port. 281 name-or-address: This field is REQUIRED. The hostname or IP address 282 or domainnname or MAC address of the controller. If the hostname is 283 locally configured, it is recommended that the URI uses the IP 284 address. If the hostname is available via DNS the URI may use 285 either, so long as it is consistent. 287 port: This field is OPTIONAL. It is forbidden when the protocol is 288 layer three or layer two protocol (like IPv4 and IPv6). And it is 289 added for more fine-gained request when the protocol is upper-layer 290 protocol. For some classic protocols, if the port is not indicated, 291 we use the default port. For example, the default port of SSH is 22, 292 and FTP is 21, HTTP is 80. 294 A request to query the cost between hosts looks like this: 296 { 297 "cost-type": {"cost-mode" : "ordinal", 298 "cost-metric" : "routingcost"}, 299 "ConnectionURI" : { 300 "srcs": [ "ipv4:192.0.2.2:22" ], 301 "dsts": [ 302 "http:www.a.com:80", 303 "ftp:01-23-45-67-89-AB", 304 "ipv4:198.51.100.34", 305 "telnet:198.51.100.34:23", 306 "ipv6:2000::1:2345:6789:abcd" 307 ] 308 } 309 } 311 This design of API is fully compatible with ECS. TypedEndpointAddr 312 of EndpointFilter in ECS have the format of "protocal:address", and 313 the protocol only supports IPv4 and IPv6, so it can also be used in 314 this design. 316 3.2. Strategy for Multi-Path 318 The multi-path problem refers to the case when given a flow-extended 319 ECS request, more than one path are found and the ALTO server does 320 not know to return which path's cost. 322 Two reasons may cause the multi-path problem. First, the input of 323 client is not fine-grained so that there are multiple paths matching 324 a single input pair. Another reason is some requirements from 325 clients like load balancing can make traffic choose one of several 326 optional paths randomly. 328 Section 6.1 gives a strategy for multi-path problem which is by 329 returning a feedback when multi-path problem is detected in server to 330 ask client for more details to select the specific result. 332 3.3. Compatibility with Legacy Clients 334 The extension defined in this document should be compatible with 335 legacy implementations, which means clients and servers are not aware 336 of this extension. A good way to achieve this goal is defining new 337 media types for extended endpoint cost map. Based on the fact that 338 the format of the extended address is similar as that of the original 339 typed endpoint address, it would be a simpler way to implement a 340 parser which can handle both typed endpoint addresses. 342 Therefore, no new media type is defined in this document. Instead, 343 this document extends the specifications of Information Resource 344 Directory (IRD) in the ALTO protocol. Because the legacy ALTO 345 clients MUST ignore unknown fields (see {8.3.7} of [RFC7285]), the 346 legacy implementations will not use the extended typed endpoint 347 address and are not aware of the existence of this extension. 349 3.4. Endpoint Cost Resources 351 There is no need in this document to extend the endpoint cost service 352 in IRD. So the legacy Endpoint Cost Resources is still useful. 354 For example, an extended endpoint cost resource in IRD is shown 355 below: 357 "endpoint-cost" : { 358 "uri" : "http://alto.example.com/endpointcost/lookup", 359 "media-type" : "application/alto-endpointcost+json", 360 "accepts" : "application/alto-endpointcostparams+json", 361 "capabilities" : { 362 "cost-constraints" : true, 363 "cost-type-names" : [ "num-routing", "num-hop", 364 "ord-routing", "ord-hop" ] 365 } 366 } 368 4. Design Principles 370 In practice, there are several principles affecting the design of ECS 371 extension. This section will talk about two major principles and why 372 they are important. 374 4.1. Path Oblivious Principle 376 The interfaces of ECS should not require or produce path related 377 information. Practically, users do not care about the real path 378 where the packets pass when they are sent between source and 379 destination. Users only care about the cost between the endpoint 380 pair. This principle requires the API design not to be related on 381 the path information. Meanwhile, the ALTO server should not reveal 382 the detailed path information to the clients, either. 384 4.2. Full Relationship Principle 386 ECS MUST provide the costs for the full relationship. It means that 387 the response map of ECS query MUST be the Cartesian Product between 388 source and destination endpoint set. ECS assumes users are always 389 asking for the full relationship. 391 5. Protocol Extension for Flow-Extended ECS 393 5.1. Endpoint Cost Service Extensions 395 This document extends the Endpoint Cost Service, as defined in 396 {11.5.1} of [RFC7285], by changing the format of EndpointFilter. 398 The media type ({11.5.1.1} of [RFC7285]), HTTP method ({11.5.1.2} of 399 [RFC7285]) and "uses" specifications ({11.5.1.5} of [RFC7285]) are 400 unchanged. 402 5.1.1. Accepted Input Parameters 404 The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended 405 as follows: 407 object { 408 CostType cost-type; 409 [JSONString constraints<0..*>;] 410 EndpointFilter endpoints; 411 } ReqEndpointCostMap; 413 object { 414 [ConnextionURI srcs<0..*>;] 415 [ConnectionURI dsts<0..*>;] 416 } EndpointFilter; 418 With fields: 420 cost-type, constraints: : As defined in {11.5.1.3} of [RFC7285]. 422 endpoints: : Change the TypedEnpointAddress to ConnectionURI to get 423 the fine-grained flow. 425 5.2. ALTO Address Type Registry Extensions 427 This document requests registration of the identifiers "mac" and 428 "domainname" as shown in Table 1. 430 +------------+----------+-----------+-------------------------------+ 431 | Identifier | Address | Prefix | Mapping to/from IPv4/v6 | 432 | | Encoding | Encoding | | 433 +------------+----------+-----------+-------------------------------+ 434 | mac | See | No | Mapping from IPv4 by | 435 | | Section | compact | [RFC0826]. Mapping to IPv4 | 436 | | 6.1.3 | encoding | by [RFC0903]. Mapping from | 437 | | | is | IPv6 by [RFC4861]. Mapping | 438 | | | available | to IPv6 by [RFC3122]. | 439 | domainname | See | No | Mapping to/from IPv4 by | 440 | | Section | compact | [RFC1034]. Mapping to/from | 441 | | 6.1.3 | encoding | IPv6 by [RFC3596]. | 442 | | | is | | 443 | | | available | | 444 +------------+----------+-----------+-------------------------------+ 446 Table 1: New ALTO Address Types 448 6. Interoperation and Exception Handling 450 6.1. Feedback when Multi-Path Detected 452 There may be several paths got by client's input, and our server did 453 not know which to choose. When multi-Path problem is detected, there 454 are two possible reasons. One is users' input is not fine-grained so 455 that there are multiple paths matching a individual input pair. 456 Another reason is some requirements like load balancing can make 457 traffic choose one of several optional paths randomly. And if it is 458 caused by the second reasons, we return all the results. And for the 459 first reason, we return a special flag to represent the reason why a 460 flow can not be returned the specific result. 462 In flow extended ECS, we return "NR" in cost field to mean there is 463 no specific path found by the ConnectionURI pair, and return "MU" in 464 cost field to mean that there are multiple paths, and client should 465 support more fine-grained information to get a path. The detailed 466 example can be found in [section 7.2] of this document. 468 In the last version of flow extended ECS, we regard the situation of 469 multi-path problem as an error, so when multi-path problem is 470 detected, server return an error to client, and extend some error 471 information in the error response. The problem of the original 472 design is that in that a query from client usually contains several 473 flows, and other flows' result is not returned only due to a single 474 flow's error. 476 7. Examples 478 7.1. Information Resource Directory 480 Here is an example of an ALTO server's Information Resource Directory 481 with an Endpoint Cost Service which supports the flow-based ECS 482 extensions. 484 GET /directory HTTP/1.1 485 Host: alto.example.com 486 Accept: application/alto-directory+json,application/alto-error+json 488 HTTP/1.1 200 OK 489 Content-Length: [TODO] 490 Content-Type: application/alto-directory+json 491 { 492 "meta" : { 493 "default-alto-network-map" : "my-default-network-map", 494 "cost-types" : { 495 "num-routing" : { 496 "cost-mode" : "numerical", 497 "cost-metric" : "routingcost" 498 }, 499 "num-hopcount" : { 500 "cost-mode" : "numerical", 501 "cost-metric" : "hopcount" 502 }, 503 } 504 }, 505 "resources" : { 506 "my-default-network-map" : { 507 "uri" : "http://alto.example.com/networkmap", 508 "media-type" : "application/alto-networkmap+json" 509 }, 510 "numerical-routing-cost-map" : { 511 "uri" : "http://alto.example.com/costmap/num-routing", 512 "media-types" : [ "application/alto-costmap+json" ], 513 "uses" : [ "my-default-network-map" ], 514 "capabilities" : { 515 "cost-type-names" : [ "num-routing" ] 516 } 517 }, 518 "numerical-hopcount-cost-map" : { 519 "uri" : "http://alto.example.com/costmap/num-hopcount", 520 "media-types" : [ "application/alto-costmap+json" ], 521 "uses" : [ "my-default-network-map" ], 522 "capabilities" : { 523 "cost-type-names" : [ "num-hopcount" ] 524 } 525 }, 526 ......... 527 And other information resources described in RFC7285 528 ......... 529 "endpoint-multicost-map" : { 530 "uri" : "http://alto.example.com/multi/endpointcost/lookup", 531 "media-types" : [ "application/alto-endpointcost+json" ], 532 "accepts" : [ "application/alto-endpointcostparams+json" ], 533 "uses" : [ "my-default-network-map" ], 534 "capabilities" : { 535 "cost-constraints" : true, 536 "cost-type-names" : [ "num-routingcost", 537 "num-hopcount" ], 538 } 539 } 540 } 541 } 543 7.2. Endpoint Cost Service 545 This example uses multi-field typed endpoint addresses to query the 546 "routingcost" for selected endpoints. And in the response, the "MU" 547 means there are multiple paths from source to "http:www.a.com", so 548 client should give more fine-grained information, but server did not 549 provide other detail informations like what port client can 550 replenish. And the response "NR" means there is no result, we can 551 not find a path by this pair of ConnectionURI. 553 POST /endpointcost/lookup HTTP/1.1 554 Host: alto.example.com 555 Content-Length: 345 556 Content-Type: application/alto-endpointcostparams+json 557 Accept: application/alto-endpointcost+json, 558 application/alto-error+json 560 { 561 "cost-type": {"cost-mode" : "ordinal", 562 "cost-metric" : "routingcost"}, 563 "multi-field-endpoints" : { 564 "srcs": [ "ipv4:192.0.2.2" ], 565 "dsts": [ 566 "http:www.a.com", 567 "ftp:01-23-45-67-89-AB", 568 "ipv4:198.51.100.34", 569 "telnet:198.51.100.34:23", 570 "ipv6:fe80::ce3d:82ff:fe34:27e0/64" 571 ] 572 } 573 } 575 HTTP/1.1 200 OK 576 Content-Length: 402 577 Content-Type: application/alto-endpointcost+json 579 { 580 "meta" : { 581 "cost-type": {"cost-mode" : "ordinal", 582 "cost-metric" : "routingcost" 583 } 584 }, 585 "endpoint-cost-map" : { 586 "ipv4:192.0.2.2": { 587 "http:www.a.com" : "MU", 588 "ftp:01-23-45-67-89-AB" : 1, 589 "ipv4:198.51.100.34" : 2, 590 "telnet:198.51.100.34:23" : "NR", 591 "ipv6:fe80::ce3d:82ff:fe34:27e0/64" : 3 592 } 593 } 594 } 596 8. Discussion 597 8.1. Endpoint Cost Service vs. Flow Cost Service 599 There are two strategies on how to extend endpoint cost service for 600 flows. The method used in this document is extending the legacy ECS, 601 and the other way is defining a new service which we can call it Flow 602 Cost Service (FCS). 604 FCS is an isolated service which is unrelated to the ECS, and this 605 service is incompatible with the legacy ECS. It calculates the cost 606 for each specific flow. For better compatibility, this document 607 chooses the first strategy, which is to extend the legacy ECS. 609 8.2. The Same Purpose Principle 611 This document intents to indicate that another design principle is to 612 ensure the same purpose. ECS SHOULD assume users submit only one 613 objective in a single query. Traffic of every endpoint pairs in this 614 query MUST have the same purpose. And if users want to query 615 multiple objective traffic types, they MAY send multiple individual 616 queries. 618 But some people may think this principle is too strong and 619 unnecessary. People can debate that ECS should be more flexible and 620 be able to allow multiple purposes. A potential advantage of 621 accepting multiple purposes may be less overhead. But it may also 622 increase the complexity of handling queries. 624 8.3. Integration with Incremental Update 626 The clients may want the result timely and efficiently, so we should 627 make client able to obtain updates to ECS results, other than by 628 periodically re-fetching them. To support this, we adopt the 629 mechanism of sse. ALTO Server defines an Update Stream Services for 630 ECS, Client establishes an HTTP stream to an Update Service, Updates 631 are Server-Sent Events (SSEs), Server decides full replacement vs 632 incremental update,Client can decline incremental updates.for more 633 information, reference [draft-ietf-alto-incr-update-sse-00]. 635 For ECS Flow, however, there are some cases that SSE does not 636 supports well. For example, after updating, the situation of multi- 637 path may occur. Then the client need query again with more fine- 638 grained information. Hence the detail design of incremental update 639 is not confirmed in this document. 641 8.4. Automatic Exploring Fine-Grained Path 643 When the query granularity are not fine-grained enough to get 644 specific result, we want the ALTO server to explore fine-grained path 645 automatically. The server can add more details by itself and explore 646 specific path. And when the client give more details, the server can 647 return the cost immediately. For example, clients may only request 648 by IPAddress, but the server can calculate some costs by IPaddress 649 and some common ports. 651 9. IANA Considerations 653 This document does not define any new media type or introduce any new 654 IANA consideration. 656 10. Privacy And Security Considerations 658 This document does not introduce any privacy or security issue not 659 already present in the ALTO protocol. 661 11. Normative References 663 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 664 Converting Network Protocol Addresses to 48.bit Ethernet 665 Address for Transmission on Ethernet Hardware", STD 37, 666 RFC 826, DOI 10.17487/RFC0826, November 1982, 667 . 669 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 670 Reverse Address Resolution Protocol", STD 38, RFC 903, 671 DOI 10.17487/RFC0903, June 1984, 672 . 674 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 675 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 676 . 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 684 Inverse Discovery Specification", RFC 3122, 685 DOI 10.17487/RFC3122, June 2001, 686 . 688 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 689 "DNS Extensions to Support IP Version 6", RFC 3596, 690 DOI 10.17487/RFC3596, October 2003, 691 . 693 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 694 Resource Identifier (URI): Generic Syntax", STD 66, 695 RFC 3986, DOI 10.17487/RFC3986, January 2005, 696 . 698 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 699 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 700 DOI 10.17487/RFC4861, September 2007, 701 . 703 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 704 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 705 "Application-Layer Traffic Optimization (ALTO) Protocol", 706 RFC 7285, DOI 10.17487/RFC7285, September 2014, 707 . 709 Authors' Addresses 711 Xvdong Shelden Shen 712 Tongji University 713 4800 Cao'an Road, Jiading District 714 Shanghai 715 China 717 Email: shenxvdong1@gmail.com 719 Jingxuan Jensen Zhang 720 Tongji University 721 4800 Cao'an Road, Jiading District 722 Shanghai 723 China 725 Email: jingxuan.n.zhang@gmail.com 727 Junzhuo Austin Wang 728 Tongji University 729 4800 Cao'an Road, Jiading District 730 Shanghai 731 China 733 Email: wangjunzhuo200@gmail.com 734 Qiao Xiang 735 Tongji/Yale University 736 4800 Cao'an Road, Jiading District 737 Shanghai 738 China 740 Email: xiangq27@gmail.com