Implementing a Simulation Model for the Evaluation of BGP Updates Impact on Real-Time Applications

Introduction

The Routing Modeling

Using the topology generator offers us the possibility of obtaining topologies closer to reality and is a practical tool. The problem lies in the fact that GT-ITM generators provide network topology but does not allow modeling of how packets are transmitted in the network. Therefore it is necessary for this part to be implemented by the user himself.

In this case, the interest falls on the routers which enable communication between the Autonomous Systems that implement BGP routing protocol. What should we model is exactly how these routers communicate with each other through e-BGP sessions, routing tables that build the way how they share the information.

Unfortunately, BGP doesn`t offer a prepared module for the implementation of the BGP. Consequently, referring to Figure 1, you need to make some modifications to the code ns2 in order to install the appropriate module. BGP for ns2 module, known as ns-BGP, is adopted to ns2 in 2004 [14] initiated by the BGP and TcpSocket modules from SSFNet [26] and implementing this protocol version 4 (BGP-4). SSFNet is a network-based simulator that enables Java language simulations through a configuration known as DML (Domain Modeling Language). With that SSFNet is based on Object Oriented language, its BGP module was a good starting point for ns2 module.

In ns2, unicast routing is achieved using tracking plans and control. The first plan makes the classification and the forward of the packets to the destination using the classification and routing modules. Classifier module manages routing node and provides an interface for the routing plan. Classifier are two types: address classifier and ports classifier. Packet classifier controls the address and sends it to dmux if it is the node itself the destination node of the package or transmits it to the following node. Dmux passes the packet to an agent in accordance with a specified destination port. While the second plan allows for the creation of the road, processing, routing algorithms and management of routing tables. Figure 1 illustrates the structure of ns-BGP unicast based on the initial structure of unicast for ns2.

Figure 1: unicast strcture of ns-BGP

As shown in the figure, the classification modules as classifier of the gate and the address send incoming packets to the respective agent or an outgoing link. These modules themselves are managed by the routing module.

Control plan consists of the following components: the logic path, the routing object, the side of the path and routing protocol. The central routing table is sustained by routing logic and routing facilities used in simulations with dynamic routing. Routing Objects encapsulate routing protocol by capturing and holding the attributes of each route announced. Finally, from the components of the routing protocol have been implemented and some specific routing algorithms.

Moreover, since the node BGP derives from a node unicast ns, Figure 1 shows and the inclusion of specific modules of the BGP and TcpSocket BGP. rtModule / BGP module manages the IPv4Classifer object while the new protocol rtProto / BGP is located in TcpSocket modules for transmitting the packets.

For each communication part BGP, is allocated an object used to establish the connection, exchange BGP messages and close the session. Four key classes used in the implementation of the BGP are:

TcpSockets

A socket is an Application Programming Interface (API) used in communications network. Applications treat socket connection to the network as the UNIX file descriptor. Similarly with the files, communications ends can be written by providing reading or erasure opportunities.

TcpSocket class is added as an implementation of the API socket, similar to the UNIX implementations. Its main functions are obey, hear, connect, close, read, and write.

IPv4Classifier

IPv4Classifier derives from Classifier class. It is implemented as a doubled class in ns2 (in C ++ and OTcL). This class uses the map from the standard libraries of C ++ models to store and look in the routing tables. To classify an incoming packet IPv4Classifier controls destination address of the packets and uses the information in the routing table to identify the paths.

rtModule / BGP

rtModule / BGP is a new routing module implemented in Tcl that provides a registration interface. When a node is created the information must be registered and the existing objects classifier in the joints must be replaced.

rtProtoBGP

rtProtoBGP Class (Agent / rtProto / BGP) is implemented as double class in ns2. An instance of this class implements BGP-4 in a node. This new routing protocol realizes most of the actions of BGP, setting communication session BGP between the parties, learning different paths through BGP speakers , selecting the best route and its preservation in the table (IPv4Classifier), and management of BGP situations.

Finally we can say that ns-BGP is in accordance with RFC 1771.

This module offers the option of setting BGP timers and the ability to implement the path deliberators.

Data Model Building

The traffic model type that is used to understand the traffic flow in the network and the approximation level with the reality, are vital parametres for the network.

Traffic analyse offers informations of average loads type, requests about the bandwidth in different applications etc. Traffic models helps network designers to make suppositions about the newtwork based in an passed experience and also performance forecasts in accordance with the future requests.

In this paper our goal is to disinguish the effects that BGP update moments have in real time applications and specifically in VOIP.

Unfortunately ns-2 doesn´t have a prepared already integrated module for VOIP.

In this concret occasion is chosen the simplest way to model a traffic in real time, based also in the below sceme for the VOIP traffic.It´s structure is shown in the picture.

Figure 2: VoIP module structure

If we could simplify this sceme in ns2 level we can tell that the easiest way for generating VoIP traffic is by creating an UDP agent whom is putted a traffic agent in application level, CBR.

To define CBR parametres is used the settings table of different codifiers of VOIP.

Table 1: Parametres for different codifies of VoIP

At the end we can say that for this paper purpose VOIP traffic is modeled as a data flow with a certain packet dimensions and transmission order.

The Network State and the Performance Evaluation

Acccording the chart in the picture after is defined the network and the data model, we can obtain the network state.

Ns2 is a simulator which depends from time and events. For this reason the network state is obtained by defining a start and end moment of the simulation and the events that will happend in this time.

In this paper the simulations are chosen that the average running time of a simulation is 80s. Simulations start at moment 0 and then are developed in order different events.

The first events group is exactly the information exchange of the routing between nodes. After nodes exchange information with each other, begins the CBR traffic transmission.This traffic will continue to be sent until the simulation time ends.

The second events group is the repeal and the continous announce of a path of a router. This normally will be accompanied with a refresh of the routing tables and will create delays in the network as consequence of the time of routers convergence. This is the moment where will be checked two of the quality main parametres packet loss and delays, so is realised the performance validation.

Model Changes

In order to appreciate as exactly as possible the performance, according with the posed problem, several times is required that some of the models parametres to be changed.

This includes changing the nodes number, simulation scennario, etc.

Simulations and Results

The simulation results for the created architecture are evaluated through different generated files. The used Software is Nestwork Simulator version 2.34 (ns 3.34) on the Ubuntu 8.10 operating system.

Routing Model Chosen Authentification

To verify the implemented routing protocol behaviour is done a simple test with the following specifications. Th epicture below shows the network topology used for simulation. The network consist of 3 AS where each of them is represented from a node AS 0, AS 1, and AS 2 (nodes 0,1 dhe 2 respectively). IP adress of each node is shown in the table.The adressing scheme is 10.(AS nr).(nodenumber).1.

Figura 3: Network topology

Table 2 : IP Adress

BGP agents are configured in each of the three nodes (0,1 and 2). For the nodes 0 and 2 the interval values of hold timer and keep-alive timer are those by default specificated in RFC 1771 [15] (hold time: 90 s, keep-alive : 30 s). To see the situation in reconnection situation, the intervali of keep-alive timer for the agent BGP in node is kept in the 200 s value. This way the BGP agent in node 0 wonn´t receive the message ´´keep the connection alive´´during the time and will requesthe reconnection.

In the 0.25 s BGP agent in node 0 advertises a new path for the adress 10.0.0.0/24. In 0.35 s, the BGP agent in node advertises a new path for the adress IP 10.1.1.0/24. In 0.45 s, BGP agent in node 2 advertises a path for the dresën IP 10.2.2.0/24. In 28 s, 90.38 s, and119.0 s, ns2 shows routing tables for the BGP agents.The simulation ends in 120.0 s. tcl file for this simulation is attached in Shtojca 1.

time: 28

dump routing tables in all BGP agents:

BGP routing table of node0

BGP table version is 10, local router ID is 10.0.0.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 self - - -

*> 10.1.1.0/24 10.1.1.1 - - - 1

*> 10.2.2.0/24 10.2.2.1 - - - 2

BGP routing table of node1

BGP table version is 16, local router ID is 10.1.1.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 10.0.0.1 - - - 0

*> 10.1.1.0/24 self - - -

*> 10.2.2.0/24 10.0.0.1 - - - 0 2

BGP routing table of node2

BGP table version is 10, local router ID is 10.2.2.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 10.0.0.1 - - - 0

*> 10.1.1.0/24 10.0.0.1 - - - 0 1

*> 10.2.2.0/24 self - - -

time: 90.38

dump routing tables in all BGP agents:

BGP routing table of node0

BGP table version is 23, local router ID is 10.0.0.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 self - - -

*> 10.2.2.0/24 10.2.2.1 - - - 2

BGP routing table of node1

BGP table version is 42, local router ID is 10.1.1.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.1.1.0/24 self - - -

BGP routing table of node2

BGP table version is 23, local router ID is 10.2.2.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 10.0.0.1 - - - 0

*> 10.2.2.0/24 self - - -

Time: 119

dump routing tables in all BGP agents:

BGP routing table of node0

BGP table version is 30, local router ID is 10.0.0.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 self - - -

*> 10.1.1.0/24 10.1.1.1 - - - 1

*> 10.2.2.0/24 10.2.2.1 - - - 2

BGP routing table of node1

BGP table version is 56, local router ID is 10.1.1.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 10.0.0.1 - - - 0

*> 10.1.1.0/24 self - - -

*> 10.2.2.0/24 10.0.0.1 - - - 0 2

BGP routing table of node2

BGP table version is 30, local router ID is 10.2.2.1

Status codes: * valid, > best, i - internal.

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0/24 10.0.0.1 - - - 0

*> 10.1.1.0/24 10.0.0.1 - - - 0 1

*> 10.2.2.0/24 self - - -

As it can be seen from the routing tables, every BGP agent learns about other agents during the 28 second. In the 39.0 second the session falls out between nodes 0 and 1 and nodes 0 and 2 remove the path toward the net 10.1.1.0/24 from their tables. Also node 1 deletes the paths that had for 0 and 2. After is reestablished the session nodes 0 and 1 exchange all the information that had in the routing tables and converge for the second time.This test verifies the correctness of the routing protocol model.

5.2 Stub-Domain with CBR Traffic Topology Simulation

The topology used in the simulation is given in the picture below:

Figure 4: Network topology according the stub-domain model

As we mentioned above the topology is generated through GT-ITM according the model Transit-Stub of the Internet. The routing Module does not offer many adopting chances in case of a large number of nodes and as a result we have chosen the option of modeling a subgraph of the Internet.

This subgraph consists of a transit domain which has 4 nodes (BGP routers) and 12 terminal domains which are modeled with a router each one.

Tabela 3 : graph settings

This topology is generated from the input file in the GT-ITM .

In the total we have 16 nodes. As shown in the table the transit domain is modeled with 4 nodes that exchange BGP communication with each other. All four these are (edge) routers. Transit AS is organised with a cluster and two path reflectors which are nodes 2 and 3. For terminal AS is chosen the logic of showing them through a node.This is in accordance with the AS definition. The adressing scheme is chosen in the form 10.0.$i.1 for the routers inside the transit AS where $i is the node number (0,1,2 or 3) and 10.$j.$i.1 for the routers in AS stub, where $j is for the AS number and $i for the node number (4,5..15).

The network configuration is realised as below:

BGP Agents are configured in each of the nodes. Interval values of hold timer and keep-alive timer are default (hold time: 90 s, keep-alive : 30 s).

UDP Agents are configured in nodes 0 (burimi) dhe 1. The traffic in these two nodes passes through node 2, according the routing tables.

CBR traffic is modeled with these settings: packetSize_ 160, interval_ 0.02 and rate_ 64kb.

After the node configuration, the following step is defining the scheduled events. In this simulation we want to see the convergence time of the three routers included in the communication which are n15, n3 and n2. The events are scheduled as it follows:

In 5.0 fillon transmetohet trafiku CBR

In 6.0 agent 15 shows the routing table

In 30.0 agent 3 shows the routing table

In 30.0 agenti 2 shows the routing table

In 35.0 agent 15 announces the net fall 10.12.15.0/24"

In 36.0 agent 15 shows the routing table

In 36.0 agent 3 shows the routing table

In 36.0 agent 2 shows the routing table

In 36.0 agent 15 network 10.12.15.0/24"

In 55.0 agent 15 no-network 10.12.15.0/24"

In 62.0 agjenti 3 shows the routing table

In 62.0 agent 2 shows the routing table

The last event is realised with the goal to see the system behaviour in a situation where a path is shown and is disconnected again and again during a short period of time (route flapping).

In this way it will be seen if there are lost or dalys in packets during BGP routing tables updates.

5.3 Simulation Results

Through Nam, we see that the first packet CBR is generated in the 5.0 second:

Figura 5.-a: Is sent the first packet CBR

In the 35.0 second we see that is sent the information for a falling path from node 15.

Figura 5.-b: Is sent the routing information

Node 3 learns about the node 15 fall and passes this information to its neighbours:

Figura 5.13-c: Shpërndahet informacioni rrugëzimit

During running time in the scrren we have this data about the routing tables.

Node 2 advertises node 13 about the changes in the routing as shown in the picture :

Figura 5.-d: The routing information is distributed from node 2

Meanwhile the routing tables in different moments are shown below :

Time: 30

BGP routing table of n3BGP table version is 14, local router ID is 10.0.3.1Status codes: * valid, > best, i - internal.Network Next Hop Metric LocPrf Weight Path 10.0.0.0/24 self - - - 10.1.4.0/24 10.0.0.1/32 - - - 1 i 10.2.5.0/24 10.0.0.1/32 - - - 2 i 10.3.6.0/24 10.0.0.1/32 - - - 3 i 10.4.7.0/24 10.0.0.1/32 - - - 4 i………………….

……………….....

10.10.13.0/24 10.0.2.1/32 - - - 10 i10.11.14.0/24 10.0.2.1/32 - - - 11 i10.12.15.0/24 10.12.15.1/32 - - - 12 BGP routing table of n2BGP table version is 12, local router ID is 10.0.2.1Status codes: * valid, > best, i - internal.Network Next Hop Metric LocPrf Weight Path 10.0.0.0/24 self - - - 10.1.4.0/24 10.0.0.1/32 - - - 1 i10.2.5.0/24 10.0.0.1/32 - - - 2 i……………….

……………….

10.10.13.0/24 10.10.13.1/32 - - - 10 10.11.14.0/24 10.11.14.1/32 - - - 11 10.12.15.0/24 10.0.3.1/32 - - - 12 i

Based on this data we see that in the 30 second agents 3 and 15 have converged and have a clear information about the network.

In the 35 second is announced the network fall 10.12.15.0/24. Nodes 2 and 3 remove the path to this network from the routing tables.

In the 36 second the path is established again and nodes 2 and 3 must convergence in second 60, but in second 55 the path falls again. Node 15 adevrtises the network again that the path is set up. All these falls and raises of the paths cause often packets sending which consume the bandwidth and the nodes elaborating abilities. Because the programmed module does not have mechanisms for “route flap damping” the network passes from a divergence state which can not be solved between 80 seconds chosen for the simulation.

After finishing the simulations the first element which is taken in consideration is the number of lost packets before to schedulate the unstainability event and after schedulation of this event.

From the registration file we see that in the case where the simulation is done without the events presence that cause path fluctuation lost packets are in the level 776. After the mentioned events this number goes in797. This means that the loosing level in packets is increased with 21 in 100 seconds of simulation.

Figure 6: Packet loss

Conclusions

In this paper is offered an integrated environment for the simulations realisation which ai mis to study the convergence problem of BGP in the traficc of real time communications croos-domain. For this environment is followed a metodology which starts with the network model definition, ns2 modulesrmination and continous analysis “What-If”.

Network topology modelation is a very important step. Internet modelling often is turned in a challenge as a result of its diversity nature, dimensions and heterogenity. To create a model near the reality are preferred to be chosen the random generators, but which models partly the internet hierarcy.

The realised simulations shows that the convergence time of BGP are in accordance with the base requirements for BGP. Also it shows that the convergence time problem affects directly in the traffic which permeats the networks. In a large simulation this affect will be multiplied in accordance with the network sizes taking in consideration the fact that the consumed bandwidth from the packets BGP is in related with network dimensions.

References