ALTO H. Song Internet-Draft Huawei Intended status: Standards Track Y. Sun Expires: April 24, 2014 ICT Chinese Academy of Sciences October 21, 2013 ALTO Protocol Extension For Overlay Routing draft-song-alto-overlay-routing-00 Abstract This document describes an ALTO protocol extension for overlay routing. It considers three different methods to route traffic from a data source to a data receiver, which are direct Internet routing, VPN tunnel, and overlay routing via intermediate/relay node(s), analyze their use cases in real world and then proposes an extension to ALTO protocol so as to support a ALTO client to get cost value between hosts via these different routing methods. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Song & Sun Expires April 24, 2014 [Page 1] Internet-Draft Overlay Routing October 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overlay Routing Cost Service Extension . . . . . . . . . . . 5 3.1. Overlay Routing Cost . . . . . . . . . . . . . . . . . . 5 3.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 5 3.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 6 3.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 7 3.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 8 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Normative References . . . . . . . . . . . . . . . . . . 9 4.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction ALTO protocol [I-D.ietf-alto-protocol]provides an interface to applications with appropriate information to guide an optimal node selection based on the Internet service provider's policy when there are more than one application nodes providing the same service. It usually aggregates network locations into PIDs, and assigns lower cost value for a PID pair that are topologically close. So when application node follows the advice from ALTO server to choose one resource provider with a PID that has lower cost from its own PID, with higher probability the application node can keep the content request and response traffic flow intra domain, which can reduce the suffering increasing interdomain traffic for ISPs, and avoid the congestion in the backbone network. More factors for node selection can be considered, such as pricing, congestion, and etc. The existing ALTO protocol has its limitations. For example, in a cost map it only gives one cost value between source PID and destination PID, assuming there is only one path between them. But it can be routed through different paths in overlay routing. So we propose to add a "via" parameter as an extension to the cost map. In this document, we give use cases first, and then the possible way to extend the ALTO protocol to achieve it. An overlay network is a computer network which is built on the top of another network. Nodes in the overlay can be thought of as being Song & Sun Expires April 24, 2014 [Page 2] Internet-Draft Overlay Routing October 2013 connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network[overlay_network]. One example of overlay netwok over IP network is CDN network. A CDN network consists of many CDN nodes with different levels. One edge CDN node often needs to pull content from another node that is in a higher distribution level position in the CDN topology. There usually can be several paths to send the content from the source CDN node to the edge CDN node. One way obviously is the direct IP routing. And if the direct routing path is not good, then the source CDN node will select another CDN node as the intermediate node to transport the content to the that destination edge node, which will be more efficiency than the direct routing path. Of course, there are usually more than one intermediate node available, and the source CDN node needs to select a "best" one. In some cases, there can also be a VPN tunnel between two CDN nodes, or between two different data center locations to transfer data. Note that in this document, the VPN refers to the VPN service provided by the Internet Service Provider, which is used to guarantee the quality of delivery service. The service/content providers often classify the data into delay-sensitive and delay-insensitive, Because VPN tunnel is more expensive than the direct Internet routing method, and at the same time has higher QoS guarantee than the direct Internet routing method. The delay-sensitive data is usually transported via the VPN tunnel and the delay-insensitive data can be transported over the VPN tunnel if there is available capability for it, but can also be transported over the direct Internet routing method in order to leave VPN capability for delay-sensitive data. The overlay routing method via intermediate nodes (can be an intermediate CDN server, a data center gateway and etc.) is an optimization to the direct Internet routing method, thus the QoS is a little higher than the direct Internet routing method, but it is not as good as a VPN tunnel. Song & Sun Expires April 24, 2014 [Page 3] Internet-Draft Overlay Routing October 2013 /--------\ |/// \\\| | CDN Node | |\\\ 1 ///|\ \-+------|| \\ | || \ | || \\ Overlay Routing || \ via CDN Node 2 Direct Internet Routing || \\ || \ | || \\ | || /----\---\ | || |/// \\\| \ || | CDN Node | \ || |\\\ 2 ///| \ || \--------/ \ VPN tunnel / \ || / \ || / \ || \ || / Overlay Routing \ || / via CDN Node 2 /-----++-\ / |/// \\\| / | CDN Node | |\\\ 3 ///| \--------/ Figure 1. Different ways for sending content from Node 1 to Node 3 So the transport between two Internet hosts can be from: direct Internet routing one/more intermediate overlay nodes a VPN tunnel In this document, we propose a new overlay routing cost service for ALTO protocol, which can be used by the ALTO client to compare the routing cost through different paths between two Internet hosts. As it is not usually to use two or more relay nodes, we do not consider that in this document. Actually, if there are two or more relay nodes, it can be considered as multiple one relay node and use the service provided by this document multiple times to solve the issue. Song & Sun Expires April 24, 2014 [Page 4] Internet-Draft Overlay Routing October 2013 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The concepts and data formats are consistent with ALTO protocol base document . [I-D.ietf-alto-protocol] 3. Overlay Routing Cost Service Extension The reader is assumped to read ALTO protocol before this document, especially section 8 of ALTO protocol. The Overlay Routing Cost Service provides information about costs between individual endpoints through direct Internet routing, VPN or overlay routing. 3.1. Overlay Routing Cost An Overlay Routing Cost resource provides information about costs between individual endpoints from different paths. 3.1.1. Media Type The media type of Overlay Routing Cost is "application/alto- overlayroutingcost+json". 3.1.2. HTTP Method The Overlay Routing Cost resource is requested using the HTTP POST method. 3.1.3. Accept Input Parameters An ALTO Client supplies the overlay routing cost parameters through a media tyep "application/alto-overlayroutingcostparams+json", with an HTTP POST entity body of a JSON Object of type ReqOverlayRoutingCostMap: object { CostType cost-type; [JSONString constraints<0..*>;] EndpointFilter endpoints; } ReqOverlayRoutingCostMap; object { Song & Sun Expires April 24, 2014 [Page 5] Internet-Draft Overlay Routing October 2013 TypedEndpointAddr srcs<0..*>; TypedEndpointAddr dstc<0..*>; JSONBool drr; JSONBool vpn; [TypedEndpointAddr relays<0..*>;] } EndpointFilter; with fields: cost-type The Cost Type (Section 10.7 of ALTO protocol ) to use for returned costs. The cost-metric and cost-mode fields MUST match one of the supported Cost Types indicated in this resource's capabilities. The ALTO Client SHOULD omit the description field, and if present, the ALTO Server MUST ignore the description field. constraints Defined equivalently to the "constraints" input parameter of a Filtered Cost Map (see Section 11.3.2 of ALTO protocol). endpoints A list of endpoints including source endpoints, relay endpoints and destination endpoints for which path costs are to be returned. If "drr" is true, the ALTO server MUST provide the cost of direct Internet routing from the source endpoint to the destination endpoint. If the value provided by a ALTO Client for "vpn" is true and a provider's VPN is existed between a source and destination endpoints pairs, the ALTO server MUST provide the cost of using the VPN tunnel. If the value provided by a ALTO Client for "vpn" is true, but the ALTO server cannot find the VPN information between any source and destination endpoints, it MUST ignore it. The ALTO server MUST provide the cost from source endpoints to destination endpoints through each relay node that is listed in the relay node array. If the list of Source or Destination Endpoints is empty (or not included), the ALTO Server MUST interpret it as if it contained the Endpoint Address corresponding to the client IP address from the incoming connection (see Section 13.3 for discussion and considerations regarding this mode). The Source and Destination Endpoint lists MUST NOT be both empty. The relay node list can be empty. Note that ALTO client SHOULD NOT set "drr" to true, "vpn" to false and the relay node list to empty in a single request, in that case, the ALTO client should use Endpoint Cost Service. 3.1.4. Capabilities In this document, we define OverlayRoutingCostCapabilities the same as FilteredCostMapCapabilities. See Section 11.3.2.4 of ALTO protocol. Song & Sun Expires April 24, 2014 [Page 6] Internet-Draft Overlay Routing October 2013 3.1.5. Uses None. 3.1.6. Response The "meta" field of an Overlay Routing Cost response MUST include the "cost-type" key, to indicate the Cost Type used. The data component of an Overlay Routing Cost response is named "overlay-routing-cost-map", which is a JSON object of type OverlayRoutingCostMapData: object { [OverlayRoutingCostMapData overlay-routing-cost-map;] [EndpointTwoLevelCosts vpncost;] [EndpointTwoLevelCosts drrcost;] } InfoResourceOverlayRoutingCostMap : ResponseEntityBase; object-map { TypedEndpointAddr -> EndpointTwoLevelCosts; } OverlayRoutingCostMapData; object-map { TypedEndpointAddr -> EndpointOneLevelCosts; } EndpointTwoLevelCosts; object-map { TypedEndpointAddr -> JSONValue; } EndpointOneLevelCosts; Specifically, an OverlayRoutingCostMapData object is a dictionary map with each key representing a TypedEndpointAddrr string identifying the Source Endpoint specified in the input parameters, and for each Source Endpoint, a EndpointTwoLevelCosts dictionary map object has each key respresenting a TypedEndpointAddr identifying the Destination Endpoint, and for each Destination Endpoint, a EndpointOneLevelCosts dictionary map object denotes the associated cost with each relay nodes specified in the input parameters. The key "vpncost" is a dictionary map with each key respresenting a TypedEndpointAddr string identifying the Source Endpoint specified in the input parameters, and for each Source Endpoint, a EndpointOneLeveCost dictionary map object denotes the associated VPN cost to each Destination Endpoint if existed. So the vpncost may only contain a few values where there are VPN tunnels between source endpoints and destination endpoints. Song & Sun Expires April 24, 2014 [Page 7] Internet-Draft Overlay Routing October 2013 The key "drrcost" is a dictionary map with each key respresenting a TypedEndpointAddr string identifying the Source Endpoint specified in the input parameters, and for each Source Endpoint, a EndpointOneLeveCost dictionary map object denotes the associated cost to each Destination Endpoint. Note that ALTO server SHOULD NOT provide only a single direct routing cost map. 3.1.7. Example POST /overlayroutingcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: TBA Content-Type: application/alto-overlayroutingcostparams+json Accept: application/alto-overlayroutingcost+json,application/alto-error+json { "cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost"}, "endpoints" : { "srcs": [ "ipv4:1.1.1.1" ], "dsts": [ "ipv4:2.2.2.2", "ipv4:3.3.3.3", ], "drr": false, "vpn": true, "relays": [ "ipv4:6.6.6.6", "ipv4:7.7.7.7" ] } } HTTP/1.1 200 OK Content-Length: TBA Content-Type: application/alto-overlayroutingcost+json { "meta" : { "cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost" } }, "overlay-routing-cost-map" : { "ipv4:1.1.1.1": { "ipv4:2.2.2.2": { Song & Sun Expires April 24, 2014 [Page 8] Internet-Draft Overlay Routing October 2013 "ipv4:6.6.6.6": 1, "ipv4:7.7.7.7": 2, }, "ipv4:3.3.3.3": { "ipv4:6.6.6.6": 2, "ipv4:7.7.7.7": 3 } } } "vpncost": { "ipv4:1.1.1.1": { "ipv4:2.2.2.2": 0 } } } 4. References 4.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [overlay_network] , "overlay network", . http://en.wikipedia.org/wiki/Overlay_network 4.2. Informative References [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- ietf-alto-protocol-20 (work in progress), October 2013. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [I-D.ietf-alto-deployments] Stimerling, M., Kiesel, S., and S. Previdi, "ALTO Deployment Considerations", draft-ietf-alto-deployments-06 (work in progress), February 2013. Authors' Addresses Song & Sun Expires April 24, 2014 [Page 9] Internet-Draft Overlay Routing October 2013 Haibin Song Huawei Email: haibin.song@huawei.com Sun Yi ICT Chinese Academy of Sciences Email: sunyi@ict.ac.cn Song & Sun Expires April 24, 2014 [Page 10]