routing protocol extension for resilient gmpls … protocol extension for resilient gmpls...

Routing Protocol Extension for Resilient GMPLS Multi-domainNetworks

Anna Manolova, Sarah RueppDTU Fotonik

Oersteds plads Building 3432800 Kgs. Lyngby, Denmark{anva,srru}@fotonik.dtu.dk

Ricardo Romeral, Sergio RodriguezTelematics Engineering Department

University Carlos IIIMadrid, Spain

[email protected]

Abstract: This paper evaluates the performance of multi-domain networks under the Generalized Multi-ProtocolLabel Switching control framework in case of a single inter-domain link failure. We propose and evaluate a routingprotocol extension for the Border Gateway Protocol, which allows domains to obtain two Autonomous Systemdisjoint paths and use them efficiently under failure conditions. Three main applications for the protocol extensionare illustrated: reducing traffic loss on existing connections by exploiting pre-selected backup paths derived withour proposal, applying multi-domain restoration as survivability mechanism in case of single link failure, andemploying proper failure notification mechanisms for routing of future connection requests under routing protocolre-convergence. Via simulations we illustrate the benefits of utilizing the proposed routing protocol extension fornetworks employing different resilient mechanisms (both protection and restoration), as well as for networks whichhave not employed any resiliency technique. We show the need for differentiated failure handling for improvingnetwork performance under failure situations. Furthermore, we draw parallel between different network parametersand the efficiency of the applied notification and survivability strategies in the network.

Key–Words: multi-domain, GMPLS, BGP, AS-disjoint, performance enhancement

1 Introduction

Building the future Optical Internet will require usingthe entire potential of the optical networks, in par-ticular the ability to automatically set-up and man-age lightpaths (the so-called Labeled Switched Paths(LSPs)) under a framework such as the GeneralizedMulti-Protocol Switching (GMPLS) [1]. The ultimategoal is to perform automatic LSP establishment in amulti-domain context, where different domains (Au-tonomous Systems (ASes)) collaborate, allowing dy-namic reservation of resources across domain bound-aries. Two main challenges can be outlined: politicaland technical. When the political problems are solvedthrough new inter-AS agreements and business mod-els the technology must be ready to support the re-quired dynamics and automation of the provisioningprocess.

Currently, there is no standard for inter-domainrouting in GMPLS networks. Several proposals arebeing investigated among which is the current de factostandard for inter-domain routing in the Internet -BGP-4 [2]. In this context we can ask the question: isBGP, ready to be the next Optical Internet routing pro-tocol? The routing requirements, taken into conside-ration when BGP was designed, and the requirements

of the dynamic future Internet are very different. QoSsupport, reliability requirements and adequate supportfor a dynamic network environment have not been en-visioned as main requirements of the routing protocol.In the future Internet though, these are paramount andnecessitate extended information exchange betweendomains. Optical networks can transport a lot of infor-mation per second and failures heavily affect the per-formance of the network. Each domain should haveenough information to adequately react to failures, butthe current version of BGP does not provide such in-formation.

In this paper we present an extension of the BGPprotocol which allows for the computation of twoAS-disjoint paths per destination. AS-disjoint pathsare important for providing survivability in the multi-domain environment as well as for facilitating ade-quate reaction to changes in the network, which trig-ger BGP re-convergence. We illustrate the operationof the mechanism as well as the benefits of havingtwo disjoint AS PATHs for enhanced network perfor-mance under single inter-domain link failure. Thiswork is extension of the work presented in [3].

The paper is organized as follows: Sec. II andSec. III outline the problem and the related work inthe area respectively. Sec. IV gives details on the pro-

WSEAS TRANSACTIONS on COMMUNICATIONSAnna Manolova, Sarah Ruepp, Ricardo Romeral, Sergio Rodriguez

ISSN: 1109-2742 185 Issue 3, Volume 9, March 2010

posed BGP extension. Sec. V focuses on the potentialperformance enhancements the extended BGP can of-fer to a multi-domain network. Sec. VI presents thesimulation set-up and the obtained results. Conclu-sions are drawn in Sec. VII.

2 Disjoint path computation inmulti-domain networks

The multi-domain disjoint path computation problemstems from the fact that no one in the multi-domainnetwork has the complete network graph in orderto run the Suurballe algorithm [4] for disjoint pathcomputation. In some scenarios, especially multi-ASones, it is not possible to obtain the complete graph ofthe network without flooding the network with sensi-tive information, which is unacceptable because of thestrong privacy protection policies between the ASes.

We divide the methods for solving the multi-ASdisjoint path computation problem in three categories(see Fig. 1). The first one uses standard BGP informa-tion or manual configuration to find the AS PATH toa destination and tries to compute two disjoint pathsalong the obtained AS PATH, i.e. it shares ASes. So-lutions from this category necessitate sharing of in-formation between the domains or employing novelprotocols and/or new extensions to standard protocolsas in PCE [5], PPRO [6] and ARO [7]. A drawbackis that the applied optimization in these mechanismscan be done only within one AS PATH, and this limitstheir efficiency. Furthermore, an AS failure or discon-nection between two ASes on the path cannot be reco-vered using such approaches. The second category ofsolutions provides two AS-disjoint paths between thesource and the destination. After that, two LSPs canbe established via standard signalling protocols, e.gRSVP-TE, one along each AS PATH. The third cat-egory provides partially AS-disjoint paths, i.e. onlypart of the paths share the same ASes, but this type ofsolution requires sharing of more information in or-der to obtain the solution and suffers from the samedrawbacks as the solutions in the first category.

This paper proposes a solution within the secondcategory. We design an algorithm for AS-disjoint pathselection using BGP extensions. The mechanism pro-vides two AS-disjoint policy-compliant paths betweenany two routers in a multi-domain network whereASes are multi-homed. Employing the proposed so-lution in connection-oriented networks does not ex-clude the usage of other advanced schemes for optimalpath computation such as the PCE approach. BGP andPCE are completely interoperable since PCE elementsneed an AS PATH in order to calculate an optimal

AS 1

AS 2 AS 3

AS 4

(a) Disjoint paths using the same AS PATH

AS 1

AS 2 AS 3

AS 4

AS 5

(b) Disjoint path using disjoint AS PATHs

AS 1

AS 2 AS 3

AS 4

AS 5

(c) Mixed solution

Figure 1: AS-disjoint path solution categories.

path for each LSP request. Furthermore, calculatingtwo disjoint paths using different AS PATHs reducesthe complexity of the joint path computation processsince the complex disjointness calculations need to beperformed only for the source and the destination do-mains. We envision the BGP as a complementaryrouting protocol which provides a higher level pathspecified by AS numbers, whereas PCE can be usedinternally in each domain for optimal path computa-tion.

3 Related work

Several proposals for BGP modifications for multi-path dissemination can be found in the literature.Kushman et al. [8] have proposed R-BGP, a modi-fication of BGP that allows to send to downstreamneighbors alternative paths per destination. Two BGPpeers exchange the standard AS PATH and an alter-native AS PATH, called a failover path. Using thissolution the number of lost packets decrease signif-icantly during BGP re-convergence. There are twodrawbacks though. First, the forwarding process inall involved routers must be changed, because a deci-sion of which path (normal or failover) to be used istaken on a per packet basis. Second, in order to usethe failover path an extra BGP session via the failoverpath with the neighbor must be established. Thereare several differences between R-BGP and our so-lution. First, R-BGP is for packet switched networks,whereas our proposal is for connection oriented net-works. In GMPLS networks source routing is a funda-



mental feature, thus the head-ends of all connectionsrequire an extended view of the overall path, not onlythe next hop. In our solution the BGP speakers dis-seminate alternative AS PATHs to all their neighbors,thus disseminating alternative AS PATHs to all BGPspeakers in the network, not only to the downstreamneighbors. Second, the Kushman et al. [8] proposalsupports protection only against link failures betweenneighboring domains. Our proposal is more generaland offers survivability support for link failure, nodefailure and even entire AS failure.

Other proposals, as Bhatia et al. [9] or Waltonet al. [10], try to eliminate the BGP route oscilla-tions sending extra information in the BGP UPDATEmessages. Walton propose to send several paths, notnecessarily disjoint, for the same destination usinga Path Identifier attribute. Bhatia propose to useMultiple-Hop Capability to report to a BGP peer morethan one Next-Hop for the same reachable destina-tion. The goal of these proposals is to reduce oreliminate the well-known BGP route oscillations. Ourproposal, on the other hand, does not seek to elimi-nate route oscillation during BGP re-convergence, butrather to eliminate (or minimize) the effect of the os-culations on the operation of the network. In this pa-per we illustrate how providing two AS-disjoint pathsper destination can be used for survivability support inconnection-oriented networks as well as for enhanc-ing network performance under BGP re-convergencefor future connection requests.

4 Obtaining disjoint AS PATHs withBGP

BGP is a path vector protocol, which means that thecreated routing table contains the destination, the nexthop towards the destination and the path to reach thedestination. These are distributed via BGP UPDATEmessages between BGP peers which contain: Net-work Layer Reachability Information NLRI (i.e. thedestination), AS PATH (sequence of ASes to be tra-versed on the way to the destination) and the next hop.Interior routing information is not shared across do-main borders via BGP, so different ASes have no in-terior information about other ASes. Limiting theshared information is done for scalability purposes aswell as to avoid disclosure of sensitive information toother domains. Thus, the received BGP informationby an AS is aggregated as much as possible and justone AS PATH to a destination is chosen and furtherdistributed to other BGP peers1. BGP peers choose

1Note that aggregation of destinations is a common practice inBGP, in which case only one AS PATH is distributed per aggre-

paths according to a special decision procedure de-scribed in RFC 4271 [2]. In this paper paths chosenunder the standard BGP operation are referred to asprimary AS PATHs.

Our proposed mechanism is a concurrent modi-fied BGP decision procedure which obtains a disjointAS PATH to the primary AS PATH, referred to as sec-ondary AS PATH. This secondary path can be used forresilience purposes, load balancing or routing of LSPrequests during BGP protocol re-convergence.

The proposal necessitates three new Routing In-formation Bases (RIBs)2: Adj-RIB-Disj-In, Loc-RIB-Disj and Adj-RIB-Disj-Out (in practice a secondaryroute can be identified by a flag in the existing RIBs).The proposed extended BGP decision procedure con-stitutes of three phases as follows:

1. When a BGP entity receives an UPDATEmessage for a secondary AS PATH from a peer,the route is added to the Adj-RIB-Disj-In and apreference is assigned. Upon a route additionor change in the Adj-RIB-In or Adj-RIB-Disj-In,phase two is triggered.

2. For the destination under update, select the bestroute disjoint to the one in the Loc-RIB fromall available routes to that destination in all Adj-RIB-In and Adj-RIB-Disj-In. The selected routeis included in the Loc-RIB-Disj; this RIB keepsall the BGP secondary routes used locally. If thisimplies a route change in Loc-RIB-Disj, applyphase 3.

If no disjoint route exists this means there is trapin the topology of ASes3 or the existing disjointpath is not policy-compliant. This can be solvedby changing the primary path by manual config-uration of the local preferences or by adjustingthe local policies.

3. After a change in the Loc-RIB-Disj, the newroute undergos a policy filtering process and isincluded in the selected Adj-RIB-Disj-Out; UP-DATE messages are sent further.

Note that the received secondary routes are inAdj-RIB-Disj-In not in Adj-RIB-In and thus, they arenot selectable as primary routes by the normal BGPdecision procedure. This is a desirable behavior sincesecondary routes might create loops if the usual hop-by-hop routing of the standard BGP is used. Due to

gated destination.2Please refer to [2] for standard BGP operation description and

terminology.3Theoretically in a 2-node-connected network there always

exist 2 disjoint paths between nodes unless there is a trap in thetopology.



the specifics of the proposed algorithm and the hop-by-hop routing paradigm, enforced by the BGP pro-tocol, source routing is needed in order to use thesecondary paths [11]. This is necessary because insome cases two neighboring ASes choose each otheras next hop for their secondary paths and in othercases they choose other neighboring ASes. This istopology dependent and cannot be predicted. Thus, inorder to use the secondary path, the responsible bordernode must apply source routing for forwarding LSPrequests on the secondary path. Possible solutions forsource routing on the inter-AS level with BGP are pro-posed in [11] and [12].

Considering the operation of the proposed BGPenhancements the scalability of the protocol is not se-riously harmed. The amount of stored data is at mosttwice the amount of data stored in BGP speakers un-der standard BGP operation since there are only twopaths per destination.

On Fig. 2 an example of how the proposed BGPmodification works is shown. Subfigure a) showsthe RIB’s content for destinations in AS 5 in theother ASes and the selected AS PATH (marked withsolid line orange background). These paths are ob-tained using the standard BGP process. As sub-figure b) shows, all ASes which can select disjointAS PATH to the primary path among all availablepaths in their Adj-RIB-Ins do that (paths marked withdashed line purple background), and send an UP-DATE with the disjoint AS PATH information to theirpeers (solid purple lines). ASes which receive newdisjoint AS PATH information include it in the Adj-RIB-Disj-In and the selection mechanism is activated(subfigure c)). The new selected route is sent furtheruntil all ASes have a disjoint AS PATH, just as shownin subfigure d).

5 Network performance enhance-ment

Obtaining two disjoint paths per destination is bene-ficial not only for survivability in a dynamic multi-domain environment, but also for load balancing andnetwork performance enhancement in case of failureswhen no resiliency mechanisms are applied. In ourwork we focus on three performance aspects. First weanalyze the benefit of having two disjoint paths perdestination with respect to the loss of traffic. SinceBGP protocol re-convergence takes significant time[13], this results in high loss of traffic on existingconnections and thus degraded network performance.Then, we focus on applying connection restoration forthe affected LSPs. Utilizing the pre-selected disjoint

2-4-5

1-2-4-5

2-4-5

3-2-4-5

2-4-5

5

2-3-5

3-5

4-5

1-3-5

5

3-5

2-3-5

AS 1

AS 2

AS 3 AS 5

AS 4

RIB

RIB

RIB

RIB

5

2-3-5

5

3-5

2-3-5

AS 1

AS 2

AS 3 AS 5

AS 4

RIB

RIB

RIB

RIB

3-5

4-5

1-3-5

5

2-3-5

5

3-5

2-3-5

AS 1

AS 2

AS 3 AS 5

AS 4

RIB

RIB

RIB

RIB

3-5

4-5

1-3-5

D-RIB

2-4-5

D-RIB

5

3-5

2-3-5

AS 1

AS 2

AS 3 AS 5

AS 4

RIB

RIB

RIB

RIB

3-5

4-5

1-3-5

D-RIB

D-RIB

a)

b)

c)

d)

5

2-3-5

Figure 2: Modified BGP work example.

paths we can restore the affected connections at thetime of failure without being affected by the BGP re-convergence delay or route oscillations. The third as-pect we analyze is the performance of the dynamicmulti-domain network in terms of blocking of futureconnection request when no resiliency mechanismshave been applied. During the BGP re-convergencesome nodes loose visibility of destinations or loopsare created. This increases the LSP connection re-quest blocking. Thus, the applied failure notificationmechanism becomes paramount for proper networkoperation.

5.1 Failure recovery

There are two main approaches for providing re-silience in a network - protection and restoration. Pro-tection is the process of establishing a backup path,disjoint to the primary path, before the failure occurs.Restoration is the process of re-establishing an affec-



ted connection after failure using an alternative path.The total recovery time for the different approachescan be approximately given by the following equa-tions [14]:

TProtectionrecovery = Td + Tn + Tsw, (1)

TRestorationrecovery = Td + Tn + Tsetup + Tsw, (2)

where Td is the time to detect the failure, Tn is the timeto notify the node, responsible for the failure recovery,Tsetup is the time to set up the new LSP and Tsw is thetime to switch over the traffic to the new establishedpath.

Improving network performance under linkfailure means minimizing the time to recover from thefailure. In case of protection, the time to recover istypically much shorter than in case of restoration be-cause in the latter case the node initiating the backuppath setup must compute an alternative path at timeof failure. If no specific disjoint path computationmechanism is used then Tsetup typically includes theBGP re-convergence time. If an AS-disjoint alterna-tive path is available, the Tsetup can be drastically re-duced. Thus, in both cases (protection and restoration)the availability of AS-disjoint primary and secondarypaths is clearly beneficial for resilience support in themulti-domain network.

A similar approach for path protection, based onpre-computed backup paths, is presented in previousworks [15] and [16]. The authors of [15] use pre-computed paths for MPLS protection and focus onthe delay parameter, whereas we focus on blockingprobability under restoration. Moreover, our work isfocused on dynamic failure recovery in multi-domainconnection-oriented networks, whereas [15]and [16]focus on single domain cases and on pre-planned pro-tection strategy.

5.2 Failure notification strategies

In case of a link failure it is paramount to informthe proper network elements in order to minimize theimpact of the failure through proper failure notifica-tion. In a multi-domain scenario there is still no con-sensus whether a failure should be signalled all theway to the head-end of an affected connection or if itshall be handled locally. For single domain operationthe head-end of the connection decides the protec-tion method [17]. For multi-domain networks thoughit is not clear due to the diverse policies applied inthe ASes and their capabilities for survivability sup-port. In order to evaluate this we use the extensions ofthe BGP protocol proposed in this paper and we ana-lyze the blocking ratio of connection requests after an

inter-domain link failure using the following notifica-tion strategies:

• No notification: In this case the BGP protocolre-converges without notifying anybody of thefailure. All LSP requests which cannot be routeddue to lack of visibility or routing loops in thisperiod are dropped.

• Local notification: In this case only the bordernodes of the domains which detect the failure arenotified. The border nodes then route the upcom-ing LSP requests using the secondary paths ob-tained by the BGP modification proposed in thispaper. If a routing loop occurs (in case a domainuses its upstream neighbor for the backup path)the requests are dropped at the upstream node4.No BGP re-convergence is performed.

• Head-end notification: In this case the head-endsof the connections are notified that they must usetheir corresponding secondary paths, obtainedusing the proposed AS-disjoint BGP extensions.In this case no routing loops are possible and LSPblocking occurs only due to lack of resources.No BGP re-convergence is performed.

• Mixed strategies: Here the LSP requests arerouted on the secondary paths during the BGPprotocol re-convergence (using either the Head-end or the Local notification) and when the BGPprotocol converges, the subsequent connectionrequests are routed on the new primary paths.

The actual failure notification can be performedin several ways, e.g. by the RSVP-TE Notify messageor by extending the BGP Keep Alive messages. Inour implementation we have employed the RSVP-TENotify message, which is used to propagate a list ofaffected destinations in case of a link failure. Thescope of propagation of the message depends on theapplied notification procedure as described above.

6 Simulation results

The behavior of the extended BGP protocol wasevaluated via two different simulation activities. First,a Quagga implementation of the BGP extension wasused to validate the process of obtaining AS-disjointpaths and to evaluate the protocol overhead duringBGP convergence. Then, the network performanceunder the outlined earlier application scenarios was

4Due to loop-detection mechanism within the RSVP-TE im-plementation.



evaluated via simulations with the event driven sim-ulator tool OPNET [18]. We have evaluated the be-havior of the modified protocol in two Pan-Europeantopologies. For the Quagga implementation, eachcountry is represented by one border node (see Fig. 4),whereas for the network performance evaluations wehave used the COST 266 topology [19] (see Fig.??).Here the intra-domain topologies of the separate do-mains are randomly generated and have no more than4 nodes acting as sourses/destinations. In total thereare 46 source/destination nodes in 22 domains inter-connected via 40 inter-domain links. The domainboundaries are assumed to be the geographical bor-ders of the countries.

During the BGP path selection procedure thehop count is selected as a routing metric. Nospecific import/export policies are applied, i.e. itis assumed that all domains offer transit ser-vices to all their neighbors. The values for theMin Route Advertisement Interval Timers are set ac-cording to the specification in RFC 4271, i.e. 30 sec-onds for eBGP and 5 seconds for iBGP.

The two simulation activities are as follows. Forthe first one, we examine the entries in the Adj-Rib-In and Adj-Rib-Disj-In databases of all border nodeswith respect to one specific destination and we ob-serve the selection process and the backup path dis-semination process. For the second activity we con-duct several simulations in order to illustrate the po-tential benefits of using the proposed AS-disjoint BGPmodifications. First, we illustrate the benefit foravoiding loss of traffic on established LSPs duringBGP re-convergence. Then, we show the recoverysuccess ratio of affected LSPs when two differentrestoration strategies are applied. Last, we focus onthe effect of different failure notification strategieson the LSP blocking ratio for requests which occurduring and after the link failure, i.e. we focus on theLSP rejection ratio. For these simulations the follow-ing settings are used. All connection requests haveexponentially distributed duration with mean value of600 seconds. The input load of the network is reg-ulated by varying the mean value for the LSP inter-arrival time. Depending on the used amount of wave-lengths per link we evaluate the behavior of the net-work at high, medium and low loads. Wavelengthcontinuity constraint is assumed. For LSP signal-ing we use the RSVP-TE protocol. The wavelengthassignment at the destination node is random amongall free wavelengths along the path.

Amsterdam

Athens

Barcelona

Belgrade

BerlinBirmingham

Bordeaux

Brussels

Budapest

Copenhagen

Dublin

Dusseldorf

Frankfurt

Glasgow

Hamburg

Helsinki

Krakow

Lisbon

London

Lyon

Madrid

Marseille

Milan

Munich

Oslo

Palermo

Paris

Pragu

Rome

Seville

Sofia

Stockholm

Strasbourg

Vienna

Warsaw

Zagreb

Zurich

Figure 3: Cost 266 Pan-European topology.

6.1 Extended BGP protocol behavior evalu-ation

In this section the simulation results conducted withthe Quagga implementation of the BGP extension arepresented. The emulated network topology can be ob-served on Fig. 4. The target destination is domain 17.Fig. 5(a) shows the entries in the Adj-Rib-In database5

in all nodes regarding destination 17 during the BGPconvergence (i.e., during obtaining the primary paths).The chosen paths are indicated in oval forms. Fig. 5(b)illustrates the entries in the database when the AS-disjoint dissemination is active (secondary advertise-ments are indicated with asterisks) and the chosen sec-ondary paths (indicated with dashed lines). Fig. 6illustrates the BGP overhead and convergence timewhen normal BGP is used and when the AS-disjointoption is activated for the emulated network for desti-nation - domain 17. It can be seen, that when the AS-disjoint option is activated the overhead in the networkhas increased with about 65%, whereas the time toconverge the protocol has increased with about 50%,compared to the case when no extensions are used inthe network. This is due to the fact that both processes(for working path and for as-disjoint path) are runningin parallel. The results show that obtaining two AS-disjoint paths per destination does not cause excessiveoverhead in the network.

5One database is used for both primary and secondary ad-vertisements, where the incoming advertisements regarding sec-ondary paths are indicated in asterisks



AS01

AS02

AS03

AS16

AS17

AS18

AS19

AS21

AS04

AS05

AS06

AS20

AS07

AS08

AS09

AS12

AS10

AS11

AS13

AS14

AS15

Figure 4: Tested Pan-European topology.

6.2 Traffic loss under BGP re-convergence

Here we focus is on the main goal of the BGPextension, namely saving traffic during BGP re-convergence. We investigate the performance underhigh network load (1 Erlang input load per node).Our performance metric is the BGP re-convergencetime. Without having pre-established secondary pathsduring this period the source nodes cannot redirect thetraffic from the primary LSPs on the secondary ones,thus the traffic on them will be lost. We evaluate there-convergence time in case of failure of every inter-domain link in the network separately. The lost trafficunder BGP re-convergence is proportional to the timeto re-converge the BGP protocol, thus it is approxi-mate value calculated as N ∗ T ∗ C, where N is thenumber of affected connections on the failed link, Tis the BGP convergence time for that failure case andC is the capacity of the connections. Here we assume10 Gbps connections.

On Fig. 7 it can be seen that for the failed linksthe convergence time varies between 5 seconds and3 minutes. Considering the bit rate of the affectedconnections and the number of affected LSPs a linkfailure results in loss of approximately 0.5 to 115Tb traffic due to path osculations and loss of visibil-ity. Using our proposed mechanism for deriving AS-disjoint backup paths can significantly decrease theamount of lost traffic in the network since the sourcenodes do not have to wait for the BGP protocol to re-converge in order to obtain an alternative path.

AS01

21-03-17

02-03-17

AS02

03-17

AS03

08-17

19-17

17

AS04

06-07-17

20-17

AS05

06-07-17

20-17

AS06

04-20-17

05-20-17

07-17

AS07

17

AS08

03-17

16-03-17

17

AS10

11-13-07-17

09-08-17

AS11

12-08-17

10-09-08-17

13-07-17

AS12

15-17

09-08-17

11-13-07-17

08-17

AS13

14-17

07-17

AS14

15-17

13-07-17

17

AS15

14-17

12-08-17

17

AS17 AS18

19-17

21-03-17

17

AS19

03-17

18-17

17

AS20

17

AS21

18-17

01-02-03-17

03-17

AS09

12-08-17

08-17

AS16

08-17

03-17

(a) Primary paths

AS01

21-03-17

02-03-17

AS02

03-17

AS03

08-17

*16-08-17*

*21-18-17*

*02-01-21-18-17*

17

AS04

06-07-1720-17

AS05

*06-04-20-17*

*20-04-06-07-17*

20-17

AS06

05-20-17

*07-13-14-17*

07-17

AS07

*06-04-20-17*

17

AS08

03-17

*03-19-17*

16-03-17

12-15-17

*09-12-15-17*

17

AS10

*11-13-07-17*

*09-12-15-17*

09-08-17

AS11

*12-08-17*

*13-14-17*

10-09-08-17

12-15-17

AS12

*08-03-17*

09-08-17

11-13-07-17

15-17

AS13

*14-15-17*

11-12-15-17

07-17

AS14

15-17

13-07-17

17

AS15

12-08-17

17

AS17 AS18

21-03-17

*19-03-17*

17

AS19

18-17

17

AS20

141

14

*05-06-07-17*

17

AS21

18-17

01-02-03-17

03-17

AS09

*08-03-17*

*12-08-17*

*10-11-12-15-17*

08-17

AS16

*08-03-17*

*03-19-17*

03-17

*21-18-17* *01-21-18-17* 19-17 06-07-17 06-07-17 04-20-17 *13-14-17*

03-17 12-15-17 11-12-15-17 13-07-17 08-17 14-17 15-17

14-17 08-17 19-17 03-17 *04-06-07-17* 18-17

(b) Disjoint secondary paths

Figure 5: Adj-Rib-In and Adj-Rib-Disj-In entries andselected primary and secondary paths.

6.3 LSP restoration

As we illustrated on Fig. 7, waiting for BGP to re-converge results in huge amount of lost traffic. Thus,using the proposed AS-disjoint BGP path dissemina-tion we can re-establish the affected LSPs using thesecondary paths. Since all routers in the network havetwo disjoint paths (if such exist and are policy com-pliant) two restoration approaches can be used - end-to-end (E2E) and local-to-egress (L2E)6.

Fig. 8 illustrates the amount for saved trafficwhen applying restoration for different normalized in-put traffic loads at 50 wavelengths per link for twointer-domain link failures. In all cases the recoveryprocess is in the order of 100 milliseconds, which is

6Local restoration is not an option unless there are parallellinks between the border nodes, adjacent to the link failure. Thisis due to the fact that border routers have only visibility to reach-able destinations and no visibility to other routers in neighboringdomains.



0

50

100

150

200

250

300

Normal BGP AS-disjoint

BGP

Increase (in %)

# B

GP

Up

dat

e m

essa

ges

(a) BGP overhead

0

10

20

30

40

50

60

70

80

90

100

Normal BGP AS-disjoint BGP Increase (in %)

Co

nv

erg

ence

tim

e (s

ec.)

(b) BGP convergence time

Figure 6: BGP versus AS-disjoint BGP protocol eval-uation.

insignificantly small compared to the 3 minutes BGPre-convergence time. Furthermore, it can be observedthat the efficiency of the recovery approach dependson the failed link. Applying our AS-disjoint pathselection algorithm brings flexibility in the recoveryprocess by facilitating differentiated failure handling,since all border routers have disjoint paths to all des-tinations. This brings advantage for operators whichserve customers with diverse service requirements.

6.4 Failure notification analysis for futureLSP requests

Here we evaluate the importance of proper failure no-tification method for reducing the blocking of LSP re-quests under BGP re-convergence. Our first case is afailure of the link with the most lost traffic from ourprevious experiment (i.e. link 31 which is Berlin -Warsaw). We consider the case of a medium and lowload in the network. The results for the LSP block-ing ratio using the different notification strategies are

0

20

40

60

80

100

120

140

160

180

200

1 3 5 7 9

11

13

15

17

19

21

23

25

27

29

31

33

35

37

39

Failed link

Co

nv

erg

ence

tim

e (s

ec.)

(a) BGP convergence time after failure

0

20

40

60

80

100

120

140

1 3 5 7 9

11

13

15

17

19

21

23

25

27

29

31

33

35

37

39

Failed link

Lo

st t

raff

ic (

Tb

)

(b) Lost traffic on affected connections

Figure 7: BGP convergence time and lost traffic onaffected connections.

presented on Fig. 9.

As it can be seen, the LSP blocking ratio for thewhole network is the highest for the Local notifica-tion strategy. This implies that the objective to pre-serve the failure information locally is not always thebest choice. Applying the Local notification schememay yield longer paths for the LSPs, which resultsin increased blocking probability. For the mediumloaded network the remaining strategies perform al-most equally good. This is due to the fact that undermore loaded condition, the LSP blocking is dominatedby the lack of resources. Thus, the difference betweenthe schemes is difficult to observe. At the low loadsthough, the Mixed strategy (Head-end) performs thebest. Under this scheme the LSP requests are routedfrom the Head-end on their secondary paths during theBGP re-convergence and on their new primary pathsafter the re-convergence. The achieved improvementcompared to the Local notification strategy is about50%.



0

50

100

150

200

250

300

350

400

450

500

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7

Normalized input load per node [Erl]

Res

tore

d t

raff

ic [

Tb

]

Restored L2E, link Warsar-Berlin

Restored E2E, link Warsar-Berlin

Restored L2E, link Rome-Zagreb

Restored E2E, link Rome-Zagreb

Affected traffic on link Warsaw-Berlin

Affected traffic on link Rome-Zagreb

Figure 8: LSP restoration success ratio for two diffe-rent link failures and two restoration strategies.

Fig. 10 illustrates the blocking ratio of two flows7

in case of two different link failures for all tested noti-fication mechanisms: flow England → Hungary withfailed link Berlin - Warsaw and flow Poland→Greecewith failed link Belgrade - Sofia. The mixed strategyis Mixed strategy (Head-end) and the network is un-der medium load condition. The goal is to see howdifferent failures affect different individual flows andhow the investigated notification schemes perform ona per flow basis.

The first thing to be noticed is that different strate-gies affect the blocking ratio of flows differently. Forthe first flow (England → Hungary) informing thehead-end of the connections (England in this case)brings significant LSP blocking improvement (around50% better than the Local notification). For the sec-ond flow though, the Local notification yields the low-est blocking ratio (around 30% better than the Head-end notification). This calls for the development ofschemes which handle affected flows in a differenti-ated manner.

The second interesting result is that for failed linkBerlin - Warsaw the blocking of the observed flowunder Head-end notification is lower after the failurethan before the failure. Furthermore, the mixed strat-egy is performing worse than the Head-end notifica-tion. This is due to the fact that the obtained sec-ondary path is better than both the old primary pathand the new primary path obtained after protocol re-convergence, which yields lower blocking ratio. Thisimplies that configuring the BGP routers of a certaindomain taking only the bi-lateral agreements with theneighbors into account is not enough to obtain thebest performance in a multi-domain environment. In

7Here flow refers to set of connection requests between a fixedsource/destination pair. Since the AS PATH is the same for thesame source/destination pair the LSP requests will follow thesame set of ASes.

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 5000 10000 15000 20000 25000 30000 35000

Time (sec)

Blo

ckin

g r

atio

Head-end notification

Local notification

No notification

Mixed strategy (Head-end)

Mixed strategy (Local)

(a) Medium network load (17.25 Erl.)

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0 5000 10000 15000 20000 25000 30000 35000

Time (sec)

Blo

ckin

g r

atio


Local notification

No notification


Mixed strategy (Local)

(b) Low network load (8.6 Erl.)

Figure 9: LSP blocking ratio for different notificationstrategies.

the Future Optical Internet a global coordination is re-quired in order to provide end-to-end QoS of connec-tions crossing multiple domains.

Fig. 11 presents the blocking ratios for differentfailure cases. The X-axis presents the failed link andits relative load calculated as the ratio between theaffected LSPs at the time of failure and the total capa-city of the link (30 wavelengths). The Y-axis presentsthe blocking ratio for one of the flows passing the par-ticular failed link.

It is clearly visible that there is a relation betweenthe load on the link and the efficiency of the appliednotification strategy. The more loaded the failed linkis the less effective the Local notification is. This isdue to the fact that when a link is heavily loaded thenre-directing all LSP requests on the same local backuppath will saturate it faster, due to the presence of orig-inal traffic on that path. The Head-end notification onthe other hand re-directs the affected flows from thehead-ends of the connections and achieves in effectload balancing which decreases the blocking proba-bility.



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 5000 10000 15000 20000 25000 30000 35000

Time (sec.)

Blo

ckin

g r

atio

fo

r fl

ow

Hu

ng

ary

->E

ng

lan

d


Local notification

No notification


(a) Flow Hungary → England, failed link Berlin - Warsaw

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 2000 4000 6000 8000 10000 12000 14000

Time (sec.)

Blo

ckin

g r

atio

fo

r fl

ow

Po

lan

d->

Gre

ece


Local notification

No notification

Mixed strategy

(b) Flow Poland → Greece failed link Belgrade - Sofia

Figure 10: LSP blocking ratio for different notifica-tion strategies for two monitored flows.

7 Conclusions

In this paper we propose an extension of the BGPprotocol for obtaining AS-disjoint paths in a multi-domain GMPLS network. We focus on the potentialbenefits of applying the proposed mechanism for im-proving network performance in case of inter-domainlink failures. The conducted protocol evaluation ana-lysis with a Quagga implementation reveal that theprice for obtaining two disjoint paths per destinationis not excessive. In fact, the generated overhead andthe increase in the convergence time are about 50%.Simulation results, performed with an event drivensimulator, illustrate that employing AS-disjoint pathsfor reestablishing affected LSP connections can po-tentially save huge amounts of traffic. With BGP re-convergence times within tens of minutes, this impliesa lot of saved revenue.

Furthermore, we showed that deploying the cor-rect failure notification strategy can considerablylower the blocking ratio of new LSP requests. Diffe-

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Berlin - Warsaw

(0.73 Erl.)

Marseille -

Rome (0.67 Erl.)

Strasbourg -

Frankfurt

(0.57 Erl.)

Amsterdam -

Glasgow

(0.5 Erl.)

Zagreb -

Belgrade (0.43

Erl.)

Brussels - Paris

(0.3 Erl.)

Belgrade - Sofia

(0.23 Erl.)

Failed link

Blo

ckin

g r

atio

Local notification


Figure 11: Blocking ratio of different flows for diffe-rent failed links for two notification strategies.

rent failures affect LSP request flows in different waywhich calls for a differentiated approach for failurenotification and failure recovery. Our results indicatethat the more loaded the failed link is the less effectivethe Local notification strategy is. The presented re-sults also imply that the position of the link failure, re-lated to the head-end of the affected LSP request flow,as well as the actual position of the failed link withinthe multi-domain topology, should be taken into ac-count when deciding the notification mechanism.

Applying the proposed BGP enhancement faci-litates the operation of a highly dynamic and auto-matic multi-domain network, by providing flexibilityfor differentiated failure handling. It is an importantstep towards making BGP a viable solution for the Fu-ture Optical Internet under the GMPLS umbrella.

Acknowledgements: The work described in this pa-per was carried out with the support of the BONE-project(”Building the Future Optical Network in Europe”), a Net-work of Excellence funded by the European Commissionthrough the 7th ICT-Framework Programme.

References:

[1] E. Mannie et al. ”Generalized Multi-Protocol LabelSwitching (GMPLS) Architecture,” RFC 3945, Octo-ber 2004.

[2] Y. Rekhter and S. Hares. ”A Border Gateway Protocol4 (BGP-4),” RFC 4271, January 2006.

[3] A. Manolova, S. Ruepp, R. Romeral. ”Enhancing net-work performance under single link failure with AS-disjoint BGP extension,” In Proc. 4th WSEAS Inter-national Conference on CIRCUITS, SYSTEMS, SIG-NAL and TELECOMMUNICATIONS (CISST), Jan-uary 2010.

[4] J.W. Suurballe. ”Disjoint Paths in a Network,” Net-works, 4:125-145, June 1974.



[5] A. Farrel, J.-P. Vasseur, and J. Ash. ”A Path Compu-tation Element (PCE)- Based Architecture,” RFC 4655(Informational), August 2006.

[6] J.P. Lang, Y. Rekhter, and D. Papadimitriou. ”RSVP-TE Extensions in support of End-to-End General-ized Multi-Protocol Label Switching (GMPLS)- basedRecovery,” RFC 4872, May 2007.

[7] A. DÆAchille, M. Listanti, U. Monaco, F. Ric-ciato, D. Ali, and V. Sharma. ”Diverse Inter-Region Path Setup/Establishment,” draft-dachille-diverse-inter-region-path-setup-01.txt, October 2004.

[8] N. Kushman, S. Kandula, D. Katabi and B. Maggs. ”R-BGP: Staying Connected in a Connected World,” 4thUSENIX Symposium on Networked Systems Design& Implementation, April 2007.

[9] M. Bhatia, J.M. Halpern and P. Jakma. ”Ad-vertising Multiple Next Hop Routes in BGP,”Internet Draft, August 2006, work in progress.http://tools.ietf.org/html/draft-bhatia-bgp-multiple-next-hops-01.txt.

[10] D. Walton, A. Retana, E. Chen and J. Scud-der. ”Advertisement of Multiple Paths in BGP,”Internet Draft, July 2008, work in progress.http://tools.ietf.org/html/draft-walton-bgp-add-paths-06.txt.

[11] X. Li, Sarah Ruepp, Lars Dittmann, and Anna V.Manolova. ”Survivability-Enhancing Routing Schemefor Multi-Domain Networks,” GLOBECOM 2008:2232-2236.

[12] A. Manolova, S. Ruepp, J. Buron, and L. Dittmann.”On the Efficiency of BGP-TE Extensions for GMPLSMulti-Domain Routing,” 13th ONDM conference,February 2009.

[13] M. Tuba. ”Computer Network Routing Based on Im-precise Routing Tables,” WSEAS TRANSACTIONSon COMMUNICATIONS, Issue 4, Volume 8, April2009.

[14] J. P. Vasseur, M. Pickavet, and P. Demeester. ”Net-work Recovery: Protection and Restoration of Optical,SONET-SDH, IP, and MPLS” Morgan Kaufmann Pub-lishers Inc., San Francisco, CA, USA, 2004.

[15] T. Xiansi, Ch. Jingwen, M. Yajie, O. Liang, Y.Zongkai. ”An Analytical Model and A Fast Mecha-nism for Fault Restoration with QoS Constraints inMPLS Networks Based on n:m Protection,” WSEASTRANSACTIONS on COMPUTERS Volume 7, 2008.

[16] H. Hwang, S. Ahn, Y. Yoo, C. Kim. ”Configuration ofShared Backup Cycles for Local Restoration in ATMMesh Networks,” WSES / IEEE SSIP ’01, MIV ’01,SIM ’01, RODLICS ’01 International Conferences,September, 2001.

[17] P. Pan, G. Swallow, A. Atlas. ”Fast Reroute Exten-sions to RSVP-TE for LSP Tunnels,” RFC 4090, May2005.

[18] OPNET Modeler, http://www.opnet.com

[19] R. Inkret et al. ”Advanced Infrastructure for PhotonikNetworks,” Extended final report of COST Action 266,available at http://www.ufe.cz/dpt240/cost266/.



routing protocol extension for resilient gmpls … protocol extension for resilient gmpls...

Documents