[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/