Considerations of Deploying ALTO using BGP - Link State (BGP-LS) AdvertisementTongji University4800 Cao'An HwyShanghai201804Chinajingxuan.zhang@tongji.edu.cnSichuan UniversityNo.24 South Section 1, Yihuan RoadChengdu610000Chinakaigao@scu.edu.cnTelefonicaRonda de la Comunicacion, s/nMadrid28050Spainluismiguel.contrerasmurillo@telefonica.comAltenCarrer de Josep Pla, 2Barcelona08019Spainanais.escribano@alten.esUST GlobalRamirez de Arellano 29Madrid28043SpainPatricia.Diez@ust-global.comTelefonicaAvenida del Conocimiento, 12Granada18016Spainfranciscojose.canohila@telefonica.com
Networks
ALTO WGALTO, Internet-DraftThis document discusses the requirements and deployment considerations of
providing Application-Layer Traffic Optimization (ALTO) information in the
inter-domain scenario using Border Gateway Protocol - Link State (BGP-LS)
extension.Requirements LanguageThe 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 .IntroductionThe major component of the Application-Layer Traffic Optimization (ALTO)
deployment is the network information collection.
discussed multiple options to collect the network information from the
inter-domain networks.To collection the related network information for ALTO, the following
high-level questions should be considered:
Can the ALTO service realistically discover that information?
Is the distribution of that information allowed by the operators of that
service?
Is it information that a client cannot find easily some other way?
The Border Gateway Protocol - Link State (BGP-LS) extension is
one of the popular options and has been deployed in many Autonomous Systems
(ASes) in recent years [TODO: Need some reference].BGP-LS enables ALTO server to provide underlay inter-domain topology
information using the link-state information in IGP domains.To leverage BGP-LS to generate ALTO information effectively, some
requirements for deployment should be considered.This document discusses these requirements and the corresponding deployment
considerations.Additionally, this document describes some inter-domain scenarios to test the
deployment.New Problem Statement and Working ItemsThis document was initially written to summarize ALTO deployment
consideration using BGP-LS. However, authors are finding new interesting
practical problems when pushing the deployment to large-scale ISP networks.Authors identify two problems:Problem 1: how to efficiently obtain fine-grained global ALTO information
from multiple networks?Problem 2: how to efficiently reconstruct and disseminate the ALTO
information upon dynamics?Considering the scale of the ISP carrier networks and the frequency of
network dynamicity, the previous design cannot survive. We have to target a
systemtic design to support (1) distributed information collection, and
(2) calculation and incremental information recomputation.Thus, authors propose a hierarchical architecture to deploy ALTO servers. To
make the deployment in different small networks compatible with each other,
the interfaces to allow interoperations between different ALTO servers are
required. Although we can design and implement those interfaces outside the
scope of ALTO, we believe making ALTO provide this capability by itself can
be a more coherent approach and also have more potential benefits.We are still heavily working on the initial specification. No more details
are added in the current document. But we have already done a paper
submission to talk about the initial design. For people interested in this
work, please feel free to contact us.BackgroundALTO Inter-domain Deployment Problem discusses considerations of ALTO deployment in different network
scenarios. The inter-domain network is the most common scenario to deploy
ALTO.In practice, the following approaches are used to collect information from
the network:
BGP-LS Background and Benefits for ALTOBGP-LS is designed to allow a BGP speaker to advertise the link state
database (LSDB) or traffic engineering database (TED) of its connected IGP
area.BGP-LS defines a new address family, link state, in the BGPv4 framework .Using BGP-LS, the ALTO server can communicate to only BGP speakers to collect
all those information.ALTO Deployment Problem using BGP-LSA simple deployment solution is to connect the ALTO server as a BGP reflector
client of every BGP speakers in the network. However, this solution is
expensive and redundant. And because of the BGP updates, the ALTO server
could receive a lot of inconsistent redundant informaiton. To avoid the
redundancy and inconsistency of the collected information, a deployment
solution should be minimal.To understand what is a minimal solution to deploy ALTO using BGP-LS, the
following questions are raised:
Is it necessary to connect the ALTO server to every AS within a BGP session?
Does the session between the ALTO server and each AS have to enable BGP-LS?
If using BGP-LS, can the number of necessary BGP sessions be reduced?
The following example shows a minimal deployment in a simple example topology.Consider the following AS-level topology as an example. Assuming all the BGP
sessions between ASes have enabled BGP-LS, the BGP speaker on AS B can
received the IGP topologies from all the three ASes. Thus, to make sure the
ALTO server collect all the inter-domain and intra-domain topology
information, the minimal deployment could be to set up the the ALTO server as
a BGP reflector of the BGP speaker on AS B.However, it is not enough for collecting the routing information. As the BGP
is a destination-based routing protocol, AS B could not receive the routing
information between endpoints from AS A and AS C. To get the missing routing
information, the ALTO server should also connect read the BGP RIB of AS A or
AS C at least.As the result, the minimal solution is to establish a BGP session to AS B
with BGP-LS and another BGP session to AS A (or AS C) without BGP-LS.The following part of this document will discuss how to achieve the minimal
ALTO deployment using BPG-LS in detail. Specifically, two questions are
required to be answered:
Which BGP speakers are required to be connected to the ALTO server?
Which BGP sessions are required to enable BGP-LS?
Requirements for Deploying ALTO in the Inter-domain Scenario using BGP-LSBasic RequirementsThe following basic requirements are required by ALTO inter-domain deployment in any case.Req 1: The ALTO server MUST be able to collect topology information from
multiple IGP areas.Req 2: The ALTO server MUST be able to collect routing information for any pairs of endpoints.Req 3: The ALTO server MUST be able to collect performance metrics across routes.BGP-LS specific RequirementsThe following additional requirements are required by ALTO deployment when using BGP-LS.Req 4: The ALTO server SHOULD only communicate with necessary BGP speakers.Req 5: The ALTO server SHOULD only enable BGP-LS advertisement in necessary BGP sessions between BGP speakers.ALTO Deployment Considerations using BGP-LSThis section discusses some deployment considerations about how to address
the basic requirements (Req 1-3) when satisfying the BGP-LS specific
requirements (Req 4-5).Provisioning of Topology InformationAs BGP-LS advertisement cannot be propagated to remote the remote ASes, each
BGP speaker can only discover directly peered IGP topologies using BGP-LS.To satisfy Req 4, the ALTO server should only communicate to transit networks
or IXPs using BGP-LS. As the IGP topology of a stub network can always be
discovered by its peered transit networks or IXPs, so it is not necessary to
communicate with the stub network.Specifically, the ALTO server should find a minimal BGP speaker set whose
peered networks can cover all IGP domains.Provisioning of Routing InformationAs BGP is a destination-based routing protocol, a stub network can receive
all the inter-domain routing information from all the reachable destinations
via BGP.Thus, to satisfy Req 4, the ALTO server should only communicate to stub networks
using BGP, as the inter-domain routing information from the transit networks is
not necessary.Assuming the ALTO server has already collected the complete topology
information using BGP-LS, the ALTO server will have the LSDB of every IGP
domain.To satisfy Req 5, all the BGP sessions connected to the stub networks do not
have to enable BGP-LS.Provisioning of Performance Metric InformationTBD.Configuration Interfaces of Map CalculationConfiguration Interface of Network Map CalculationTo generate a network map, one or more BGP RIBs that could provide the
topology information MUST specified. Each BGP RIB MAY include a pre-computed
topology from the RIB, and an option indicating if the BPG-LS is enabled.The inspect-igp option in the first-hop-cluster-algorithm field indicates
if the ALTO server exposes information about the IGP topologies. If it is
true, the ALTO server will inspect all the IGP topolgies from the BGP RIBs
that enalbe BGP-LS (whose bgp-ls option is true).Configuration Interface of Cost Map CalculationTo generate a cost map, besides the dependent network map, one or more
alternative BGP RIBs could be specified to provide necessary routing
information to the ALTO server.Configuration ExamplesExample NetworkConfig a network map:Test to fetch the network map:Config a cost map:Test to fetch the cost map:Test ScenariosTest Environment SetupTest ApproachTest ResultsReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]Application-Layer Traffic Optimization (ALTO) ProtocolApplications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPIn a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).Application-Layer Traffic Optimization (ALTO) Deployment ConsiderationsMany Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric ExtensionsThis document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.Informative ReferencesMulti-Cost Application-Layer Traffic Optimization (ALTO)The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.ALTO Extension: Path VectorThis document is an extension to the base Application-Layer Traffic Optimization protocol [RFC7285]. The current ALTO Cost Services allow applications to obtain cost values on an end-to-end path defined by its source and destination. The present extension provides abstracted information on particular network parts or elements traversed by a path between its source and destination. Examples of such abstracted parts are networks, data centers or links. This is useful for applications whose performance is impacted by particular network parts they traverse or by their properties. Applications having the choice among several connection paths may use this information to select paths accordingly and improve their performance. In particular, they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This document introduces a new cost type called Path Vector. A Path Vector is an array of entities that each identifies an abstracted representation of a network part and that are called Abstract Network Element (ANE). Each ANE is defined by a set of properties. ANE properties are conveyed by an ALTO information resource called "Property Map", that can be packed together with the Path Vectors in a multipart response. They can also be obtained via a separate ALTO request to a Property Map. An ALTO Property Map is an extension to the ALTO protocol, that is specified in another document entitled "Unified Properties for the ALTO Protocol" [I-D.ietf-alto-unified-props-new].Unified Properties for the ALTO ProtocolThis document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to generic types of entities, and by presenting those properties as maps, similar to the network and cost maps in [RFC7285].Application-Layer Traffic Optimization (ALTO) Cost CalendarThis document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendar, with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.ALTO Incremental Updates Using Server-Sent Events (SSE)The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes; and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.BGP-LS Extension for Inter-AS Topology RetrievalThis document describes the process to build BGP-LS key parameters in Native IP multi-domain scenario and defines some new inter-AS TE related TLVs for BGP-LS to let SDN controller retrieve the network topology automatically under various environments. Such process and extension can expand the usage of BGP-LS protocol to multi- domain, enable the network operator to collect the connection relationship between different AS domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol.