Bandwidth consumption in multipath resilience …Munich University of Technology (TUM) Institute of...

Munich University of Technology (TUM)Institute of Communication Networks (LKN)

Prof. Dr.-Ing. Jorg Eberspacher

Interdisciplinary Project

Bandwidth consumption in multipath resilience

networks

Students: Wolfgang Muhlbauer Matthias WimmerMatriculation numbers: 2276911 2343548Addresses: Ludwig-Thoma-Str. 9 Thuringer Str. 41

92245 Haselmuhl 74172 NeckarsulmTutor: Claus GruberInitiation: 2003-02-01Delivery: 2003-08-14

Abstract

Different resilience schemes are available for implementation in a network, that have dif-ferent characteristics of reaction speed and needed network capacity. To maximize thecapacity a network provider is able to sell, a protection scheme has to be selected, thatoffers the most capacity while not exceeding the maximum acceptable reaction time.

In this project software had to be implemented, that calculates the bandwidth usage ofdifferent recovery schemes, and the results had to be compared. A working implementationhas been build, that is able to calculate small networks and medium networks, if the numberof paths considered for the solution is limited. Accurate computations of bigger networksseem not to be possible with today’s computer hardware as the memory requirements areincreasing exponentially with the size of the given network.

2

Contents

Contents 3

1 Introduction 61.1 Basics about Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 MPLS/IP Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Concepts of Ensuring Resilience 112.1 Resilience Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 1+1 Path Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2 1:1 Path Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 1:N Shared Path Protection . . . . . . . . . . . . . . . . . . . . . . 132.1.4 End-to-End Path Protection . . . . . . . . . . . . . . . . . . . . . . 142.1.5 Haskin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.6 Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.7 Regional Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.8 Local-to-Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.9 Ring Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.10 P-Cycle Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Multi-path Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Stub release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Implementation 213.1 Overview of the Implementation Components . . . . . . . . . . . . . . . . 213.2 Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Data Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Network Resources (Paths and Circles) . . . . . . . . . . . . . . . . 253.3.2 Unambiguous Identification of Protection Resources . . . . . . . . . 263.3.3 Management of the CPLEX Solver Variables . . . . . . . . . . . . . 27

3.4 The Solver CPLEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.1 Embedding of the Solver into the Software . . . . . . . . . . . . . . 283.4.2 Design of Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3

CONTENTS 4

3.5 Modular Design of the Software . . . . . . . . . . . . . . . . . . . . . . . . 313.5.1 Multipath Support for Working and Protection Resources . . . . . . 323.5.2 Equal and Free Distribution of Capacities . . . . . . . . . . . . . . 333.5.3 Supported Resilience Strategies . . . . . . . . . . . . . . . . . . . . 353.5.4 Support of different Optimization Targets . . . . . . . . . . . . . . 363.5.5 Flexible Application of different Resilience Strategies to one Physical

Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.6 Implementation of the Output Classes . . . . . . . . . . . . . . . . . . . . 37

4 User Instruction 394.1 Use from the command-line . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Direct call from another program . . . . . . . . . . . . . . . . . . . . . . . 41

5 Problems and Difficulties during the Project 425.1 Memory Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1 Decreasing the number of paths . . . . . . . . . . . . . . . . . . . . 445.2 Problems with Minimizing the Maximum Used Edge Capacity . . . . . . . 45

6 Results 476.1 Effects of Path Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Comparison of the Resilience Strategies in terms of Bandwidth Consumption 48

6.2.1 Case Studies for the COST 239 Network . . . . . . . . . . . . . . . 486.2.2 Case Studies for the COST 239 Network with 100 Gib/s links . . . 516.2.3 Case Studies for the WMW Network . . . . . . . . . . . . . . . . . 52

6.3 Influence of Multipath Extensions on Bandwidth Consumption . . . . . . . 536.4 Use of Different Target Functions . . . . . . . . . . . . . . . . . . . . . . . 556.5 Conclusions - Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Summary and Outlook 57

A Sample GML file 59

B Example program using the calculator 60

C Constraint Modelling 62C.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62C.2 Multipath Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62C.3 Resilience Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

C.3.1 1+1 Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63C.3.2 1:N and Haskin Protection . . . . . . . . . . . . . . . . . . . . . . . 64C.3.3 Link, Regional and Local-To-Egress Protection . . . . . . . . . . . . 65C.3.4 Ring and p-Cycle Protection . . . . . . . . . . . . . . . . . . . . . . 66C.3.5 Rerouting with and without Stub-Release . . . . . . . . . . . . . . 67

CONTENTS 5

D Contents of the annexed CD 70

List of Figures 71

List of Tables 72

Bibliography 73

Chapter 1

Introduction

The first fully intelligible telephone call occurred on March 6, 1876, when Alexander Gra-ham Bell called to his assistant, who was just in another room: “Come here, Watson, Iwant you”. Certainly, Bell would be surprised about the technology progress in informationand communication systems which has taken place since his world-changing invention.

But despite of the rise of radio, television and internet, new forms of communications arefar from being perfect.

Take as an example the global medium internet, which can be classified as one of themost important communication networks. Much progress has been achieved in this field,nonetheless there remains a lot to do. Nowadays networks need not only provide morecapacities to satisfy the demand for higher transfer rates but also need to guarantee ahigher Quality of Service (QoS).

To an increasing degree networks are supposed to carry mission critical, real-time andother high priority traffic (e. g. IP telephony) over the public internet. It is obvious, thatany network that carries critical, high-priority traffic needs to be resilient to faults. Justimagine that an excavator cuts through a fiber optic cable by mistake. In such a scenario itwould be essential to keep failure times as short as possible in order not to affect real-timeor high-priority traffic.

To sum up, resilience and survivability of link failures are aspects which should not beneglected in the further development of communication networks. It was the main task ofthis work to investigate different methods which could ensure these key features in futurenetworks.

6

CHAPTER 1. INTRODUCTION 7

1.1 Basics about Resilience

In the following the term “resilience” refers to the ability of a network to keep servicesrunning despite a failure. To achieve more resilience, it is necessary to have a certainredundancy of capacities in the network, which can take over the affected traffic in thecase of a link failure (e. g. caused by a cable cut). In principle, one can distinguishbetween two different approaches:

• Protection Schemes: The alternative protection resources, which are to be used inthe case of a link failure, are calculated in advance. If an error occurs, the disruptionof the traffic will be short, as traffic must only be redirected to the already reservedbackup routes.

• Restoration Schemes: The protection resources are calculated in advance, like forProtection. But the backup routes are set up not before the failure happens. Thetraffic can not be redirected before the new route has been established in the network.

• Rerouting Schemes: In an error case, the affected traffic will be redirected to alter-native routes which are not calculated until the error has been detected. It is notguaranteed, that a new routing can be found.1 Normally, this scheme has advantagesin terms of bandwidth consumption.

The question arises, under which criteria the demand between two network nodes should berouted so that not bandwidth is wasted. Different protection mechanisms, i. e. algorithmsrestoring services carried by a specific network topology, will be introduced in Chapter 2.Basically, there exist two approaches for such protection algorithms:

• Link orientated: Multiple links that support end-to-end connectivity can be individ-ually switched to restore service. One could also say that only the traffic betweentwo nodes is considered.

• Path orientated: A model in which all traffic is routed on complete paths (virtualconnections) from the source node to the target node of a demand.

In this work, the path-orientated method is used, as it enables to discard paths in advanceand in this way to reduce the large number of paths which otherwise would have to beconsidered for the calculation of the routing and the needed protection capacities.

It may be helpful to give an overview of the steps which are necessary to gain more resiliencewithin a given network.

1. Topology Discovery: A central instance or several distributed instances are neededthat know the topology of the network (ring, mesh).

1We calculate the routings in a way, that for every failure a new routing can be found. Else we couldcalculate nothing and it would be hard to compare results.


2. Constraint-based Route Selection: With the help of an algorithm the primary routes(working capacities) and the protection routes are calculated. The algorithm isconstraint-based, i. e. the routing underlies certain restrictions (e. g. ”Do not ex-ceed the maximum allowed capacity of an edge). In this work, we will focus on thataspect. The constraint-based route selection will be done by the linear constraintsolver CPLEX.

3. Signalling Protocol: A protocol is needed which is responsible for the communicationbetween the network nodes, the reservation of the protection capacities and the pro-tection switchover from working resources to protection resources in an error case.For example protection functionality is defined for:

• Optical Layer

• SONET/SDH

• ATM/Frame Relay

• MPLS/IP

In the next section, the basic principles of MPLS recovery will be outlined.

1.2 MPLS/IP Recovery

MPLS (Multi Protocol Label Switching) is a protocol which works together with differentprotocols of the network and data link layer, but which is especially interesting when theIP protocol is used as network layer protocol.

The main idea is, that at the beginning of a new data transfer a virtual connection is builtup ensuring that all packets travel along a fixed path from the source to the target node.Thus MPLS offers the possibility of using connection-orientated features together with theconnectionless protocol IP.

The forwarding of MPLS packets is done according to a label which is generated duringthe setup process of a connection and which is appended to the IP packet.

Figure 1.1 shows a MPLS domain, i. e. a portion of a network that understands MPLS. Alabel sequence defines the so-called Label Switched Path (LSP) on which an IP packet isrouted through the network. Each Label Switched Router (LSR) uses only such a label toforward a packet.

The setup of the LSP is done by special signalling protocols and must be initiated by theLabel Edge Router (LER) if the packet comes from outside the MPLS domain. The LabelDistribution Protocol (LDP) with its extensions Constraint-Based Routing LDP (CR-LDP)and the Resource Reservation Protocol (RSVP) offer traffic engineering methods and the


LSR

MPLS domain

LSR

LSR

LSR

LSR

LER

LER

LSP

Figure 1.1: MPLS Architecture

provisioning of alternate paths. Thus it is ideally suited for providing more resilience innowadays networks.

1.3 Overview

The aims of this work can be summarized in four points:

1. Introduction into different approaches to achieve more resilience in nowadays net-works.

2. Comparison of different resilience strategies in terms of their bandwidth consumption.

3. Investigation of the effects of multipath extensions on bandwidth consumption.

4. Development of a software which calculates the needed bandwidths for the differ-ent resilience concepts. Software design can be characterized by a high modularityand expandability, thus offering many possibilities in terms of different multipath-concepts, different optimization targets and different resilience methods.

In the next chapter the theory of the implemented resilience and multipath concepts willbe introduced. Chapter 3 gives a close look onto the implementation whereas Chapter 4will describe how to use the software. After some case studies on example networks in


chapter 6, results will be evaluated and conclusions about the bandwidth consumptions ofthe resilience concepts will be drawn.

Chapter 2

Concepts of Ensuring Resilience

To achieve the goal of network resilience, that we introduced in chapter 1, there are differentresilience schemes available, from which the network planner can choose one for all trafficin the network or several for different traffic classes.

The reason why he might choose different schemes for the different traffic classes and whythere does not exist a single optimal solution, is, that the resilience schemes differ on theone hand on the amount of bandwidth they need and on the other hand on the time theyneed to restore the operation of a broken connection. Also they may use a different numberof protection paths and, if there are more paths in the network, the routers need biggertables to store the routings for the paths.

An additional difference is, how they are able to handle multiple link failures or nodefailures. But in this project we only cared about single link failures, assuming nodes to bevery reliable and link failures to be fixed before the next link failure happens.

2.1 Resilience Methods

The commonness of resilience methods is, that all use redundant capacity in the networkto replace failed capacity in the case of an error. They differ in when these capacities arereserved—either they are reserved all the time or they will not be reserved before they areneeded—and where the capacity will be replaced. This can be done at the last workingnode before a failed link, at the source of the affected path or somewhere in between.

Another difference is where this additional “protection” capacity ends: it can either inde-pendently go to the target of the the traffic or only bypass the failed link and reuse thestill functional end of the original “working” path.

Especially for schemes that reserve their protection capacity not before it is needed, a morelocal rerouting can speed up the restoration as less signalling is needed than to setup a

11

CHAPTER 2. CONCEPTS OF ENSURING RESILIENCE 12

completely new path from the source to the target.

2.1.1 1+1 Path Protection

D

A C

B

Figure 2.1: One plus one protection: There is a demand from D to C, it is routed on D-B-Cand on D-A-C.

A very simple and very fast approach to ensure resilience is to send all data on two disjointpaths through the network. If the protection is handled at the physical network layer, thereceiver is then able to just select the stronger signal. If it is handled at a higher layer, thedecision on where to receive data can be made based on where packets are arriving first.

If elements on one of the two paths fail, the receiver automatically selects the other path.There is no need to signal this event to the sender as it already transmits the data on bothpaths. This makes the 1+1 path protection scheme very fast and simple to implement inthe network.

The drawback to this approach is, that compared to the unprotected case at least thedouble1 amount of capacity is needed in the network.

2.1.2 1:1 Path Protection

1:1 path protection2 works very similar to the 1+1 path protection discussed in 2.1.1, butthe traffic is only sent on one of the two paths (the “working path”), on the other path(the “protection path”) no traffic is sent as long as the working path does not fail. Aslong as there is no need to use the protection path, its capacity can be used to carry lowpriority traffic.

The drawback compared to 1+1 path protection is, that the receiver has to signal thesender, that it has to switch to the protection path. This signalling takes some time where

1it can be more than the double amount if the second path is longer than a single path; the second onewill never be shorter than a single one as it could be used as the single one else

2please note: the classes in our program, that have a OneToOne in their name do not implement 1:1path protection but 1:1 shared path protection which is an alternate name for 1:N shared path protection


D

A C

B

Figure 2.2: One to one protection: There is a demand from D to C, it is routed on D-B-Cand protected by D-A-C.

the transmitted data is lost. As with 1+1, 1:1 path protection can survive at least one linkfailure per demand.

2.1.3 1:N Shared Path Protection

A CB

DEF

Figure 2.3: One to N protection: There are demands from F to B and from E to B. Thefirst demand is routed over A, the second has a direct routing. Both paths are protectedby routes reusing the same edges E-D, D-C and C-B.

If we only have the need to survive one link failure in our network3, we get further flexibilityin selecting protection paths and we can save protection capacity.

Any given single link failure can only affect one of several disjoint paths in the network.Therefore it is possible, that disjoint paths can share capacity for their protection paths.

While for 1:1 path protection it was possible to use a static setup of the protection paths,in the case of 1:N shared path restoration they can not be setup before they are needed,because many networks reserve the capacity of a path as soon as it is inserted and the

3assuming that they can be fixed before the next failure occurs and that is unlikely that two links failat the same time


other paths, that share the capacity, can not be inserted afterwards. This results in anadditional slowdown of the restoration as not only the sender has to be informed, but thepath has to be established as well.

2.1.4 End-to-End Path Protection

Up to this point, it was always the responsibility of the receiver to detect a failure and theresponsibility of the sender to switch the paths and start sending on the protection path4.If there was a failure in a working path, a second and completely disjoint path was used.This is called “end-to-end path protection”.

On the one hand this minimizes the number of protection paths, that have to be maintainedin the network. It does not matter which link of a working path fails, it will always be thesame protection path, that takes over the traffic. On the other hand failures have to besignalled end to end through the whole network, if it is not 1+1 path protection that isused.

To speed up signalling and to keep failure times as short as possible, the 1:1 and 1:Nrecovery schemes can be modified to detect and react on failures locally.5

2.1.5 Haskin

A CB D

EFGH

Figure 2.4: Haskin protection: There is a demand from H to E. The working path is H-G-F-E. The protection path is F-G-H-A-B-C-D-E. Depending on which link of the workingpath fails, the protection path is used starting at a different node.

One possible way for a local reaction on failures is, that the last node in front of the brokenlink detects the failure and redirects the traffic to a reverse path back to the sender. At thenode sending the traffic this reverse path is continued on a disjoint route to the originalreceiver.

4in the case it did not already send the traffic on both paths5For 1+1 this is not necessary as there is no signalling, that would benefit of local decisions and

reactions.


With this scheme only the last working node on the working path has to detect the failureand reroute the traffic to the protection path. Besides the receiver has to detect, that itgets the signal on the protection path instead of the working path. As with 1+1 protectionthere is no need to inform the sender of the failure.

If haskin protection is used with 1:1 protection, no global signalling is needed as all pro-tection paths can be setup in advance. It seems, that it does not make much sense to usehaskin protection together with 1:N protection as there is an even longer path, that wouldhave to be setup and signalled in case of a failure.

2.1.6 Link Protection

A CB D

EFGH

Figure 2.5: Link protection: There is a demand from H to E that is routed on H-G-F-E. Each link on the working path has its own protection path (H-A-B-G, G-B-C-F andF-C-D-E).

Another possible reaction for the last node in front of a failed link is to send the traffic ona small local protection path to the next node on the working path6.

Because only small protection paths are used, it is faster to setup these paths than end-to-end protection paths. This makes link protection interesting as a 1:N protection scheme,but it is also possible to use it for 1:1 protection. Neither the sender nor the receiver hasto be informed of the restoration and therefore no global signalling is needed.

The drawback to this protection scheme is, that every node on a working path has itsown unique protection path. This results in a very large number of protection paths, thatexist in the network. Especially if they are used with 1:1 protection, they need quite somecapacity in the network. But even with 1:N protection they have to be stored somewherein the network where it results in bigger routing tables.


A

B C

D

EFGH

I

J K

Figure 2.6: Regional protection: There is a demand from I to D, that is routed on theworking path I-J-K-A-B-C-D. If a link in the first half of this path fails, the protectionpath I-H-G-A is used. If a link on the second half of this path fails, the protection pathA-F-E-D is used.

2.1.7 Regional Protection

Regional protection is a variant of the link protection scheme, that tries to reduce thenumber of protection paths by not defining unique protection paths for each node in theworking path, but using the same protection path for nodes that follow each other.

Regional protection can be considered as splitting the whole path into multiple partialpaths, that are protected end-to-end on their own.7

While reducing the number of protection paths compared to link protection, regional pro-tection can still handle failures close to their occurrence as long as the regions are notselected to large8.

2.1.8 Local-to-Egress

An other variant of the link protection scheme is not to use protection paths, that end atthe node after the failed link, but to use protection paths, that end in the target of thedemand, which has to be routed by the working path.

The protection paths in this scheme are allowed to use links, that had been used by therouting of the working path as long as it is not the link, that is protected by this protectionpath.9

6this is the first node after the failed link7One is not really forced to protect these partial paths end-to-end. It would also be possible to use

other schemes like haskin protection. Using haskin protection would result in a protection scheme that isvery similar to ring protection (see 2.1.9) with multiple rings.

8it is assumed that regions are defined by the operator of a network9please note: our implementation differs from this, intentionally our program only allows disjoint paths

to be used


A CB D

EFGH

Figure 2.7: Local-to-Egress protection: There is a demand from H to E that is routed onthe working path H-G-F-E. If the first link fails, the protection path is H-A-B-C-F-E. If thesecond link fails, the protection path is G-B-C-D-E. If the third link fails, it is protectedby F-C-D-E.

Local-to-Egress protection is a more liberal version of the Link Protection Scheme: Linkprotection is always a valid solution for the Local-to-Egress Scheme, but the second isallowed not to route to the node at the end of the failed link.

2.1.9 Ring Protection

A

B C

D

EFGH

I

J K

Figure 2.8: Ring protection: There is a demand from I to D and it is routed on the workingpath I-J-K-A-B-C-D. If a link in the first half fails, the protection direction K-J-I-H-G isused starting in the last working node of the working direction, e. g. J if the link J-K fails.If a link in the second half fails, the protection direction C-B-A-F-E-D is used. (Note thatwe would get exactly the same picture if we take the example in figure 2.6 and protect theregions with Haskin.)Note: The working direction in our examples is counter-clockwise, the protection directionis clockwise.

A different approach to survive failures in a network is ring protection. For this scheme thenetwork is constructed of routing cycles. Each cycle consists of two directions, that cancarry traffic. For normal operation only one direction (the “working direction”) is used. Ifone of the nodes on this circle detects, that the link to the next node is broken, it redirects


all incoming traffic for which it is not the target to the other direction (the “protectiondirection”) of the cycle, where it is passed through to the node at the other end of thefailed link. This node then reinserts the traffic in the normal path of the working direction.Traffic on the protection direction is passed to this node even if it has reached the targetnode before. This is done because otherwise every node had to check for arriving data onthe protection direction. It would then be necessary to signal the failure to all nodes onthe ring. If it is passed the whole protection direction but the broken link, no signallingis required at all: the last node that receives data just passes the data to the protectiondirection and the node that does not get a signal on the working direction starts receivingthe protection direction.

There is no need that all nodes of a network are on the same cycle. A network can be buildby multiple cycles that share nodes. These nodes then work as gateways between differentcycles and pass the traffic from one circle to the next one.

2.1.10 P-Cycle Protection

A

B C

D

EFGH

I

J K

Figure 2.9: P-Cycle protection: There is a demand from I to D, that is routed on theworking path I-J-K-A-B-C-D. If one of the link fails, the same protection paths are usedas in normal ring protection link in figure 2.8.

P-cycles are an extension to rings where the capacity of the protection direction is alsoused to protect direct links (called “straddling links”) between two nodes on the ring.

If an in-cycle link fails, protection is handled the same way as with normal rings. If astraddling link fails, the two end nodes of this link pass the traffic that was routed on thestraddling link to the other node on the protection direction of the cycle.

P-cycles preserve the advantage of very fast recovery times in rings and additionally protectthe straddling links without needing additional protection capacity.


A

B C

D

EFGH

I

J K

Figure 2.10: P-Cycle protection: There is a demand from I to D, that is routed on theworking path I-A-D. If one of the link fails, they can be protected by the protectiondirection of the two rings. If I-A fails, it will be protected by I-H-G-A. If A-D fails, it willbe protected by A-F-E-D.

2.2 Multi-path Extensions

While in 2.1 we always had one single working path for each demand and at most oneprotection path per possible failure and demand, we can extend our schemes to allowmultiple working and/or protection paths.

If we allow multiple working paths per demand, we can satisfy demands, that a networkwith only single working paths would not be able to carry, either because the capacity oneach link in the network is smaller than the demand or because the traffic, that is alreadycarried in the network, is that big that on none of the links there is enough free capacityto satisfy the demand.

With the multi-path extensions the sender10 can split the demand into smaller parts, whichall have their own working paths that are routed independently.

As we were able to split the working path into multiple paths, we can also split theprotection paths into several protection paths per working path and failure.

By using multi-paths, we have to decide, if we allow the distribution to an arbitrary numberof paths or if we want to fix or limit the number of multi-paths. Also we have to decide, ifwe allow free distribution of traffic to the multi-paths or if we want to fix the distributionin a way, that every multi-path carries the same fraction of the traffic. The advantage ofusing the same fraction on any path is, that it can be implemented in hardware more easilyby a counter, that is reset to zero, if it reaches the number of paths. For each counter valuean other path is selected.

10It is also possible, that an intermediate node splits the traffic into different paths, but this can bemodeled as two different end-to-end paths, that use the same nodes at the beginning.


2.3 Stub release

A CB D

EFGH

I KJ L

Figure 2.11: Stub release: In this network all edges have a capacity of one for each direction,the demands use the same bandwidth. One demand is routed on A-B-C-D, the otherdemand is directly routed from C to B. It would not be possible to find protection pathsfor this routing without stub release. If the link A-B or C-D fails only the lower protectionpath is needed, if the link B-C fails, A-B and C-D gets free capacity that can be used toprotect C-B with the upper protection path.Note: Without stub release it would be possible to route the demand from A to D onA-I-J-K-L and find protection paths for this routing, but more capacity is used in thiscase.

Another bandwidth optimization we are able to use if protection capacity is setup notbefore it is needed, is to release the failed working paths before the protection paths areestablished. This freed capacity can then be used by protection paths, that recover thenetwork operation. An example for a network that benefits from stub release is given infigure 2.11.

Stub release is especially useful for protection schemes, that do not pre-reserve the capacityof their protection paths. Therefore all 1:N protection schemes can be used with stubrelease. It has to be noted, that first releasing the stubs requires some additional time.

Chapter 3

Implementation

3.1 Overview of the Implementation Components

In our implementation of a multi-path resilience routing calculator we reuse two externalcomponents. One is ILOG’s linear equation solver Concert/CPLEX, that is further de-scribed in 3.4. The other given component is the GRAPH library [Gru03] of Claus Gruber.GRAPH is a general purpose library to read, write, represent and manipulate graphs.

We extend the GRAPH component with our Network Representation component. Thiscomponent implements different types of networking layers1 inheriting the basic character-istics of graphs from the classes in the GRAPH library. We add the possibility to relatenodes and edges in different layers with each other using templates from the GRAPH li-brary and add the ability, that other components can add equation solver variables to theelements of the network.

1the layered network model, that we are using is described in 3.2

Constraints

Networkrepresentation

Resilienceschemes

CoursecontrolGRAPH

CPLEXlinear solver

Figure 3.1: Components implemented and used in our project

21

CHAPTER 3. IMPLEMENTATION 22

In the Network Representation component we also implement the representation of pathsin the network, methods to calculate them and a system to cache2 them. On the one handthe caching system is used to speed up the processing because we need to get the pathsbetween given nodes multiple times and on the other hand we can ensure that the samepath is always represented by the same instance of a path class. The methods that calculatepaths in the network are able to limit the number of paths between each pair of nodes.If other variants of limiting the number of paths are desired, this can be implemented inthese methods as well. The reason why the number of paths had to be limited is describedin 5.1. More information about data representation can be found in 3.3.

The Constraints component contains the interface to the CPLEX solver. It is an abstrac-tion of the equations and inequations, that are needed to calculate the optimized routingin the network. The classes in this component define what is possible in the network. Anexample for a constraint is, that on none of the links in the physical network it is possi-ble to carry more traffic than there is capacity on it. A closer look at some of the usedconstraints is given in 3.4.2.

The Resilience Schemes component contains the knowledge of what constraints have tobe used to get which resilience scheme. Different classes in this component implementthe different resilience schemes that we support with all their variants. More informationabout these classes is given in 3.5.

The last component is the Course Control. This part of our software defines the order ofactions, that have to be done, and the interface to the user. After the he has created therepresentation of the network and its demands3 he passes the control along with his wisheson which methods should be used to the Course Control.

After the Course Control has been started by the user, it first generates instances of theResilience Schemes classes, that implement the the desired protection methods. Theseclasses are responsible to return all the constraints, that describe the implemented protec-tion scheme. It is possible for the user to pass different demands to the Course Control withdifferent wishes on the resilience methods. The Course Control will hold the constraintsuntil all of them are returned by the individual resilience schemes. Thereafter it creates anenvironment for the CPLEX component and causes the constraints to add their equationsand inequations to this CPLEX environment. Having added all constraints the solver isstarted to do the actual calculations.

As last step it is necessary to read the result, that we (hopefully) got from Concert, andadd a representation of it to the representation of the network. How this is done is furtherexplained in 3.6.

2actually there are two caches: one cache stores the paths, that are calculated as general use pathsbetween two nodes and that can be limited in number or length; a second cache keeps paths, that arecalculated by combining or modifying paths from the first cache and that are not contained in the firstcache

3typically this is done by instructing the software to read the definitions as GML files


3.2 Input and Output

All reading and writing of graphs and their relations to each other is done using the GML(Graph Markup Language). GML is a textual serialization of the graph using a list of keyand value pairs. The values in these pairs can be lists of key value pairs again. A samplefor a simple GML file containing the complete graph K3 is given in appendix A.

As input to our software two graphs are read: The first defines the physical network withthe link capacities, that are available in the network4. The second defines the demands,that should be routed on this network.

The GML files for both networks should contain the key graph containing a list of nodes,edges and some attributes as value. Supported attributes for both graphs are id anddirected. The first attribute defines a unique numerical id for both of the two graphs,the second attribute should always be set to 1 as we only support directed graphs at themoment.

Each node has node as its key in the GML file and its value is a list of the followingattributes:

• id: graph-unique numerical ID of this node

• label: label of this node, e. g. name of a city

• relatedDemandNode: reference to the representation of this node in the demand node,defined as the concatenation of the id of the demand graph, an underscore and theid of the node in the demand graph (this attribute only exists in the physical graph)

• relatedPhysicalNode: reference to the representation of this node in the physicalnetwork, defined as the concatenation of the id of the physical graph, an underscoreand the id of the node in the physical graph (this attribute only exists in the demandgraph)

Each edge has edge as its key in the GML file and its value is a list of the followingattributes:

• id: graph-unique numerical ID of this edge

• label: label of this edge

• source: id of the source node of this edge

• target: id of the target node of this edge

• capacity: capacity of the link (integer value, this attribute only exists in the physicalgraph)

4nodes are not capacity limited in our model


graph attribute description

demand routedOn relation to all edges in the protection graphthat are used to carry the demand

physical belongsToProtectionEdge relation to the protection edge for that hasto be used if this physical edge fails

physical belongsToWorkingEdge relation to the working edge that is protectedby this edge

physical partOfProtection relation to the protection edges that willroute their traffic over this physical edge ifthey are used

protection isValidFor a working edge can have different protectionedges from which one is chosen if a physi-cal edge fails, for which physical edges theprotection edge is valid is defined in this at-tribute

protection protects relation to the working edge that is protectedby this edge

protection routedOn relation to the physical edges that form thisprotection edge

working belongsToDemandEdge relation to the demand that is routed by thisworking edge

working protectedBy relation to the protection edges that are usedto protect this working edge

working routedOn relation to the physical nodes that are usedto route this working path

Table 3.1: GML attributes defining the relations between the edges in the graphs

• demand: demand that exists between the source and target node of this edge (integervalue, this attribute only exists in the demand graph)

As the result of its calculations our software will create two additional graphs that representthe result and add relations between these four graphs. The first of these two graphs is theworking graph, defining the routings of the demands in the physical network while there isno link failure. The second one defines how the network has to reroute the traffic for everypossible link failure.

To support the additional graphs new relations have to be defined. The relations betweenthe nodes in the different graphs are always called relatedXXXNode where XXX is one ofDemand, Physical, Working or Protection and define which nodes are the same node inthe network. For the edges a more complex relation model is used and described in table3.1.


3.3 Data Representation

As described in 3.2, the input information is given in two GML files, one for the physicalnetwork and one for the demand. Based on these two files, a series of new data is generatedby the software in order to keep everything transparent and to store additional informationneeded for the calculation process. A quite obvious example for such a new data structurewould be a path, which consists of nodes and edges and provides means to realize a path-orientated calculation of the optimal “resilient” routing. In the following subsections wewill take a closer look at some important aspects of data representation in the software.

3.3.1 Network Resources (Paths and Circles)

In all resilience concepts with the exception of Ring and p-Cycle Protection, all capacities,no matter whether working or protection capacities, are routed on paths (in the case ofRing and p-Cycle Protection unidirectional circles are taken as protection resources). Both,paths and circles, have in common that they could be used to carry traffic either to satisfya demand or to protect a working resource. This commonness is reflected in the softwaredesign, with ResourceEntity being an abstract base class for the classes Circle and Path

(cf. Figure 3.2).

ResourceEntity

Path Circle

Figure 3.2: Simplified Diagram of Resources used to transport Traffic

In principle, each instance of class Path constitutes a virtual connection and could bea possible candidate for meeting a demand between its source and end node. If aResourceEntity is such a candidate, a variable will be created which the linear solverCPLEX is supposed to extract. Therefore it is also the task of Path or Circle to give ameaning to a CPLEX variable, i. e. with the help of ResourceEntity CPLEX variablescan be identified.

The implementation of the classes Path and Circle is quite obvious. EachResourceEntity stores a list of all nodes which make up the path or the circle, andoffers certain methods to the user which facilitate co-operation with the ResourceEntity.

Last but not least, the question remains who creates a ResourceEntity. It is thetask of class PhysicalNetwork which offers with the methods getAllPaths() and


getAllCircles() the possibility of calculating and generating all paths and circles,respectively. As the number of all paths and all circles can get immensely large,ResourceEntities normally are cached in the PhysicalNetwork and only those pathsand circles are considered for optimization calculation which seem to make sense undercertain criteria. The UML class diagram in Figure 3.3 shows the relationship between thejust mentioned classes.

+getAllPaths()

+getAllCircles()

-pathCache

-circleCache

PhysicalNetwork

Path Circle

1

* 1 *

Figure 3.3: relationship between the network, paths and circles

3.3.2 Unambiguous Identification of Protection Resources

The software permits to calculate an optimal “resilient” routing for the most diverse re-silience concepts, which differ in the way they protect the working resources. One justneeds to compare 1:N Protection with Link Protection: In the Link Protection Schemeeach link of each path is protected, meaning that each protection path is only valid for acertain link failure, whereas in 1:N Protection each protection path is valid for all errors,which could occur on the working path. This matter of fact indicates that different re-silience concepts require different “identifiers” for the protection resources, telling exactlyunder which situations a protection path will be actually used. All such identifiers arederived form the base class ProtectionKey, as shown in Figure 3.4.

Details about the those classes can be found in the doxygen documentation. Nonetheless,each subclass will be explained shortly:

• PathPair: This class is used for 1+1, 1:N and Haskin Protection. Each protectionpath belongs to a specific working path. The method getErrorEdge will alwaysreturn a NULL pointer, as the protection path is not only valid for one single failureedge of the working path.

• PathPairForErrorEdge is a subclass of PathPair and used for Link, Regional andLocal-To-Egress Protection. Here each protection path is only valid for a specificerror edge.

• RerouteProtectionKey: In rerouting resilience methods, the reroute paths are notassociated with a working path. Therefore the method getWorkingPath() will al-ways return NULL.


#protectionResource

ProtectionKey

#workingPath

PathPair

-errorEdge

RerouteProtectionKey

-workingPath

-errorEdge

RingProtectionKey

-errorEdge

PathPairForErrorEdge

Figure 3.4: overview of classes used to identify a protection resource

• RingProtectionKey: The main difference to the other subclasses is that p-Cycle andRing Protection use a cycle to protect working capacities.

The next subsection will briefly discuss how these ProtectionKeys work together with thevariables of the CPLEX solver.

3.3.3 Management of the CPLEX Solver Variables

The CPLEX solver is without any doubt the main item of the software. For the solvingprocess, it needs to be fed with a series of variables (e. g. variables for the possible workingand protection capacities or the used capacities on each edge). It makes sense to integrateall variables of one semantic group (for example variables for the used working capacities)in a central class, CplexVariable (cf. Figure 3.5). In the following, the most important

+operator[]()

+firstIterationKey()

+nextIterationKey()

+addVariableForEachKey()

-allVariables

CplexVariable

KeyType, CplexVariableType

Figure 3.5: Class CplexVariable

aspects of this class will be described:

• CplexVariable is a template class with the parameters


– KeyType: The class which gives a CPLEX variable a meaning. Used KeyTypes

are PhysicalEdge, Path or any subclass of ProtectionKey.

– CplexVariableType: Indicates whether a IloNumVar (double variable) or aIloBoolVar (boolean variable) is used is as CPLEX variable.

• All information about the CPLEX variables is stored in a private map structurecalled allVariables. The single CPLEX variable can be accessed by an “identifier”instance of type KeyType.

• The class CplexVariables offers iterators to go through all variables stored in theclass CplexVariable. These iterators are mainly used by the constraints.

• With the method addVariableForEachKey(listOfKeys) a new CPLEX variable iscreated for each member in listOfKeys.

3.4 The Solver CPLEX

In this section some details concerning the used solver will be discussed. ILOG CPLEX(version 7.5) delivers a flexible optimizer for solving linear and mixed integer problemsin resource-allocation applications (transportation logistics, telecommunication networksdesign and supply chain planning). As interface to the solver, ILOG Concert Technologyis taken, which alleviates the access to the solver by a complete supported C++ API.

3.4.1 Embedding of the Solver into the Software

+getEnvironment()

+getModel()

+getTargetFunction()

-env

-model

-cplexSolver

-targetFunctionExpr

CplexSolverEnvironment

Solver

Model

Variables Constraints Target Function

Figure 3.6: Solver Components and their Representation in the Software

The basic principle how the solver works, is depicted by Figure 3.6. First of all, a modelhas to be built up: A certain problem is translated into variables where the variablesare subjected to constraints (equations/inequations). Together with the variables and theconstraints, an optimization target (target function) is formulated which tells the solver


what should be optimized. After the model has been completed, the solver can begin hiswork.

Within the software the class CplexSolverEnvironment is the central class for all issuesthat concern the solver (cf. Figure 3.6). It stores pointer or references to the model, tothe environment (sort of container where the extractable variables are managed), to thesolver and to the expression which forms the target function. The subsequent steps makeit more clear, how the solver CPLEX is embedded in the software:

• In the constructor of class CplexNetworkCalculator, an instance ofCplexSolverEnvironment is created, leading to the creation of a new modelin CplexSolverEnvironment.

• The CplexNetworkCalculator passes a pointer or reference ofCplexSolverEnvironment to all classes which will get into contact with CPLEX(e. g. classes which add constraints to model). The target function is added by asubclass of CplexNetworkCalculator.

• After the model has been completed, CplexNetworkCalcultor callscreateCplexSolver() of CplexSolverEnvironment to create a solver instance.Then the calculation is started. If successful, the solver then contains the desiredoptimal results.

3.4.2 Design of Constraints

An essential part of the work with the solver is the design of the constraints. So it isnecessary, to go into the representation of constraints within the software.

Note, that the target function is handled by the CplexNetworkCalculator. Figure3.7 shows that all constraints within the software are subclasses of the abstract classConstraint. As each constraint gets information about all variables, needed for the equa-tions or inequations to be formed, each subclass of Constraint can simply add itself tothe model by calling the method addYourself(). This is desired, as the modular designof the software demands a flexible co-operation of diverse constraint combinations. Aftera list of all needed constraints has been generated, it is quite easy to actually add the listitems to the model.

It should be noted that each constraint normally adds several equations/inequations to amodel not only one. Furthermore the class CplexVariable (see 3.3.3) enables to manage aset of CPLEX variables with the same meaning (e. g. set of all variables for possible workingpaths), which predestines instances of CplexVariable for the use within the constraints. Inthe following some constraints will be presented, which are generally used for all resilienceconcepts within the software. More special constraints for multipath extensions and thetarget function will be discussed in the next section.


+addYourself()

Constraint

CplexCalculateSharedCapacityConstraint

CplexCapacityToBinaryVarConsistenceConstraint

CplexDemandIsSatisfiedConstraint

CplexEqualDistributionConstraint

CplexGlobalWorkingPathsAreProtectedConstraint

CplexLimitMaximumEdgeCapacityConstraint

CplexLimitNumberOfEntitiesConstraint

CplexLocalWorkingPathsAreProtectedConstraint

CplexStubReleaseConstraint

Figure 3.7: Subclasses of Constraint

• CplexLimitMaximumEdgeCapacityConstraint: This constraint ensures that theused capacity on each edge e (UCe) does not exceed its allowed capacity (ce).

UCe ≤ ce (3.1)

• CplexDemandIsSatisfiedConstraint: It is the task of this constraint to guaranteethe satisfaction of all demands di,j between all nodes i and j of the network. Thecapacities of all paths p between the nodes i and j (WPCi,j,p) must together equalthe demand. ∑

p from i to j

WPCi,j,p = di,j (3.2)

• CplexGlobalWorkingPathsAreProtectedConstraint andCplexLocalWorkingPathsAreProtectedConstraint: Each working path p, leadingfrom node i to node j (WPCi,j,p) must be protected by protection resources r for alledge failures fe (PPCp,r,fe).

WPCi,j,p =∑

r could protect p if fe fails

PPCp,r,fe (3.3)

With the help of the class ProtectionKey (cf. 3.3.2), it is possible to usethe constraint class CplexLocalWorkingPathsAreProtected for all resilience con-cepts, except for 1:N Protection, 1+1 Protection and Haskin Protection whereCplexGlobalWorkingPathsAreProtected is taken and except for Rerouting.

• CplexCalculateSharedCapacityConstraint and CplexStubReleaseConstraint:Apart from 1+1 Protection, several protection resources share their capacities with


each other. The shared capacity on each edge e (SCe) is at least as large as the sumof all protection capacities r (PPCp,r,fe) that are routed over edge e in the case of asingle link failure fe. So for local strategies (e. g. Link Protection) and Reroutingwithout Stub Release a constraint can be formulated as follows:

SCe ≥∑

r contains e

PPCp,r,fe (3.4)

If Rerouting with Stub Release is used, CplexStubReleaseConstraint is taken in-stead of CplexCalculatedSharedCapacityConstraint. The main idea with stubreleasing is that the working paths which are affected by a single link failure givefree their reserved resources which makes it possible to reuse them for the reroutingprocess. The edge capacity of edge e in the case of the single link failure fe thenconsists of the working path capacities not affected by the failure (WPCnotAffected)and the used reroute resources (RPCused). This capacity must not exceed the sumof working capacities (WCe) and shared capacities (SCe) on this edge e:

∑WPC contains e

WPCnotAffected +∑

RPC contains e

RPCused ≤ WCe + SCe (3.5)

• Calculating the Edge Capacity: The total capacity on edge e (ECe) includes theshared protection capacities (SCe) and the working capacities routed on this edge(WPCi,j,p):

ECe = SCe +∑

path p contains e

WPCi,j,p (3.6)

The calculation of this edge capacity is not done in a special subclass of Constraint,but in the resilience class which builds up the list of needed constraints for a specificstrategy.

To sum it up, all constraint classes are kept as general as possible by implementing themas template classes and by using the principle of inheritance. In this way constraints canbe used for the most diverse resilience concepts.

3.5 Modular Design of the Software

It was the main requirement for the software to allow a flexible combination of the most di-verse approaches to gain more resilience. Different resilience strategies, different optimiza-tion targets, different multipath extensions should work together without any problems.This subsection gives an overview on all independent and orthogonal modules available inthe software.


3.5.1 Multipath Support for Working and Protection Resources

As described in 2.2, sometimes it can be useful to distribute traffic on several paths and notonly to use one path between a source node and a target node. Such multipath extensionsmay lead to a reduction in bandwidth consumption, as resources can be used more flexibly.

This software supports four multipath variants which differ in respect of the number ofused working and protection paths (cf. table 3.2).

Nomenclature within Number of working paths Number of protection pathsthe software to satisfy a demand to protect one working pathSingleSingle 1 1SingleMulti 1 >1MultiSingle >1 1MultiMulti >1 >1

Table 3.2: Nomenclature of Multipath Variants within the Software

In the software, both working and protection resources can be adjusted to allow

• only one path

• allow a maximum of two multipaths

• allow a maximum of three multipaths

• permit an arbitrary number of multipaths

for one demand or to protect one working path, respectively.

The implementation of these multipath extensions is primarily done by a constraint thatlimits the number of alternative working or protection resources depending on the desirednumber of “multipaths”.

To illustrate, let WPUi,j,p be a binary CPLEX variable for a working path p which couldpossibly satisfy the demand between nodes i and j. This variable is true (1) if the work-ing path carries traffic for the demand i, j, otherwise it would be false (0). The classCplexLimitNumberOfEntitiesConstraint allows only a maximum of limit such workingpaths for demand di,j.

∑

p from i to j

WPUi,j,p ≤ limit (3.7)

In the software, the class CplexLimitNumberOfEntitiesConstraint is a template classand kept as general as possible. Thereby it can be used to limit working paths as wellas protection resources. If an arbitrary number of “multipaths” is allowed, the classCplexLimitNumberOfEntities is not needed at all.


Very frequently, in addition to a binary variable indicating whether a resource is used totransport traffic, also a IloNumVar CPLEX variable is needed which reflects the actualcapacity on a working or protection resource. Let this variable be WPCi,j,p (WorkingPath Capacity) for a working path with start node i and end node j. In such a case, theconsistence between WPUi,j,p (Working Path Used) will be achieved by using the constraintCplexCapacityToBinaryVarConsistenceConstraint:

WPUi,j,p ≥ WPCi,j,p

di,j

(3.8)

This inequation ensures that WPUi,j,p is always true if WPCi,j,p has a greater value than0. Note that, dividing the right side by the demand or another value large enough pre-vents the quotient on the right side from getting larger than 1. Once again, the classCplexCapacityBinaryVarConsistenceConstraint can guarantee consistence between bi-nary and capacity variables for working and protection variables.

The class hierarchy for the multipath extensions will be discussed in the next subsectiontogether with equal and free distribution of capacities.

3.5.2 Equal and Free Distribution of Capacities

Multipath extensions include that several resources are allowed to satisfy a demand or toprotect a working path. If there are no further restrictions, capacities could be distributedamong resources, where some resources carry the main part of the overall traffic, othersmaybe only a small portion of it. To prevent such a situation it would be desirable to forcea “resilient” routing solution in which capacities are equally distributed among the usedmultipath resource. The constraint CplexEqualDistributionConstraint does exactlythis.

Let WPCi,j,p1 and WPCi,j,p2 be variables indicating the used capacities on alternativeresources (here working paths from the same source node to the same target node). Thecorresponding binary variables are called WPUi,j,p1 and WPUi,j,p2, the demand between iand j is di,j. The following two inequations describe how equal distribution can be achievedfor WPCi,j,p1 and WPCi,j,p2:

WPCi,j,p1 −WPCi,j,p2 ≤ di,j (2−WPUi,j,p1 −WPUi,j,p2) (3.9)

WPCi,j,p1 −WPCi,j,p2 ≥ di,j (WPUi,j,p1 + WPUi,j,p2 − 2)

Of course, these two inequations seem to be rather complicated and incomprehensible atthe beginning, but in order to avoid non-linear expressions it could not be done withoutsuch a tricky approach. By trial and error, it becomes clear that WPCi,j,p1 must equalWPCi,j,p2 if both resource p1 and p2 are actually used.

Equal and Free Distribution forms together with the different multipath variants the frame-work for all resilience strategies. In implementation this is reflected by the fact that all


concrete resilience classes are derived from so-called abstract CplexResilienceModules.These modules have principally two tasks:

• Creating all CPLEX variables which are needed for a multipath and Equal/FreeDistribution variant. Some multipath variants do not require the complete set ofCPLEX variables (e. g. no binary variables for the working paths necessary). There-fore each abstract class which constitutes a CplexResilienceModule only generatesthe needed CPLEX variables.

• Creating all constraints that are necessary for the chosen multipath and equal distri-bution variants, and adding them to a list of constraints which will be supplementedby the concrete subclass.

The immensely large number of possible combinations for multipath and equal distributionvariants results in the class diagram of Figure 3.8:

ConstraintCollection

CplexResilienceStrategy

DedicatedMultiMultiFreeDistFreeDist DedicatedSingleSingleDedicatedSingleMultiFreeDistDedicatedMultiSingleFreeDist

DedicatedMultiMultiFreeDistDefault

DedicatedMultiMultiDefaultFreeDist

DedicatedMultiMultiDefaultDefault

DedicatedMultiSingleDefault DedicatedSingleMultiDefault

Figure 3.8: Overview of all dedicated Resilience Modules

In this context it is worth mentioning that it is the class CplexResilienceStrategy whichselects and creates all relevant ProtectionKeys (c.f. 3.3.2) from all principally possibleProtectionKeys (e. g. generating all PathPairs with the Haskin paths as protection re-sources for the working paths).

One further aspect remains to discuss. Protection capacities are dedicated in thecase of 1:N Protection or shared in all other resilience strategies. Therefore, for eachCplexResilienceModule named with Dedicated there exists also a module named withShared which contains additional CPLEX variables for the shared protection capacitieson all edges. All shared CplexResilienceModules are derived from two base classes:CplexSharedCapacityVariable (containing the additional CPLEX variables) and the cor-responding dedicated CplexResilienceModule. As an example, Figure 3.9 depicts theinheritance for the “SingleSingle” multipath variant:


DedicatedSingleSingle

SharedSingleSingle

CplexSharedCapacityVariable

Figure 3.9: Dedicated and Shared CPLEX Resilience Modules

3.5.3 Supported Resilience Strategies

The software supports the following resilience methods (for closer information, see chapter2):

• 1+1 Protection and 1:N Protection

• Haskin Protection

• Link Protection

• Regional Protection

• Local-To-Egress Protection

• Rerouting with and without Stub-Release

Each of these resilience concepts can be arbitrarily combined with a multipath andequal/free distribution variant.

As the CplexResilienceModules already compile the list of the constraints andgenerate the needed CPLEX variables, each concrete resilience class must onlycreate the extra-needed constraints with the correct template parameters (e. g.CplexLocalWorkingPathsAreProtectedConstraint) and inherit the rest from aCplexResilienceModules. Most of the constraints which are not part of theCplexResilienceModule were described in 3.4.2.

Exemplarily, Figure 3.10 shows the complete inheritance path for the classOneToOneHaskinSingleSingle5 which is responsible for 1:N or Haskin Protection. It isderived from SharedSingleSingle and therefore only uses one working path to satisfy ademand and only one protection path to protect a working path.

5Please note: OneToOne* classes implement 1:N protection, that can also be called 1:1 shared protec-tion. Normal 1:1 protection is equivalent to 1+1 in terms of capacity usage and is implemented in theOnePlusOne* classes.


ConstraintCollection

CplexResilienceStrategy

DedicatedSingleSingle

SharedSingleSingle

OneToOneHaskinSingleSingle

Figure 3.10: Derivation Tree for OneToOneHaskinSingleSingle

3.5.4 Support of different Optimization Targets

Maybe that there are different aspects that should be optimized in a given network. There-fore the software permits to choose from one of the following target functions T (ECe

represents the working capacity on edge e, WCe the working capacity, aECe the maximumallowed capacity on edge e, and E the set of all edges in the network):

1. CplexMinTotalCapacityCalculator: The total edge capacities are minimized.

T = min∑e∈E

ECe (3.10)

2. CplexMinWorkingCapacityCalculator: The used working capacities are minimized.

T = min∑e∈E

WCe (3.11)

3. CplexMinUtilisationRatioCalculator: Minimize the maximum ratio “working ca-pacity on an edge : allowed capacity on an edge”.

T = min

(maxe∈E

WCe

aECe

)(3.12)

The method addTargetFunction() in CplexNetworkCalculator is kept abstract and im-plemented in a subclass according to one of the just mentioned possibilities (see Figure3.11).


+addTargetFunction()

CplexNetworkCalculator


CplexMinTotalCapacityCalculator


CplexMinWorkingCapacityCalculator


CplexMinUtilisationRatioCalculator

Figure 3.11: The Network Calculators

3.5.5 Flexible Application of different Resilience Strategies toone Physical Network

It is possible to apply different resilience concepts to different parts of a network. Moreprecisely that means, that one can use a separate resilience strategy for each single demandgraph if the whole demand for one physical network is split into several parts. Thus itcan be examined whether a mixture of resilience concepts has advantages in bandwidthconsumption.

If such a “multi-demand” method is used for a network, the CPLEX variables and expres-sions for the used edge capacities constitute the connecting link between the single resiliencestrategies. In principle, a class is instantiated for each resilience method, whereby eachresilience class provides a method which returns a CPLEX expression for the total usededge capacity and the working capacity on an edge caused by its protection mechanisms.Actually, these methods are made available by the CplexResilienceModules. It is thetask of CplexNetworkCalculator to add up all the used edge capacities of the resiliencestrategies and to limit the maximum used capacity on this physical edge.

Finally, it is pointed out, that nonetheless, there can exist only one network calculator andone target function for the given physical network.

3.6 Implementation of the Output Classes

After everything has worked out so well and the optimal results haven been calculated,it is still necessary to transfer the solver results in the output structures described in3.2. There is an extra class hierarchy which is responsible for the output and the set-ting of the relations (see Figure 3.12). The central method is createResultGraphs()

which creates a new Working and Protection Graph and sets the relations due to thecomputed results and according to the criteria described in 3.2. Each concrete instance


Output

+createResultGraphs()

CplexOutput

OneToOneHaskinOutput LocalOutput RerouteOutputRingOutput

Figure 3.12: The Output Class Hierarchy

of a Output class is created in the constructor of the correspondent resilience class (e. g.OneToOneHaskinSingleSingle instantiates a OneToOneHaskinOutput class).

As different resilience strategies use different ProtectionKeys (PathPair,PathPairForErrorEdge), there is a concrete subclass of CplexOutput for each re-silience strategy. In order to keep large parts of the output implementation neverthelessindependent from the used multipath variants, CplexOutput is realized as a templateclass and implements the abstract class Output. Fur further details about how relationsare set, please see 3.2.

Chapter 4

User Instruction

4.1 Use from the command-line

Our software has a rich choice of command line arguments that can be passed to it whenstarted. A summary of these options is given in table 4.1.

The basic principle is, that multiple demands can be specified by using the –demand optionmultiple times. For each demand another resilience strategy can be selected by prefixingthe demand option with the selection options. By default the following options are selected:

• --strategy-1toN: use the one to N protection scheme

• --arbitrary-workingpaths: use an arbitrary number of working paths per demand

• --free-working: use free distribution of traffic on the working paths

• --arbitrary-protectionpaths: use an arbitrary number of protection paths perworking path

• --free-protection: use free distribution of traffic on the protection paths

• --target-mintotal: minimize total used capacity

If two demands have to be routed on a single physical network, the first one with 1:1protection and single-paths and the second with link protection and two multi-paths andequal distribution the following command can be used:

./multipath-routing -N phys.gml -t1O -D demand1.gml -l2TeE -D demand2.gml

To get some nicer and more verbatim output, it is suggested always to use the commandline options -cv.

39

CHAPTER 4. USER INSTRUCTION 40

short long description

input file options-N –network=file GML file that contains the physical network-D –demand=file GML file that contains a demand on the

physical network, multiple demands can bespecified, the resilience scheme is selected byoptions in front of this

selection of the resilience strategy for following demands-p –strategy-1plus1 one plus one protection-t –strategy-1toN one to n protection-h –strategy-haskin haskin protection-l –strategy-link link protection-r –strategy-regional regional protection-g –strategy-local local to egress protection-i –strategy-ring ring protection-y –strategy-pcycles p-cycle protection-S –strategy-nostubrelease rerouting without stub-release-s –strategy-stubrelease rerouting with stub-releasemulti-path options for the following demands-1 –one-workingpath one working path (per demand)-2 –two-workingpaths two working paths-3 –three-workingpaths three working paths-a –arbitrary-workingpaths arbitrary number of paths-O –one-protectionpath one protection path (per working path)-T –two-protectionpaths two protection paths-H –three-protectionpaths three protection paths-A –arbitrary-protectionpaths arbitrary number of paths-e –equal-working equal distribution for working paths-f –free-working free distribution for working paths-E –equal-protection equal distribution for protection paths-F –free-protection free distribution for protection pathstarget selection (used for all demands)-C –target-mintotal minimize total used capacity-W –target-minworking minimize total working capacity-U –target-utilisation minimize max utilisation ratiopath reduction-m –maxpaths=number limit the number of used paths per node pair-L –maxlength=length limit the maximum length of pathsmiscellaneous options-n –nice=nice increase the nice of the program-c –color enable some colors-v –verbose write some statistics to the console-? –help show help message

–usage display brief usage message

Table 4.1: Command line arguments of the software package

CHAPTER 4. USER INSTRUCTION 41

4.2 Direct call from another program

As an example on how to use our “network routing calculator” in other software one shouldhave a look at our implementation of the command line application. This small tool isimplemented in the files Commandline.cpp and Process.cpp.

Two functions have to be implemented to embed the calculator in other software:

void multipath::statusUpdateDomain(std::string);void multipath::statusUpdateProcess(long int, long int);

The first function is called by the calculator every time it changes the processing domain.With the argument to this function it is passing which domain has been entered. Thesecond function is called by the calculator, if it wants to inform about the process of atask, that takes some time to complete. The first parameter to this function specifies howmany steps have been completed, the second parameter specifies how many steps have tobe done in total.

If the implementor of the software, that uses our calculator is not interested in getting theinformation, he can just implement these functions to return immediately to the caller.

What is left to be done by the user is to create the instances of the physical networkand at least one demand, create an instance of the calculator (RoutingWithResilience),pass the graphs to this instance, tell what resilience scheme should be used and start thecalculation.

How this can be implemented in ten lines of code is demonstrated in the file Example.cpp,that also contains many comments in the code and does not need any code to handle thecommand line like Commandline.cpp. Example.cpp can be found in appendix B.

The physical network is created by calling ReadOne(...) and ReadTwo(...) on an in-stance of PhysicalNetwork. Exactly the same has to be done for the DemandGraph.

When the RoutingWithResilience instance is created, the PhysicalNetwork and theselected target function is passed to it.

The demands are added to the calculator by individual calls of the methodcombineDemandWithResilience(...). The first parameter is the instance of the demandgraph, that should be added, the other parameters define the protection scheme, thatshould be used.

If all demands have been added the calculation is started by a call to eithercreateResultsFiles() or getResultGraphs(). If the first one is called, the results of thecalculation are written to GML files in the working directory. If the second one is called,instances of the working and protection graphs are returned.

Chapter 5

Problems and Difficulties during theProject

5.1 Memory Consumption

When we started to implement our calculator, we already expected, that we would have totake care about memory usage. Therefore we tried to implement everything with as littlememory needed as possible. We created three sample networks, that were used to test ourimplementation. To ease debugging we created the networks to be calculable very fast:they contained only a few nodes, that were not very intermeshed.

After we had fixed most of the bugs we got some bigger sample networks. Some statisticsabout the networks have been put in table 5.1. We soon noticed, that we were not ableto handle these sample networks. Even with COST—the smallest network—we did notmanage to create all the expressions, that we wanted CPLEX to solve.

Our code has been checked again not to contain memory leaks and not to allocate memory,that is not needed. At the same time we added functions to our software, that told us howmany instances of different entities we had. Very soon it became clear, that the problemwith all the calculations was, that there were too many available paths between a given pairof nodes which all could be used to route a given demand. E.g. for the COST network wecould use between 923 and 1,760 possible paths for each demand we placed in the network.Given the 110 possible combinations of nodes in this network there are a total of 140,040possible paths in this network. For the COST network we were able to keep all the possiblepaths in the memory.

The next step in the calculation is to generate a list of the pairs of disjoint paths betweenthe same nodes. In some form this list is needed in any resilience scheme as we have to findsome sort of disjoint protection paths for our working paths. We have to calculate thesepairs and keep them in memory as we have to tell our CPLEX solver all possible paths it

42

CHAPTER 5. PROBLEMS AND DIFFICULTIES DURING THE PROJECT 43

network #nodes #edges #edges/node #paths / de-mand

#disj. pathpairs / demand

own 1 4 5 1.25 3 6own 2 8 11 1.38 3 6own 3 5 16 3.20 9 36COST 11 52 4.73 923 to 1760 ∼ 250,000 to

500,000Labnet03 20 106 5.30 ∼ 0.4 to 1.5 mio. ∼ 2 · 1011*GS40 40 154 3.85 ∼ 500 to 100,000 ∼ 500 mio.*GT40 40 344 8.60 ∼ 5 · 1018* ∼ 6 · 1036*GS80 80 314 3.93 ∼ 1.5 · 109* ∼ 6 · 1017*GT80 80 886 11.08 ∼ 1.5 · 1030* ∼ 6 · 1059*

* estimated values

Table 5.1: Comparison of the sizes of our example networks

can use as variables.1

In the COST network there are about 250,000 to 500,000 possible path pairs for eachdemand. Each instance of a path pair has a size of 12 B2 without the entities it references.The COST network contains 110 demands.3 Given these numbers we need at least about375000 · 12 · 110 B ≈ 472 MiB of memory just for all instances of path pairs.

Together with the paths we already calculated and all referenced data, that has beenallocated, we are not able to generate all PathPairs and keep them in memory.

Given the bigger Labnet03, we did some additional calculation on the size, that is neededto keep a path in memory. The size of the pure instance of Path is 20 B, but more memoryis needed as it contains a list, that dynamically allocates memory to reference the edges,the path consists of. Including this dynamic allocation, each instance of Path had about630 B memory usage.

There are 380 pairs of nodes in the Labnet03 network, each pair has between 400,000 and1,500,000 possible paths. To keep all these paths in memory we would need 380·950000·640B ≈ 211.8 GiB of memory.4 Therefore for the Labnet03 and all following networks we werenot even able to calculate all possible paths.

We expect5, that we would get about 2 · 1011 disjoint path pairs for each demand inLabnet03. This would result in at least 90 · 2 · 1011 · 12 B ≈ 2 · 1014 B ≈ two hundred

1For more information on how CPLEX is used see 3.42B = byte, KiB = kilobyte, MiB = megabyte, GiB = gigabyte3Actually it contains 220 demands, but there are always two demands that have the same source and

target. To save memory these two demands can be summed and calculated as one demand.4On a 32 bit hardware architecture each process can get at most 4 GiB of memory.5assuming that about 25% of the paths are disjoint, we estimate this number as 0.25 · paths2


thousand GiB memory usage to keep the PathPairs.

5.1.1 Decreasing the number of paths

To get the problem closer to a dimension where it can be solved, the number of paths hasto be decreased. If there are less paths, we can narrow the solution space. The problemwith this is, that we do not get the best possible solution as long as not all paths, that areneeded by this solution, are in the set of paths, that we have selected. Therefore we haveto find a good way to select the set of paths, that are used for the calculation.

Another possible idea is to place only one demand in the network and calculate a routingfor this demand. After this routing has been found, the available capacity of the links inthe network is decreased by the capacity the routing for this demand needs. Afterwardsthe modified network can be used to find a routing for the second demand. This ideadoes not result in the ideal solution for the routing either as routing for already placeddemands can not be changed, if that would result in less total bandwidth usage. Our testsindicated, that without a limitation on the number of paths, we were not even able to placeone demand in the network.

Decreasing by limiting the length of paths

The first way to decrease the number of paths we implemented was, that we limited themaximum length of paths, that we used for our calculations, to a value, that can be selectedby the user.

The problem with this approach is, that if the network gets bigger, it can be assumed,that for some node pairs long paths are needed while for other node pairs small paths arepossible.

Decreasing by limiting the number of paths

To fix this problem we implemented, that the number of paths can be decreased by spec-ifying the maximum number of paths between two nodes, that should be used. For eachnode pair the number of paths is then limited individually and the shortest possible pathsbetween these nodes are used.

A problem with both approaches is, that we prefer the shortest possible paths. This resultsin preferring routes, that go through the center of the network. If the network is operatednear its capacity limits, a routing often cannot be found as for all links in the center of thenetwork all capacity is used and no additional demands can be placed while there are stilllonger paths available, that have free capacity.


Other heuristics to decrease the number of paths

For fixing this problem, it could be considered to select the paths randomly and repeat theselection and calculation multiple times. Afterwards the best found solution is used.

We expect, that if we select random paths, it does not make very much sense to search foran exact solution within these random paths. It could be faster to just insert the demandsand their protection capacity into the network with randomized heuristics multiple timesand compare the results.

An additional idea to deterministically limiting the number of paths but find routingsoutside of the center of the network is, that we modify the definition of the length of apath by not only counting the number of hops but introducing higher link costs for centerlinks. Paths can then be selected based on their total cost. The cost of a link could bedefined as the number of possible paths, that would use this link.

Outcomes of the limitations

Having implemented the limitations for the number of paths, we could calculate the COSTnetwork with our software. The maximum of memory we could use for solving was 2 GiB,even we had more memory installed in the computer system we were using. This is alimitation of the Linux address space on 32 bit architectures. With 32 bit only 4 GiB canbe addressed, 1 GiB is reserved for the Linux kernel and another 1 GiB block is reservedfor shared objects, leaving 2 GiB usable for the code and data of a process.

Our tests at the COST network advise that limiting the number of paths does not decreasethe quality of our results. Table 6.1 demonstrates, that using more than 50 paths did notchange the results. Depending on the resilience strategy we used, we could calculate resultswith up to about 100 considered paths per node pair.

5.2 Problems with Minimizing the Maximum Used

Edge Capacity

In 3.5.4 we described that the implementation design takes into consideration the use ofdifferent target functions. Besides the minimization of the working capacities and the totalused capacities, it is sometimes also desirable to optimize the maximum utilization ratioof edges.

Unfortunately, the implementation of CplexMinUtilisationRatioCalculator causedproblems. Optimizing the maximum utilization ratio of an edge, actually means thatthe target function has to minimize the maximum of a set of variables or solver expres-sions, respectively. In the mathematical notation of 3.5.4, this problem was formulated in


the following way (refer to 3.5.4 for nomenclature of the variables in the equation).

T = min

(maxe∈E

WCe

aECe

)(5.1)

As CPLEX Concert offers a function IloMax(IloNumVarArray array) which returns fromthe passed IloNumVarArray the maximum of all array variables , we first hoped that thisfunction would do it. But CPLEX always interrupted the calculation with the message“Aborted”, which did not constitute a very helpful information.

After a long error search, we finally had another idea how to realize this target function.The principle is depicted by the following simplified code excerpt.

// create a new CPLEX variableIloNumVar maximum(cplexEnvironment);// go through all edgesfor (edgeIter=allEdges.begin(); edgeIter!=allEdges.end(); ++edgeIter) {

// new constraint: maximum is greater than utilization ratio of actual edgemodel.add( maximum >= (1/allowedEdgeCapacity) * workingCapacityOnEdge );

}// now just minimize the variable maximummodel.add( IloMinimize(cplexEnvironment, maximum) );

So the main idea is to introduce a new variable (maximum) and to set up a constraint foreach edge which ensures that maximum is greater than the utilization ratio of each edge.Just minimize this variable, and the problem is solved!

Chapter 6

Results

After addressing the theoretical foundations of different resilience strategies and the imple-mentation aspects of the software and the constraint modelling, it is time to investigate thedifferent resilience approaches in terms of their bandwidth consumption. Due to the richchoice of available multipath extensions and resilience concepts in the software, emphasiswill be placed on representative tests which clearly demonstrate the effects of a certainsoftware feature.

For our tests we take two sample networks:

• COST 239 Network (see Figure 6.1): COST 239 is a highly meshed networkwith 11 nodes and 52 directed links (forming 26 bidirectional links). It contains 220demands. As there are always two demands for the same source and target node,we always sum up two such demands demands thus receiving 110 demands in thenetwork.

• WMW Network: This is a sample network created by our own with the advantagethat is relatively small thus enabling the comparison of all possible resilience strate-gies without using path limitation. It has the structure of a 3 × 3 matrix, where allneighbor nodes within a row or a column are connected by a link with a capacity of100 Gib/s in each direction. The demand graph includes demands for all possiblenode pairs.

6.1 Effects of Path Limitation

Due to memory shortage (see 5.1), it is sometimes not possible to calculate an optimal“resilient” routing by taking into account all paths of the COST network. Table 6.1 showsthe computed minimum bandwidth consumption in the COST 239 Network depending onthe considered number of shortest paths per node pair.

47

CHAPTER 6. RESULTS 48

number of paths pernode pair

total used capacity time needed for calculation

10 1649.12 < 1 min20 1621.15 13 min30 1613.40 47 min40 1612.85 1h 24 min50 1612.65 3h 2min60 1612.65 4h 1min70 1612.65 7h 1min80 1612.6590 1612.65100 1612.65105 1612.65

Table 6.1: Influence of path limitation on the computed bandwidth consumption (1:Nprotection, arbitrary number of working and protection paths)

It is striking that we do not receive any improvement in the minimum bandwidth con-sumption if we consider more than the 50 shortest paths between a node pair. Therefore itseems that taking into account only the shortest paths between a source and a target nodeconstitutes a reasonable approach to cope with the memory shortage problem. Figure 6.2suggests, that there can be networks where all paths have to be considered. In the exampleof Figure 6.2 only the longest path is disjoint to the other paths. Nonetheless, we do notexpect such a case in average networks.

6.2 Comparison of the Resilience Strategies in terms

of Bandwidth Consumption

In order to receive significant results about the bandwidth consumptions of the differentresilience approaches, it makes sense to calculate the total used capacity of each resiliencestrategy with the same multipath extensions and the same number of considered pathsbetween two nodes.

6.2.1 Case Studies for the COST 239 Network

The results for the COST 239 Network are depicted in table 6.2.

For 1+1 protection and Haskin there was no solution. For 1+1 protection it is apparentlytrue, that no solution can exist in the COST 239 network. COST 239 has a total capacityof 1910.976 Gib/s and we were placing demands with a total capacity of 870 Gib/s. As


London

Berlin

Vienna

Milan

ZurichParis

BrusselsLuxembourg

Amsterdam

Prague

Copenhagen

Figure 6.1: COST 239 Network

A B

Figure 6.2: Constructed network where the longest path is needed to find a solution forprotecting traffic from A to B. Limiting the number of considered paths will result in nofound solution.


Number of Number of Used TotalResilience Strategy Workings Protection Working Used

Paths Resources Capacity Capacity1+1 Protection no solution exists1:N Protection 136 613 1279.39 1612.65Haskin no solution existsLink Protection 133 597 1272.97 1743.67Local-To-Egress Protection 138 651 1270.27 1719.64Regional Protection* 133 764 1279.39 1612.65Rerouting with Stub Release 136 808 1279.39 1612.65Rerouting without Stub Release 139 850 1279.39 1612.65

* calculated with only 50 paths per node pair

Table 6.2: COST 239: Comparison of the resilience strategies in terms of their bandwidthconsumption and of the number of considered Paths (75 paths per node pair, arbitrarynumber of working and protection paths)

COST 239 has no redundant links between two nodes, we always need at least three linksto satisfy one demand: One of the two paths needs at least one link. As the secondpath cannot use the same link, it has to pass an other node, needing at least two links.3 · 870 = 2610 > 1910.976, meaning that it is not possible, that there is a solution for 1+1protection.

For Haskin it is not so easy to show that there really is no solution. Using the COSTnetwork with 100 Gib/s links (see 6.2.2), we obtain a solution. But this solution cannotbe applied in non-modified COST 239 as on some links there would be more traffic thanallowed edge capacity.

Comparing all possible schemes, we obtained the least used capacity for 1:N, regionalprotection and rerouting with and without stub release. It is clear that regional protectionnever could need more capacity than 1:N protection as long as we do not fix the regions,that have to be used. Therefore regional protection is always able to use the same routingas 1:N by forming only one big region.

1:N and rerouting without stub release show no difference in the calculated routing, butrerouting time must be considered needed for the calculation of a replacement path. There-fore it is not very surprising, that we obtained the same results. For rerouting with stubrelease it would be possible to get a result with less used capacity and we described anetwork with this case in 2.11. But for highly meshed networks, there seems to be no ad-vantage in using stub release, as each link of a working path must have a possible reroutepath. Normally the links in these rerouted paths can be taken to construct a completelydisjoint path from the source node to the target node, then being a valid routing for an1:N protection path as well.


If we compare 1+1 protection and 1:N protection, we see that 1+1 protection always needsmore or at least the same capacity, as a routing for 1+1 protection is always a valid routingfur 1:N protection as well. 1+1 protection and 1:1 protection are the same only differingwhether the protection path is used permanently or not.

At the example of the COST 239 network, we observe that link protection needs morenetwork capacities than 1:N protection. Link protection could never need less capacitythan 1:N protection, because it is possible to construct a valid 1:N routing out of the linksused for link protection:

• Concatenate all protection paths (“link bypasses”) in the order of the links theyprotect.

• If a link is used twice in this path, the nodes at the ends of this link are passed twice.Therefore a loop exists in the concatenated path. This loop can be removed.

Every link in this constructed path is used only once and every link, that is used, iscontained in one of the protection paths of the link protection as well. Therefore theconstructed path uses the same or less capacity on each link and it is therefore possible touse this path in the network.

To be a valid protection path, it is necessary, that the constructed path is disjoint to theworking path. The constructed path will be disjoint, because if it would contain one ofthe working edges, it would pass both end nodes of this link. As it is constructed outof protection paths and this link is one of the links that has an own protection path, wewould have passed both end nodes of this link twice. Therefore this link would have beenpart of a protection path loop and would have been removed in the second step of theconstruction.

Local to egress uses less capacity than link protection. It is clear, that local to egress couldnever need more capacity than link protection as link protection routing is always a validlocal to egress routing.

6.2.2 Case Studies for the COST 239 Network with 100 Gib/slinks

The results for the COST 239 Network with 100 Gib/s links are depicted in table 6.3.

If we enhance the capacity in the COST network to 100 Gib/s for each link we can findvalid solutions for 1+1 protection and haskin protection, that were not possible in theCOST 239 network in 6.2.1. For the other protection schemes we get results, that needless capacity than the results in 6.2.1. This is possible as additional protection paths can betaken in the COST 100 Gib/s network, that are not possible for links in the non-modifiedCOST network if no sufficient capacities are left to carry these protection paths.



Paths Resources Capacity Capacity1+1 Protection* 110 116 1535.00 3142.501:N Protection 136 455 1277.46 1582.93Haskin* 128 492 1267.50 1773.44Link Protection 129 646 1272.50 1692.25Local-To-Egress Protection 123 565 1272.50 1679.78Regional Protection 134 643 1277.69 1582.92Rerouting with Stub Release 137 668 1277.69 1582.92Rerouting without Stub Release 140 687 1277.69 1582.92

* calculated with 75 paths per node pair

Table 6.3: COST 239: Comparison of the Resilience Strategies in terms of their BandwidthConsumption and of the Number of used Paths (50 paths per node pair, arbitrary numberof working and protection paths

For all resilience strategies it was possible to find better routings in the COST 100 Gib/snetwork. The reason for this fact lies in the first COST network which possesses onlysmall capacity reserves. Therefore additional capacities result in much more routing flex-ibility and in noticeable improvements in terms of bandwidth consumption. If capacitieswere added to a network, which already has a huge amount of free capacities, an expan-sion of network resources would not necessarily lead to a further reduction in bandwidthconsumption. In the COST network the benefit is between 1,8% and 2,9%.

In 6.2.1 we have already shown that we always need more or the same capacity for 1+1 asfor 1:N. Haskin will also always need at least the same capacity as 1:N protection. This isbecause the second part of the haskin path, starting at the source node of the protectedworking path, can always be used as a protection path for 1:N protection. If at leastone working path is longer than one link, at least this protection path is shorter for 1:Nprotection than for haskin, therefore if at least one working path is longer than one link,1:N protection will need really less capacity than haskin.

6.2.3 Case Studies for the WMW Network

The results for the WMW Network are shown in table 6.4.

The crucial advantage of this network is, that we obtain solutions for 1+1 protection andhaskin. For both we did not get results in 6.2.1. In exchange, we receive no solutions forlink protection and local to egress in the WMW network. This is a counter-example todemonstrate, that it is not possible to transform either the solution of link protection orlocal to egress protection to a result for haskin or 1+1 protection and vice versa.



Paths Resources Capacity Capacity1+1 Protection 72 72 783.62 1466.961:N Protection 90 129 564.74 867.76Haskin 79 89 564.74 1009.96Link Protection no solution existsLocal-To-Egress Protection no solution existsRegional Protection 95 307 564.74 867.76Rerouting with Stub Release 94 272 564.74 867.76Rerouting without Stub Release 94 284 564.74 867.76

Table 6.4: WMW Network: Comparison of the resilience strategies in terms of their band-width consumption and of the number of considered paths (arbitrary number of workingand protection paths, no path number limitation)

For the other resilience schemes we get the relations for the bandwidth usage, as we ex-pected and discussed them already. The relations are also shown in table 6.5. We also getresults for the ring protection and p-cycle protection scheme. In the COST network wecould not keep all needed constraints in the memory of our computer and therefore couldnot present a result.

In the case of the WMW network we need more capacity for ring protection than for p-cycleprotection. This is not very surprising: Every ring protection routing is a valid p-cycleprotection without straddlings. Therefore, allowing straddling links can only decrease theneeded capacity but never increase it.

1+1 = 1:1 ≥haskin prot. ≥

link protection ≥1:N = reroute without stub rel.

≥ regional protection≥ reroute with stub rel.

link protection ≥ local to egress protection

ring protection ≥ p-cycle protection

Table 6.5: Comparison of the bandwidth consumption of different resilience strategies

6.3 Influence of Multipath Extensions on Bandwidth

Consumption

It can be speculated that using several working paths to satisfy a demand or severalprotection resources to protect one working path, reduces the required total bandwidth. Toconfirm this assumption, different multipath extensions were combined with 1:N Protection


and applied to a modified COST 239 Network where each edge in the physical network hasa capacity of 200 Gib/s. In this way, we get a solution even if we allow only one workingpath to satisfy a demand. The results are shown by table 6.6.

Allowed Number Number of Number of Used Totalof Working Workings Protection Working Used

Paths Paths Resources Capacity Capacityarbitrary 137 492 1276.85 1586.29

3 137 492 1276.85 1586.292 134 483 1276.85 1586.291 110 327 1272.50 1604.92

Table 6.6: Comparison of the Multipath Extensions in terms of their Bandwidth Consump-tion (40 shortest paths per node pair, 1:N Protection)

No matter whether we allow an arbitrary number of working paths for one demand orwhether we restrict the number of working paths to 2 or 3 paths, we always get the sameresults for the required total capacities. But if we permit only one working path perdemand, bandwidth consumption is relatively high compared with the multipath cases. Ofcourse, the network topology of COST 239 (highly meshed) could be a possible reasons forthis behavior. Nonetheless it can be concluded that multipath extensions normally leadto a considerable reduction in bandwidth consumption as they allow to split the requiredcapacity, needed to satisfy a demand, into a series of smaller ones which are routed ondifferent paths. Thus available resources can be utilized more effectively and distributioncan be done in a more granular way.

Not surprising is the fact, that the number of used working resources decreases if we restrictthe number of working paths per demand.

Multipath with an arbitrary number of working paths or protection resources has thedisadvantage that traffic may be distributed very unequally on the used resources. To avoidthis problem, the solver can be forced to distribute traffic equally on alternative resources.How this affects the bandwidth consumption can be seen in table 6.7. The results indicate

Allowed Number Total Capacity Total Capacity Usedof Working Paths (Free Distribution) (Equal Distribution)arbitrary 1586.29 1588.443 1586.29 1588.472 1586.29 1588.521 1604.92 -

Table 6.7: Comparison of Equal and Free Distribution in terms of their Bandwidth Con-sumption (40 shortest paths per node pair, 1:N Protection)

that we need more bandwidth if we want working capacities to be distributed equally


among the alternative working paths between a source and a target node. This behavioris obvious, as equal distribution simply constitutes an additional restriction compared tofree and arbitrary distribution. From this point of view, it is clear that equal distributioncannot require less capacities than free distribution.

6.4 Use of Different Target Functions

In addition to the optimization of the total used capacity, the software allows to minimizethe working capacities or the maximum edge utilization ratio. Table 6.8 demonstrates theeffects of the possible target functions if 1:N Protection is used.

Total Used Maximum Edge Average EdgeOptimization Target Used Working Utilization Utilization

Capacity Capacity Ratio RatioTotal Capacities 1612.65 1279.39 99.52% 69.41%

Working Capacities 1623.86 1267.50 94.34% 67.55%Max. Edge Utilization Ratio 1682.83 1315.62 70.00% 69.03%

Table 6.8: Effect of the Target Function on the Results (COST 239 Network, 60 paths pernode pair, 1:N Protection without any multipath extensions)

The results may not seem very surprising. Concerning the used capacities the results tonot differ extremely. Here the optimization of the maximum edge utilization ratio has theworst results.

If the total used capacities or the used working capacities are optimized, the maximumedge utilization ratio amounts to 99.52% and 94.34% meaning that there exists an edgewithin the network of which almost the complete available capacity is utilized. By usingthe target function which minimizes the maximum edge utilization ration, one can achievea far better maximum ratio of 70.00%. Therefore it could make sense to use that targetfunction instead of the optimization of total capacities or of working capacities, as eachedge still keeps a certain capacity reserve.

In the end, it is also striking that the average of the edge utilization ratio is relativelyindependent of the used target function, always accounting for about 68%.

6.5 Conclusions - Summary

In the following we want to give a short summary of the most important conclusions whichcan be drawn from the results. For closer details, the preceding sections should be referredto.


• Due to memory shortage we sometimes cannot consider all paths between a sourcenode and a target node for the calculation of an optimal “resilient” routing. However,it was shown in 6.1 that selecting only the shortest paths from all possible paths foreach node pair, constitutes a good heuristic to cope with memory problems.

• Within a given network, different resilience schemes normally differ in the amountof required bandwidth. Concerning bandwidth consumptions some general conclu-sions could be drawn, for example that Link Protection and 1:N protection usuallyrequire more capacities than 1:N Protection (for more details refer to Table 6.5).Nonetheless, it would be dangerous to judge resilience strategies simply by lookingat their bandwidth consumption. Other aspects, e. g. the setting up of the protec-tion resources, and failure times have always kept in mind, if one wants to comparedifferent resilience schemes with each other.

• In the case of multipath extensions the results are unambiguous. Allowing severalworking paths for each demand or several protection resources to protect one workingpath normally leads to a reduction in the required bandwidth. This result can beexplained by the fact that multipath extensions permit to distribute capacities in amore granular, capacity-saving way.

Chapter 7

Summary and Outlook

“New forms of communications are far from being perfect”. It was the task of this workto reflect on how actual networks can come closer to “perfect forms of communication”in terms of more “resilience”. Under “resilient” networks we understand networks whichare not vulnerable to link failures and which keep failure times as short as possible ifnevertheless an error should occur.

In the Introduction we mentioned MPLS/IP which offers traffic engineering methods andthe provisioning of alternate paths, thus enabling the technical realization of the conceptswhich could ensure more resilience in nowadays networks. The theoretical foundations ofsuch resilience concepts together with possible multipath extensions were then discussedin Chapter 2.

In the following Chapter 3 we talked about everything concerning the implementation ofthe resilience concepts. Emphasis was given to the implementational aspects which enablethe high modularity, i. e. the rich variety of different options which are provided by oursoftware. Multipath extensions, resilience concepts and different target functions can bearbitrarily combined to calculate an optimal “resilient” routing according to the personalwishes.

After showing how the software is used in Chapter 4, we addressed some of the problemswe had during our work (e. g. shortage of memory) and what we did to cope with thedifficulties (path limitation).

In the preceding Chapter 6 we presented our results. We found out that local resiliencestrategies such as Link Protection or Local-To-Egress Protection apparently need morebandwidth than the global approach represented by 1:N Protection. This is possibly dueto the fact that 1:N Protection offers a greater choice concerning the establishment ofprotection resources.

Furthermore, we got the same results for Rerouting with and without Stub-Release. Maybethe reason for this unexpected behavior lies in our highly meshed test networks.

57

CHAPTER 7. SUMMARY AND OUTLOOK 58

Finally, we were able to demonstrate that the use of multipath extensions leads to aconsiderable reduction of bandwidth consumptions.

Of course, there still remains a lot to do. More detailed tests on different sample networksare needed to make significant statements on how the resilience strategies and multipathextensions behave in terms of bandwidth consumption.

Currently a graphical front-end is being developed, which provides a breakdown of relatedgraphs. We hope that by using this front-end, our software will constitute a helpful toolfor the investigation of bandwidth consumption in “resilient” networks.

Appendix A

Sample GML file

The following file is a GML sample containing the complete graph K3, that is a graph withthree nodes, that are all connected with each other.

graph [id 1name "K3"label "K3"directed 0

node [id 1 ]

node [id 2 ]

node [id 3 ]

edge [id 12source 1target 2 ]

edge [id 13source 1target 3 ]

edge [id 23source 2target 3 ] ]

59

Appendix B

Example program using thecalculator

#include "multipath.h"

namespace multipath {// we don’t care what the calculator is doingvoid updateStatusDomain(std::string) {}void updateStatusProcess(long int, long int) {}

}

int main() {// get a GML parser instanceGRAPH::GmlIo parser;

// read in physical network and the demand graphmultipath::PhysicalNetwork physicalNetwork;multipath::DemandGraph demandGraph;

// ... the basic node and edge structurephysicalNetwork.ReadOne(&parser, "../graphs/Test/testGraph_physical.gml");demandGraph.ReadOne(&parser, "../graphs/Test/testGraph_demand.gml");

// ... the relationsphysicalNetwork.ReadTwo(&parser, "../graphs/Test/testGraph_physical.gml");demandGraph.ReadTwo(&parser, "../graphs/Test/testGraph_demand.gml");

// a "calculator"-instance is created. Two parameters are needed:// - the physical network for the optimization (there can only be one)// - the target function (there can also only be one: Here MINTOTALCAPACITYmultipath::RoutingWithResilience routingResilienceOptimator(&physicalNetwork,

60

APPENDIX B. EXAMPLE PROGRAM USING THE CALCULATOR 61

multipath::MINTOTALCAPACITY);

// the following step is needed for each demand graph (there can be several)routingResilienceOptimator.combineDemandWithResilience(demandGraph,

multipath::ONETOONEPROTECTION, multipath::ARBITRARYNUMBEROFPATHS,multipath::ARBITRARYNUMBEROFPATHS, false, false);

// we must tell the routingResilienceOptimator what resilience strategy// to use for a demand, ...// here: the DemandGraph "demandGraph" is supposed to be 1:N protected,// having an arbitrary number of working paths to satisfy a demand and a// arbitrary number of protection paths to protection one working path.// Traffic is distributed freely with no further restrictions among their// paths.

// after all DemandGraphs are added the solving process is started and all// output files for the different demand graphs are createdroutingResilienceOptimator.createResultFiles();

return 0;}

Appendix C

Constraint Modelling

It is the intention of this appendix to give an overview on the constraint modelling of thesoftware. Due to the high modularity of the software it does not make sense to deliver acomplete description of all constraints. Nonetheless, a representative selection will help tounderstand the overall constraint modelling.

C.1 Abbreviations

To keep everything transparent the variables and parameter abbreviations which are usedin the mathematical notations, are all taken from the following table C.1.

C.2 Multipath Extensions

Although the resilience strategies differ in their approaches to gain more resilience forsingle link failures, there is a lot which all resilience methods have in common. Espe-cially constraints dealing with multipath extensions and with equal and free distributionof capacities are generally used and therefore will be subject of this section.

• Some multipath extensions require the number of used alternative working and pro-tection resources not to exceed a certain limit limit. This can be achieved by thefollowing constraint (here for the working paths).

∑p∈Ws,t

WPUs,t,p ≤ limit ∀ s, t ∈ N : s 6= t (C.1)

• There are some multipath extensions which need in addition to a boolean variableWPU or PPU also a variable WPC or PPC for the capacities on a resource. In such

62

APPENDIX C. CONSTRAINT MODELLING 63

a case it must be ensured that the boolean variable is always true, if the correspondingcapacity variable has a value greater than 0. This consistence can be achieved by thefollowing constraint (exemplarily shown for the working paths).

WPUs,t,p ≥WPCs,t,p

ds,t

∀ s, t ∈ N : s 6= t, p ∈ Ws,t (C.2)

• If multipath extensions are used, there can exist several working paths to meet ademand and several protection resources to protect a working path. For each re-silience strategy, the working capacities to satisfy a certain demand can be equallyor freely distributed among the used alternative working paths. The same it is withthe protection paths.

Whereas free distribution does not require any further constraints, equal distributionfor the working and protection resources must be ensured by a constraint (see C.3for the working paths). To keep everything linear, we take two inequations whichguarantee that the capacities must be equal if alternative working paths p1 and p2are used for the the same demand:

WPCs,t,p1 −WPCs,t,p2 ≤ ds,t(2−WPUs,t,p1 −WPUs,t,p2)

WPCs,t,p1 −WPCs,t,p2 ≥ ds,t(WPUs,t,p1 + WPUs,t,p2 − 2) (C.3)

∀ s, t ∈ N : s 6= t, p1, p2 ∈ Ws,t : p1 6= p2

C.3 Resilience Concepts

It is the task of this section to show the modelling of the different resilience concepts atthe example of “Single-Single”, where no multipath extensions are used at all. Theimplementation of all available target functions Z was already described in 3.5.4 and willnot be explained in this appendix (in all models the sum of required edge capacities isminimized).

C.3.1 1+1 Protection

Z = min∑

ei,j∈E

ECi,j (C.4)

The maximum allowed capacity must not be exceeded.

ECi,j ≤ ci,j ∀ei,j ∈ E (C.5)

There is exactly one working path for each demand.∑

p∈Ws,t

WPUs,t,p = 1 ∀s, t ∈ N : s 6= t (C.6)


Each working path is protected by exactly one protection path.

WPUs,t,wp =∑

pp∈Ws,t1

PPUs,t,wp,pp ∀s, t ∈ N : s 6= t, wp ∈ Ws,t (C.7)

The total capacity of an edge consists of the protection capacities and the working capac-ities on this edge:

ECi,j =∑

pp,wp2

(PPUs,t,wp,pp · ds,t) +∑

p3

(WPUs,t,p · ds,t) ∀ei,j ∈ E (C.8)

C.3.2 1:N and Haskin Protection

1:N and Haskin Protection can be summarized in the same model, as they only differ inthe calculation of the protection paths:

• 1:N Protection: Working and protection path must have the same start and end nodeand must be disjoint.

• Haskin Protection: The protection path (Haskin path) begins at the last hop of theworking path and goes back to the start of the working path in reverse order, thenleading to the end node of the working path on a disjoint path.

Z = min∑

ei,j∈E

ECi,j (C.9)



There is exactly one working path for each demand.

∑p∈Ws,t

WPUs,t,p = 1 ∀s, t ∈ N : s 6= t (C.11)


WPUs,t,wp =∑

pp valid 4

PPUs,t,wp,pp ∀s, t ∈ N : s 6= t, wp ∈ Ws,t (C.12)

1pp and wp are disjoint and pp has the same start and end node as wp2all protection paths pp for working path wp which contain edge ei,j3all working paths p which contain edge ei,j


Several protection paths share the protection capacities with each other. The sharedcapacity on an edge is at least as large as the maximum protection capacities that arerouted on this edge in the case of a single link failure:

SCi,j ≥∑

pp,wp5

(PPUs,t,wp,pp · ds,t) ∀ei,j, fei,j ∈ E : ei,j 6= fei,j (C.13)

The total capacity of an edge includes the shared protection capacities on this edge andthe working capacities on this edge:

ECi,j = SCi,j +∑

wp6


C.3.3 Link, Regional and Local-To-Egress Protection

Link, Regional and Local-To-Egress Protection can be summarized in the same model asthey only differ in the calculation of the protection paths:

• Link Protection: Each protection path starts at the start node of the working pathand follows the working path until it reaches the error edge. Now it bypasses theerror edge and then again follows the working path to its target node.

• Regional Protection: The only restriction here is that the protection path starts andends at the same nodes as the working path and does not contain the actual erroredge.

• Local-To-Egress: Each protection path starts at the start node of the working pathand follows the working path until it reaches the error edge. Now traffic is routedfrom the source node of the error edge to the end node of the working path on adisjoint path.

Z = min∑

ei,j∈E

ECi,j (C.15)




p∈Ws,t

WPUs,t,p = 1 ∀s, t ∈ N : s 6= t (C.17)

4“pp valid means” that pp could protect the working path wp if 1:N or Haskin Protection is used.5all valid protection paths pp for the working paths wp: ei,j ∈ Ps,t,pp ∧ fei,j ∈ Ps,t,wp6all working paths p which contain edge ei,j


Each working path is protected by exactly one protection path if there is a failure on oneof its edges.

WPUs,t,wp =∑

pp valid 7

PPUs,t,wp,pp,fe ∀s, t ∈ N : s 6= t, wp ∈ Ws,t, fe ∈ Ps,t,wp (C.18)


SCi,j ≥∑

pp,wp8

(PPUs,t,wp,pp,fe · ds,t) ∀ei,j, fei,j ∈ E : ei,j 6= fei,j (C.19)


ECi,j = SCi,j +∑

wp9


C.3.4 Ring and p-Cycle Protection

Ring and p-Cycle Protection can be summarized in the same model as they only differ inthe calculation of the protection circles. In both cases the working paths are protected bycircles but with the following differences:

• Ring Protection: The reverse edge of each edge of a used working path must be partof a circle.

• p-Cycle Protection: If the start and end nodes of a working path edge are part of acircle, this edge can be protected by the circle. In this way ”straddling links” as wellas “on-cycle” links are possible.

Z = min∑

ei,j∈E

ECi,j (C.21)



7“pp valid” means that pp could protect the working path wp if edge fe fails and Link, Regional orLocal-To-Egress is used as resilience strategy

8all valid protection paths pp for the working paths wp: ei,j ∈ Ps,t,pp ∧ fei,j ∈ Ps,t,wp9all working paths p which contain edge ei,j



p∈Ws,t

WPUs,t,p = 1 ∀s, t ∈ N : s 6= t (C.23)

Each working path is protected by exactly one protection circle if there is a failure on oneof its edges.

WPUs,t,wp =∑

pc valid 10

PPUs,t,wp,pc,fe ∀s, t ∈ N : s 6= t, wp ∈ Ws,t, fe ∈ Ps,t,wp (C.24)


SCi,j ≥∑

pc,wp11

(PPUs,t,wp,pc,fe · ds,t) ∀ei,j, fei,j ∈ E : ei,j 6= fei,j (C.25)

The total capacity of an edge includes the shared protection capacities (of the circle) onthis edge and the working capacities on this edge:

ECi,j = SCi,j +∑

wp12


C.3.5 Rerouting with and without Stub-Release

Rerouting can be done with and without stub-release. In the mathematical model thisdifference is reflected in only in one constraint.

Z = min∑

ei,j∈E

ECi,j (C.27)




p∈Ws,t

WPUs,t,p = 1 ∀s, t ∈ N : s 6= t (C.29)

10“pc valid” means that pc could protect the working path wp if edge fe fails and Ring or p-CycleProtection is used as resilience strategy

11all valid protection circles pp for the working paths wp: ei,j ∈ pc ∧ fei,j ∈ Ps,t,wp12all working paths p which contain edge ei,j



WPUs,t,wp =∑

rp valid 13

PPUs,t,rp,e ∀s, t ∈ N : s 6= t, wp ∈ Ws,t, fe ∈ Ps,t,wp (C.30)

The shared reroute capacities must be calculated differently depending on whether stub-release is used or not:

• With Stub-Release: The capacity of edge e in the case of a failure of edge fe consistsof the capacities of the working paths which are not affected by the failure and thecapacities of the used reroute paths. This capacity must not exceed the sum ofworking and shared capacities on this edge:

∑

rp14

PPUs,t,rp,fe · ds,t +∑

wp15

WPUs,t,wp · ds,t ≤ SCi,j +∑

wp16

WPUs,t,wp · ds,t

∀ei,j, fek,l ∈ E : ei,j 6= fei,j (C.31)

• Without Stub-Release: Several reroute paths share protection capacities with eachother. The shared capacity on an edge is as least as large as the maximum reroutecapacities that are routed on this edge additionally in the case of a single link failure:

SCi,j ≥∑

rp17

(PPUs,t,rp,e · ds,t) ∀ei,j, fei,j ∈ E : ei,j 6= fei,j (C.32)


ECi,j = SCi,j +∑

wp18


13“rp valid means” that rp has the same start and end node as wp14all reroute paths rp which are used if edge fe fails and which contain edge e15all working paths which are not affected by the failure of edge fe and which contain edge e16all working paths which contain edge e17all reroute paths rp which are used if edge fe fails and which contain edge e18all working paths p which contain edge ei,j


Sets:N set of all network nodesE ⊂ N × N set of all network edgesWs,t ⊂ P(E) s, t ∈ N set of all possible paths between

node s and tPs,t,p ⊂ E s, t ∈ N edges of a path p (leading from node s

p ∈ Ws,t to node t)C ⊂ P(E) set of all circles in the network

Parameters:ci,j ∈ R ei,j ∈ E maximum allowed capacity on edge ei,j

ds,t ∈ R s, t ∈ N demand from node s to node t

Variables:ECi,j ∈ R ei,j ∈ E used capacity on edge ei,j

PPUs,t,wp,pp ∈ B s, t ∈ N binary variable which shows whether path ppwp, pp ∈ Ws,t is a used protection path for path wp

(for 1+1, 1:N strategies)PPCs,t,wp,pp ∈ R s, t ∈ N variable for the capacity of a path pp which

wp, pp ∈ Ws,t is used as a protection path for path wp(for 1+1, 1:N strategies)

PPUs,t,,wp,pp,e ∈ B s, t ∈ N binary variable which shows whether path ppwp, pp ∈ Ws,t is a used protection path for wp in errore ∈ E case e (for local strategies)

PPUs,t,wp,pc,e ∈ B s, t ∈ N binary variable which shows whether circle pcwp ∈ Ws,t is a used protection circle for wp in errorpc ∈ C case ee ∈ E (for Ring and p-Cycle Protection)

PPUs,t,rp,e ∈ B s, t ∈ N binary variable which shows whether path rprp ∈ Ws,t, is a used reroute path if edge e failsei,j ∈ E (for rerouting strategies)

SCi,j ∈ R ei,j ∈ E shared protection capacity on edge ei,j

WPUs,t,p ∈ B s, t ∈ N binary variable which shows whether path pp ∈ Ws,t is a used working path for the demand ds,t

WPCs,t,p ∈ R s, t ∈ N variable for the capacity on a working path pp ∈ Ws,t

Table C.1: Abbreviations for the Constraint Modelling

Appendix D

Contents of the annexed CD

Files Directory Description* GRAPH/ GRAPH library used by our program

*.ppt Presentation/ Our presentation slides*.gml Results/COST/*/ Graphs of different results for COST*.dat Results/COST/*/ Summary of results for COST

README Results/COST/*/ How the program was invoked*.txt Results/COST/*/ When the program was started and has finished

* Results/COST-100G/*/ Results for COST with 100 Gib/s links* Results/COST200/*/ Results for COST with 200 Gib/s links* Results/WMW/*/ Results for WMW network

*.tex Workout/ TEX sources of the workout*.pdf Workout/ Compiled version of the workout

* bin/ Ready compiled version of our program*.html doxygen/ Class documentation of the software*.gml graphs/COST/ COST 239 network GML files*.gml graphs/COST-100G/ COST 239 with 100 Gib/s links*.gml graphs/COST-200G/ COST 239 with 200 Gib/s links*.gml graphs/WMW/ WMW network GML files

* truck/* The sources for our program* truck/CIRCLES/ 3rd party extension for GRAPH library

Table D.1: Contents of the annexed CD

70

List of Figures

1.1 MPLS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 One plus one protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 One to one protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 One to N protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Haskin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Link protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Regional protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Local-to-Egress protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.8 Ring protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 P-Cycle protection (ring failure) . . . . . . . . . . . . . . . . . . . . . . . . 182.10 P-Cycle protection (straddling failure) . . . . . . . . . . . . . . . . . . . . 192.11 Stub release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Components implemented and used in our project . . . . . . . . . . . . . . 213.2 Simplified Diagram of Resources used to transport Traffic . . . . . . . . . . 253.3 relationship between the network, paths and circles . . . . . . . . . . . . . 263.4 overview of classes used to identify a protection resource . . . . . . . . . . 273.5 Class CplexVariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6 Solver Components and their Representation in the Software . . . . . . . . 283.7 Subclasses of Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.8 Overview of all dedicated Resilience Modules . . . . . . . . . . . . . . . . . 343.9 Dedicated and Shared CPLEX Resilience Modules . . . . . . . . . . . . . . 353.10 Derivation Tree for OneToOneHaskinSingleSingle . . . . . . . . . . . . . . 363.11 The Network Calculators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.12 The Output Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1 COST 239 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Constructed network where the longest path is needed to find a solution for

protecting traffic from A to B. Limiting the number of considered paths willresult in no found solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

71

List of Tables

3.1 GML attributes defining the relations between the edges in the graphs . . . 243.2 Nomenclature of Multipath Variants within the Software . . . . . . . . . . 32

4.1 Command line arguments of the software package . . . . . . . . . . . . . . 40

5.1 Comparison of the sizes of our example networks . . . . . . . . . . . . . . . 43

6.1 Influence of path limitation on the computed bandwidth consumption (1:Nprotection, arbitrary number of working and protection paths) . . . . . . . 48

6.2 COST 239: Comparison of the resilience strategies in terms of their band-width consumption and of the number of considered Paths (75 paths pernode pair, arbitrary number of working and protection paths) . . . . . . . 50

6.3 COST 239: Comparison of the Resilience Strategies in terms of their Band-width Consumption and of the Number of used Paths (50 paths per nodepair, arbitrary number of working and protection paths . . . . . . . . . . . 52

6.4 WMW Network: Comparison of the resilience strategies in terms of theirbandwidth consumption and of the number of considered paths (arbitrarynumber of working and protection paths, no path number limitation) . . . 53

6.5 Comparison of the bandwidth consumption of different resilience strategies 536.6 Comparison of the Multipath Extensions in terms of their Bandwidth Con-

sumption (40 shortest paths per node pair, 1:N Protection) . . . . . . . . . 546.7 Comparison of Equal and Free Distribution in terms of their Bandwidth

Consumption (40 shortest paths per node pair, 1:N Protection) . . . . . . . 546.8 Effect of the Target Function on the Results (COST 239 Network, 60 paths

per node pair, 1:N Protection without any multipath extensions) . . . . . . 55

C.1 Abbreviations for the Constraint Modelling . . . . . . . . . . . . . . . . . . 69

D.1 Contents of the annexed CD . . . . . . . . . . . . . . . . . . . . . . . . . . 70

72

Bibliography

[AK] A. Authenrieth and A. Kirstadter. RD-QoS - The Integrated Provisioning ofResilience and QoS in MPLS-based Networks.

[BHD+97] M. Beck, Bohme H., M. Dziadzka, U. Kunitz, R. Magnus, and D. Verworner.Linux-Kernel-Programmierung. Addison-Wesley Longman Verlag, 1997.

[Erl01] Dr. Thomas Erler. UML. verlag moderne industrie Buch, 2001.

[Gru03] Claus Gruber. GRAPH. http://www.lkn.ei.tum.de/~claus/GRAPH/, 2003.

[Pri02] Robert Prinz. Diplomarbeit-Kapazitatsplanung fur WDM-Netze unterBerucksichtigung von Mehrfachfehlern. 2002.

[SGA02] D. A. Schipke, C. G. Gruber, and A. Authenrieth. Optimal Configuration ofp-Cycles in WDM Networks. 2002.

[Ste01] Prof. Dr. Angelika Steger. Diskrete Strukturen. Springer-Verlag, Berlin, Heidel-berg, New York, 2001.

[Str00] Biarne Stroustrup. Die C++ Programmiersprache. Addison-Wesley, Munchen,2000.

73

Bandwidth consumption in multipath resilience …Munich University of Technology (TUM) Institute of...

Documents

Transcript of Bandwidth consumption in multipath resilience …Munich University of Technology (TUM) Institute of...