Efficient Distributed Bandwidth Management for MPLS Fast Reroute

Transcription

1 Efficient Distributed Bandwidth Management for MPLS Fast Reroute Dongmei Wang and Guangzhi Li Abstract As service providers move more applications to their IP/MPLS (Multiple Protocol Label Switching [1]) backbone networks, rapid restoration upon failure becomes more and more crucial. Recently MPLS fast reroute has attracted lots of attention as it was designed to meet the needs of real-time applications, such as voice over IP. MPLS fast reroute achieves rapid restoration by computing and signaling backup label switched path (LSP) tunnels in advance and re-directing traffic as close to failure point as possible. To provide a guarantee of bandwidth protection, extra bandwidth has to be reserved on backup LSP tunnels. Using path merging technique as described in [2] only, the network is able to share some bandwidth on common links among a service LSP and its backup LSPs. But no solution is provided on how to share bandwidth among any service LSPs and backup LSPs for MPLS fast reroute. In this paper, we provide an efficient distributed bandwidth management solution. This solution allows bandwidth sharing among any service LSPs and backup LSPs with a guarantee of bandwidth protection for any single node/link failure. We also propose an efficient algorithm for backup path selection, and provide the associated signaling extensions for additional information distribution and collection. To evaluate our schemes, we compare them via simulation with the basic MPLS fast reroute proposal [2] on two networks. Our simulation results show that using our bandwidth management scheme can significantly reduce restoration overbuild from about 250% to about 100%, and our optimized backup path selection can further reduce restoration overbuild to about 60%. Index terms Simulation, Restoration, Protocol, MPLS Fast Reroute A. INTRODUCTION As service providers move more applications to their IP/MPLS (Multiple Protocol Label Switching [1]) backbone networks, such as voice over IP and on-line games, et. al., rapid restoration upon failure becomes more and more crucial. Recently MPLS fast reroute has attracted lots of attention as it enables the re-direction of traffic onto backup LSP (label switched path) tunnels rapidly in the event of a failure [2], which would be sufficient for most of IP based application requirements. Internet Engineering Task Force (IETF) has published RFC 4090 [2] to address the necessary signaling extensions for supporting MPLS fast reroute, and how to use path merging technique to share the bandwidth on common links among a service LSP and its backup LSPs. However, no solution is provided on how to share bandwidth among any service LSPs and backup LSPs for MPLS fast reroute so far. Recently there has been a great deal of work addressing restoration functionality and schemes in IP/MPLS networks [3,4,5,6,11,12,13,14] as well as how AT&T Labs- Research, 180 Park Avenue, Florham Park, NJ {mei,gli}@research.att.com to manage restoration bandwidth among network and select optimized restoration paths [7,8,9,10]. However, all of them deal with path-based end-to-end LSP restoration except [13,14] addressing routing protocol fast re-convergence. To the best of our knowledge, we have not seen any published paper to address bandwidth sharing among any service LSPs and any backup LSPs for MPLS fast reroute. Since the backup LSPs are preestablished, even though they do not consume bandwidth before failure happens, the network has to reserve enough restoration bandwidth to guarantee the LSP restoration for any failure. Without bandwidth sharing among backup LSPs for different service LSPs, the network may need to reserve much more bandwidth on its links than necessary. Here we propose an efficient distributed bandwidth management solution for MPLS fast reroute for bandwidth sharing among any service LSPs and any backup LSPs. Our scheme is based on the observation that the restoration bandwidth can be shared by multiple backup LSPs so long as their protected service LSP path segments are not susceptible to simultaneous failure. This observation has been used by many researchers [8,10,20,22]. But how to apply this observation on MPLS fast reroute is still unclear. We also provide an efficient distributed backup path selection algorithm to maximize the bandwidth sharing. Our proposals have no confliction with the IETF MPLS fast reroute RFC 4090 [2] but rather enhancements to it. Since we address distributed bandwidth management and backup path selection, link usage information needs to be distributed throughout the network. Some of the required information is provided by current link state routing protocol extensions [15,16]. Different from other research work assuming routing protocol to distribute all required information, here we propose signaling protocol extensions to disseminate and collect few key information among network nodes 1. Our proposal keeps the overhead of distributing and collecting the additional information scalable. To demonstrate the efficiency of our proposals, we evaluate the bandwidth efficiencies of our approaches and the IETF MPLS fast reroute [2] via simulation on two networks: a US intercity backbone network and a Toronto metropolitan network from [12]. The results 1 This paper uses node, router, and LSR exchangablely.

2 demonstrate that our two enhancements are able to reduce the amount of reserved restoration bandwidth dramatically. This represents a potentially significant cost savings to network providers. Since the additional information needed for bandwidth management doesn t require extra link state information to be flooded via the routing protocol, there is no routing protocol scalability issue. Thus, our proposed two enhancements are suitable for use in real IP/MPLS networks. In this paper, we only describe the necessary information required to be distributed and how to process this information on each label switched router (LSR) for bandwidth management and leave the detail signaling object extensions and protocol compatibilities for standardization process. The contributions of this paper can be summarized as follows: We present a new distributed bandwidth management mechanism to achieve any service LSP to any backup LSP bandwidth sharing and describe operation procedures in detail. We proposed message extensions between neighbor nodes to distribute and collect a few critical information. We designed a distributed backup paths selection algorithm, which using partial routing information only to achieve complete routing information result. Based on our simulation, the proposed new bandwidth management mechanism and backup path selection algorithm can significantly reduce the network restoration overbuild. The paper is organized as follows. Section B summarizes MPLS fast reroute mechanism and discuss its bandwidth management issues. We denote the IETF fast reroute scheme in [2] as our baseline. Section C describes our first enhancement and gives an operational overview of our proposed bandwidth management method and data structure updating procedures. Section D presents our second enhancement of efficient backup path selection algorithm and introduces new signaling messages between neighboring nodes to distribute and collect extra information. Section E discusses related work. Section F and section G present the simulation scenarios and performance results. 1) Baseline B. MPLS FAST REROUTE IETF fast reroute [2] defines two MPLS fast reroute methods: one-to-one backup method and facility backup method. The one-to-one backup method creates detour LSPs for each protected service LSP at each potential point of failure, such as link failure or node failure. The one-to-one backup is corresponding to each individual LSP. The facility backup method creates a bypass tunnel to protect a potential failure point. Any LSPs using the same protected facility will be protected by the same bypass tunnel. Thus, facility backup method can be presetup around potential failure point in the MPLS network and the bypass tunnels can be pre-designed in a centralized system to reduce network restoration capacity. However, the one-to-one backup method has to establish/delete backup LSPs on time as protected LSP comes and goes in a distributed MPLS network. In this paper, we only consider one-to-one backup method and propose a mechanism to manage network capacity such that LSPs can share bandwidth on common links globally under single node/link failure assumption. R1 R2 R3 R4 R5 R6 R7 R8 R9 Protected LSP: R1->R2->R3->R4->R5 R1 s backup: R1->R6->R7->R8->R3 R2 s backup: R2->R7->R8->R4 R3 s backup: R3->R8->R9->R5 R4 s backup: R4->R9->R5 Figure 1: One-to-one Backup Method Example Figure 1 is an example from IETF RFC [2] illustrating one-to-one backup method. As [2] pointed out, to fully protect an LSP that traverses N nodes, there could be as many as N-1 backup paths. To minimize the number of LSPs in the network, it is desirable to merge a backup LSP to its service LSP when feasible. When a backup LSP intersects its service LSP at a node with the same outgoing interface, it will be merged. When two backup paths for the same protected service LSP travel a common link in the same direction, the required bandwidth can be shared since they are protecting different failure scenarios. When a failure occurs along the service LSP, the upstream node close to the failure point detects the failure and re-directs the traffic onto the local backup LSP. For example, if node R3 fails, R2 will detect the failure and redirect traffic along R2 s backup path. Now the traffic will travel along R1->R2->R7-> R8->R4->R5. Since R2 cannot distinguish the failure between link R2->R3 and node R3, R2 s backup usually excludes R3. Although backup LSPs do not consume bandwidth before failure, the network needs to reserve enough bandwidth along backup LSP links to guarantee 100% failure restoration. Using LSP merging technique, the bandwidth for service LSP and its backup LSPs can be shared along common links. With single failure assumption, the bandwidth for different backup LSPs of

3 the same service LSP can be shared along common links. But no solution is provided for bandwidth sharing among any service LSPs and backup LSPs in [2] as we pointed out before. 2) Design Overview Assume an MPLS backbone network represented by the graph G=(V,E), where V is the set of network nodes (e.g., label switch routers) and E is the set of network links. Protected LSP requests originating at clients arrive at the source nodes and they are established or deleted in a distributed manner, via signaling among the nodes. For each protected LSP request, the source node needs to compute a service path Ps and each node (say node k) except the destination node along the service path needs to compute a backup path Pr(k) in the network. The backup path Pr(k) protects failures of node k s immediate downstream node and immediate downstream link. Here immediate downstream node is the next node of node k along Ps and immediate downstream link is the link between node k and its immediate downstream node. In general, multiple service LSPs may share a common network resource, hence a single network resource failure, such as link failure or node failure, can cause multiple service LSPs to fail simultaneously. The design objectives for Ps and Pr(k) are as follows: (1) Ps and Pr(k) should be k s immediate downstream node disjoint. (2) The required bandwidth associated with different Pr(k) of Ps should be shared if they share a common link. (3) Backup LSPs from different service LSPs should share bandwidth on common links if their protected service path failure points are not subject to simultaneous failure. (4) Enough bandwidth must be reserved on all links in the network such that for any single failure, there is enough bandwidth to restore all affected service LSPs. (5) The total bandwidth reserved for restoration over the whole network should be minimized. Within distributed context, there is no centralized server to reserve restoration capacity on links and compute optimized backup paths. Rather, since LSP requests arrive one at a time at a source node, the source node needs to select the service path and the nodes along the service path are required to make the backup path selection independently without knowledge of future requests. If the network does not have enough bandwidth available for either the service path or one of the backup paths, the request should be blocked during LSP provisioning. 3) Shared Reservation A protected LSP in a MPLS network supporting oneto-one backup method has both a service path and N-1 backup paths where N is the number of nodes along the service path. During normal network operation, the traffic is traveling along the service path and backup paths consume zero bandwidth, but resources are reserved along the backup paths. The bandwidth reserved on each link along the backup paths can be shared across multiple backup paths of the same LSP and multiple backup paths of the different LSPs provided the protected failure points are not expected to fail simultaneously. The bandwidth reserved on the backup paths must be sufficient to recover all affected service LSPs in the event of any link/node failure based on our design objective. This requires the specific failure events that are to be protected against to be identified when selecting and reserving bandwidth along the backup paths. Then nodes along the backup path need to know the protected failure points (e.g, immediate downstream link and immediate downstream node) along the service path when reserving bandwidth to allow bandwidth sharing. A E C D B Figure 2: Shared Reservation Example Figure 2 shows a simple example illustrating a shared reservation, which comes from [7]. The figure shows a network with 6 nodes and 7 links. Suppose an LSP request asking for one unit of bandwidth from A to B arrives at node A. Node A selects A-B for the service path and A-C-D-B for the backup path. When these LSPs are established, one unit of bandwidth is allocated on link AB, and one unit of bandwidth is reserved on each of links AC, CD, DB. Subsequently, another protected LSP request asking one unit bandwidth from E to F arrives at node E. Node E selects E-F for the service path and E-C-D-F for the restoration path. In this example, when setting up the protected LSP, it is unnecessary to reserve an additional unit of bandwidth on link CD because the two service paths AB and EF are failure disjoint, i.e., they are not subject to simultaneous failure under the single failure assumption. Thus, a total of five units of bandwidth are reserved to protect both service paths against any single link failure whereas without shared reservations, a total of six units of bandwidth would be needed. Sharing the reserved bandwidth among the backup paths of different protected LSPs reduces the total reserved bandwidth required. F

4 4) Routing Information Exchange In MPLS networks, a link state routing protocol, such as Open Shortest Path First protocol (OSPF) or Intermediate System-Intermediate System protocol (IS- IS), is used to distribute network topology information to each node in a particular network routing domain. Traditionally, these protocols have only propagated link up/down status among the nodes. To support path computation in MPLS networks, both OSPF and IS-IS have been extended to propagate additional information about each link, such as available bandwidth, bandwidth in service, et al. [15,16]. This information is used to select the service path for each LSP request. However, to support backup path selection, some algorithms require extra information to be carried by routing and signaling protocols [7,10]. Most path selection algorithms in current networks are based on Dijkstra s algorithm, which selects a path of minimum weight among all suitable paths. The assignment of link weights provides a knob to control path selection. In this section, we describe link state information that is distributed in order to compute the link weights. The key idea is that the weights used to compute the backup path should take into account shared restoration bandwidth. We assume that the following link state information is flooded by the routing protocol, which is the so-called partial information from paper [8]. Note that information item 2 and item 3 are available in current extensions of OSPF/IS-IS for MPLS. It also should be possible to distribute the information in item 1 using existing OSPF/IS-IS traffic engineering extensions. 1. Reserved bandwidth (R[e]): This bandwidth is not used on unidirectional link e when the network is in a non-failure condition, but may be used by the restoration process upon failure; 2. Available bandwidth (A[e]): This bandwidth is free to be allocated to service bandwidth or reserved bandwidth as new LSP requests arrive. Note that the total bandwidth on unidirectional link e is S[e]+R[e]+A[e] where S[e] is total consumed bandwidth for service paths on link e. The three types of bandwidth share a common bandwidth pool; 3. Administrative weight (W[e]): This quantity is set by the network operator and may be used as a measure of the heuristic cost to the network. A path with a smaller total weight is typically preferable. 5) Bandwidth Management Mechanism Assuming that service paths are always selected as the shortest path based on the administrative weights. The critical issue addressed in this paper is how to book-keep the bandwidth used and reserved on each unidirectional link individually such that there is only necessary but sufficient bandwidth reserved on each link, and how to collect the necessary information to select better backup paths to minimize the total reserved restoration bandwidth over all network links. For each link, there is bandwidth on both directions and there are two nodes on two ends. Following convention, each node is responsible for the traffic outgoing direction link. For each link direction, the responsible node maintains a local array Failother[f], where f is any possible failure points, denoted as set F. In this paper, f ranges among any single link and single node, which means F={E} {V}. Failother[f] is the amount of bandwidth required on this link direction to restore all failed LSPs if failure f occurs. Then, reserving a bandwidth equal to R = max {Failother[f]: f F} ensures that there are sufficient and necessary bandwidth reserved to protect against any single failure. R is distributed to all other network nodes using the extended routing protocol. Section C describes in detail how to maintain the Failother array along the backup paths. Briefly, when a backup path is selected, a signaling message carrying the protected failure points (immediate downstream link and immediate downstream node) on the service path is sent along the backup path. This allows the responsible nodes along the backup path to be able to update the corresponding Failother[f] entry individually. C. ENHANCEMENT I Assuming that responsible node of each unidirectional link e along a backup path keeps track of the bandwidth on e that has been reserved to protect against any failure f. This information is maintained in Failother(e)[f], which will be updated during the signaling process. During the lifecycle of an LSP, the operations include creation and deletion. We describe proposed signaling extensions and procedures for updating the local data structures during LSP creation and deletion below. 1) LSP creation When one source node receives a protected LSP request, it computes a service path Ps using constrained shortest path first algorithm (CSPF) with administrative weights and available bandwidth of each unidirectional link. In this paper, we assume the use of the RSVP Traffic Engineering (RSVP-TE) extensions [17] which allow signaling messages to be explicitly routed from the source to the destination. Similar extensions are required for constraint-based routing label distribution protocol (CR-LDP) [18]. LSP creation involves an initial signaling message PATH from source node to destination node with admission control along the computed service path, then

5 a bandwidth reservation message RESV is returned from destination node to source node to finish the service path establishment. Upon receiving the RESV message, each node along the service path selects a local repair backup path to the destination node by excluding the immediate downstream node and applying constrained shortest path first algorithm according to [2]. Then the node sends a signaling message PATH along the selected backup path to establish the backup LSP and reserve the shared restoration bandwidth. This PATH message will include the immediate downstream link and immediate downstream node information on the service path. This immediate downstream link and immediate downstream node information is used to maintain shared reservations at each unidirectional link along the backup path. The responsible node of unidirectional link e along the backup path updates the Failother(e) array as follows: Failother(e)[f] Failother(e)[f] + b where f are immediate downstream link and immediate downstream node on the service path and b is the requested bandwidth of the protected LSP. The implementation of this approach requires a consistent assignment of network link ids and node ids by all network nodes. Since link state routing gives each node a consistent view of the network topology, each link can be indexed by hashing the node ids of the two end points of the link in a standardized way. Another possible solution is for the network provider to provision a globally unique link id for each link. 2) Example We consider a simple MPLS network with 5 nodes and 6 links. The network topology and node ids are shown in Figure 3. Suppose there already exists one protected LSP (LSP1 in the example) of one unit of bandwidth from node A to B with backup path A-C-D- B. Now suppose node A receives another protected LSP request LSP2 of bandwidth one unit from A to E. At this time, node A has the information of the network topology with reservation information R[AC] = R[CD] = R[DB] = 1 and the reserved bandwidth on other unidirectional links is all zero. A C LSP 1 LSP 2 LSP 2 LSP 1 LSP 2 E B D Figure 3: LSP Creation Example Node A first computes the service path, Ps={A-C-E}. Then a PATH message is sent along A-C-E. When E receives the PATH message, it sends out a RESV message along the reverse path from E to A to establish the LSP. C first receives the RESV message and computes the backup path protecting link C-E using the CSPF algorithm, which is Pr1={C-D-E}. Then C sends a PATH message along C-D-E including downstream link C-E information to establish the backup path C-D- E. Each responsible node of unidirectional links along Pr1 updates the Failother array correspondingly. After A receives the RESV message, it computes the backup path protecting downstream link A-C and downstream node C using the CSPF algorithm, which is Pr2={A-B- D-E}. Then A sends a PATH message along A-B-D-E including downstream link A-C and downstream node C information to establish the backup path A-B-D-E. Each responsible node of unidirectional links along Pr2 updates the Failother array correspondingly. Although Pr1 and Pr2 will merge at node D, this scheme requires the PATH message to reach the destination node to update the Failother array individually. After the protection LSP path and its backup paths are established and all local arrays are updated, each node also updates the available and reserved bandwidths of each unidirectional link and these changes for the affected unidirectional links are disseminated to other nodes via extended routing protocol OSPF or IS-IS. The final status will be: R[AC] = R[CD] = R[DB] = R[AB] = R[BD] = R[DE] = 1, S[AB] = S[AC] = S[CE] = 1, and the service bandwidth and reserved bandwidth on all other unidirectional links are zero. Although both backup paths A-C-D-B and C-D-E for different protected LSPs are using the common unidirectional link C-D, only one unit of bandwidth will be reserved. This is because these two backup LSPs protect two different failure points. In IETF fast reroute [2] using merging technique only, two units of bandwidth will be required on link C-D since these two backup LSPs are for two different protected LSPs and should reserve bandwidth individually. 3) LSP deletion When a source node receives a LSP deletion request, the network must delete the service LSP and its backup LSPs, and release the reserved bandwidth for shared restoration. Because the Failother arrays are updated via each responsible node individually, the deletion process needs to update these arrays individually too. In RSVP with traffic engineering, the source node sends one PATHTEAR message to the destination node along service path. Each node along the service path also needs

6 to send one PATHTEAR message along each backup path Pr. Those PATHTEAR messages along the backup paths should include their immediate downstream link/immediate downstream node information such that the responsible nodes of each unidirectional link along the backup path update the Failother array as follows: Failother(e)[f] Failother(e)[f] b, where f is the carried immediate downstream link/immediate downstream node on the service path and b is the required LSP bandwidth. At last, updates to A[e] and R[e] are handled similarly as in LSP creation. D. ENHANCEMENT II 1) Backup Path Optimization A B D H Figure 4: Backup Path Selection Our objective is to minimize the total required restoration bandwidth in the network. In MPLS fast reroute, we pre-select backup paths for each protected LSP or protected facility. Since restoration bandwidth can be shared across backup paths, it provides us an opportunity to optimize the backup path selection to reduce the overall restoration bandwidth. Here we only focus on one-to-one backup method. Figure 4 uses a simple example to illustrate this idea. We consider an example MPLS network with 6 nodes and 7 links. Suppose that there exists a LSP of one unit of bandwidth from node A to E with service path A-E and backup path A-H-E. Next, node A receives another LSP request of one unit bandwidth from A to D and the service path is computed as A-B-D. Then if A selects the shortest disjoint path A-E-G-D and B selects B-A-E-G-D as their backup paths respectively, the total required restoration bandwidth will be 6 units while if A selects another longer path A-H-E-G-D as the backup path, and B selects B-A-H-E-G-D as its backup path, the total required restoration bandwidth will be 5 units only assuming that paths A-E and A-B-D are failure disjoint. This example shows that the immediate downstream node disjoint shortest path as restoration path may not always lead to minimal restoration capacity. An optimized restoration path selection should minimize the total required restoration bandwidth. Although one may also optimize the service path selection to reduce the total required bandwidth, including both service path and G E backup paths, longer service path may result in larger total bandwidth requirements for all LSPs since service paths cannot be shared. Also longer service path may lead to longer service delay. Thus we do not consider service path optimization here and assume that the service path for each LSP is always the shortest path from source node to destination node with available bandwidth. 2) A Centralized Algorithm Paper [8] classified the routing information model as minimal information, partial information and complete information in end-to-end restoration. It found that complete information model is able to achieve optimized backup selection but the complete information dissemination may not be scalable. Thus complete information model fits for centralized algorithm. Partial information can be easily collected via current routing information extension. Thus partial information model fits for distributed algorithm. In this enhancement, we will describe a centralized algorithm using complete information model to MPLS fast reroute first. Then we discuss how to implemented this algorithm in distributed context with only partial information dissemination in the entire network. With complete information, we define a conflict matrix failneed, where failneed[f,e] represents the amount of traffic that will be rerouted on unidirectional link e when failure f occurs. Note the amount of backup capacity reserved on unidirectional link e is R[e]=max f F failneed[f,e]. In end-to-end shared backup capacity restoration, for a service path Ps is selected, the sharable restoration bandwidth on link e would be: r(e) = max f F failneed(f,e) - max f Ps failneed(f,e). Then the algorithm will reset link weights based on r(e) and select the disjoint shortest path as the restoration path to maximize the backup path sharing. In MPLS fast reroute, after the service path Ps is selected with N nodes on the path, we need to select N-1 restoration paths starting from each node along the service path except the destination. Let Pr(k) be the restoration path starting from node k. Note that Pr(k) only requires DR(k) and/or DL(k) disjoint from service path, where DR(k) and DL(k) refer to node k s immediate downstream node and immediate downstream link along the service path Ps. Then the sharable restoration bandwidth on each unidirectional link e would be: r[e] = max f F failneed[f,e] - max f {DR(k),DL(k)} failneed[f,e]. Then the restoration path can be selected from new link weights based on r[e]. The detail optimized algorithm is described in section D.4. From this algorithm, we noticed that the information we needed is the sharable restoration bandwidth r[e] only on each unidirectional link. The calculation of r[e]

7 depends on two parts: max f F failneed[f,e] and max f {DR(k),DL(k)} failneed[f,e]. The first part is equivalent to the total reserved bandwidth on link e, i.e., R[e], which is assumed to be disseminated via routing protocol exchange. Thus this information is available at each node. Now if each node along the service path is able to get the second part information, this centralized algorithm is able to be implemented in each node with partial routing information only. Our idea is to use signaling protocol instead of routing protocol to distribute and collect the second part information.. 3) Signaling Extensions To distribute and collect the second part information for each node, we propose new signaling extensions between neighbor nodes. There are three new signaling messages: TELL, ASK and REPLY. TELL: after a node selects or deletes its backup path, it will send a TELL message to the immediate downstream node with backup path information. ASK: before a node selects its backup path, it sends a ASK message to its immediate downstream node and asks for extra information. REPLY: when a node receives the ASK message, it replies the correct information back to the ask node. Now we describe the new message operation procedures. First, for each failure, there is a master node which is responsible for maintaining the failure related information. For each link, the master node could be the node terminating the link having the smaller node id while for each node, the master node would be the node itself. The master node of each failure along the service path will keep track of the bandwidth that has been reserved on other network unidirectional links to protect against the failure itself. This information is maintained in a local array in the master node, called Failself, where Failself(f)[e] stores the bandwidth required on unidirectional link e to restore all affected LSPs if this failure f occurs. Just like Failother arrays, Failselfs are updated on each node during LSP creation and deletion. When the immediate downstream node receives TELL message about backup LSP creation, it will update the Failself array for itself: Failself[e] Failself[e] + b where e are the unidirectional links on the restoration path and b is the bandwidth of the LSP. If the immediate downstream node is also the master node of the immediate downstream link, the Failself array for the immediate downstream link should be updated exactly the same way. When the immediate downstream node receives TELL message about backup LSP deletion, the plus sign should change to minus sign in the above formula. Before a node selects its backup path, it will send a ASK message to its immediate downstream node for Failself array information for the immediate downstream node and/or the immediate downstream link. The REPLY message will reply the correct Failself arrays of the immediate downstream node and the immediate downstream link information if it is the master node of the immediate downstream link. In fact, Failself maintains the row information of the conflict matrix failneed while Failother maintains the column information of failneed. Then the maxim of Failself(DR(k))[e] and Failself(DL(k))[e] is equal to max f {DR(k),DL(k)} failneed(f,e). Thus with this Failself information, the node is able to select a backup path same as the centralized algorithm with complete information. 4) Optimized Algorithm After a node k along the service path collects the Failself array(s) from its immediate downstream node, it is able to calculate a new array T[e] = max(failself(dr(k))[e], Failself(DL(k))[e]) where e is for any unidirectional link. Then T[e] is the maximum bandwidth needed on unidirectional link e if any one of the protected failures DR(k)/DL(k) occurs. Then r[e] = R[e]-T[e] is the sharable backup capacity on unidirectional link e in our centralized algorithm. This computation is based on the network state before the new backup LSP is established. After that, node k assigns a new weight to each unidirectional link e in the network: ( b r[ e]) W[ e] if b r[ e] > 0ande { DR} w[ e] = ε if ( b r[ e] 0 or e { DP}) and e { DR} if e { DR} where {DR} is the set of links that adjacent to the immediate downstream router, which means the backup path should exclude this downstream router, and {DP} means the set of links downstream from the immediate downstream router along the service path. Then Dijkstra s algorithm is used to select the backup path using these weights. In this formula, the assigned new weight of ε is in favor of the selection of the links, which are the downstream path links for potential LSP merging and links with enough existing restoration capacity. In both cases, no extra restoration capacity is required on those links. 5) Scalability The proposed scheme scales well due to two facts: (1) it does not require each LSR to maintain the global information of each LSP s service path and restoration paths. Only two arrays, i.e., Failself and Failother, are maintained at each node. (2) it does not require each node to broadcast any extra type of messages in the entire network except three simple messages exchanging

8 between neighbor nodes. The distributed implementation of proposed algorithm relies on signaling extensions among neighbor nodes to collect some extra information without complete information flooding. The signaling overhead is minimized since only neighbor maintained array information is updated and exchanged. Although we introduced three messages, in real implementation, only the TELL message needs to be added. The ASK and REPLY functionality can be embedded in the PATH and RESV messages as below. During the service LSP setup process, we use an optional field in PATH message to request the failself information. When RESV message comes back from destination to source, the failself array is carried in an optional field from downstream node to the immediate upstream node. Hence the only signaling overhead in our proposal would be a single TELL message between two adjacent nodes per backup path. E. RELATED WORK MPLS fast reroute is a relatively new scheme and it is still undergoing IETF standardization process [2]. The internet draft [2] is only focused on the fast reroute scheme definition and backup establishment signaling protocol, which leaves how to select the backup paths and implementation open for vendor/carrier innovation. A practical algorithm should maximize backup path sharing among the same service paths and different service paths without scarifying performance and scalability. From the best of our knowledge, we have not seen any published paper for MPLS fast reroute backup path selection although many work has been done for end-to-end and segment shared backup path selection. Our enhancement I achieves backup path sharing independent of the backup path selection algorithm. The basic idea of backup path sharing and backup path control message carrying service path information has been used before [3,22], but both apply for end-to-end backup path sharing only. We applied and extended this basic idea to MPLS fast reroute first time. We also designed internal node data structure and described how to maintain those data structure at each node during LSP creation and deletion. Our enhancement II applies signaling protocol instead of routing protocol to collect extra information. Similar idea has been applied in [7,10], which assumed end-toend shared mesh restoration. For MPLS fast reroute, each backup path only protects the immediate downstream node and immediate downstream link. We simplified the signaling extension to neighbor nodes only. Such simplification makes such a scheme easy to be implemented in real networks. F. STUDY METHODOLOGY 1) The network and demands We evaluate the performance of our proposed approaches via simulation on two networks: one is a US intercity MPLS backbone network consisting of 18-PoPs (Points-of-Presence) and 30 OC48-granularity links interconnected in a dual backbone router (BR) architecture 2 [19]; the other is the Toronto metropolitan network consisting 25 nodes and 45 links from [12]. In first network, we aggregate all access routers (ARs) connecting to the same PoP into a virtual AR. Then each PoP consists of three nodes: two BRs and one AR. The AR-to-AR demands are generated using cumulative outgoing and incoming traffic from a demand forecast, i.e., all traffic starting and terminating at the AR respectively. Then we randomly select a demand according to source AR cumulative traffic outgoing probability and destination AR cumulative traffic incoming probability. In second network, we assume uniform distribution traffic: randomly select two nodes for demand source and destination. The bandwidth of each demand is uniformly generated from an interval (10,100) Mbps for both networks. For simplicity, the MPLS backbone link bandwidths are assumed to be deployed in units of OC48 channels (approx. X=2.5 Gpbs). In our simulation, we use online incremental traffic model, i.e. traffic demands arrive at the network one by one, and never leave. In our simulation results, we generate 50 random runs and calculate the average value for each data point. 2) Figures of merit A frequently used figure-of-merit is the restoration overbuild. We define α = ΣSC(i) and β = ΣTC(i), where i varies over all backbone links, SC(i) is the required number of OC48 channels for service only on link i, and TC(i) is the total required OC48 channels for both service and restoration on link i. Since service and restoration share the same bandwidth pool and SC and TC are integers, it is possible SC(i)=TC(i) although there are some restoration bandwidth requirements on link i. We refer (β α)/α as the restoration overbuild. Restoration overbuild figure-of-merit does not consider link bandwidth limitation. In real networks, link bandwidth is limited. When the network is heavily loaded, some LSP demands may be blocked due to insufficient bandwidth for either the service path or some backup paths. Then blocking probability, which is 2 For router protection, IP/MPLS service providers may use two backbone routers at each PoP and each access router is dual-homed to the two backbone routers.

9 defined as the ratio of blocked demands to total simulated demands, is another figure-of-merit used to measure the network performance G. SIMULATION RESULTS Unless otherwise stated, all the data shown is based on single link/node failure only. And each data point is the average of 50 runs with different random seeds. restoration overbuild Baseline Enhancement I Enhancement II 1) Network overbuild simulations For this set of experiments, we assume that the link capacities are set to infinity and LSP demands arrive one at a time. The service path is always routed along the shortest path. The backup paths will be selected using immediate downstream node disjoint shortest path to the destination node in baseline scheme and our enhancement I while the backup paths in enhancement II are selected using our new link weight setting. Only merging technique is used in baseline scheme while distributed bandwidth management is used in both enhancements. Then baseline only shares bandwidth between the service LSP and its backup LSPs while our enhancement schemes are able to share bandwidth among any service LSPs and backup LSPs. After all LSPs are routed on the network, we calculate the restoration overbuilds for each of the schemes. Figure 5 and figure 6 illustrate the average restoration overbuild for each of the three schemes on the first and second networks respectively over 50 random runs. Each algorithm is compared with the same traffic demands ranging from 500 to protected LSPs. Obviously, both enhancements require significantly fewer restoration overbuilds than the baseline scheme and our enhancement II requires the least for each demand set. Those conclusions are not surprising. Since baseline only uses merging technique and only shares bandwidth between the protected LSP service path and its backup paths, then each protected LSP reserves restoration bandwidth individually. Thus the baseline scheme reserves restoration bandwidth comparable to dedicated 1+1 restoration, which is very bandwidth consuming. Our enhancement I uses the default backup path selection but provides bandwidth sharing among any LSPs, it reserves the restoration bandwidth comparable to simple disjoint shortest path restoration with bandwidth sharing. Our enhancement II uses a little bit extra information to select the optimal backup path to maximize bandwidth sharing, it consumes the least restoration overbuild and it reserves the restoration bandwidth comparable to optimized shared mesh restoration with complete information [7,8,10]. restoration overbuild number of LSPs Figure 5: Restoration Overbuilds for First Network B a s e lin e E n h a n c e m e n t I E n h a n c e m e n t II n u m b e r o f L S P s Figure 6: Restoration Overbuilds for Second Network We notice that the higher the traffic demands, the larger the restoration overbuild in our figures at small demands end. This is due to the restoration overbuild calculation formula. If the bandwidth in service channels is not fully consumed by service paths, it will be used for restoration paths. Fewer demands could leave more bandwidth on service channels for restoration paths. With more and more demands, the overbuild will stabilize. Note that enhancement I performs more than 100% and about 50% better than the baseline scheme in restoration overbuild for the first network and the second network respectively. Our enhancement II requires about close to half overbuild than enhancement I in both networks. Thus, there are strong advantages to use our proposed enhancements for MPLS fast reroute. All our enhancements operate in distributed context and no centralized server is required. Also we noticed that the baseline scheme performs better in the second network than in the first network this is because the second network is denser than the first one such that the restoration paths in the second network would be shorter than the restoration paths in the first one. After using our enhancements, the restoration overbuild difference for the two networks is no longer significant. This suggests that our enhancements may not be sensitive to network topology.

10 2) Simulations for blocked demands The second set of experiments study the behavior of the baseline MPLS fast reroute one-to-one backup scheme and our two enhancements with respect to blocking probability, i.e, the percentage ratio of blocked demands to total simulated demands, when the network is overloaded. In these simulation experiments, we set each link capacity as 1 OC48 channels (total 2.5 Gbps) for both directions. Protected LSP demands are chosen as described before except that the LSP demand bandwidth is always 100 mbps. As these demands are created or deleted, we keep track of how much service bandwidth is used per link, as well as how much restoration bandwidth is reserved on each link. If there is insufficient available capacity for either the service or one of the local backup path of an incoming LSP request, this request is recorded as blocked. Note that the service path is chosen as the shortest path along links with available free bandwidth using constrained shortest path first (CSPF) algorithm in this simulation. To simulate the procedure of LSP creation and deletion, we assume LSP Poisson arrival with exponential holding time. Using the first network as an example, we first performed 10 simulation runs with different random number generator seeds with traffic load as fixed 120 erlangs for the discussed three schemes, then we compare the blocking probability (the percentage ratio of blocked demands to total simulated demands) with different number of traffic loads. Figure 7 shows the numbers of blocked demands after demands are simulated on the first network for each of the three fast reroute schemes. It is clear that both our enhancements significantly outperform the baseline MPLS fast reroute scheme and enhancement II performs the best. In order to show the impact of traffic load, we simulate traffic of demands with traffic loads of 100, 110, 120, 130, and 140 erlangs. After calculating an average of 50 runs of different random seeds, figure 8 shows the result. It is easy to see that both enhancements are able to reduce blocking probability significantly and enhancement II always performs better than enhance I. Thus with the proposed enhancements, the network is able to serve more demands than the original MPLS fast reroute scheme. We performed similar simulations on network 2 and had similar observations. blocked demands Baseline Enhance I Enhance II random runs Figure 7: Blocked Demands with 120 Erlang Traffic Load blocking probability(%) Baseline Enhance I Enhance II erlangs Figure 8: Blocked Probability vs Erlangs H. CONCLUSION We analyzed the problem of distributed bandwidth management and backup path selection for protected LSPs in MPLS fast reroute using one-to-one backup method. In particular, we proposed a new bandwidth management mechanism with implementation procedures. We further proposed using three simple signaling messages between neighbor nodes to distribute and collect extra information required by our proposed optimal backup path selection algorithm. We demonstrate that with a little bit more signaling overhead, we can use network capacity much more efficiently for MPLS fast reroute. The proposed new methods keep accurate information about the amount of capacity that must be reserved on each link in the network to restore any single link/node failure. Our proposed approaches are based on efficient distributed routing and signaling protocols, and do not rely on centralized approaches. We compared our new approaches against the IETF RFC 4090 [2] proposed solution. We conclude that the savings in restoration

11 bandwidth from backup path sharing is significant, and that considerable savings could be obtained by extending the MPLS fast reroute signaling protocol to support our proposals. REFERENCES: [1] E. Rosen et al. (ed.), Multiprotocol Label Switching Architecture, IETF RFC 3031, 2001 [2] P. Pan, G. Swallow, and A. Atlas (Editors), Fast Reroute Extensions to RSVP-TE for LSP Tunnels, IETF RFC 4090, [3] S. Kini et al., Shared Backup Label Switched Path Restoration, IETF Internet draft, work in progress, May [4] V. Sharma and F. Hellstrand (ed.), Framework for Multi-Protocol Label Switching MPLS-based Recovery, IETF RFC 3469, [5] C. Gruber, Bandwidth Requirements of MPLS Protection Mechanisms, 7 th INFORMS TELECOM, Boca Raton, Florida, [6] G. Li and D. Wang, Efficient Restoration Capacity Design in MPLS networks, to appear APCC/MDMC, Beijing, China, [7] G. Li, D. Wang, C. Kalmanek and R. Doverpike, Efficient Distributed Path Selection for Shared Restoration Connections, IEEE/ACM Transaction on Networking, Oct. 2003, 11(5), pp [8] M. Kodaliam and T. Lakshman, Dynamic Routing of Bandwidth Guaranteed Tunnels with Restoration, IEEE INFOCOM [9] Y. Liu, D. Tipper, and P. Siripongwutikorn, Approximating Optimal Space Capacity Allocation by Successive Survivable Routing, IEEE INFOCOM [10] C. Qiao and D. Xu Distributed Partial Information Management (DPIM) for Survivable Networks, INFOCOM [11] R. Doverspike and J. Yates, Challenges for MPLS in Optical Network Restoration, IEEE Communication Magazine, Feb [12] Y. Xiong and L. Mason, Restoration Strategies and Spare Capacity Requirements in Self-Healing ATM Networks, IEEE/ACM Transactions on Networks, vol 7(1), February [13] A. Basu and J. Riecke, Stability Issues in OSPF Routing, SIGCOM [14] C. Alaettinoglu, V. jacobson, and H. Yu, Towards Millisecond IGP Convergence, Internet draft, draft-alaettinoglu-isis-convergence-00.txt, IETF, Nov [15] D. Katz et al., Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630, Sept [16] H. Smit et al., Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE), RFC 3784, June [17] D. Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC3209, Dec [18] J. Ash et al, LSP Modification Using CR-LDP, RFC 3214, Jan [19] G. Li, et al, Detail Study of IP/ Reconfiguable Optical Network Architectures, OFC [20] P. Ho, J. Tapolcai, and H. Moufth, On achieving optimal survivable routing for shared protection in survivable next-generation internet, IEEE Transaction on Reliability, Vol 53(2), June 2004, pp [21] P. Ho, J. Tapolcai, and Cinkler, Segment Shared Protection in Mesh Communications Networks with Bandwidth Guaranteed Tunnels, [22] S. Han and G. Shin, Fast restoration of real-time communication service from component failure in multi-hop networks, ACM SigComm 1997.