1
Ad-hoc Recursive PCE Based Inter-domain Path Computation (ARPC) Methods Gilles Bertrand and Géraldine Texier Telecom Bretagne - RSM department - Rennes, France
[email protected],
[email protected]
Abstract—With the emergence of multimedia applications with stringent requirements, like IPTV, the need for end-toend Quality of Service (QoS) is increasing. In this paper, we investigate the problem of how to route high QoS flows with endto-end QoS guarantees in a Path Computation Element (PCE) based architecture. In this architecture, three main types of path computation methods have been proposed: methods based on aggregated representations of the network, methods using predetermined domain (AS) sequences or methods using only the knowledge of the intra-domain topology as well as of the inter-domain links connected to the domain. The last family of algorithms is called ad-hoc methods. These methods have not been extensively studied in the context of the PCE architecture yet. This paper has two main contributions. First, we propose a new Ad-hoc PCE based Recursive Inter-domain Path Computation method (ARPC) that dynamically determines the AS sequence crossed. This algorithm integrates complexity reduction mechanisms. We consider an example application of this algorithm for simultaneously minimizing the traffic forwarding cost, guaranteeing a minimum bandwidth and optimizing an additive metric related to load balancing. We assess the performance of this algorithm with regard to these objectives. A simulation study demonstrates that the complexity of ad-hoc methods is reasonable, in certain topologies. Thus, these methods deserve further study. Second, we propose that PCEs in a domain are aware of the economical cost (price) of the inter-domain links connected to this domain. We demonstrate that this additional knowledge allows the implementation of interesting economical strategies. For that, we implement a detailed example.
Keywords: MPLS, PCE, inter-domain path computation I. I NTRODUCTION The emergence of multimedia applications with stringent requirements, like IPTV or on-line gaming, underlines the need for end-to-end Quality of Service (QoS) in networks. There are two main principles for providing QoS in a telecommunication network. The first involves allocating resources per flow or per class of service. The second principle involves optimizing the performance of the network by Traffic Engineering (TE). Multi-Protocol Label Switching with Traffic Engineering (MPLS-TE) is an architecture that allows each MPLS domain to perform constrained source routing in the head-end Label Source Router (LSR) of a Label Switched Path (LSP). Path computations are based on one or several metrics associated with the links of the domain. These user oriented metrics can be related to the level of QoS or protection of the path. Alternatively, network oriented metrics can be related to traffic engineering objectives. A domain is a set of network equipments administrated by the same entity and with homogeneous configuration and
policy. More precisely, in the scope of this paper, a domain is an autonomous system (AS). ASes have a very limited collaboration due to scalability (information aggregation) and confidentiality constraints. Each AS advertises inter-domain routes toward a subset of its neighboring ASes according to its export policy: the route advertisements depend on inter-AS relationships. ASes can be bound by three main types of agreements: customer-provider, peering and providercustomer. Customer ASes have to pay when they forward traffic to a provider AS. Therefore, it is economically interesting to select appropriate egress nodes and inter-domain routes in order to minimize the cost induced by inter-domain traffic forwarding [1]. The Border Gateway Protocol (BGP-4) is the most used inter-domain protocol in the Internet. It provides a reduced path diversity due to information aggregation. Therefore, interdomain routing is far from being optimal in the current Internet [2]. Besides, Internet Service Providers (ISPs) only have a limited control on path selection. This makes load balancing and maintenance operation planning more complicated [3]. In practice, BGP only advertises reachability information between domains. This approach has been proved to be scalable but hinders the deployment of inter-domain TE mechanisms [4]. Reference [4] provides an overview of open issues in inter-domain routing. Several extensions and modifications of BGP for solving previous issues and for providing end-toend QoS have been suggested in recent papers (e.g. [5], [6], [7]). However, BGP replacement is not envisioned because of its worldwide deployment [4]. The interest for computing constrained paths crossing several domains is rising, because it would allow end-to-end flow protection, optimal path computations and inter-domain traffic engineering. A control plane enabling inter-domain path negotiation is standardized by the Internet Engineering Task Force (IETF) in the Path Computation Element (PCE) working group [8]. In the PCE architecture, LSRs can delegate path computations to a specialized network node called PCE. PCEs in different ASes are able to cooperate in order to compute constrained inter-domain LSPs. This way, constrained interdomain paths can be computed even if neither topology nor traffic information is advertised out of the domains. PCE standards do not impose a path computation algorithm. A Backward Recursive PCE based Computation (BRPC) method is under standardization [9]. BRPC assumes that the sequence of ASes crossed by the path is predetermined. Due to this assumption, good paths crossing different AS sequences
2
are ignored. In addition, because two paths crossing the same AS sequence have a larger probability to share a common risk, the simultaneous computation of a primary and of a backup path has a lower success probability [10]. Besides, the paths computed are less likely to be globally optimal1 due to the constraint added by a predetermined AS sequence [11]. This paper has two main contributions. First, we propose a new PCE based ad-hoc Recursive Inter-domain Path Computation method (ARPC) that dynamically determines the AS sequence crossed. This algorithm integrates complexity reduction mechanisms. We consider an example of application of ARPC for simultaneously minimizing the traffic forwarding cost, guaranteeing a minimum bandwidth and optimizing an additive metric related to load balancing. We assess the performance of ARPC with regard to these objectives. A simulation study demonstrates that the complexity of ARPC is reasonable, in certain topologies. This indicates that Ad-hoc methods deserve further study. Second, we propose that the PCEs in a domain know the economical cost (price) of the inter-domain links connected to this domain. We demonstrate that this additional knowledge makes the implementation of interesting economical strategies possible. For example, we integrate price information in the algorithm proposed, in order to guarantee that each AS advertises its most profitable paths. The rest of the paper is structured as follows. In Section II, we introduce the architecture considered and related work. In Section III, we describe the metrics considered and our routing algorithm. In section IV, we present an evaluation of the proposed mechanisms based on a simulation model. II. I NTER - DOMAIN PATH COMPUTATION A. Forwarding policies Unlike intra-domain routing, inter-domain routing in the Internet is mainly policy driven. There are two main types of inter-AS relationships in the Internet: customer-provider and peer-to-peer. These relationships define export policies describing which prefixes are advertised toward neighboring ASes. Each AS A advertises [10]: •
• •
to its providers: its own IP prefixes and those learned from its customers, but not those learned from its peers or from other providers, to its customers: all the reachable IP prefixes it knows, to its peers: its own IP prefixes and those learned from its customers, but not those learned from its providers or other peers.
Thus, the relationship between two ASes A and B respects the following forwarding policies [11]: •
•
If B is a customer of A, then, B can forward packets from its provider A to its customers but not to its peers or other providers. If B is a provider of A, then, B can forward packets from its customer A to any of its neighboring domain (provider, customer or peer).
1 In this paper, the paths that would be computed by an omniscient element are referred to as optimal
Fig. 1.
Architecture considered
If B is a peer of A, then, B can forward packets from its peer A to its customers but not to its providers or other peers. Export policies and forwarding policies have to be taken into account when computing an inter-domain path. This makes the computation of constrained inter-domain paths a much more difficult problem than the computation of paths at intra-domain level. •
B. The PCE architecture The MPLS architecture was mainly designed in order to provide improved packet forwarding performance compared to IP packet forwarding, thanks to label switching. It was later extended into MPLS-TE for traffic engineering. In MPLS-TE architecture, given a source-destination couple in the MPLS domain, the head-end LSR (source) is able to compute a path toward the destination, by using a Constrained-Shortest Path First (C-SPF) algorithm. CSPF is a link-state routing algorithm that requires full knowledge of the topology of the domain, as well as of the resource availability. This information is retrieved by the head-end LSR thanks to traffic engineering (TE) enabled protocols like OSPF-TE or ISIS-TE. For confidentiality and scalability reasons, it is not possible to generalize this method for inter-domain traffic engineering: network operators do not want to advertise information on their topology outside of the domain and inter-domain protocols can only advertise aggregated representations of the network, due to the number of domains (ASes) in the Internet. As a result, each domain has a partial visibility of the network. The Path Computation Element architecture provides a solution to the partial visibility problem. This architecture is standardized by the PCE working group of the IETF [8], [12]. The PCE architecture provides a method for computing inter-domain paths fulfilling a set of constraints in an MPLS network. In the PCE architecture, LSRs can act as Path Computation Clients (PCC) and send path computation requests to a PCE. The PCE performs path computation operations and replies back to the PCC. During path computation operations, a PCE can forward a request to other PCEs. Consequently, PCEs in several domains can be involved in the computation of interdomain paths. Thus, it solves the partial visibility problem. A simple PCE network is depicted in Figure 1. In this example, there is a single PCE per AS and ASes are not divided into sub-domains (areas). PCE standards describe a request-response protocol (the PCE protocol) for the computation of the paths [13]. This
3
protocol is not appropriate for the periodic advertisement of aggregated representations of the network [10]. C. The BRPC method The Backward Recursive PCE based Computation (BRPC) method is the only PCE based path computation algorithm under standardization [9]. It assumes that the sequence of domains crossed by the path computed is predetermined. The path computation request is sent by the PCC to a PCE in its domain and then, forwarded until it reaches a PCE in the destination domain. Then, the algorithm builds a Virtual Shortest Path Tree (VSPT). This structure is built recursively, from the destination. Each domain (AS(k)) concatenates its topology with the VSPT and computes a set of constrained shortest paths from its entry border routers to the path destination, in the resulting topology. The VSPT is updated in order to include the shortest paths computed and forwarded to a PCE in AS(k−1). Finally, PCE1 receives the VSPT and computes one or several constrained shortest paths satisfying the constraints. Note that the constrained shortest path computations are performed according to the same link metric in all domains.
Fig. 2.
BRPC method, example
A simple example is depicted in Figure 2. In this example, a computation request for a path from 1 to 9 is sent by a LSR denoted as 1 to a PCE (PCE1) in AS1. This request is forwarded by PCE1 toward a PCE (PCE3) in the destination domain AS3. PCE3 computes constrained shortest paths from the entry border routers (7 and 8) to the destination 9 according to the metric considered. It forwards the paths computed to a PCE (PCE2) in AS2, in a VSPT. AS2 concatenates the VSPT with its topology and computes constrained shortest paths from its entry border routers (3 and 4) to the destination 9, in the resulting topology. The shortest paths computed are composed of two segments 3→7 + 7→9 and 4→8 + 8→9 for example. The VSPT is updated with the paths computed and forwarded to a PCE (PCE1) in AS1. Then, PCE1 computes the final paths from 1 to 9, which are made up of three segments, for example 1→3 + 3→7 +7→9 or 1→4 + 4→8 + 8→9. With this procedure, optimal end-to-end paths across a predetermined sequence of ASes can be computed. D. Related work and our contributions PCE standards do not impose a path computation algorithm. A few algorithms have been proposed in the literature (Figure 3). Among them, only one is currently under standardization, it is the BRPC method [9]. The BRPC method assumes that the sequence of ASes crossed by the path is predetermined. This assumption leads to several limitations listed in [10], [11]. The main concerns expressed by Sprintson et alii in Reference [11]
are related to the optimality of the paths computed, because of the additional constraint introduced by a predetermined AS sequence. In Reference [11], Sprintson et alii propose an alternative method based on advertising an aggregated representation of the domains. Their method solves the problems introduced by predetermined AS sequences. In summary, their algorithm provides optimal solutions for the multi-domain disjoint path problem both in the general setting as well as subject to the export policy constraints. It is based on Suurballe and Tarjan method [14]. The aggregated network representation proposed is designed to enable optimal path computations and is based on line graph representations of the domains, in order to take forwarding policies into account. The size of the aggregated representation of a domain is O(B 4 ) for a domain containing B border routers. In [11], the authors mention that in the destination domain, the destination t of the request considered must be included into the aggregated representation, so that the end-to-end path can be computed by a PCE in the source domain. In our opinion, this may introduce two problems. First, in a stub domain, the number of potential destinations of an interdomain request can be high, thus a large number of nodes may have to be included in the aggregated representation of this domain. Therefore, the size of the aggregated representation of each stub AS may be much larger than O(B 4 ), which may introduce scalability concerns. Second, a domain has to be able to identify the potential destinations of inter-domain requests, when it computes its aggregated representation. The complexity of the forwarding policies makes that each AS has its view of the network that can be different from the view from another AS. Thus, it is rather difficult to find a concise aggregated representation of the network. Consequently, in this paper, we study alternative, distributed methods called ad-hoc methods, which rely on local choices in each domain [15]. Each domain is aware of the relationships it has with its neighbors. Therefore, ad-hoc methods take forwarding policies into account more easily. Ad-hoc methods require only a local view of the network: they need to be aware of the intra-domain topology and of intra-domain traffic engineering information, as well as of the inter-domain links connected to the domain considered and of their remaining bandwidth. Ad-hoc have not been extensively studied in the context of the PCE architecture yet. Unlike the methods relying on the diffusion of aggregated representations of the network, ad-hoc methods rely on simple response-request exchanges that could be implemented with a protocol such as the one described in Reference [13] with only slight modifications. The main advantage of ad-hoc methods is that they rely on dynamic network exploration for finding paths satisfying the constraints. This allows fast auto-adaptation to network and topology changes. The main drawback of these methods seems to be the potential latency and overhead introduced by network exploration. Therefore, it is important to explore the paths efficiently, even if, according to the PCE working group’s charter, the PCE architecture considers small set of domains. Thus, this work focuses on the evaluation of the complexity of ad-hoc algorithms that includes simple
4
complexity reduction mechanisms. To the best of our knowledge, this paper is the first to study complexity reduction mechanisms for ad-hoc algorithms in the PCE architecture. Ad-hoc algorithms have been proposed for peer-to-peer networks and ad-hoc networks, for example. The use of ad-hoc algorithms in the PCE architecture was first suggested in [15]. In this reference, Torab et alii provide a short example of ad-hoc cooperation. They summarize the principle of ad-hoc algorithms adapted to the PCE architecture. This principle is illustrated in Figure 4 and is explained in Section III-C. Unlike this paper, Reference [15] does not study any mechanisms for limiting the complexity of ad-hoc path computation algorithms. The advantages and drawbacks of ad-hoc PCE based path computation methods can be summarized as follows. + Ad-hoc methods rely on distributed path computations requiring only local visibility. Thus, ad-hoc methods do not require large amount of information to be advertised throughout the network. + Ad-hoc methods consider a larger path diversity than methods imposing a predetermined AS sequence. - But, the complexity of the network exploration performed by ad-hoc methods has to be controlled. Path computation algorithms Source
Distributed
Omniscient
Aggregated view
Domain sequence
Ad-hoc
CSPF
Sprintson [11]
BRPC [9]
Torab [15], ARPC
Fig. 3.
PCE-based inter-domain path computation algorithms
A summary of existing PCE-based path computation methods is presented in Figure 3. In this figure, PCE-based path computation methods are classified according to the location of the path computations as well as the information used for these computations. The Constrained Shortest Path First (CSPF) method refers to the computation of constrained shortest paths by an omniscient PCE in the source domain, it is inapplicable in the networks considered, due to forwarding policies and scalability concerns. The algorithm presented in [11] is classified as source routing, because the path computation is performed by a PCE in the source domain (but the aggregated representation computations are distributed throughout the network). Our contributions can be summarized as follows: • We propose two simple complexity reduction mechanisms for ad-hoc PCE-based path computation algorithms and demonstrate their efficiency. • We propose that PCEs are aware of the price of the inter-domain links connected to their domain. We show that this knowledge can be used in order to minimize the traffic forwarding cost paid by the domains and to increase their profits. • We describe a new ad-hoc recursive PCE based path computation (ARPC) algorithm respecting forwarding policies. This algorithm minimizes, first, the traffic forwarding price paid by each domain crossed, second, an
additive metric m associated with the path. In addition, it guarantees a minimum bandwidth and a maximum value M of the additive metric m considered. III. M ETRICS AND PATH COMPUTATION ALGORITHM A. Assumptions We consider that the PCE based routing algorithm is used only for a part of the traffic, namely the traffic with high QoS requirements or traffic with stringent protection requirements (e.g. traffic related to mission critical services). For example, in a DiffServ able network, the PCE based mechanism could be used for Expedited Forwarding (EF) traffic. The PCE has to find a path satisfying some constraints (e.g. QoS, protection, price). In the example considered in this paper, we assume that the purposes of the path computation are to minimize traffic forwarding costs, to guarantee a minimum bandwidth and to balance network load. Stated differently, the algorithm optimizes, first, a price metric and, second, an additive link metric (cost), while respecting a bottleneck metric constraint (bandwidth). A link that connects two nodes in the same domain is referred to as an intra-domain link, while a link that connects different domains is referred to as an inter-domain link. We propose that PCEs are not only aware of the cost of intradomain links in their domain, but also of the price of the interdomain links connected to their domain. The number Ner,A of inter-domain links connected to a domain A is usually much lower than the number Nra,A of intra-domain links. Thus, storing Ner,A values of a price metric should not introduce any scalability problem. PCEs use price information in order to minimize the inter-domain traffic forwarding cost. In a BGP based routing configuration, each domain would also minimize this cost by allocating the highest local preference to the least expensive inter-domain paths. Thus, the learning of inter-domain link prices by PCEs is quite similar to the configuration of local preferences in BGP routers. However, in this work, we do not study how PCEs learn the prices. Globally, we assume that each PCE knows the following characteristics of its AS: • the intra-domain topology (intra-domain links, their remaining bandwidth, and the value of the link metric considered), as is assumed for the BRPC method, • the inter-AS links connected to its AS, their type (e.g. customer to provider, peering), as well as associated price information. Part of this information is static (e.g. peering agreements) and part is dynamic (e.g. internal topology). The topology can be learned by means of ISIS or OSPF, if the AS is made of a single Interior Gateway Protocol (IGP) area. In all other cases, the PCE must be able to request intra-domain path computations to one or several intra-domain PCEs. For the sake of simplicity, we consider in this paper that each AS is made of a single area. The case of an Inter-AS TE LSP spanning multiple ASes where some of those ASes are themselves made of multiple IGP areas can be easily derived from this case by applying the path computation procedure described in this paper, recursively.
5
B. Metrics considered In this paper, two metrics are considered for the recursive computation of inter-domain paths: the value of a cost metric on all links and the traffic forwarding price on the first interdomain link of the path. The cost metric mp characterizes the quality of a path p regarding user-oriented or operator oriented objectives. The price pp is related to the economical interest of the path p. As a result, the optimization of user oriented and operator oriented metrics is considered. The price of intra-domain paths is considered to be zero. The end-to-end price pp of an inter-domain path p is the price p(e,nh) incurred by the first inter-domain link: (e, nh). This link connects the egress node e of the first AS crossed to the next-hop nh, where we call next-hop the first AS border router (ASBR) crossed in the next AS. We consider a demand d routed on a path whose first inter-domain link is (e, nh). The price paid by an AS for serving d is proportional to the bandwidth bd requested by this demand: pd(e,nh) = p(e,nh) · bd
(1)
Each domain is expected to carry the traffic on the paths that are the most profitable. In other words, if an AS A knows several paths that are suitable for a demand, then, A advertises its most profitable paths. We consider additive link costs m(i,j) in order to penalize long paths. As a result, the end-to-end cost of an interdomain path is the sum of the costs for each section of the path: ingress(s)-egress(e), egress-next_hop(nh) and next_hopdestination(t). Note that all domains have to use the same cost metric for computing intra-domain paths. We seek to balance the load over network links. Thus, the least loaded links get the smallest weights and are most likely to be used. We define the weight m(i,j) of each link (i, j) as 104 divided by its remaining capacity cr,(i,j) in Megabit per second: 104 (2) m(i,j) = cr,(i,j) C. An Ad-hoc Recursive PCE-based Path Computation (ARPC) method 1) Intra-domain routing algorithm: A standard on-line algorithm can be used for the routing of any intra-domain demand d with source s, termination t and bandwidth bd . This algorithm computes segments of inter-domain paths. If the source and the termination of the demands are the same single node, then, the cost of the path is arbitrarily set to zero. In all other cases, a variant of Dijkstra’s algorithm is run on a graph of the network where all links with remaining capacity cr,(i,j) < bd are pruned [16]. Alternative methods can be used depending on the constraints considered. For instance, reference [17] reviews methods for finding a path subject to many additive constraints 2) Inter-domain routing algorithm: The inter-domain routing algorithm running in the PCEs computes constrained interdomain paths recursively. In the example considered in this paper, the aim of this algorithm is to minimize the price paid for a demand, while fulfilling the two following QoS
constraints. First, the bandwidth allocated on each link must be equal to the demanded bandwidth. Second, a given path cost threshold related to a specified additive cost metric must not be exceeded and the value of that cost metric should be minimized. The cost metric considered in this paper is provided in equation 2. The overall algorithm, is depicted (with a few simplifications) in Figure 4. The termination of the algorithm can be guaranteed by defining the maximum number of times a single request can be forwarded. As a path is selected only if its price is better than the one of the previous best path, the algorithm converges toward the paths with the best prices. The head-end LSR s of a path sends a demand d to a PCE (PCE α) in its AS A. The request contains the following information: • the address of the source s in A of the demand d, • the address of the destination t of the demand d, • the bandwidth bd requested, • the maximum cost Md allowed, • the list of the ASes already visited (this list is empty for the first request) and • the type of the metric m to be used for the path computations. When a PCE (PCE α) in AS A receives a request, it performs the following operations, summarized in Figure 4. • It checks if its AS number appears in the list of the AS already visited. If yes, it returns a loop advertisement (cost = ∞) and terminates. If no, it performs the following operations. • It checks if the destination of the demand belongs to its AS (AS A). – If yes (the demand is intra-domain), the PCE computes a constrained intra-domain path or retrieves IGP information. ∗ If it finds an intra-domain path with a cost which is lower or equal to the maximum allowed cost, then, it returns it to the requesting PCC (s). The price of this path is zero, its next-hop address is the destination address t and the AS path contains only the AS number of A. ∗ If such a path is not found, the algorithm returns an infinite cost and the PCC is advised that no path could be found. – If no (the demand is inter-domain), the request is forwarded to a subset of the domains with which A has an agreement, depending on the forwarding policies of A. The request forwarded by a PCE α in an AS A to a PCE β in an AS B is slightly modified so that the recursive procedure can continue. • The address of the source is set to the address of the next-hop in B, • the maximum cost allowed is decreased by the cost of the inter-domain link used and • A is included in the list of the AS already visited. However, the address of the destination t, the bandwidth bd
6
y
AS already visited?
PCE2. The concatenation of the segments computed in each AS provides two disjoint paths: s, 3, 7, t and s, 4, 8, t.
cost=inf n y
Intradomain demand
cost=intradomain_cost
n for all ASBR (nh) selected
y costdest) price=0 nh=dest ASpath=[AS]
Computation of two disjoint paths, example
n cost=inf
compute_end2end_cost
y
price
