Internet DRAFT - draft-song-alto-overlay-routing
draft-song-alto-overlay-routing
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]
