ALTO J. Medved
Internet-Draft D. Ward
Intended status: Standards Track Juniper Networks
Expires: September 5, 2011 J. Peterson
Neustar
R. Woundy
Comcast Corporation
D. McDysan
Verizon
March 04, 2011
ALTO Network-Server and Server-Server APIs
draft-medved-alto-svr-apis-00
Abstract
ALTO servers require automated operation, where the topology of the
underlying networks is incorporated into network maps automatically.
In addition to the Client-to-Server API defined in the ALTO protocol
document, two more standardized API are required: an API between the
ALTO Server and networking nodes (e.g. routers), through which the
ALTO Server can get topology information from the network, and an API
between the ALTO Servers, through which they can exchange topology
and status information between themselves.
Requirements Language
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 RFC 2119 [RFC2119]
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 September 5, 2011.
Medved, et al. Expires September 5, 2011 [Page 1]
Internet-Draft Alto Server APIs March 2011
Copyright Notice
Copyright (c) 2011 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. ALTO Server API Reference . . . . . . . . . . . . . . . . . . 4
4.1. The ALTO Server-to-Network Interface . . . . . . . . . . . 5
4.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. BGP with TE Extensions . . . . . . . . . . . . . . . . 6
4.2. The ALTO Server-to-Server Interface . . . . . . . . . . . 8
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Medved, et al. Expires September 5, 2011 [Page 2]
Internet-Draft Alto Server APIs March 2011
1. Introduction
ALTO Servers are becoming increasingly important technology for
finding "the best" or "most preferred" content or server. For
example, an ALTO Server can be used to facilitate the selection of
the best cache in a CDN, the best set of peers for a P2P node
([RFC5632] or [I-D.lee-alto-chinatelecom-trial]), or the best service
instance in a cloud. These use cases will require that network and
cost map information accurately reflects the actual network topology
and utilization. Static configuration of network and cost maps is
not feasible even for moderately sized networks. Therefore, creation
of network and cost maps in the ALTO Server should be automated and
policy driven.
The ALTO Server can use multiple sources of information to generate
the network and cost maps. Network topology data coming directly
from routers is required. Additionally, traffic engineering data,
geo location data, or network resource utilization data could also be
used to further refine the maps, or to generate different maps for
different clients. The ALTO Server should use well defined APIs to
get the data required to generate maps, since the data will be
obtained from different sources provided by a multitude of vendors,
and vendor inter-operability will be critical for adoption of ALTO-
based solutions. For network topology data, this draft proposes BGP
with TE extensions as the ALTO Server-to-Network API.
The ALTO Server will typically only have partial topology data, which
will depend on the Server's location and the sources from which it
obtains data to generate the network and cost maps. To obtain a full
view of the network topology, the ALTO Server will have to exchange
topology data with other ALTO Servers, or redirect Endpoint Cost
ranking requests to the best possible ALTO Server. Therefore, a
standard Server-to-Server API is also required.
2. Scope
The scope of this draft are the ALTO Server-to-Network APIs and
Server-to-Server API that are required for automated operation of the
ALTO Service. The Server-to-Network API is used to obtain network
topology information from the underlying network. Server-to-Server
API is used to exchange topology information between ALTO servers, or
to redirect ranking requests from one ALTO Server to another. The
ALTO Client-to-Server protocol [I-D.ietf-alto-protocol] itself may be
used as the ALTO Server-to-Server protocol; in other words, one ALTO
Server may request maps or status from other servers.
Medved, et al. Expires September 5, 2011 [Page 3]
Internet-Draft Alto Server APIs March 2011
3. Terminology
We use the following terms defined in ALTO Problem Statement
[RFC5693]: Application, ALTO Service, ALTO Server, ALTO Client, ALTO
Query, ALTO Reply, ALTO Transaction.
4. ALTO Server API Reference
In addition to the ALTO protocol, which constitutes the API between
the ALTO Server and its clients, the ALTO Server needs several other
APIs to get data that are required to generate the network and cost
maps. The reference diagram of possible ALTO Server APIs is shown in
Figure 1.
+---------+ +---------+
| ALTO | | ALTO |
| Client | | Client |
|(e.g.CDN)| |(e.g.CDN)|
+---------+ +---------+
^ ^
| (1) CS | (1) CS
V V
+---------+ +---------+
| | (2) SS | |
| ALTO |<---------------------------->| ALTO |
| Server | | Server |
+---------+ +---------+
^ ^
| (3) SN | (3) SN
V V
+---------+ +---------+
| | (4) NN | |
| Network |<---------------------------->| Network |
| | | |
+---------+ +---------+
Figure 1: ALTO Server API reference
The ALTO Server interfaces shown in Figure 1 are as follows:
1. CS: The Client-to-Server interface has been the focus of the ALTO
WG, and is defined in [I-D.ietf-alto-protocol].
2. SS: The Server-to-Server interface is required to exchange
topology data and status between ALTO servers in different
networks or administrative domains. For Endpoint Cost queries,
the interface can be used to direct the client's request to the
Medved, et al. Expires September 5, 2011 [Page 4]
Internet-Draft Alto Server APIs March 2011
peer ALTO Server that has the best data to respond to the query.
The interface may also facilitate other functions, such as ALTO
Server discovery.
3. SN: The Server-to-Network interface is used to get the network
topology data from the network.
4. NN: The Network-to-Network routing and data interfaces are well-
defined in a number of standards (for example, BGP [RFC4271]),
and they are not in scope of this draft.
4.1. The ALTO Server-to-Network Interface
4.1.1. Requirements
The Server-to-Network interface should satisfy the following
requirements:
o Enable automation of the operation of the ALTO server with minimal
human intervention
o Leverage existing sources of network topology data; don't
introduce new (routing) protocols; don't force un-natural
deployment of routing protocols within the ISP network
o Leverage scalable mechanisms for (near real-time) network topology
acquisition; don't use fragile mechanisms to obtain data (e.g.
screen-scraping information from looking glass servers)
o Enable centralized and/or distributed deployments of ALTO servers
o Provide network topology information from within the ISP network
(intra-AS) as well as from outside the ISP network (inter-AS), as
well as from different intra-domain routing areas. (Note that
some ISPs use multiple AS's for different components of the
overall network topology.)
o Enable automated ALTO server policy controls above and beyond mere
routing metrics
o Provide origin security for network topology information
o Provide the right balance between frequency of updates and
accuracy /timeliness of the data. Topology updates from the
network should be throttled. For ALTO application, a 15 minute
time interval between topology updates from the network should be
sufficient.
Medved, et al. Expires September 5, 2011 [Page 5]
Internet-Draft Alto Server APIs March 2011
In addition to having a standardized Server-to-Network interface, the
algorithms for generation of ALTO network / cost maps and for
endpoint ranking should be normalized as well, to facilitate inter-
operability of different ALTO Server implementations.
4.1.2. BGP with TE Extensions
Network topology is best conveyed through routing protocols. BGP
carries information about all subnets in the network, and subnet /
prefix data from BGP is required to generate ALTO network maps.
Intra-AS topology information that is carried in link-state IGPs and
inter-AS topology information carried in BGP is required to generate
ALTO cost maps. IGP TE data is required if costs in the cost maps
have a link utilization component.
This draft proposes to use BGP with TE extensions
[I-D.gredler-bgp-te] as the ALTO Server-to-Network API that can carry
both the subnet/prefix data for network map generation and the
topology data for cost map generation. A BGP Speaker can learn a
part or the entire intra-AS topology by participating in the IGP and
then distribute the learned topology to other BGP Speakers in the AS.
The ALTO Server establishes an iBGP session with a BGP speaker within
the AS, typically a Route Reflector, and learns the intra-AS topology
from its peer BGP speaker, along with the inter-AS topology and the
subnet/prefix data.
Using BGP with TE extensions as the ALTO Server-to-Network API has
several advantages:
o Avoid peering with IGP routers, which is more challenging than BGP
peering. Moreover, IS-IS, OSPF and EIGRP implementations would be
required, although only one IGP peering implementation would
typically be used at any given time.
o Unified interface to the network (single protocol), which carries
all the network information required to generate the topological
component of network and cost maps. The alternative would be for
the ALTO Server to interface - in addition to BGP - with IS-IS,
OSPF and EIGRP routing protocols.
o Simplified handling of multi-area IGP topologies: if the ALTO
Server wants to see the entire multi-area IGP topology, it would
need to peer with at least one IGP router in each area. Since the
ALTO Server would have to reside in one of the areas, it would
have to peer with IGP routers in other areas over GRE tunnels,
which is complex and potentially error prone. Alternatively, an
ALTO Server would have to be placed in each area, and the ALTO
Servers would have to exchange topology information between
Medved, et al. Expires September 5, 2011 [Page 6]
Internet-Draft Alto Server APIs March 2011
themselves via the Server-to-Server API.
o The ALTO Server can peer with a BGP Route Reflector. Route
Reflectors are widely deployed, and the Route Reflector control
architecture dovetails nicely with the desired ALTO Server control
architecture.
o BGP policy and marking capabilities allow the operator to modify
or filter / adjust both the prefix and the connectivity
information specifically for the ALTO Server's use. This
capability is important if the BGP Speaker and the ALTO Server are
in different administrative domains.
o BGP has some origin security. This capability is important if the
BGP Speaker and the ALTO Server are in different administrative
domains.
o BGP carries multicast for future enhancements, where the ALTO
Server will be creating multicast network and cost maps.
o Using BGP with TE extensions means that there only needs to be one
BGP speaker in each area (or two for redundancy) that gets the
area's topology from local IGP routers. The topology information
is then distributed throughout the AS and relayed to all
interested ALTO Servers. The topology information can be
appropriately tagged so that is only stored by those Route
Reflectors that talk to ALTO Servers. BGP Input and Output
filtering could ensure that only the minimum set of BGP Speakers
would need to store the topology information.
o The ALTO Server only needs to peer with a single BGP Speaker to
get the entire network topology.
o BGP with TE extensions can be used between eBGP peers to advertise
intra-AS topology information between peers in different ASes.
Intra-AS topology information from multiple ASes can then be used
by an ALTO Server to create more detailed network and cost maps
for the combined network.
Due to policy and security considerations, it is assumed that an ALTO
Server speaks via the Server-to-Network APIs only to a BGP Speaker in
the same Administrative Domain (that may encompass multiple IGP areas
and ASes). Any other use cases are for further study.
Note that the network topology received by the ALTO Server must not
be summarized beyond what is expressed by the IGP in each area. This
is because the network (router) does not understand the application-
specific constraints of the ALTO Server for suitable summarization.
Medved, et al. Expires September 5, 2011 [Page 7]
Internet-Draft Alto Server APIs March 2011
Also, where different scaling of metrics and different policies exist
inside an Administrative Domain, the Alto Server is instructed via
management on how to compare or normalize the data received from the
network. The network is not expected to provide translation or
normalization.
4.2. The ALTO Server-to-Server Interface
The ALTO Server-to-Server API is required because each ALTO Server
will likely have only a partial view of the overall network. The
ALTO Server's view of the network depends on which routers are the
sources of its topology data. Each router's topology data depends on
the administrative domain (Autonomous System) where the router is
deployed. In order to generate a combined network/cost map that
covers the network beyond its own Autonomous System, an ALTO Server
needs to exchange its map information with other ALTO Servers in
other network locations and/or administrative domains. To allow
generation of combined maps, costs in partial cost maps must be
normalized.
The network and cost maps defined in the Client-to-Server ALTO
interface provide sufficient semantics to be considered a good
candidate for the Server-to-Server information exchange. In other
words, the ALTO Client-to-Server interface can be used for
communication between ALTO Servers as well.
Note that the idea of sharing information directly between ALTO
clients has already been anticipated, as stated in Section 3.1.4 in
ALTO Requirements [I-D.ietf-alto-reqs]:
REQ. ARv07-31: The ALTO client protocol SHOULD allow the ALTO server
to add information about appropriate modes of re-use to its ALTO
responses. Re-use may include redistributing an ALTO response to
other parties, as well as using the same ALTO information in a
resource directory to improve the responses to different resource
consumers, within the specified lifetime of the ALTO response...
Also, although not a formal part of the ALTO protocol, support for
redistribution of ALTO data between clients has been anticipated in
the ALTO Protocol specification [I-D.ietf-alto-protocol] - see
Sections 6.2 and 8. Sharing data between ALTO Servers is similar,
but not the same.
Typically, an ALTO Server will handle requests for different
services. Moreover, the level of trust between different ALTO
Servers can vary. Therefore, topology passed via the Server-to-
Server API may be summarized, aggregated, or incomplete as long as
they are sufficient to meet the requirements implied by the client's
Medved, et al. Expires September 5, 2011 [Page 8]
Internet-Draft Alto Server APIs March 2011
request.
5. Conclusion
Having well-defined standard APIs will facilitate inter-operation
between ALTO Servers and the different sources of information that
are required to put together the maps. It will also facilitate
inter-operation between the ALTO Servers themselves. Multiple ALTO
Servers in different administrative domains may be required to
combine partial network maps / cost maps into an overall set of maps
that cover a larger multi-provider network or the whole internet.
Altogether, having standardized APIs will facilitate inter-
operability between ALTO Servers from different vendors.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
ALTO offers advice to applications on the optimality of various
possible Internet destinations for acquiring a resource or service.
An attacker who subverts or impersonates an ALTO service might be
able to trick many application on the Internet into contacting the
same host as a part of a distributed denial of service attack, for
example. Interfaces that provision the back-end of ALTO servers are
therefore a potentially attractive to attackers, as attackers might
attempt to corrupt the ALTO database in order to launch such an
attack.
For an ALTO server back-end interface to accept topology data from
BGP, the server must trust the source of the information. The ALTO
server must peer with a known route reflector, and must authenticate
that entity, especially if it is outside the administrative domain of
the ALTO server. Any origin security mechanisms will also increase
the assurance of the ALTO server. Integrity protection for the
channel between the ALTO server and the BGP speaker will also prevent
malicious parties from inserting problem information.
Similarly, the ALTO server-to-server mechanism also requires an
authentication and data integrity mechanism. If ALTO servers share
network maps between one another, for example, assuring the
Medved, et al. Expires September 5, 2011 [Page 9]
Internet-Draft Alto Server APIs March 2011
authenticity and source of data is essential. If ALTO servers share
network maps with one another over a public network, a
confidentiality mechanism will also be desirable in order to prevent
eavesdropping.
8. Acknowledgements
Hannes Gredler from Juniper Networks made significant contributions
to concepts presented in this draft. We would like to thank Alia
Atlas from Juniper Networks for her input and comments.
9. References
9.1. Normative References
[I-D.gredler-bgp-te]
Gredler, H. and J. Medved, "Advertising Traffic
Engineering Information in BGP", draft-gredler-bgp-te-00
(work in progress), March 2011.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-06 (work in progress),
October 2010.
[I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-07 (work in progress),
January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
9.2. Informative References
[I-D.lee-alto-chinatelecom-trial]
Li, K. and G. Jian, "ALTO and DECADE service trial within
China Telecom", draft-lee-alto-chinatelecom-trial-01 (work
Medved, et al. Expires September 5, 2011 [Page 10]
Internet-Draft Alto Server APIs March 2011
in progress), October 2010.
[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
Y. Yang, "Comcast's ISP Experiences in a Proactive Network
Provider Participation for P2P (P4P) Technical Trial",
RFC 5632, September 2009.
Authors' Addresses
Jan Medved
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: jmedved@juniper.net
David Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: dward@juniper.net
Jon Peterson
Neustar
Email: jon.peterson@neustar.biz
Richard Woundy
Comcast Corporation
27 Industrial Avenue
Chelmsford, MA 01824
US
Email: Richard_Woundy@cable.comcast.com
Medved, et al. Expires September 5, 2011 [Page 11]
Internet-Draft Alto Server APIs March 2011
David McDysan
Verizon
22001 Loudoun County Pkwy
Ashburn, VA 20147
US
Email: dave.mcdysan@verizon.com
Medved, et al. Expires September 5, 2011 [Page 12]