7

Click here to load reader

Mpls Te Opnet

  • Upload
    mac-an

  • View
    220

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 1/7

 

Analysis of MPLS-TE with OPNET

Xavier Lleixà Rillo

Abstract

 Nowadays, the Internet is the most important network in the world. A lot of people use

Internet to communicate with other people, to download files, for watching TV and

many other things.

These different applications cause some problems with the communications. For

example, voice has some requirements, like jitter and delay, which does not exist in

other types of communication, like ftp. Because of these reasons, new networks should

consider the different applications when routing a packet. This is the main reason for

MPLS Traffic Engineering.

Page 2: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 2/7

Introduction

The goals of this document are to see and explain the differences between a network

with MPLS-TE and a traditional network; analyze the different MPLS-TE protocols,and see the impact of QoS in a congested network.

MPLS Traffic Engineering is composed of different protocols.

Firstly, there are the signalling protocols. Their main function is network labels

distribution. The most important signalling protocols are RSVP-TE and CR-LDP. The

main differences between them are the states. CR-LDP maintains a full adjacency

 between the different routers and RSVP-TE periodically refreshes the state of the path.

In the other hand, there are the routing protocols. The principal purposes of these

 protocols are the distribution of the information between the routers and the election of

the best path to go to a destination. In order to choose the path, they do not use the SPF

algorithm, they use CSPF. This algorithm deals with some features like bandwidth or

delay to calculate the best path. The most important routing protocols are OSPF-TE and

ISIS-TE, which are a modification of OSPF and ISIS.

MPLS-TE also provides protection functionalities. We can protect a node or a link with

a pre-established backup LSP. We have simulated this situation and we have realised

that the protection reduced the inability time of the link 45 seconds.

 Now we are going to introduce some simulations implemented with the different

 protocols and a simulation of an ISP network with MPLS-TE and QoS.

Page 3: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 3/7

Main Simulations

Signalling and routing protocols analysis (RSVP-TE, CR-LDP, ISIS-TE and

OSPF-TE) 

The objective of this scenario is to analyze the characteristics of the different signalling

and routing protocols. For each one, we will pay especial attention in the convergence

time and in the impact that they produce in the network.

We have simulated a network with the following characteristics:

•   Network with three sides:

Barcelonao  Madrid

o  Valencia

•  50 LSPs

•  Traffic classified and routed by different LSPs

•  Without QoS

•  Voice Traffic, FTP Traffic, BD Traffic, http Traffic.

The network scheme:

Page 4: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 4/7

 Now we can see the different results of the simulation:

Node %RSVP-TE %CR-LDP

LER_Barcelona 0,41040 0,53040

LER_Madrid 0,39091 0,42091

LER_Valencia 0,42965 0,42965

lsr_1 0,17393 0,08292

lsr_2 0,24336 0,25728

lsr_3 0,24234 0,23718

lsr_4 0,12482 0,02783

lsr_5 0,13290 0,01873

We can see the differences between RSVP-TE and CR-LDP. CR-LDP consumes more

CPU than RSVP-TE. The reason is that CR-LDP maintains adjacencies with all the

routers in the network and it has knowledge of the different routers. The traffic

 produced by the different protocols is also dissimilar. CR-LDP generates less traffic

than RSVP-TE. The main reason is that CR-LDP is a hard-soft protocol and RSVP is a

soft-protocol that needs to refresh the adjacencies every time period (150 msec).

NodeCPU OSPF-

Utilization (%) OSPF Router

Convergence Activity CPU ISIS -

Utilization (%) ISIS Router

Convergence Activity 

LER_Barcelona 0,52040 0,100000 0,51975 0,019667

LER_Madrid 0,40091 0,100000 0,45000 0,019667

LER_Valencia 0,40965 0,100000 0,46877 0,019667

 Now we can compare the differences between OSPF-TE and ISIS-TE. Both are link-

state protocols. In the table we can see that the CPU usage is similar in the two

 protocols. We can also realise that the convergence time for OSPF is ten times bigger

than the ISIS Router Convergence activity.

Page 5: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 5/7

MPLS-TE analysis with a ISP Network

The purpose of this scenario is to see the advantages of the implementation of a MPLS-

TE with QoS in an ISP network. Firstly, we did the simulation with the default OPNET

models in order to view the impact of the different QoS. Later, we did the simulation

with real equipment like Cisco, Juniper and Nortel.

We can divide the simulation in four parts:

•  Simulate a network without QoS

•  Simulate a network with CBFWQ

•  Simulate a network with CBWFQ and WRED

•  Simulate with real equipment (Cisco, Juniper, Nortel)

The simulation is based in the following scenario:

Page 6: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 6/7

We have simulated a network with the following characteristics:

•   Network with four sides:

•  50 LSPs

• 

Traffic classified and routed by different LSPs•  Routing protocol OSPF-TE

•  Signalling protocol RSVP-TE

•  Voice Traffic, FTP Traffic, BD Traffic, http Traffic.

•  We utilize 90% of the available bandwidth.

Results and conclusions of the simulations

We take special care of voice communication because it is the most sensible. It requiresspecific parameters to establish a good conversation. There is a great impact in the

network performance.

Simulation withot QoS

Statistic Average Maximum Minimum

Voice Packet Delay Variation  0,5636 1,5453 0,0000

Voice Packet End-to-End Delay (sec)  1,2776 2,8990 0,0008

Voice Traffic Received (bytes/sec)  27.304 43.400 0

Voice Traffic Received (packets/sec)  2.730,4 4.340,0 0,0

Voice Traffic Sent (bytes/sec)  27.616 40.000 0

Voice Traffic Sent (packets/sec)  2.761,2 4.000,0 0,0

In the table above we can see that the communication between the different sides is not

 possible because the delay variation and the End-to-End delays are too big. In the next

simulations we will see how the different QoS policies change these results.

Simulation with CBWFQ

In this simulation we applied a QoS policy. Firstly, we marked and classified the

 packets in the Ingress LERs. Later, we configured the different LSR to use CBWFQ.

We configured Voice traffic with the highest priority and a LLQ queue.

Page 7: Mpls Te Opnet

8/11/2019 Mpls Te Opnet

http://slidepdf.com/reader/full/mpls-te-opnet 7/7

Statistic Average Maximum Minimum

Voice Packet Delay Variation  0,0000005738 0,0000006425 0,0000000269

Voice Packet End-to-End Delay (sec)  0,0017456 0,0018403 0,0005041

Voice Traffic Received (bytes/sec)  27.510 40.008 0

Voice Traffic Received (packets/sec)  2.751,0 4.000,8 0,0

Voice Traffic Sent (bytes/sec)  27.576 40.000 0

Voice Traffic Sent (packets/sec)  2.757,3 4.000,0 0,0

 Now the voice packet delay variation is less than 1 mseg and the Voice Packet End-to-

End Delay is less than 2 mseg. This diminution of traffic delay causes that now the

voice communication is possible. The problem of this configuration is the packet loss.

Simulation with WRED

In the last simulation we have explained the advantages of QoS, but the main problem

of the last configuration is the packet loss because we can not distinguish between the

different packets that we have lost. For this reason we configured WRED and

eliminated the packets with an established policy. With this policy the packet loss

 became reduced a 30 %, but the jitter and the delay raised up in a 45%.

Simulation with real equipment.

We have implemented scenarios with equipment of different vendors. The equipment

that we have used is OPTERA 5XXX of Nortel, Cisco 12XXX of Cisco, ERX-14XXX

of Juniper. The parameters that we have analyzed are similar than in the other

simulations and the result of these simulations doesn’t differ to the simulations with the

OPNET models. The only difference appeared when we mixed the different vendor

equipment or when we used only vendor equipment to implement the network: the

communication load and delay grow up approximately a 15 %.