1 10260 faf10296-en_a_msword2003

Ericsson Internal

MPLS PERFORMANCE OPTIMIZATION 1 (139)Prepared (also subject responsible if other) No.

LMI/GBD Sireen Malik 1/102 60-FAF 102 96Approved Checked Date Rev Reference

EAB/GD/PP Marcin Czechowski 23/09/2008 A

MPLS Performance Optimization

Abstract

This document describes OPNET SPGuru based MPLS Performance Optimization service.

Ericsson Internal




Proprietary Nature of document

Each Ericsson document is prepared for the sole and exclusive use of the party or organization to which it is addressed. Therefore, Ericsson documents are considered proprietary, and may not be made available to any other than the addressee or persons within the addressee’s organizations who are designated to evaluate or implement the proposed solution. Ericsson documents may be made available to other persons or organizations only with the permission of the Ericsson office issuing the documents.

Copyright

©. All rights reserved. This material is subject to copyright and no part of it may be reproduced, copied, or transmitted in whole or in part by any means whatsoever (including without limitation, graphic, photographic, photocopying, electronically or mechanically) without the prior express written permission of Ericsson.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ericsson shall have no liability for any error or damages of any kind resulting from the use of this document.

This shall not be used as subject for any kind of contract negotiation, warranty or liability.

Ericsson Internal




Contents

1 Introduction............................................................................................61.1 General......................................................................................61.2 Service Overview.......................................................................71.3 Service Scope............................................................................71.4 Limitations..................................................................................81.5 Completeness............................................................................81.6 Known Issues............................................................................81.7 Notation.....................................................................................81.8 Software Version.......................................................................91.9 Changes since previous release...............................................91.10 General Comments....................................................................9

2 Overview of Network Performance Optimization.............................10

3 Network Modeling................................................................................123.1 Network Topology Model.........................................................133.2 Network Traffic Model..............................................................14

4 IP Routing.............................................................................................224.1 OSPF Convergence Time........................................................234.2 IS-IS Convergence Time.........................................................294.3 BGP Convergence Time..........................................................33

5 IGP Metrics Optimization....................................................................345.1 Network Performance Baseline...............................................345.2 IGP Metric Optimization Wizard..............................................365.3 IGP metrics based on Mobile-PBN recommendations for MPLS

LDP..........................................................................................44

6 MPLS Optimization..............................................................................486.1 Mobile-PBN recommended solution........................................506.2 Creation of MPLS LSPs...........................................................526.3 MPLS Traffic Engineering Optimization...................................556.4 MPLS Tactical Traffic Engineering Optimization.....................696.5 Survivability Analysis...............................................................756.6 MPLS Incremental Traffic Engineering Optimization...............806.7 MPLS Configlet Generation.....................................................89

7 MPLS Fast Reroute..............................................................................907.1 Enabling Fast Reroute.............................................................917.2 Bypass Tunnel Setup...............................................................937.3 Explicit Route for FRR Bypass Tunnel....................................94

8 QoS.......................................................................................................988.1 QoS Design Overview.............................................................988.2 QoS Scenario........................................................................1018.3 Edge Routers QoS Configuration..........................................1028.4 Core Routers QoS Configuration...........................................113

Ericsson Internal




8.5 QoS Verification.....................................................................1158.6 Queue Sizing.........................................................................116

9 Physical and Logical Connectivity..................................................1229.1 Physical connectivity..............................................................1229.2 OSPF parameters..................................................................1249.3 IS-IS Process.........................................................................1299.4 BGP Tuning...........................................................................130

10 Conclusion.........................................................................................131

11 Abbreviations.....................................................................................133

12 References.........................................................................................135

Ericsson Internal




Document History

Version Date Author Comments

PA1 19.09.08 Esirmal First draft

Ericsson Internal




1 Introduction

1.1 General

Ericsson as a leader in telecommunication networks and services, and shaping the future of Mobile and Broadband Internet communications offers various services from its professional services portfolio, ranging from design to integration and up to performance evaluation and improvement, to help operators control the transition versus “all-IP” networks exploiting the benefits at best.

The Network Performance Improvement for IP (NPI for IP) service helps operators to improve the support provided by the IP backbone to existing applications as well as ensure that new applications requirements can be fulfilled. The service is focused on performance aimed at measuring and improving the quality of service offered to different types of traffic.

The NPI for IP service is structured as below.

IP Network Performance Audit:

This module consists of the following three services:

o Audit for IP Core Network [1] : IP bearer, node and topology level KPI’s are evaluated and compared against reference values according to service objectives. This is an Active network testing service.

o Routing Protocols Review [2]: Online review of IP routing protocols implementation, according to best practices

o MPLS Review and Verification [3]: Offline review and verification of MPLS backbone using OPNET SPGuru software application.

MPLS Performance Optimization:

o (this document)

These services delivered, in combination or separately, have a positive impact on operator’s business helping to retain the existing customer base as well as attract new customers.

Ericsson Internal




1.2 Service Overview

The objective of MPLS Performance Optimization service is to improve important performance parameters like loss, delay, jitter etc. of the traffic transported by the MPLS network.

This optimization is primarily achieved by Traffic Engineering (TE) techniques. Following methods are considered:

MPLS Labeled Switched Path (LSP) explicit routing. Primary path is chosen in order to improve performance parameters.

MPLS secondary Path. An alternative path is chosen that ensures performance of network during “resilience mode”.

MPLS Fast Reroute (FRR) Bypass Tunnels. Explicit routes for bypass tunnels are engineered in order to control traffic in a deterministic manner, just after link/node failure.

IGP link metric optimization for MPLS LDP network. IGP link metrics are optimized for load-balancing and performance improvement.

Quality of Service (QoS) implementation is an important consideration in MPLS network. Diffserv QoS is tuned according to the actual traffic demands.

Moreover, important IP/MPLS routing control parameters that have a direct bearing on network resilience performance are also considered, for example, the IGP protocols routing Convergence Times.

1.3 Service Scope

1.3.1 In Scope

Edge-to-Edge MPLS Core Network.

1.3.2 Out of Scope

Application layer: Quality of Experience (QoE) at the application layer.

Modeling of Core nodes like MSS, SGSN, GGSN, etc.

Modeling of Client networks.

Network Management System Interface.

IP Security.

Ericsson Internal




1.4 Limitations

Performance results obtained in OPNET SPGuru simulations are not verified against real network performance results.

Redback node models are not available.

1.5 Completeness

Only Juniper network topology is modeled. Cisco topology is not modeled; however, it can be done following the guidelines recommended for Juniper devices.

Inter-networking in Multivendor environment (Juniper, Cisco and Redback) is not modeled.

1.6 Known Issues

Some aspects of OPNET SPGuru 14.0 do not work correctly, especially for bundled/aggregated links. The following have to be set up manually and verified for correct implementation.

Bundled/aggregated links import and implementation.

QoS settings.

QoS Drop Profiles are not configurable in Design Wizards. These have to be setup on each node separately.

MPLS RSVP LSP explicit paths.

RSVP is not enabled on bundled links. Some nodes do not show RSVP aggregate link attributes at all.

NetDoctor reports incorrect results for Bundled/Aggregated links.

Incorrect IP addressing of bundled/aggregated links, set up as a result of import of topology configuration files, causes simulation to crash.

IGP Metric Optimization Wizard does not work properly for bundled links.

1.7 Notation

Following notation is used in this document

Ericsson Internal




Menu items commands: OPNET Menu Commands

Hierarchical parameter selection: Parameter selection->sub-parameter

Parameter and attribute values: “Value”

Special notes Note:

1.8 Software Version

OPNET SPGuru 14.0

1.9 Changes since previous release

First release

1.10 General Comments

MPLS Performance Optimization objectives considered in this document are in line with Ericsson solutions and best practices. These objectives may be modified as per customer policy and guidelines. In that case, a common understanding must be reached and agreed with the customer before the start of the service.

An effort has been made to include dominant MPLS Performance Optimization methods in this document. Some guidelines are also included on the relevance and application of each method in a specific scenario. However, in the delivery of a service some methods may be less relevant than others. These need to be clarified and agreed with the customer before the start of the service.

Ericsson Internal




2 Overview of Network Performance Optimization

The key network performance objectives can be classified as:

Traffic oriented, and

Resource oriented

Traffic oriented objectives are related to the Quality of Service (QoS) of traffic. Following QoS objectives are important:

Minimization of Delay

Minimization of Packet Loss Ratio

Minimization of Jitter

Maximization of Throughput

The most important resource in a network is capacity or bandwidth. Therefore, the most important resource oriented performance objective is:

Minimization of Bandwidth Utilization

Lack of network resources, enough to accommodate the offered traffic, leads to congestion in the network. For example, the residual bandwidth on a link is not enough to accommodate the required bandwidth of a traffic flow. This type of problem is fixed with network capacity expansion.

Congestion may also be caused when traffic flows are inefficiently mapped on to available network resources thus causing some resources to become over-utilized while others remain under-utilized. This type of congestion problems are addressed through Traffic Engineering (TE).

Capacity expansion schemes put capacity where traffic requires it. TE methods, on the other hand, put traffic where there is capacity in the network.

The two performance objectives (traffic and resource) are fundamentally tied to each other: Resource utilization has a direct impact on QoS parameters.

Consider the following simple relationship for utilization:

(1)

Ericsson Internal




Utilization is then a function of two parameters: the offered load, and the available capacity. It can be reduced by either capacity expansion, or by reduction in load.

Now consider, a typical packet loss performance model1 as a function of utilization [10], shown in Figure 1:

Figure 1 Packet loss against utilization

Figure 1 shows packet loss performance degradation as a function of increasing utilization. From a performance perspective, there are three regions to be considered. The first region is for utilization below 40% where performance degradation with increasing utilization is relatively acceptable. The second region is between 40% to 80% utilizations where performance degradation is rapid, and the third region is above 80% utilization where performance degradation is almost exponential.

Network designers, therefore, consider 80% utilization as the upper limit for dimensioning purposes. The tendency is to plan the network in the first region (less than 40% utilization). Region between 40% and 80% utilizations is considered only for network operation in resilience mode.

Figure 1 shows packet loss performance against network utilization. Packet Delay and Jitter have similar dependence on queue build up as a result of high utilization.

1True for constant packet size and Poisson arrival process. Traffic with different variation/correlation and/or variable packet sizes will push the curve up or down. The important thing to consider is the shape of the curve which shows rapid performance degradation after 70%-80% utilization.

Ericsson Internal




To summarize the discussion so far, utilization has an impact on QoS parameters, and that lowering the utilization leads to better QoS performance. Therefore, the first target for any network optimization scheme should be to reduce utilization. This performance improvement target is either achieved by capacity expansion or by traffic engineering methods.

Traffic engineering process attempts to enhance the overall network utilization, by keeping the maximum network utilization or average link utilization down, and by managing a balanced distribution of traffic across a network. The objective of such TE strategies is to Minimize Maximum Utilization, through efficient resource allocation.

When congestion is minimized through efficient resource allocation, packet loss decreases, delay decreases, and aggregate throughput increases. Thereby, the perception of network service quality experienced by end users becomes significantly enhanced.

The trick is to find not only the shortest path but find the shortest and optimal path considering the constraints on the traffic which does not necessarily mean the selection of the shortest path between a source and destination. So contrary to the path taken by flows in normal Shortest Path First routing, it is possible that, for example, two data flows may take completely different paths even though they have the same originating node and the final destination node.

In most cases, network operators tend to perform TE optimization before any network capacity expansion plans are put in place. This is the scope of discussion in this topic. TE methods are discussed for MPLS LDP and MPLS RSVP networks. It is also shown in this document that in some cases optimization does not bring any improvement in network performance, and therefore, capacity expansion is the only option.

3 Network Modeling

Network topology and traffic models are set up in OPNET SPGuru simulation environment.

Network topology model is built by importing node configuration files. The complete methodology to build the topology model is found in MPLS Review and Verification service [3].

There are various ways to build network traffic model in OPNET. Either application layer traffic models like HTTP, FTP, etc. available with the software can be used, or network traffic matrix information can be imported, for example, from Cisco Netflows, Netscout nGenius, Spreadsheet, etc.

Ericsson Internal




In this document, traffic matrix is imported using the Spreadsheet Import method. For other methods, please consult OPNET documentation [6].

3.1 Network Topology Model

An example topology, shown in Figure 2, is used to demonstrate MPLS Performance Optimization methods. It will be used throughout the document.

KHI03

GE2

GE2

JRTR45

Ge-2/0/0

Ge-2/0/2

JRTR46

2 X GE2 X GE

2 X GE

2 X GE

2 X GE

2 X GE

2 X GE

2 X GE

GE1

2 X GE

2 X GE

2 X GE

GE1

2 X GE

2 X GE

2 X GE

2 X GE2 X GE

2 X GE 2 X GE

2 X GE

GE2GE2

GE2

2 X GE 2 X GE

2 X GE

GE

STM4 X 2

STM4 X 3

SUK01 KHI02 KHI01

ISB01

GE1

GE3

GE1

GE2

JRTR11 (M10i)

Ge-0/0/2

Ge-0/0/0

JRTR12 (M10i)

Ge-1/0/0

Ge-1/1/0

JRTR02 (M10i)

Ge-0/0/2

Ge-0/0/0

STM4-0/1/0STM4-0/2/0STM4-1/2/0

JRTR01 (M10i)

Ge-0/2/0Ge-0/1/0

Ge-1/1/0

JRTR32 (M10i)

Ge-0/0/0

JRTR31 (M10i)

STM4-0/1/0STM4-0/2/0STM4-0/3/0STM4-1/2/0

Ge-1/0/2

Ge-1/0/0

JRTR08(M10i)

Ge-0/0/0

Ge-1/0/2

JRTR13(M10i)JRTR14(M10i)GE2

GE2

JRTR21(M10i)

Ge-0/0/0

Ge-1/0/0

JRTR22(M10i)

Ge-0/0/0

Ge-1/0/0

QUT01

GE2

GE2

JRTR19(M10i)

Ge-0/0/0

Ge-1/0/0

JRTR20(M10i)

Ge-0/0/0

Ge-1/0/0

LAH02

GE2

GE2

GE2

GE2

JRTR09(M10i)

Ge-0/0/2

STM4-0/1/0STM4-1/2/0

JRTR06(M10i)

Ge-0/0/0

Ge-1/0/0

Ge-0/2/0

2 X GE

2 X GE

2 X GE

JRTR07(M10i)

Ge-0/2/0Ge-1/0/0

Ge-0/0/0

JRTR10(M10i)

Ge-1/0/0

Ge-0/0/0

GE1

JRTR15(M10i)

Ge-1/0/0

Ge-0/0/0

JRTR16(M10i)

Ge-1/0/0

Ge-0/0/0

MUL01

LAH01

GUJ01

JRTR24 (M320)

STM4-5/0/1STM4-4/0/0 STM4-5/0/0

JRTR28 (M320)

Ge-0/0/0STM4-4/0/3 STM4-5/0/3

STM1-0/1/3STM1-1/1/3STM1-2/1/3STM1-3/1/3

STM1-x/x/x STM1-x/x/x STM1-x/x/x

STM1-0/1/0STM1-1/1/0STM1-2/1/1STM1-3/1/0

JRTR23 (M320)

STM4-4/0/2 STM4-4/1/2 STM4-5/0/2 STM4-5/1/2

STM4-4/0/1 STM4-5/0/1

STM4-4/1/0 STM4-5/1/0

STM4-4/0/0 STM4-5/0/0

Ge-0/0/0

JRTR26 (M320)

STM4-4/0/3 STM4-5/0/3

Ge-0/0/0

GE1

JRTR27(M320)

FSB01

GE

GE

GE

SWI24

GE GE

GE

GEGE

GE

GEGE

PWR01

GE2 X GE

2 X GE2 X GE

STM1 X 4

STM4 X 2

STM1 X 3

JRTR05(M10i)

Ge-0/0/0

Ge-0/2/0

Ge-1/0/0

GE1

GE2

2 X GE

2 X GE

2 X GE

JRTR43(M10i)

JRTR44(M10i)

FSB02

Ge-0/0/0

GE2

GE2

JRTR36(M10i)

Ge-0/0/0

Ge-1/0/0

JRTR35(M10i)

Ge-0/0/0

Ge-1/0/0

GEGE

ABT01

GE

STM1 X 7

STM1 X 4

ISB02

GE2

GE2JRTR38(M10i) JRTR37(M10i)

STM4-4/0/0 STM4-4/1/0

STM4-4/0/1STM4-4/1/1

Ge-0/0/0 STM1-0/1/0 STM1-1/1/1STM1-1/2/0STM1-2/1/0STM1-3/1/0

STM4-4/0/2STM4-5/0/2

STM1-0/1/1STM1-0/2/0 STM1-1/1/0 STM1-3/1/1

ST

M4

-4/0

/3

S

TM

4-4

/1/3

2 X GE

2 X GE2 X GE

STM4 X 1

GE2

GE2

JRTR40(M10i)

Ge-0/0/0

Ge-1/0/0

JRTR39(M10i)

Ge-0/0/0

Ge-1/0/0

GEGE

JLM01

GE

STM1 X 5

STM1 X 7

4 X STM1

STM4 X 2

STM4 X 1

STM4-4/0/1

STM4 X 2GE1

JRTR41(M10i)

Ge-1/0/0

Ge-0/0/0

JRTR42_C2811

Ge-0/1/0

Ge-0/0/0

SWL01 GE

FE

FE

STM4 X 2

JRTR30 (M320)

Ge-0/0/0

STM4-4/0/2

STM4 X 2

STM4 X 2

Ge-1/0/0

Ge-0/0/0

STM4 X 2

STM1 X 5

STM4 X 2

HYD01

GE2

GE2

JRTR33(M10i)

Ge-0/0/0

Ge-1/0/0

JRTR34(M10i)

Ge-0/0/0

Ge-1/0/0

GE GE

GE

STM1 X 4STM4 X 3

STM4 – 0/1/0STM4 – 0/2/0STM4 – 1/2/0

STM1-0/1/2 STM1-0/2/0 STM1-1/1/2 STM1-1/2/0 STM1-2/1/2 STM1-3/1/1G

e-0

/0/0

STM1-0/1/0STM1-1/1/0STM1-2/1/1STM1-3/1/0

STM1 X 4

STM1 X 6

STM1 X 6

STM4 X 3

STM4 X 4

STM4 X 4

STM4 X 4

STM4 X 2

10.0.16.53

10.0.16.13

10.0.16.45

10.0.16.1

10.0.16.33

10.0.16.17

10.0.16.5

10.0.16.37

10.0.16.38

10.0.16.46

10.0.16.61

10.0.16.62

10.0.16.6

10.0.16.9

10.0.16.2

10.0.16.10

10.0.16.18

10.0.16.14

10.0.16.22

10.0.16.21

10

.0.2

0.3

7

4.6510

.0.2

0.6

6

10

.0.2

0.5

7

10.0

.20

.58

10.0.16.34

10.0.16.54

10

.0.2

0.3

8

10.0.24.910.0.24.10

10.0.24.210.0.24.6 10.0.24.22 10.0.24.18

10

.0.2

4.1

7

10

.0.2

4.2

1

10

.0.2

4.1

As-1

As-0

As-2

As-2

As-0

As-0

As-0

As-0

As-0

As-0

As-0

STM4-5/0/1 STM4-4/0/1 STM4-4/0/0 STM4-5/0/0

As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0

JRTR42(M10i)

10

.0.2

0.2

10

.0.2

0.6

10

.0.2

0.2

6

10

.0.2

0.2

2

10.0

.20

.30

10

.0.2

0.3

4

10

.0.2

0.1

8

10

.0.2

0.1

4

10.0.20.49 10.0.20.50 10.0.20.53 10.0.20.5410.0.20.46

10.0.20.45 10.0.20.10

10.0.20.9

28.9

28.10

28.22

28.21

10.0.28.2

10.0.28.6

10.0.28.5

10.0.28.1

10.0.28.14

10.0.28.18

10.0.28.17

10.0.28.13

10

.0.2

0.2

5

10

.0.2

0.1

10

.0.2

0.1

7

STM1-0/1/1STM1-1/1/1 STM1-2/1/0

STM1 X 3

10

.0.2

0.1

3

10

.0.2

0.2

910

.0.2

0.3

3

10.0

.20

.21

10.0

.20

.5

10

.0.2

4.5

10

.0.2

4.3

3

10.0.24.42 10.0.24.34

10.0.24.3710.0.24.38

10.0

.24

.41

10.0

.24

.45

10.0.24.4610

.0.2

4.4

910.0.24.5010.0.24.58

10.0

.24

.57

10.0.24.5410.0.24.53

10.0.24.62

10

.0.2

4.6

1

10.0.24.6510.0.24.66

10.0.28.26

10.0.28.30

10.0.28.29

28.33

28.34

10.0.28.37

10.0.28.38

10.0.28.42

28.46

28.45

10

.0.2

0.7

0

10

.0.2

0.7

4

10

.0.2

0.6

9

10.0

.20

.85

10.0.20.73

10.0.20.77 10.0.20.78 10.0.20.89 10.0.20.90

STM1 X 4

10.0

.20

.82

10

.0.2

0.8

1

STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1STM1-0/2/0STM1-0/2/1

AS-0

STM4-4/1/1 STM4-4/2/1 STM4-5/1/1 STM4-5/1/2

STM1-0/1/2STM1-1/1/2STM1-2/1/2STM1-3/1/2 STM1-0/2/1

STM4-4/0/0 STM4-5/0/0

As-0

STM4-4/1/0 STM4-5/1/0

STM4-4/0/1 STM4-5/0/1

As-1

STM4-4/0/3 STM4-4/1/3 STM4-5/0/3

As-4

STM4-4/1/1 STM4-4/2/1 STM4-5/1/1 STM4-5/1/2

As-3

ST

M4-4

/0/2

S

TM

4-4

/1/2

ST

M4-5

/0/2

As

-1

As-0

STM1-0/1/3STM1-1/1/3STM1-2/1/3STM1-3/1/3

ST

M4

-4/0

/2

ST

M4

-4/1

/2S

TM

4-5

/0/2

As

-1

10

.0.2

0.6

5

As

-3

As-3

ST

M1

-0/1

/2

ST

M1

-0/2

/0

ST

M1

-1/1

/2

ST

M1

-1/2

/0

ST

M1

-2/1

/2

ST

M1

-3/1

/1

STM4-4/0/3 STM4-5/0/3

As-2

10

.0.2

0.8

6

As-1

As

-1

As-2

As-3

8.6

4

10.0

.24

.70

JRTR25 (M320)

STM4-4/0/0 STM4-4/1/0STM4-4/0/1STM4-4/1/1

ST

M4

-4/0

/3

ST

M4

-4/1

/3

STM4-4/0/2STM4-5/0/2

STM1-0/1/0 STM1-1/1/1STM1-1/2/0STM1-2/1/0STM1-3/1/0

Ge-0/0/0

As-0

As-2

As

-110

.0.2

4.6

9

STM4-4/0/2 STM4-5/0/2

As-0

As-0

STM4 X 2

10.0.28.49

10.0.28.50

AS-0

AS-2

STM4-0/1/0STM4-0/2/0STM4-1/2/0STM4-1/3/0

ST

M4

-0/1

/0

STM1-0/1/2 STM1-0/2/2 STM1-1/1/2 STM1-1/2/2 STM1-2/1/1STM1-2/2/1 STM1-3/1/3

STM4 X 2

10.0.28.25

10.0.28.41

ST

M4-0

/1/0

S

TM

1-1

/2/0

AS

0

1 X STM410.0.16.42

10.0.16.41

ST

M4

X 4

As-5

As-5

As-0

As-5As-5

STM4-4/0/2 STM4-5/0/2

As-6

Ge-0/2/0

As-5

As6

STM4-4/1/0 STM4-5/1/0

As3

STM4-4/1/1 STM4-5/1/1

As1

STM4-4/0/0 STM4-5/0/0

As4

STM4-4/0/1

STM4-5/0/1

STM4-4/0/1

STM4-4/0/0 STM4-5/0/0

As3

STM4-5/0/1

As4

STM4-4/0/3 STM4-4/1/3 STM4-5/0/3 STM4-5/1/3

As3

JRTR29 (M320)

As-3

STM1-0/1/1STM1-0/2/0 STM1-1/1/0 STM1-3/1/1

As-5

STM1-0/1/2 STM1-0/2/2 STM1-1/1/2 STM1-1/2/2 STM1-2/1/1STM1-2/2/1 STM1-3/1/3

As-4

AS-2

AS-4

AS-4

As-6As-6

STM4-4/1/0 STM4-5/1/0

As1

STM4-4/1/1 STM4-5/1/1

As2

Ge-1/0/0

Ge-1/0/2

Ge-0/0/0

Ge-1/0/0Ge-1/2/0

Ge-1/0/0

Ge-1/0/2

Ge-0/0/0

Ge-0/1/0Ge-1/2/0

Ge-0/0/0

Ge-0/0/2

Ge-1/0/0

Ge-1/0/2

Ge-0/0/2STM4-0/1/0STM4-0/2/0STM4-0/3/0STM4-1/2/0

Ge-1/0/0

Ge-0/0/2Ge-0/1/0

Ge-1/1/0

Ge-1/2/0

Ge-0/2/0Ge-1/2/0

Ge-0/0/0

Ge-1/1/0

Ge-1/0/0

Ge-0/1/0

Ge-0/0/0

Ge-1/0/2

STM4 – 0/1/0STM4 – 1/2/0

As-0

Ge-1/0/0

Ge-0/0/2

Ge-3/0/0

Ge-3/0/2

STM1- 2/1/0STM1- 2/1/1STM1- 3/1/0STM1- 3/1/1

Ge-2/0/2

Ge-3/0/2

Ge-2/0/0Ge-3/0/0

STM1- 2/1/0STM1- 2/1/1STM1- 3/1/0STM1- 3/1/1

As-0As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0

As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1

As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1

As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1STM1-0/2/0STM1-0/2/1

AS-0

Ge-1/1/0

Ge-0/1/1

Ge-0/0/0

Ge-1/0/0

Ge-1/0/2

STM4-0/1/0STM4-1/2/0

AS-0

Ge-0/0/0

Ge-1/0/0

Ge-0/0/2

Ge-1/0/2

Ge-0/0/0

Ge-1/0/0

Ge-0/2/0

Ge-1/1/0

Ge-0/1/1

As-0STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1STM-0/2/0

As-0STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1STM-0/2/0

As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1

As-0

STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1

Ge-1/1/0

Ge-1/0/0

Ge-0/1/0

Ge-0/0/2

Ge-1/0/0

Ge-0/0/0

Ge-1/0/0

Ge-0/0/2

Ge-1/0/0

Ge-0/1/0

Ge-0/2/0

Ge-0/0/0Ge-1/1/0

ST

M4

-0/1

/0

ST

M4

-1/2

/0

AS

0

ST

M4

-0/1

/0

ST

M4

-1/2

/0

AS

0

ST

M4

-0/1

/0

ST

M4

-1/2

/0

AS

0

ST

M4

-0/1

/0

ST

M4

-1/2

/0

AS

0

Ge-2/0/0

Ge-2/0/0

Ge

-2/0

/0

Ge-2/0/0

FE

GUJ_NS-208_1

GUJ_NS-208_2

FE

AB

T0

1_

NS

-20

8_

2

AB

T0

1_

NS

-20

8_

1FE

FEIS

B0

2_

NS

-20

8_

1

ISB

02

_N

S-2

08

_2F

E

FE

JL

M0

1_

NS

-20

8_

2

JL

M0

1_

NS

-20

8_

1FE

FE

SWL01_NS-208_1

SWL01_NS-208_2

FE

FE

GE

SWI80

SWI79

GE

FSB02_NS-208_2

FSB02_NS-208_1

FE

FE

SWI63

SWI64

HYD01_NS-208_2HYD01_NS-208_1

FE

FE

GE

SWI81 SWI82

QUT01_NS-208_2QUT01_NS-208_1

FE

FE

GE

SWI72SWI71

KHI03_NS-208_2KHI03_NS-208_1

FE

FE

GE

BD_SWI56BD_SWI55

GE

SWI75

SWI76

GE

SWI73SWI74GE

SWI59 SWI60

GE

SWI77SWI78

GE

GE

GE

SWI02

SWI01

LAH01_ISG-2000_1

LAH01_ISG-2000_2

FE

ISG

SWI47

FE

SWI48

ISG

GE

GE

GE

SWI20

SWI19

FE

SWI50

FE

SWI49

LAH02_NS-208_1

LAH02_NS-208_2

JRTR17(M10i)

Ge-0/0/0

Ge-1/0/0

10.0.24.25 As-0STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1STM1-0/2/0STM1-0/2/1

JRTR18(M10i)

Ge-0/0/0

Ge-1/0/0

10.0.24.26As-0STM1-0/1/0STM1-0/1/1STM1-1/2/0STM1-1/2/1STM1-0/2/0STM1-0/2/1

GE GE

SWI25SWI26

GEFE

SWI68

FE

PWR01_NS-208_2 PWR01_NS-208_1

SWI67

GEFE FE

ISB01_NS-208_2 ISB01_NS-208_1

GE GE

SWI25SWI26

SWI58 SWI57

GE

GE

GE

FE

SWI66

MUL01_NS-208_1

MUL01_NS-208_2

GE

SWI23

FE

SWI65

GE

GE

FE

SWI62

FSB01_NS-208_1

FSB01_NS-208_2

GE

FE

SWI61

SWI14

SWI13

GE

GEFE

SWI69

SUK01_NS-208_2

GE

FE

SWI70

SUK01_NS-208_1

SWI30SWI29

GE

GEFE

SWI54 KHI02_NS-208_1

GE

FE

SWI53KHI02_NS-208_2

SWI22 SWI21

GE

GE GE

SWI51 SWI52

SWI18SWI17

ISGISG

KH

I01_IS

G-2

000_1

KH

I01_IS

G-2

000_2

Ericsson Internal




Figure 2 Network Topology

Figure 3 OPNET implementation of example topology

Figure 3 shows the equivalent OPNET implementation2.

Save the network model in a scenario. Select Menu Scenarios->Manage Scenario.

Rename the present scenario to Network Baseline Model scenario.

2 Configuration files for a pair of routers in KHI were not available

Ericsson Internal




3.2 Network Traffic Model

Only two traffic types are considered in this document. Other traffic flows can be modeled in a similar fashion.

Figure 4 Traffic import methods

Voice traffic

- Diffserv marking = Expedited Forwarding

- VRF = Voice (In this topology Route Target = 10)

- Traffic load-balanced to PE routers

Sigtran traffic

- Diffserv marking = Assured Forwarding (AF11)

- VPN = Sigtran (In this topology Route Target = 80)

- Traffic is not balanced over two PE routers. Traffic is sent on one active path to one PE. The standby path for Sigtran traffic is over the second PE router.

As per Mobile-PBN design recommendations both traffic types are contained in their respective VPNs.

The two considered traffic matrices are given in Figure 5 and Figure 6 for Sigtran and Voice traffic respectively.

Ericsson Internal




Figure 5 Sigtran traffic matrix

SOURCE LAH01 LAH02 GUJ01 KHI01 KHI02 KHI03 SUK01 QUT01 HYD01 ISB01 ISB02 PWR01 JLM01 ABT01 FSB01 FSB02 SWL01 MUL01LAH01 X 128.012 116.44 3.624 1.376 1.236 1.88 1.928 4.432 2.84 4.792 8.312 26.496 4.844 0 9.144 14.416 13.612LAH02 130.336 X 270.772 8.464 3.216 2.892 4.364 4.48 10.284 6.632 11.188 19.296 61.508 11.248 0 21.356 33.468 31.596GUJ01 89.472 208.16 X 19.608 9.432 3.848 3.664 8.928 8.64 24.524 14.9 25.028 33.884 9.448 0 28.44 28.116 43.576KHI01 5.888 13.748 31.856 X 70.072 63 46.076 76.292 116.352 5.676 9.58 18.136 10.776 9.932 0 9.712 20.184 15.772KHI02 2.236 5.224 15.328 71.324 X 24.368 27.516 39.264 72.584 2.156 3.64 8.724 5.184 5.088 0 3.692 8.036 7.588KHI03 2.012 4.696 6.256 63.172 24.004 X 7.024 17.112 16.564 1.94 3.272 3.56 2.116 2.076 0 3.316 3.28 3.096SUK01 3.052 7.088 5.956 25.356 17.544 2.956 X 6.856 6.636 6.084 3.116 5.232 2.016 1.976 0 3.16 3.124 3.86QUT01 3.136 7.28 14.508 41.452 24.056 8.04 7.652 X 18.048 6.244 3.2 10.152 4.908 4.812 0 3.244 7.608 8.12HYD01 7.2 16.712 14.04 71.376 42.732 7.732 7.36 17.932 X 14.34 7.348 12.34 4.752 4.66 0 7.448 7.364 9.104ISB01 2.808 6.56 26.52 3.468 1.316 1.184 1.128 3.816 8.76 X 70.124 129.492 58.18 62.556 0 3.38 11.012 10.396ISB02 4.74 11.072 14.74 5.852 2.224 2 1.904 1.956 4.488 75.952 X 57.044 4.988 21.536 0 5.704 5.64 5.328

PWR01 8.224 19.088 24.76 11.08 5.332 2.176 3.196 6.2 7.54 99.676 36.804 X 8.376 23.34 0 6.208 9.476 10.74JLM01 13.12 30.456 19.22 6.632 3.192 1.304 1.24 3.02 2.924 58.284 13.712 8.468 X 3.196 0 9.62 9.512 11.76ABT01 4.792 11.128 9.348 6.46 3.108 1.268 1.208 2.94 2.848 47.5 10.76 18.072 3.164 X 0 3.62 3.576 4.424FSB01 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 0 0FSB02 8.056 18.816 25.052 10.16 4.888 1.996 1.9 1.952 4.476 3.284 5.54 6.028 8.476 3.512 0 X 48.356 59.784SWL01 12.7 29.484 24.772 10.044 4.832 1.972 1.876 4.572 4.428 7.488 5.48 9.2 8.38 3.476 0 33.224 X 40.608MUL01 11.992 27.836 24.8 9.484 4.564 1.864 2.32 4.88 5.472 10.096 5.172 10.428 10.36 4.296 0 44.288 43.788 X

Figure 6 Voice traffic matrix

OPNET allows various ways to import traffic data. See Figure 4. “From Spreadsheet..” import method is used to build the traffic model here.

Setting up the Spreadsheet is a time consuming and error-prone process. Not only the Spreadsheet must be in a certain format, but it must also have correct traffic source and destination IP addresses.

A shortcut is proposed to speed up the traffic modeling process.

Ericsson Internal




Create artificial MPLS VPNs traffic

flows

Export the artificial traffic flows to a

Spreadsheet

Edit the exported traffic flow

Spreadsheet. Set real traffic demands

Import the Spreadsheet in to

the project

Figure 7 Traffic modeling method

It is recommended to first create artificial traffic flows among the nodes and then export the resulting traffic matrix to a Spreadsheet. Edit the Spreadsheet as per the real traffic matrix and then import it to the project. See Figure 7.

Here are the steps:

1 Start by selecting all PE routers in the project space. Right-click on any PE router and choose Select Similar Nodes. Select any missing nodes by holding the CTRL button and clicking on the node. See Figure 8.

Figure 8 All PE routers selected

Ericsson Internal




Figure 9 Creating MPLS VPN flow for Voice traffic (RT=10 and DSCP = EF)

2 Select Menu Traffic->Create Traffic Flows-> MPLS VPN. Window as shown in Figure 9 pops up. Set Route Target and Type of Service by clicking on the relevant tabs. Since these are artificial flows, leave the packets/sec and Bits/sec fields as they are. Set the color of the flow in case there is a need to visualize it, later on.

Note that Route Target = “10” is chosen. This action, therefore, creates Voice traffic flows among all nodes that contain Voice VPN.

3 Repeat the same process for Sigtran traffic. This time use Route Target = “80” and Type of Service as “AF11”

4 Once artificial demands are created, export this artificial traffic matrix to an excel sheet.

Select from Menu Traffic->Export Traffic Flows->To Spreadsheet

5 Select options Display file in spreadsheet program and Export node names. See Figure 10.

The first option opens the exported traffic matrix in Spreadsheet that can be saved for editing.

Ericsson Internal




Figure 10 Traffic matrix export

6 Click Export. In the window that pops up, give a meaningful name to the file and save it.

7 At the end of this action, a window with Traffic Matrix Spreadsheet pops up. See Figure 11.

It contains a list of traffic demands detailing each flows:

Source name, IP address and Port address

Destination name, IP address and Port address

Protocol

Type of Service

Average Packet Size

Traffic in Mbps. This is given in the last column.

Ericsson Internal




Figure 11 Exported traffic matrix (shown in MS Excel)

All traffic parameters in the Spreadsheet (Figure 11) remain unchanged, only the traffic volume in the last column is modified to reflect the real traffic matrix.

8 The next step is to take each entry in the traffic matrices, given in Figure 5 and Figure 6, and fill in the exported traffic Spreadsheet.

For example, consider the traffic demand in 3rd row in Figure 11.

Ericsson Internal




This is Sigtran traffic demand (see Type of Service = “AF11”) between RTR01 at LHR01, and RTR05 at KHI01 sites.

In the Sigtran traffic matrix (Figure 5) see that the traffic demand is 9.6Mbps (the 1st row and the 4th column). This value can be substituted in the exported Spreadsheet (Figure 11).

It is to be kept in mind that Sigtran traffic is not load-balancing. Therefore, choose two nodes on two sites that are in the same “color”, for example red and red, or blue and blue. Both RTR01 and RTR05 are connected to blue topology, so set the demand between these two nodes as 9.6Mbps.

This also means that Sigtran traffic between RTR02 and RTR08 is zero. So that it can be set in the same step. Similarly there is no traffic from blue to red topology under normal conditions. Therefore, these two traffic values can also be set as zero. Following picture emerges for one Sigtran traffic demand between LHR01 and KHI01 sites:

RTR01 (blue) and RTR05 (blue) : 9.6Mbps

RTR02 (red) and RTR08 (red): 0Mbps

RTR01 (blue) and RTR08 (red): 0Mbps

RTR02 (red) and RTR05 (blue): 0 Mbps

9 Repeat step 9 for Voice traffic. The filling-in process is slightly more complex as each traffic demand must be halved. Voice traffic is load-balanced over two router PE pairs. For example total Voice traffic demand between the two sites is 3.6Mbps, then

RTR01 (blue) and RTR05 (blue) : 1.8Mbps

RTR02 (red) and RTR08 (red): 1.8Mbps

RTR01 (blue) and RTR08 (red): 0Mbps

RTR02 (red) and RTR05 (blue): 0 Mbps

10 Set all traffic demands that are not relevant, equal to zero.

11 Once the traffic model is built in the Spreadsheet, it can be imported back to the project space.

Select from Menu Traffic->Import Traffic Flows->From Spreadsheet…

Then enter the full path to the Spreadsheet with traffic model. Click Import.

Ericsson Internal




Note: It is important to maintain the .txt format of the Spreadsheet. If the file is “Saved As” in the MS Excel format, import process will report errors due to change in format. It is advisable to use File Explorer application to copy and paste the file from one directory to another.

4 IP Routing

IGP Convergence Time is a critical performance parameter. Network operators use IGP Convergence time as a key metric for any IGP protocol such as IS-IS and OSPF. There are different types of network events that can cause IGP convergence. These network events are as following [11] :

Link removal

Unplanned link failure

Line card failure

Route changes such as withdrawal, flap, next-hop change, and cost change.

Session loss due to loss of peer or adjacency

Link recovery

Link insertion

Methodology for studying and tuning the convergence times of dominant IGP routing protocols is discussed in this chapter. OPNET Discrete Event Simulation (DES) is used for studying network convergence.

Setup Discrete Event Simulation (DES) reporting

Run DESStudy DES

Reports for IGP covergence

Change parameters as

required

Figure 12 IGP Convergence Time tuning using DES

The process for studying and tuning IGP Convergence Time is given in Figure12. First the relevant reporting system in DES environment is set up. DES is run and Convergence Time results are studied. Further optimizations can be made by changing the routing protocols parameters. It is also possible to introduce link failures in the network, and check the IGP Convergence Time.

Ericsson Internal




4.1 OSPF Convergence Time

OSPF Convergence Time can be studied in the following way.

1 Duplicate Network Baseline Model scenario, by selecting Menu Scenarios-> Duplicate Scenario, and rename it to OSPF Convergence scenario.

2 DES reporting needs to be configured.

Select from Menu DES->Choose Individual Statistics.

Choose Global Statistics->OSPF, as shown in Figure 13

3 Run DES. Select Menu DES->Discrete Event Simulation.

Figure 13 OSPF convergence report settings

Ericsson Internal




4 View Results by right-clicking on the project space (away from all objects).

See Figure 14 for results and reporting.

5 Click on the DES Graphs tab and select from the tree Global Statistics->OSPF.

6 Check boxes for

Network Convergence Activity and

Network Convergence Duration statistics.

Figure 14 DES reports

Ericsson Internal




Network Convergence Activity plots a value of 1 for the interval when convergence activity is detected in the topology.

Network Convergence Duration plots the time it took the network to converge after each period of convergence activity.

7 Click Show. Figure 15 shows the zoomed time convergence plots. To change the time scale to seconds, right-click on the graph panel and choose Time Axis->Seconds

Result: Convergence Time for OSPF in this network is about 70 seconds.

Figure 15 OSPF Network Convergence Activity and Duration graphs

Ericsson Internal






8 For further optimization, OSPF timers can be changed.

Select Menu Protocols->OSPF->Configure Interface Timers. See Figure 16. Note timer settings.

Similarly SPF timers can be tuned using Menu Protocols->OSPF->Configure SPF Calculation Timers. See Figure 17.

Ericsson Internal




Figure 18 OSPF convergence for Hello timer = 2 seconds.

9 Repeat Steps 2 to 5.

For example for Hello Interval = “2 seconds”, the Convergence Time is ”~28seconds” (ignore the time in transient part when network is ramping up). See Figure 18.

Impact of other parameters can be studied in a similar fashion.

4.1.1 Convergence Time after Link Failure

It is possible to study IGP routing protocol Convergence Time in case of link failures. A link/node failure can be introduced.

1 Open the object palette (icon next to the printer icon), search and select the Failure Recovery icon and drag it on to the project editor. Close the object palette.

Ericsson Internal




Figure 19 Failure introduction mechanism

2 Double click on the Failure Recovery object.

Choose Edit Attributes. See Figure 19.

Click the Link Failure Recovery Specifications attribute.

Set the rows to 1.

Configure the RTR05<->RTR24 link, for example, to fail at 1200seconds

3 Run DES.

Select Menu DES->Configure Run Discrete Event Simulation

Results are shown Figure 20.

Ericsson Internal




Figure 20 OSPF routing convergence after link failure

Result: It takes 10 seconds for OSPF to converge after a link failure.

For faster convergence, impact of faster timers on Convergence Time can be studied in similar fashion.

4.2 IS-IS Convergence Time

IS-IS is a hierarchical routing protocol like OSPF. IS-IS uses two levels of hierarchy: Level 1 and Level 2. Level 1 systems route within an area. When the destination is outside the area, they route toward a Level 2 system.

Each router resides in exactly one level. Like OSPF, it also implements a Link-State Database per every area and every level.

Ericsson Internal




IS-IS Scope

Single Area (49.0752)Single Level (Level 2)

Secondary 4Secondary 3

Secondary 2

Primary 2

Primary 3 Primary 4

Primary 1

Secondary 1

Secondary 5 Secondary 6

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

SR

Figure 21 IS-IS in the MPLS backbone

Due to the size of the network, a single backbone area is sufficient. All backbone routers are configured to be part of a single Level 2 area.

The variables pertinent to IS-IS SPF algorithm calculations are defined as:

Minimum Interval (seconds): Specifies the minimum interval between SPF calculations. The Router will perform at most 1 SPF calculation in this interval.

Initial Wait (milliseconds): Specifies the amount of time the router must wait before doing the very first SPF calculation (or the first SPF calculation AFTER the network has converged).

Wait Time Increment (milliseconds): Specifies the increment to the waiting time between SPF calculations. For example, if this attribute is set to 1000 milliseconds (1 sec), then the router must wait 1 sec. between the first and second SPF calculations, 2 (1 + 1) seconds between the second and third calculations, 4 (2 + 2) seconds between the third and fourth calculations and so on.

Ericsson Internal




Figure 22 IS-SPF SPF timers calculations

IS-IS Convergence Time can be studied in the following way:

1 Duplicate Network Baseline Model scenario, by selecting Menu Scenarios-> Duplicate Scenario, and rename it to IS-IS Convergence scenario.

2 DES reporting for IS-IS needs to be configured.

Select Menu DES->Choose Individual Statistics for IS-IS.

3 Select Menu Protocols->IS-IS->Configure SPF Calculation Parameters.

Window as shown in Figure 22 pops up.

Note: OPNET can set Minimum Interval = 1 sec.

Instead of dealing with link failure separately, it is introduced as part of Convergence Time study.

4 Open the object palette (icon next to printer icon), select the Failure Recovery icon and drag it onto project editor. Close the object palette.

5 Double-click on the Failure Recovery object, and choose Edit Attributes. This is exactly the same process as done for OSPF. Attribute window is shown in Figure 19.

Ericsson Internal




6 Click the Link Failure Recovery Specifications attribute.

Configure the RTR05<->RTR24 link to fail at “200seconds”.

7 Choose DES->Configure Run Discrete Event Simulation.

Set Values per statistics to “3600” so a value is written for each statistic per second. Results are shown Figure 23.

Figure 23 IS-IS routing convergence (failover at 200seconds)

Result: It can be seen that network convergence activity happens at the start and at the failover time (200seconds). It takes about half a second for the routing to converge. This is a good evidence of fast convergence of IS-IS protocol, and is one of the reason for its popularity in modern MPLS networks.

Further optimization of IS-IS protocol can be done by changing the time parameters in Step 3 and running the DES again.

Ericsson Internal




4.3 BGP Convergence Time

The scope of this service is the Edge-to-Edge MPLS network. Client networks are not modeled. OPNET facilitates the setting of MPLS VPN traffic flows on loopback addresses; therefore client networks’ modeling is not required. Since VRF interfaces towards client networks are not active, VRF routing tables are empty.

In any case BGP Convergence Time tuning can be done exactly in the same way as performed for OSPF and IS-IS protocols.

8 Set up the BGP reports. See Figure 13.

Figure 24 BGP Timer setup

9 Set up BGP timers by selecting Menu Protocols->BGP->Configure Timers.

Figure 24 shows the window giving options to set up different BGP timers.

10 Run DES.

The results can be studied in the same way as done for OSPF and IS-IS protocols.

Ericsson Internal




5 IGP Metrics Optimization

IGP link metrics optimization is one of the classical ways of load-balancing traffic. In IP networks Shortest Path First (SPF) protocol is used to make the distributed routing decisions. The idea of metric optimization is based on the manipulation of link metrics in such a way that the traffic takes up the least utilized path. This path might be longer in terms of hops (and delay) but because the links are running at lower utilization the resulting traffic performance is expected to improve.

MPLS LDP does not use explicit paths and relies instead on SPF routing. Therefore, for topologies with LDP label switched paths, IGP metric optimization is important for performance improvement.

Two methods are discussed in this chapter. The first method involves setting up the metrics as per Mobile-PBN design recommendations. The other is to use a heuristic algorithm to solve the network optimization problem and find the set of optimized link costs.

First baseline network performance is established. Then the network is optimized with TE strategies. Performance comparisons are made to ascertain the impact of optimization on performance.

5.1 Network Performance Baseline

The topology considered in this scenario uses OSPF weight settings based on the division of a constant bandwidth by the interface bandwidth as in 108/(interface bandwidth in bps). This is a standard IGP scenario.

Reference bandwidth is set as 100Gbps.

Interface Bandwidth [bit/s] OSPF Metric10 GE 10 000 000 000 101 GE 1 000 000 000 100OC-3c/STM-1c 155 520 000 650STM-4 622 080 000 160STM-16 2 488 320 000 40STM-64 9 953 280 000 10FE 100 000 000 1 000E3 34 368 000 3 000E1 2 048 000 50 000

Table 1 OSPF Link Metrics

Ericsson Internal




Figure 25 Baseline performance. Links coloured by load

Figure 26 Link load colouring legend

Ericsson Internal




1 Select OSPF Convergence scenario. Select Menu Scenarios-> Duplicate Scenario. Rename the new scenario as Network Baseline Performance scenario.

2 Run Flow Analysis to establish the network performance under un-optimized conditions. The results show that Maximum Utilization is 124%. This network suffers from performance problems.

Performance Analyzer Results:

Measure ValueWAN Link - Number of overutilized links 4WAN Link - Maximum Utilization (%) 124WAN Link - Total Consumed BW (bps) 1.63296e+010WAN Link - BW Efficiency (%) 17.2LAN - Maximum LAN Utilization (%) 0.000000Demand - Total Active Demands 616Demand - Failed-Unroutable Demands 0

3 Visualize network links colored by load intensity.

Select Menu View->View Link Loads->Color by Link Load.

Coloring legend is shown in Figure 26.

All links with utilization more than 80% are colored red.

Links with utilization between 40% and 80% utilization are shown in yellow, and so on.

Some core links in Figure 25 are indicating high utilization while others are either empty or lightly utilized. This is because traffic has moved towards higher speed bundles as compared to the single STM-1 links. Recall that link metrics are set as per interface capacity: higher speed links have lower metrics and thus attract traffic.

Two optimization strategies are considered for IGP metrics optimization. The first scenario considers OPNET SPGuru IGP Metric Optimization wizard, and the other uses OSPF metrics settings as recommended by the Mobile-PBN reference design[8]. As it will be shown, both optimizations show considerable performance improvement by load-balancing the network.

5.2 IGP Metric Optimization Wizard

This utility is used to perform Traffic Engineering by optimizing the Interior Gateway Protocol metrics. The design action has three modes of operation:

Ericsson Internal




(1) Inspect - Analyze the current solution and create reports that describe the quality of the solution and the violations of the specified requirements.

Figure 27 Configuration of IGP metric optimization method

(2) Repair - Use the optimization algorithm to automatically repair the solution in order to satisfy the constraints.

(3) Optimize - Use the optimization algorithm to improve the solution quality with respect to the objective (Minimize Maximum Link Utilization, etc.) assuming that the current solution satisfies all requirements.

Following steps are taken for IGP metrics optimization.

Ericsson Internal




1 Select OSPF Convergence scenario. Then select Menu Scenarios-> Duplicate Scenario. Rename the new scenario as OSPF Optimization.

2 Start the igp_metric_optimization utility to “optimize” the topology.

Figure 28 Attribute settings for IGP metric optimization

3 Open Design->Configure/Run Design Action.

Configuration window as shown in Figure 27 allows different design action to be configured.

4 Arrange the design action by Technology (see left top corner of Figure 27).

5 Choose igp_metric_optimization.

6 Click Edit Attributes. Figure 28 shows the attributes window.

Ericsson Internal




Confirm that the Optimization Objective function is set to Min Max Link Utilization.

Set the Interior Gateway Protocol to OSPF (or IS-IS).

Figure 29 Improvement in link utilization reported per iteration

OSPF metric range is from 1 to 65535. Maximum Allowable Metric is set to “OSPF” meaning 65535.

Maximum Flow Analysis Runs is set to 100. Increase to 150 (or more) if no solution is obtained. Generally speaking, increasing the iterations improves the solution but at the cost of algorithm run time - there is a trade-off involved. However, very high number of iterations may bring only diminishing returns as solution approaches the optimality point.

Click OK.

7 Click Run on the main optimization design window (Figure 27).

Ericsson Internal




8 Figure 29 reports the Maximum Link Utilization in the network after every run. As evident from the picture the optimization algorithm is minimizing the utilization.

The final result is a solution with utilization lower than 80%.

Figure 30 Improvement in network after optimization

The result of this optimization can be seen in Figure 30. No red links are visible.

9 The result of optimization can be seen. Open Results.

Click on the Design-igp_metric_optimization tab.

Ericsson Internal




Select Global Tables->Change Summary.

This is shown in Figure 31

Performance MeasureInitial Value

Final Value

Changed Interfaces 10Affected Interfaces 60Degraded Interfaces 21Affected Demands 403Degraded Demands 259Violations 5 0Maximum Utilization (%) 124.1 76.03Average Utilization (%) 16.23 14.21Bandwidth Average Utilization (%) 12.62 11.76Maximum Hop Count 5 6Average Hop Count 3 3Bandwidth Average Hop Count 2.72 2.67Maximum Delay (milliseconds) 0.76 0.33Average Delay (milliseconds) 0.07 0.04Bandwidth Average Delay (milliseconds) 0.05 0.03Maximum Propagation Delay (milliseconds) 0 0.01Average Propagation Delay (milliseconds) 0 0Bandwidth Average Propagation Delay (milliseconds) 0 0Maximum Jitter 0.54 0.01Average Jitter 0.02 0Bandwidth Average Jitter 0.01 0

Figure 31 IGP Optimization report

Figure 32 shows improvement in link utilizations as result of IGP metric optimization.

The first link shows an improvement of 80.73% as the TE improved the utilization from 99.35% to 18.62%. Recall from Equation (1) that any reduction in link load will result in reduction of utilization.

It can be seen in the result sheet that significant utilizations were achieved with IGP TE optimization.

Ericsson Internal




As discussed earlier the improvement in performance would lead to improvement in performance.

Node Interface Link

Initial Utilization (%)

Final Utilization (%)

Change in Utilization (%)

Imported Network.RTR25-ISB01-M320-RE0so-2/1/0

Imported Network.RTR26-FSB01-M320-RE0 / so-2/0/2 (10_0_24_30) <-> RTR25-ISB01-M320-RE0 / so-2/1/0 124.1 43.37 -80.73

Imported Network.RTR24-KHI01-M320-RE0so-1/1/0

Imported Network.RTR25-ISB01-M320-RE0 / so-1/1/0 (10_0_20_38) <-> RTR24-KHI01-M320-RE0 / so-1/1/0 73.99 0 -73.99

Imported Network.RTR26-FSB01-M320-RE0so-2/0/2

Imported Network.RTR26-FSB01-M320-RE0 / so-2/0/2 (10_0_24_30) <-> RTR25-ISB01-M320-RE0 / so-2/1/0 91.25 24.41 -66.84


Imported Network.RTR30-FSB02-M320-RE0 <-> RTR28-KHI02-M320-RE0 94.2 60.15 -34.05

Imported Network.RTR20-QUTO1-M10i-RE0so-0/2/0

Imported Network.RTR28-KHI02-M320-RE0 <-> RTR20-QUTO1-M10i-RE0 89.34 59.51 -29.83


Imported Network.RTR28-KHI02-M320-RE0 <-> RTR20-QUTO1-M10i-RE0 92.48 65.97 -26.51


Imported Network.RTR35-ABT01-M10i-RE0 / so-0/2/0 (10_0_24_34) <-> RTR25-ISB01-M320-RE0 / so-3/2/1 74.06 61.99 -12.07


Imported Network.RTR29-ISB02-M320-RE0 <-> RTR28-KHI02-M320-RE0 75.48 66.41 -9.07

Imported Network.RTR30-FSB02-M320-RE0so-2/1/0

Imported Network.RTR30-FSB02-M320-RE0 <-> RTR29-ISB02-M320-RE0 68.46 60.73 -7.72


Imported Network.RTR30-FSB02-M320-RE0 <-> RTR29-ISB02-M320-RE0 70.69 65.23 -5.46

Imported Network.RTR42-SWLO1-M10i-RE0ge-0/0/0

Imported Network.RTR42-SWLO1-M10i-RE0 / ge-0/0/0 (10_0_28_34) <-> RTR41-SWLO1-M10i-RE0 / ge-0/0/0 9.2 4.95 -4.25

Imported Network.RTR13-KHI02-M10ige-0/1/0

Imported Network.RTR28-KHI02-M320-RE0 <-> RTR13-KHI02-M10i 31.32 27.3 -4.01

Imported Network.RTR14-KHI02-M10ige-0/0/0

Imported Network.RTR14-KHI02-M10i / ge-0/0/0 (10_0_20_45) <-> RTR13-KHI02-M10i / ge-0/0/0 9.43 5.42 -4.01

Imported Network.RTR19-QUTO1-M10i-RE0ge-0/0/0

Imported Network.RTR20-QUTO1-M10i-RE0 / ge-0/0/0 (10_0_20_50) <-> RTR19-QUTO1-M10i-RE0 / ge-0/0/0 5.86 2.69 -3.17

Figure 32 Improvement in link utilizations as a result of Traffic Engineering using OSPF optimization

Ericsson Internal




Demand Name

Initial Delay (ms)

Final Delay (ms)

Change in Delay (%)

Change in Propagation

Initial Jitter

Final Jitter

Change in Jitter (%)

RTR31-GUJ01-M10i-RE0 (ge-1/0/0_621) --> RTR07-FSB01-M10i-RE0 (ge-1/0/0_621) 0.75 0.01 -98.54 9.59 0.54 0 -100

RTR01-LHR01-M10i-RE0 (ge-1/0/0_621) --> RTR07-FSB01-M10i-RE0 (ge-1/0/0_621) 0.75 0.01 -98.41 -71.03 0.54 0 -100

RTR01-LHR01-M10i-RE0 (ge-1/0/0_621) --> RTR15-MUL01-M10i-RE0 (ge-1/0/0_621) 0.76 0.01 -98.03 15.46 0.54 0 -100

RTR117-PWRO1-M10i-RE0 (ge-1/0/0_621) --> RTR07-FSB01-M10i-RE0 (ge-1/0/0_621) 0.54 0.01 -97.97 0 0.54 0 -99.81

RTR01-LHR01-M10i-RE0 (ge-1/0/0_621) --> RTR44-FSB02-M10i-RE0 (ge-1/0/0_622) 0.76 0.02 -97.89 -73.66 0.54 0 -100

RTR31-GUJ01-M10i-RE0 (ge-1/0/0_621) --> RTR15-MUL01-M10i-RE0 (ge-1/0/0_621) 0.76 0.02 -97.89 -11.8 0.54 0 -100

RTR31-GUJ01-M10i-RE0 (ge-1/0/0_621) --> RTR44-FSB02-M10i-RE0 (ge-1/0/0_622) 0.76 0.02 -97.89 -100 0.54 0 -100

RTR117-PWRO1-M10i-RE0 (ge-1/0/0_601) --> RTR41-SWLO1-M10i-RE0 (ge-1/0/0_601) 0.55 0.01 -97.44 0 0.54 0 -99.81

RTR117-PWRO1-M10i-RE0 (ge-1/0/0_601) --> RTR44-FSB02-M10i-RE0 (ge-1/0/0_601) 0.55 0.01 -97.44 23.31 0.54 0 -99.81

RTR117-PWRO1-M10i-RE0 (ge-1/0/0_621) --> RTR44-FSB02-M10i-RE0 (ge-1/0/0_622) 0.55 0.01 -97.44 23.31 0.54 0 -99.81

RTR117-PWRO1-M10i-RE0 (ge-1/0/0_601) --> RTR15-MUL01-M10i-RE0 (ge-1/0/0_601) 0.55 0.02 -97.07 -18.18 0.54 0 -99.81

RTR117-PWRO1-M10i-RE0 (ge-1/0/0_621) --> RTR15-MUL01-M10i-RE0 (ge-1/0/0_621) 0.55 0.02 -97.07 -18.18 0.54 0 -99.81

Figure 33 Improvement in traffic performance as a result of Traffic Engineering using OSPF optimization. Only some demands are shown due to space constraint.

Ericsson Internal




Figure 33 shows the improvement in traffic/demand performance parameters as result of IGP metric optimization. The table shows optimization improves the Edge-to-Edge delays. See column Change in Delay (%). Clearly QoS (delay and Jitter performance) has improved for traffic demands with improvement in utilization achieved by IGP optimization.

Results: New optimized OSPF weights are reported in Global Tables->Changed Interfaces and can be exported for usage in real network IGP Traffic Engineering. See Figure 34.

Node Interface LinkMetric Type

Final Metric

Imported Network.RTR20-QUTO1-M10i-RE0 so-0/2/0 Imported Network.RTR28-KHI02-M320-RE0 <-> RTR20-QUTO1-M10i-RE0 OSPF Cost 38Imported Network.RTR24-KHI01-M320-RE0 so-1/1/0

Imported Network.RTR25-ISB01-M320-RE0 / so-1/1/0 (10_0_20_38) <-> RTR24-KHI01-M320-RE0 / so-1/1/0 (10_0_20_37) OSPF Cost 88

Imported Network.RTR25-ISB01-M320-RE0 so-2/1/0

Imported Network.RTR26-FSB01-M320-RE0 / so-2/0/2 (10_0_24_30) <-> RTR25-ISB01-M320-RE0 / so-2/1/0 (10_0_24_29) OSPF Cost 60

Imported Network.RTR25-ISB01-M320-RE0 so-3/2/1

Imported Network.RTR35-ABT01-M10i-RE0 / so-0/2/0 (10_0_24_34) <-> RTR25-ISB01-M320-RE0 / so-3/2/1 (10_0_24_33) OSPF Cost 38

Imported Network.RTR26-FSB01-M320-RE0 so-2/0/2

Imported Network.RTR26-FSB01-M320-RE0 / so-2/0/2 (10_0_24_30) <-> RTR25-ISB01-M320-RE0 / so-2/1/0 (10_0_24_29) OSPF Cost 60

Imported Network.RTR28-KHI02-M320-RE0 so-1/1/0 Imported Network.RTR29-ISB02-M320-RE0 <-> RTR28-KHI02-M320-RE0 OSPF Cost 94Imported Network.RTR28-KHI02-M320-RE0 so-2/1/0 Imported Network.RTR30-FSB02-M320-RE0 <-> RTR28-KHI02-M320-RE0 OSPF Cost 62Imported Network.RTR28-KHI02-M320-RE0 so-2/1/1 Imported Network.RTR28-KHI02-M320-RE0 <-> RTR20-QUTO1-M10i-RE0 OSPF Cost 39Imported Network.RTR29-ISB02-M320-RE0 so-2/1/0 Imported Network.RTR30-FSB02-M320-RE0 <-> RTR29-ISB02-M320-RE0 OSPF Cost 50Imported Network.RTR30-FSB02-M320-RE0 so-2/1/0 Imported Network.RTR30-FSB02-M320-RE0 <-> RTR29-ISB02-M320-RE0 OSPF Cost 51

Figure 34 OSPF optimized metrics

5.3 IGP metrics based on Mobile-PBN recommendations for MPLS LDP

The design recommendations of Mobile-PBN reference design solution [8] are considered here. The objective is to balance the network, and also to ensure that traffic from a site does not transit another site on its way to destination.

Figure 35 gives an overview of the IGP metric settings for LDP. Only a couple of sites are shown at each location to keep the picture uncluttered. M320 routers represent the core routers while M10is represent the PE routers.

Though the design recommendations are for primary and secondary sites, the same argumentation holds true for this topology of edge and core routers. Link metrics M, N, m and n must fulfill the condition [8]:

Ericsson Internal




M320

M320

M320

M320

M320

M320

M320 M320

M10i

M10i

M10i

M10i

M10i M10i

M10i

M10i

NM

NN

N

N

N

N

N

N

N

N

N

n n

n

n

n n

n

n

M

M

M

m m

m

m

Figure 35 OSPF metrics in the MPLS backbone for LDP label switched paths

M+N < 2n+m

This condition is fulfilled if an assumption is made that links in/towards sites are not faster than links in/between core sites:

N<=n (2)

M<=m (3)

The following settings were chosen for the topology:

N = n = 140

M = 50

Ericsson Internal




N = 100

These setting can be implemented by taking the following steps on each node.

1 First, open a new scenario.Select OSPF Convergence scenario. Select Menu Scenarios->Duplicate Scenario. Rename the new scenario as OSPF Metrics MPBN Metrics scenario.

2 Open any node’s attributes, and select IP Routing Protocols ->OSPF Parameters->interface information->Cost.

Set interface cost as discussed above. See Figure 36.

Figure 36 OSPF metric setting for a link

Ericsson Internal




Figure 37 Improvement in performance with Mobile-PBN OSPF metrics

3 This step has to be repeated for each connected interface in the topology,

This action ensures that traffic from sites does not get routed through other sites, and that the network is load-balanced in a better way.

4 For verification of traffic routing, run Flow Analysis (FLAN). The results show that maximum utilization has improved and is under 80%.

Performance Analyzer Results: Measure Value

WAN Link - Number of over-utilized links 0

Ericsson Internal




WAN Link - Maximum Utilization (%) 76.3WAN Link - Total Consumed BW (bps) 1.38695e+010WAN Link - BW Efficiency (%) 11.8LAN - Maximum LAN Utilization (%) 0.000000Demand - Total Active Demands 616 0

Figure 37 shows network with links colored by load. There are no red links in the topology after optimization. This means that in terms of reducing the maximum utilization Mobile-PBN metrics and IGP optimization algorithm have produces comparable results. However, the noticeable difference is the difference in the number of links with utilizations between 40% and 80% levels (yellow links).

This is intuitive as IGP optimization algorithm is explicitly searching for solutions that minimize the maximum utilization of the links. However, Mobile-PBN recommended metrics consider performance only implicitly. The recommendations assume that network has enough dimensioned capacity to ensure performance.

Which method should be used to optimize network?

It is clear that if the customer has implemented Mobile-PBN solution for MPLS LDP in the IP backbone then the method considered in 5.3 should be used, as this provides a consistent and deterministic approach to dimension and plan the network.

However, in case of arbitrary MPLS LDP topologies IGP optimization algorithm may be considered.

To summarize, utilization is the most important performance parameter in a network. It should be the focus of any Traffic Engineering optimization methodology. Lowering the utilization, improves the Quality of Service (QoS) of traffic demands. This in turn produces a better Quality of Experience (QoE) for users as reduced losses, delay and jitter leads to better application layer performance.

6 MPLS Optimization

MPLS Traffic Engineering mechanism is discussed is this chapter. MPLS Label Switched Paths (LSP’s) can be signaled with one of the following MPLS signaling protocols:

1. Label Distribution Protocol (LDP)

2. Resource Reservation Protocol with Traffic Engineering Extensions (RSVP-TE)

Ericsson Internal




As discussed in the previous chapter, LDP signaled LSP’s strictly follow the topology defined by the IGP and therefore do not provide any Traffic Engineering capabilities.

On the other hand by using RSVP-TE the operator keeps control on how the traffic flows through the network, allowing optimal use of network resources.

From a Mobile-PBN reference solution [8] point of view there are no specific requirements on the Label Distribution Protocol implementation, either LDP or RSVP-TE are valid options and convergence time in case of failure is the main focus from the requirements point of view. On the other hand, from a provisioning and maintenance point of view it is also desirable to keep the solution as simple as possible.

There are various options available to setup MPLS TE in OPNET SPGuru. Following methods are discussed in this chapter:

1. MPLS TE setup. This method setups explicit paths for primary and secondary paths. It considers an objective function (Min Max Link Utilization) in setting up the LSPs.

2. MPLS Tactical TE setup. This method looks at LSPs on congested links and attempts to find alternative paths in order to alleviate congestion.

3. MPLS Incremental TE setup. Does a variety of things, however, its most important application is to find a global optimization solution for existing MPLS primary and secondary paths.

Method 1 is useful for a global solution where an operator has decided to move from a MPLS LDP setup to MPLS RSVP TE setup, or even is a green field operator considering MPLS TE strategy. Method 2 is relevant for networks in which a small number of links are congested - the tactical planning algorithm moves a few LSPs away from congested inks, on to alternative links in an attempt to alleviate congestion. Method 3 attempts to optimize the MPLS RSVP TE network that is suffering from congestion problems.

In addition to the above steps, Survivability Analysis is also run. This action is especially useful for spotting capacity issues for secondary paths that come in to the picture in case of failures in the network.

Visual representation of the MPLS Traffic Engineering process is shown in Figure 38

Ericsson Internal




Create MPLS LSPs

Perform MPLS TE Optimization for secondary and Primary Paths

Perform MPLS Tactical TE if a few links are congested

Perform MPLS Incremental TE if majority of links are congested

Perform Survivability

Analysis

Figure 38 MPLS TE process

Generally speaking, the MPLS TE Optimization and MPLS Tactical TE Optimization steps give enough performance gains for the normal operation of network. However, Survivability Analysis and MPLS Incremental TE Optimization allow analysis and optimization of MPLS network’s performance in resilience mode.

Note: Link and LSP coloring (Administrative Groups) is the recommended option in Mobile-PBN reference design [8]. During the course of development of this SDI, link coloring was implemented. It was found that link coloring recommendations by Mobile-PBN solution work in OPNET implementation for primary paths, however, secondary paths fail because they inherit the properties of the primary paths which can not be overridden. This problem requires further investigation. More over, from an OPNET implementation point of view, link coloring is a time consuming process. Each interface in the topology has to be configured, as well as all LSPs have to be set up for path requirements.

Instead, a short-cut solution is shown that produces the same routing pattern, and can be used for performance optimization.

6.1 Mobile-PBN recommended solution

Mobile-PBN solution [8] recommends following LSP implementation between two sites. Please see Figure 39 for visualization.

Configuration on the “red “site router at Site 1 (S1_SR1):

Red Straight LSP:

Primary path: exclude blue and green links

Secondary path: exclude red links

Fast Reroute: remove constraints (by default the constraints of the primary path are inherited)

Crossed LSP:

Primary path: exclude red links

Ericsson Internal




SIte 2Site 1

S1_SR1

S2_SR1

S2_SR2

S1_SR2

LSP straight path: shortest path with

RED links

LSP straight path: shortest path with

BLUE links

Bypass path protecting straight RED must use

BLUE and GREEN links

Bypass path protecting straight BLUE must

use RED and GREEN links

Loopback S1_R1

Loopback S1_R2

Loopback S2_R1

Loopback S2_R2

Bypass to protect straight LSP from S1_SR1 to S2_SR1

Bypass to protect straight LSP from S1_SR2 to S2_SR2

Figure 39 MPLS LSP setup as per Mobile-PBN reference design

Secondary path: exclude blue links


Local LSP:

Primary path: exclude blue and red links

Secondary path: no restrictions


Ericsson Internal




The following is configured on the “blue “ site router in Site 1 (S1_SR2):

Blue Straight LSP:

Primary path: exclude red and green links

Secondary path: exclude blue links


Crossed LSP:

Primary path: exclude blue links

Secondary path: exclude red links


Local LSP:

Primary path: exclude blue and red links

Secondary path: no restrictions


An identical configuration is done on S2_SR1 and S2_SR2.

6.2 Creation of MPLS LSPs

In this section, methodology to setup MPLS LSPs among all PE routers will be discussed. The steps include:

Setting up a new scenario

Enabling MPLS and RSVP/LDP on all interfaces.

Selection of PE routers, and

Creation of full mesh between PE nodes

Ericsson Internal




Enable MPLS and RSVP on all interfaces

Select all PE routers

Create a full mesh of LSPs between

nodes

Figure 40 MPLS LSP creation process

Here are the implementation details.

1 Duplicate OSPF MPBN Metrics scenario and rename it to MPLS TE scenario.

2 Select Protocols-MPLS->Configure Interface Status.

Figure 41 Enabling MPLS on all interfaces

Figure 42 Enabling RSVP on all interfaces

Ericsson Internal




Select Enable and All routers.

3 Enable RSVP on all interfaces. Select Protocols-RSVP->Configure Interface Status.

Select Enable and Interfaces on All routers.

4 Select all PE routers in the project space. Right-click on any PE router and choose Select Similar Nodes.

Select any missing nodes by holding the CTRL button and clicking on the node.

See Figure 8, it shows topology after selection of PE routers.

5 Select Menu Protocols->MPLS->Full Mesh of LSPs between nodes.

Select Use Tunnel as Shortcut as No. See Figure 43.

Click Create.

This action will create a number of LSPs are per the number of selected nodes in the network.

At the lower left cornet of the project window, a message reports the creation of LSPs. See Figure 44.

Figure 43 Creating full mesh of TE tunnels between selected nodes

Ericsson Internal




Figure 44 LSP creation report

The resultant topology now has the following features:

OSPF metrics set up as per Mobile-PBN recommendations

MPLS RSVP TE using CSPF

No Explicit Routing

No secondary path

No MPLS Fast Reroute

6.3 MPLS Traffic Engineering Optimization

OPNET MPLS TE Design wizard computes the primary and (optionally) secondary explicit routes for the LSPs defined in an MPLS network. It uses a Traffic Engineering algorithm.

The TE algorithm finds one primary explicit route for each LSP. These primary routes are optimized to be routed over the shortest paths with respect to a user-selectable link cost metric and to minimize a user-selectable global objective function.

Ericsson Internal




Figure 45 Method to setup explicit primary and secondary LSPs

The TE algorithm is also used to find one secondary explicit route (ER) for each LSP to protect any single node, link, or Shared Risk Group (SRG) failure. A shared capacity protection scheme is used. The secondary routes for LSPs can share their reserved capacity as long as their primary ERs do not share a common failure condition.

Both primary and secondary routes are optimized with respect to a selected link metric and global optimization function.

Setting up MPLS TE explicit primary and secondary paths manually is a time-consuming process. Here, a short-cut method is shown that can reduce the time effort considerably.

Ericsson Internal




Here are the implementation details:

The explicit paths, shown in Figure 39 for Mobile-PBN LSP routing, use interconnect link between PE routers to switch from the red to blue topology.

1 Select the MPLS TE scenario.

2 To setup such a routing scheme, disable the interconnect links between core routers.

3 Select the interconnecting link between core routers and then use the button to disable/fail it.

The resulting topology is shown in Figure 45. Note the disabled links between PE routers.

Ericsson Internal




Figure 46 MPLS_TE Design Attributes

4 Select Design->Configure/Run Design Action.

5 Select mpls_te. In the tab for Target Scenario select Current. See Figure 46.

Ericsson Internal




Figure 47 MPLS_TE Design Attributes

6 Click Edit Attributes. Figure 47 shows the attributes window

Select Primary <->Secondary ER Relationship as Link Disjoint.

Choose Select Primary ER Computation and Secondary ER Computation subscriptions as 100%.

Note that Optimization Objective for both primary and secondary routes is Min Max Link Subscription

Click OK, and return to the design wizard.

7 Click Run.

Since Target Scenario was chosen as Current, design wizard will work on the same scenario and will not produce a new scenario.

Ericsson Internal




Figure 48 MPLS TE Design Wizard results

8 Click on View Reports button. See Figure 48.

9 Click on the Design-mpls_te tab and select LSP Explicit Routes Summary

Figure 49 Primary and secondary LSPs

10 Click Show to see the list of LSPs created. See Figure 49.

By clicking on the blue colored numbers in the sheet in the primary Hop Length (LSRs) and secondary Hop Length (LSRs), path details of primary and secondary LSPs can be seen.

11 Run Flow Analysis.

Explicit paths can now be visualized.

Ericsson Internal




Figure 50 Network browser

12 Select View ->Show Network Browser. See Figure 50.

Arrange the view to see LSPs by Source

Figure 51 Network browser with E1 explicit route selected

13 Click on any node and open the tree to see associated paths.

Ericsson Internal




Each node has two explicit paths: E1 and E2. E1 is the primary path while E2 is the secondary path.

For example, visualize E1 explicit route for LSP between RTR05 and RTR02 by opening node RTR05 and opening the tree for the relevant LSP. See Figure 51.

Figure 52 Explicit route shown project window

14 Click on E1 path, it will show the LSP route in the project browser.

An explicit path is selected as shown Figure 51 and visible in Figure 52.

The explicit route shown in Figure 52 is as per Mobile-PBN recommendations.

15 To inspect the secondary path routing, disable the link between RTR08 and RTR28 routers.

Ericsson Internal




Figure 53 Failed link between RTR08 and RTR28

Select the link and then use the button to disable/fail it. This is shown in Figure 53

Figure 54 E1 path is disabled. LSP now uses secondary route E2

16 Run Flow Analysis. Network Browser shows that E1 explicit route is invalid, and that LSP is using E2 explicit route. See Figure 54.

17 Click on the E2 path in Network Browser. This will show the path in project browser. See Figure 55. This is as per Mobile-PBN recommendations.

Ericsson Internal




Figure 55 Secondary path after link failure.

Inspection of other LSPs shows that primary and secondary explicit routes of Straight and Crossed LSPs are routed according to the Mobile-PBN recommendations.

Important: However, the Local LSPs that are not setup as per Mobile-PBN recommendation because of this short-cut method.

Consider the Local LSPs between the two PE routers. The primary explicit routes are not a problem, as both PE routers are adjacent. However, the secondary explicit routes are forced to route over core topology as interconnect links between core-routers were failed (step 2, see Figure 45) before running the MPLS TE wizard.

Therefore, secondary paths of Local LSPs need to be fixed.

OPNET QuickPlan wizard is used to fix this problem.

18 Choose one of the PE routers in the topology by right-click on the node icon.

For example, right-click on RTR05 and select Show Attached Paths

This action will make visible all LSPs attached to this node.

19 Select the LSP between RTR05 and RTR08.

20 Select Quick Plan->LSP Route Selection.

See Figure 56.

This action starts the Quick Plan utility.

See Figure 57.

Ericsson Internal




Figure 56 Selection of LSP between RTR05 and RTR08

Figure 57 Quick Plan wizard for LSP route selection

Ericsson Internal




Figure 58 LSP route selection in Quick Plan Wizard

21 Click Next all the way till the window shown in Figure 58 becomes visible.

In the Primary route window, select a Route Name. The first entry should be in green color indicating that this is the current primary path.

Click on this path, and then click on Select Primary button.

This path will be shown in project browser as a direct one hop LSP between the two PE routers.

22 Now select secondary Route. Select the candidate that shows the secondary explicit router as Figure 59.

23 Click Next all the way to finish the wizard.

Figure 59 Secondary LSP route selection from candidate LSPs list

Ericsson Internal




24 Repeat the same process for the LSP in the opposite direction, i.e. RTR08->RTR05.

25 Change the two LSPs between the rest of the PE pairs in the same fashion.

At the end of this process, the resulting explicit routing pattern should be as per Mobile-PBN recommendations of Figure 39.

The only difference is that Mobile-PBN solution uses color constrains, this solution on the other hand sets up explicit routes for primary and secondary paths.

26 Select Protocols->MPLS->Update LSP Details to accept the solution.

Figure 60 Load distribution to Primary Paths

Ericsson Internal




The resultant topology then has the following features:

o OSPF metrics set up as per Mobile-PBN recommendations

o MPLS RSVP TE

o Explicit Routing for primary path

o Explicit Routing for secondary path

o No MPLS Fast Reroute (this will be considered in Chapter 7).


Figure 60 shows the load distribution. One link is 80.95% utilized.

If MPLS overhead is taken away from this load, the maximum link utilization for the topology is around 76% which was achieved with implementation of Mobile-PBN recommended OSPF metrics in sub-section 5.3. The maximum utilization in both cases is comparable. The difference here is that now MPLS explicit paths are in place which provide fast and deterministic re-routing in case of failures.

28 Consider the impact of failures on network performance.

Take for example, the failure of link between RTR08 and RTR28, as shown in Figure 53.

Fail the link and run Flow Analysis

Results show that maximum utilization has increased from 81% to 102%.

Performance Analyzer Results: Measure ValueWAN Link - Number of overutilized links 1WAN Link - Maximum Utilization (%) 102WAN Link - Total Consumed BW (bps) 1.66675e+010WAN Link - BW Efficiency (%) 17.4LAN - Maximum LAN Utilization (%) 0.000000Demand - Total Active Demands 616Demand - Failed-Unroutable Demands 0MPLS LSP - Number of LSPs 1122

Ericsson Internal




Figure 61 Link load distribution after link failure

The resulting routing network load is shown in Figure 61.

Three links are now over utilized and maximum utilization has shot up to 102%

Clearly this network will have performance problem in case of failures. This can be fixed by either capacity expansion or re-optimization of the existing solution. The decision depends upon the number of links suffering from congestion in case of link failures.

If only a few links are showing congestions, use the Quick Plan utility or MPLS Tactical TE wizard (discussed in the next sub-section) to fix the problem.

Ericsson Internal




However, if a large number of links are showing congestion problems then a global optimization solution using MPLS Incremental TE wizard is recommended. This is discussed in sub-section 6.6.

If no improvements are possible then capacity expansion might be the only option.

OPNET facilitates the study of impact of network failures on performance. Survivability analysis is a tool in OPNET SPGuru that automatically fails one node/link at a time and analyses the impact on network performance.

6.3.1 Configlet for MPLS TE

Configlets may be generated that contain pseudo-code for setting up explicit paths. This is discussed in sub-section 6.7

6.4 MPLS Tactical Traffic Engineering Optimization

This action uses a wizard to interactively perform Tactical MPLS Traffic Engineering. This action focuses on using new or existing LSPs to alleviate congestion on a specific target link. The workflow includes steps to:

- Identify the current heavy utilization LSPs.

- Reroute an LSP to avoid the congested link.

- Confirm the change(s) and generate output reports.

- Iterate multiple times.

Identify the heavy utilization LSPs

Reroute an LSP to avoid congested

link

Confirm Changes in Utilization

(performance)

Figure 62 Tactical MPLS TE planning

For the selected link direction, the wizard presents the set of users of the link. The users are either existing LSPs or IP traffic flows that are directly using the link. The wizard allows rerouting existing LSPs onto alternate paths to avoid the congested link or creating and routing a new LSP to divert an IP traffic flow around the congested link.

Ericsson Internal




The wizard steps may be repeated multiple times to reroute multiple users. The resulting changes may be output as Configlet files with the commands to make the necessary MPLS changes. This is discussed in 6.7

Following implementation steps are taken for Tactical MPLS TE optimization.

1 Duplicate the MPLS TE scenario from the last sub-section and rename it to MPLS TE Tactical.


3 Select View->Visualize Link Loads->Color by Link Load.

Figure 63 shows link utilizations.

Figure 63 Flow analysis results for over-utilized link

Ericsson Internal




Figure 64 Selection of LSP between RTR05 and RTR117

4 Right-click on the over-utilized link, select Quick Plan->Tactical MPLS TE. See Figure 64.

Quick Plan window pops up.

See Figure 65.

See that link towards RTR24 (first row) is 80.95% utilized. This is the target of tactical planning.

Ericsson Internal




Figure 65 Quick Plan wizard for LSP route selection

Ericsson Internal




Figure 66 LSP route selection in Quick Plan Wizard

5 Click Next, window as shown in Figure 66 pops up.

It shows a list of LSPs using this link. LSPs are arranged in descending order of utilization.

The first LSP has 13% contribution to the total utilization (total carried traffic 19.754Mbps).

6 Click Next.

Figure 67 LSP route selection from candidates list

Ericsson Internal




The next window (shown in Figure 67) gives the possibility to choose alternative paths. For the given topology, Candidate 2 primary path (yellow dotted line) is selected. It routes the traffic away from the over-utilized link and over to a path touching RTR26.

7 Click Select Primary to select this Candidate 2 as primary path.

Leave secondary path as it is. No changes are required.

8 Click Next.

The wizard now routes the selected LSP over the new path, and recalculates the link utilization.

Figure 68 Result of tactical TE planning

See Figure 68. The link utilization has now reduced to 67.66%, bringing it under the threshold of 80%.

9 Click Next.

The next window gives an option to reiterate the same tactical optimizations.

Click No at this stage and end the wizard

10 At the end of this action, return to project space, and turn on the link color visualization.

Ericsson Internal




As visible from Figure 69 all links are under 80% utilization as a result of tactical MPLS LSP rerouting. There are no red links in the topology.

This method can be used iteratively to find new routes for LSPs in a network which has a small number of over utilized links. Instead of global optimization, a quick fix to performance can be achieved by rerouting a few LSPs.

Figure 69 Link load visualization after manual reroute of LSP

6.4.1 Configlet for Tactical MPLS TE

Configlet may be generated that contain pseudo-code for setting up explicit paths. This is discussed in sub-section 6.7

Ericsson Internal




6.5 Survivability Analysis

In addition to the MPLS TE methods discussed in this chapter, further insight into network performance is gained by performing a global Survivability Analysis.

1 Select Menu Flow Analysis->Configure/Run Survivability Analysis.

Figure 70 Configuration of Survivability Analysis

Ericsson Internal




Figure 71 Selection of reports for Survivability Analysis

The scope of analysis is single link failure, therefore unselect Nodes and select WAN Links. See Figure 70.

2 Click Select Reports. Open the selection tree, and select all reports. See Figure 71.

Click OK to return to the Configure/Run Survivability Analysis window.

3 Click Run. The first available results are provided by Flow Analysis. It reports the impact of failure of each link and the resultant.

Ericsson Internal




Figure 72 Results for Survivability Analysis

For example, in Figure 72, report for two link failure cases is shown.

The first link failure shows no impact on network performance; however, the second link failure causes the maximum utilization to degrade significantly to 140%.

4 Relevant survivability reports can be assessed via Flow Analysis Tables tab in Flow Analysis results. Figure 73 shows the set of available results.

Ericsson Internal




Figure 73 Reports for Survivability Analysis

Figure 74 Summary report of Survivability Analysis

5 Click on the Analysis-> Web Report Summary.

Figure 74 shows the worst case utilization in failure mode is 158.53% - roughly double the baseline utilization of 81%

It also shows that 55 link failure scenarios did not degrade performance; however, 52 scenarios caused the performance to worsen. This means that network has major capacity problems.

Ericsson Internal




Figure 75 Failure impact on demand performance

6 To see the impact of failures on traffic demands select Analysis-> Failure Impact-Demands.

Figure 75 shows a part of the report. It gives a list of traffic performance parameters for all the demands impacted, per failed link. In the first row, it can be seen that the link failure did not produce any impact. However, in the second row, the failure impacted all demands (51 out of 51) and that delay performance worsened by 8.24%!

For a small number of links, MPLS Tactical TE can be attempted, especially for high priority demands. For a large number of links, this might not be a feasible option, and global optimization with MPLS Incremental TE may be attempted.

Because of large number of congested links, a global re-optimization is attempted in sub-section 6.6

6.6 MPLS Incremental Traffic Engineering Optimization

This action performs an incremental MPLS Traffic Engineering optimization. This design action computes primary and (optionally) secondary explicit routes for LSPs.

The design action has four modes of operation:

(1) Inspection - Analyze the current solution and create reports that describe the quality of the solution and the violations of the specified requirements.

Ericsson Internal




(2) Fix - Use the optimization algorithm to automatically repair the solution in order to eliminate as many violations as possible.

(3) Optimization - Use the optimization algorithm to improve the solution quality with respect to the objective (Minimize Maximum Link Subscription, etc.) assuming that the current solution satisfies all requirements.

(4) Interactive - Run the design action through a Wizard User Interface that will step through the complete workflow.

The design algorithm may be used to find one secondary explicit route (ER) for each LSP to protect any single node, link, or Shared Risk Group (SRG) failure. A shared capacity protection scheme is used. The secondary routes for LSPs can share their reserved capacity as long as their primary ERs do not share a common failure condition.

The secondary routes are also optimized with respect to a selected link metric and global optimization function.

Note: MPLS Incremental TE Wizard is used in Interactive mode for MPLS optimization.

Following implementation steps are taken.

1 Duplicate the MPLS TE scenario from the sub-section 6.3 and rename it to MPLS TE Incremental.

2 Select Design->Configure/Run Design Function.

Arrange the available utilities by Technology. Select mple_te_incremental from the list.

Keep Target Scenario as current. See Figure 76.

3 LSP Sizing.

This action has an objective function that optimizes link subscription. The LSPs in this topology, however, are currently unsized. This means they are not requesting any bandwidth from the links.

LSPs are going to be sized before starting this part of performance optimization.

Note: Bandwidth reservation for LSPs is neither a Mobile-PBN design recommendation nor it is being proposed. It is merely a tool to facilitate the offline optimization objective functions used in the MPLS Incremental TE Wizard.

Ericsson Internal




Select the Design->Configure/Run Design Action menu item.

Expand the Link Dimensioning node in the tree viewer.

Expand the mpls_lsp_sizing design action.

Click on Edit Attributes button to see the parameter in detail.

Set the Target Utilization to “100%”.

The design action will then set the LSP reserved bandwidth equal to traffic flows it is carrying.

Click Run in the Configure/Run Design Action window.

The design action with then run Flow Analysis to determine the usage of each LSP, and produce reports indicating the changes that it made.

Click View Reports to see that all LSPs have been sized.

Ericsson Internal




Figure 76 MPLS_TE_INCREMENTAL wizard

Ericsson Internal




Figure 77 MPLS_TE_INCREMENTAL attributes

4 Select Edit Attributes. See Figure 77.

Select Primary <->Secondary ER Relationship as Link Disjoint.

Choose Select Primary ER Computation and Secondary ER Computation subscriptions as “100%”.

Note that Optimization Objective for both primary and secondary routes is Min Max Link Subscription

It is important to set Incremental Mode as Interactive

5 Click OK, and return to design wizard.

Ericsson Internal




Figure 78 Solution inspection by mpls_te_incremental wizard

Figure 79 MPLS_TE_INCREMENTAL wizard solution repair

6 Click Run.

7 The next window gives an option to inspect the current solution. Click Yes and proceed to the next window.

The wizard inspects the solution. See Figure 78.

Ericsson Internal




8 Click Next. The next window, shown in Figure 79, gives an option to repair the solution. Select Yes, and hit Next.

The wizard runs and repairs the solution. A summary report is given in the next window, see Figure 80. The repair solution fixed/routed all LSPs.

Figure 80 MPLS_TE_INCREMENTAL wizard solution repair report

Figure 81 MPLS_TE_INCREMENTAL wizard primary and secondary paths fix/routing

Ericsson Internal




A separate window reports the quality of solution in real-time. See Figure 81. Note that algorithm reports violations as some of the secondary LSP result in more than 100% link subscription. Around 8% secondary LSPs are non-compliant.

The red (and blue) line in Figure 81 shows that the wizard fixed/routed all primary LSPs. The light blue (and green) reports fixed/routed secondary LSPs. The fixing/routing part of the solution is in reference to TE objectives set in the fist part of the wizard.

Figure 82 MPLS_TE_INCREMENTAL gives an option to re-optimize the solution.

9 Click Next.

10 The next window, shown in Figure 82, gives an option to re-optimize the solution.

Select “Yes” and hit Next.

The design wizard attempts to find a global optimization solution for primary and secondary LSPs.

The design action searches for improvements that will minimize the maximum link subscription without violating the other constraints.

Ericsson Internal




Figure 83 MPLS_TE_INCREMENTAL optimization

See Figure 83. The algorithm attempts to find a better solution but could only level off after a certain point. Otherwise, the picture would show a sloping down curve showing reduction in cost.

Here are the results from Flow Analysis which show small improvement in solution for primary paths but at the cost of 8% secondary paths non-compliant to 100% limit.

Performance Analyzer Results: Measure ValueWAN Link - Number of overutilized links 0WAN Link - Maximum Utilization (%) 75.1WAN Link - Total Consumed BW (bps) 1.78892e+010WAN Link - BW Efficiency (%) 18.5LAN - Maximum LAN Utilization (%) 0.000000Demand - Total Active Demands 616Demand - Failed-Unroutable Demands 0MPLS LSP - Number of LSPs 1122

Ericsson Internal




Figure 84 Results of re-optimization by MPLS_TE_INCREMENTAL Wizard

Figure 84 shows that the Incremental wizard has improved the primary path load-balancing. However, as already pointed 8% of LSPs are non-compliant meaning that they do not respect the optimization constraints.

In OPNET documentation/tutorials there are example networks available that show successful optimization. However, in the scope of discussion in this document, this example gives an interesting insight into the relevance of optimization for moderate to highly utilized networks. Where primary paths, for normal operation of network, could be optimized, it is clear from the results of Survivability Analysis and Incremental MPLS TE that this network:

1) Is not further optimizable for both primary and secondary paths

Ericsson Internal




2) Will perform poorly in resilience mode. It lacks capacity to support secondary paths.

Topologies that are unbalanced, and not as heavily loaded as this one, are good candidates for optimization. As load is spread around in the network making use of empty or un-utilized links, thereby, reducing the utilization of congested links. This network is already optimized, and is under moderate to high utilization in the core links. Global optimization does not bring any further benefit.

A network may not be optimizable and therefore capacity expansion may be considered.

Though it is out side the scope of this document, a capacity expansion scenario can be easily set up by running the Link Dimensioning Wizard or Link Dimensioning Resilience Wizard. Or by simply, using the link attributes to set up higher capacity links. There is a range of link models available in OPNET that can be used for capacity planning strategy.

Please refer to relevant capacity planning services offered by Ericsson.

6.6.1 Configlet for MPLS Incremental TE

Configlet may be generated that contain pseudo-code for setting up explicit paths. This is discussed in sub-section 6.7

6.7 MPLS Configlet Generation

OPNET provides two utilities to export MPLS LSP information

1. MPLS Explicit Routing Configlet Generation

2. MPLS Explicit Routing Text files Generation.

The first utility is especially useful in that it generates Configlets that can be used to create LSPs in the real network. Configlet generation utility’s only requirement is that LSPs have valid IP addresses at the two ends. As LSPs in this topology are tied to loopback addresses, this condition is met.

An excerpt of Configlet file for RTR10 generated by this utility is given below:

/*MPLS Explicit Route Configlet Generated by SP GuruDevice: Imported Network.RTR10ID: 10.0.254.110Command Version: JUNOS 8.x

Ericsson Internal




*/groups { mpls-lsp-group { protocols { mpls {# LSP: RTR10 -> RTR118 label-switched-path "RTR10 -> RTR118" { primary RTR118 { } secondary "RTR118_1" { } }

… } mpls-er-group { protocols { mpls { path RTR118 { 10.0.28.5 strict; 10.0.24.13 strict; 10.0.24.22 strict; } path "RTR118_1" { 10.0.28.9 strict; 10.0.28.1 strict; 10.0.24.29 strict; 10.0.24.18 strict; 10.0.24.26 strict; } } path "RTR40_1" { 10.0.28.9 strict; 10.0.28.1 strict; 10.0.24.29 strict; 10.0.24.58 strict;

… }}apply-groups [ mpls-er-group mpls-lsp-group ];

7 MPLS Fast Reroute

Fast Reroute refers to a set of MPLS local restoration mechanisms providing a fast repair, as there’s no need to wait for the ingress router to be informed. They redirect the traffic from the upstream router of the link or node where the failure occurred.

Ericsson Internal




This is accomplished by pre-computing and pre-establishing a bypass tunnel that avoids the failed node or link.

There are two different types of local restoration mechanism to protect the RSVP signaled LSP traffic:

1. Fast Reroute one-to-one: each LSP that requires to be protected has its own LSP backup. The one-to-one mechanism is known in the Juniper literature as “Fast Reroute”.

2. Fast Reroute many-to-one backup: many LSPs can be protected with the same backup LSP. This mechanism can provide either, only link protection or, both link and node protection.

Enable FRREnable Bypass

Tunnel to protect interfaces

Setup Explicit Path for Bypass Tunnel

Figure 85 FRR Bypass Tunnel TE process

As a first step, FRR is enabled on all LSPs. Then Bypass Tunnel protection is set up on all active interfaces. Lastly, explicit paths are setup for Bypass Tunnels.

The mechanism chosen for local restoration in Mobile-PBN reference solution in Juniper backbone is Fast Reroute (one-to-one protection).

Implementation steps are as following.

7.1 Enabling Fast Reroute

1 Duplicate MPLS TE Tactical or MPLS TE Incremental scenario and rename the new scenario to FRR Resilience scenario.

2 Select Menu View->Paths->Show All

3 Right-click on any LSP and choose Select Similar Paths.

4 Right-click on any LSP and select Edit Attributes.

Ericsson Internal




Figure 86 Node attributes for setting up Fast Reroute recovery configuration

Check the box Apply changes to selected objects. This allows the attribute changes in this object to be applied to all selected LSPs. See Figure 86.

5 Select the attribute Recovery Parameters->Fast Reroute Configuration->Protection Scheme and set it One-to-One Backup.

This action will enable LSPs to use one-to-one FRR recovery in case of failure.

6 Click OK.

7 Select View->Paths->Hide All to hide all LSPs.

Ericsson Internal




7.2 Bypass Tunnel Setup

Next step is to set up the Bypass tunnels.

8 Open Protocols->MPLS->Create facility protection bypass tunnels utility.

Figure 87 Facility protection set up utility

Ericsson Internal




Figure 88 Create facility protection

9 Set the options to protect all and links and click OK. See Figure 88.

Bypass LSPs will be shown in the project space.

10 Check that each bypass tunnel is associated with an interface.

Right-click on any node and open its attributes.

Click MPLS->MPLS Parameters->Interface Information.

11 Click in Bypass Tunnel Configuration column for any active interface.

This action shows a list of bypass tunnel LSPs protecting the interface. This attribute is automatically populated by the Create facility protection bypass tunnels.

7.3 Explicit Route for FRR Bypass Tunnel

The next step is to create explicit routes for the newly create bypass tunnels.

12 Open the Design->Configure/Run Design Action window.

13 Select Fast Reroute->MPLS_frr_bypass_lsp_routing. See Figure 89.

Figure 89 MPLS FRR Bypass routing design utility

Ericsson Internal




Figure 90 Bypass route summary statistics

14 Click Run.

15 View Long to open the summary of bypass tunnel explicit routing

Figure 90 shows the summary.

Total 86 bypass tunnels are created and all were routed.

To examine the explicit routes visually, select

16 Select Menu View ->Show Network Browser

Arrange the view to see LSPs by Source

17 Expand any node and click on the bypass tunnel to see its explicit path (run flow analysis if not run already).

Ericsson Internal




Figure 91 Bypass route selection in Network Browser

Figure 92 Bypass route for selected ER in project space

The FRR bypass tunnel to protect link between nodes RTR01 and RTR23 is shown in Green color. This set up is exactly as per Mobile-PBN recommendations.

18 Perform analysis of network when FRR is active. Duplicate the existing scenario and rename it as FRR Resilience Failure

19 Now select Flow Analysis -> Configure/Run Flow Analysis

20 Under the MPLS tab, set the MPLS rerouting mode to Fast Reroute Only.

Ericsson Internal




Figure 93 Flow analysis to analyse Fast Reroute

21 Click Run. Results are given as:

Performance Analyzer Results: Measure Value

WAN Link - Number of overutilized links 21WAN Link - Maximum Utilization (%) 446WAN Link - Total Consumed BW (bps) 2.93745e+010WAN Link - BW Efficiency (%) 30.4LAN - Maximum LAN Utilization (%) 0.000000Demand - Total Active Demands 616Demand - Failed-Unroutable Demands 0MPLS LSP - Number of LSPs 1256MPLS LSP - Number of Unrouted LSPs 1122

Results show that the maximum utilization in the network is 446%! This is a significantly high utilization.

Figure 94 Performance bottlenecks for FRR operation

Ericsson Internal




This means that during the time FRR is active protecting an interface, in case of failure, for a very brief time the network will have very poor performance. To get an understanding of performance bottlenecks in the network for FRR operation, visualize links colored by load. This is shown in Figure 94.

The solution to this congestion problem is either to invest in capacity expansion or tolerate the degraded performance.

8 QoS

QoS Design wizard is used for setting up the Deficit Weighted Round Robin (DWRR) queues on Juniper routers. The design action is used to automate the configuration of IP QoS parameters on routers in the network. The design action allows definition of a QoS configuration template that can then be applied to specified nodes and interfaces in the network. The application is additive with respect to the current IP QoS configurations. This means that the traffic classes defined on the design action will add to the set of traffic classes that are already defined on the target nodes. For traffic classes with the same Class Name, the design action will overwrite the existing definition. The same is true for traffic policies, queue profiles and interface QoS schemes.

The design methodology followed in this document is based on Mobile-PBN reference design recommendations [8]. The design action consists of the following steps

1 Clear the existing QoS implementation

2 Configure and run design action ip_qos_configuration_dwrr_exp_edge on the edge routers

3 Configure and run design action ip_qos_configuration_dwrr_exp_core on the core routers.

4 Verify that IP QoS is implemented

5 Size the queues as per traffic requirements

Note: The QoS framework imported from the Juniper node configuration files did not work. To workaround this issue, all the routers were cleaned of the imported QoS parameters, and design wizard was used to setup the QoS framework from scratch.

8.1 QoS Design Overview

A summary of QoS design for this network is given here.

Ericsson Internal




DiffServ Class Queue PLP

NC/CSC7 3 highNC/CSC6 3 lowEF 1 lowAF11 2 lowAF12 2 highBE1 0 lowBE 0 high

Two router queues are shared by more than one traffic class:

Signaling (AF11) and Streaming (AF12) share queue 2

Interactive (BE1) and Background (BE) share queue 0

Differentiation within one queue is implemented through drop profiles. Drop profiles define a fill level of the queue at which packets of one class start to be dropped. Drop profiles are selected by the PLP bit mentioned earlier.

On queue 2, a drop profile is configured that starts dropping Streaming packets before signaling packets are dropped. This implements priority for signaling packets. On queue 0, a drop profile is configured that drops background traffic before Interactive traffic is affected by congestion.

Scheduling priorities are given as:

DiffServ Class Scheduler Priority

NC/CSC7 highNC/CSC6 highEF highAF11 lowAF12 lowBE1 lowBE low

Classification and Marking

Table 3 shows the DSCP and EXP fields codes used in the backbone.

Diffserv Class IP DiffServ, DSCP MPLS EXP value

CS7 111 000 111

Ericsson Internal




CS6 110 000 110

EF 101 110 010

AF11 001 010 100

AF12 001 100 101

BE1 000 001 001

BE 000 000 000

Table 3 Network-wide DSCP and EXP field definition

Traffic on the physical interface is scheduled based on the Deficit Weighted Round Robin (DWRR) algorithm.

Transmit rate

This parameter is chosen based on dimensioning, individually for each router interface and forwarding class.

For NC traffic, the GE interface’s queue scheduler bandwidth is hard-coded to 5% by the JUNOS operating system. This value cannot be changed by the user.

5% scheduler bandwidth is reserved for BE traffic

The remaining 90% bandwidth should be shared amongst the EF & AF queues.

Buffer size

NC: 5% (following a general Juniper recommendation)

EF: 5ms temporal (see below)

AF: same percentage as the transmit rate parameter for the queue

BE: remainder

Policing

Not done

Ericsson Internal




8.2 QoS Scenario

1 Duplicate FRR Resilience scenario and rename the new scenario to QoS scenario.

2 To clear all the present QoS implementation, select Menu Protocols->IP->QoS->Configure QoS.

Figure 95 QoS clear operation

3 In the configuration window, as shown in Figure 95, set

QoS Scheme as “None”.

QoS Profile as “None”.

Click OK.

Note: This action should clear up the existing QoS scheme/profile. For some routers, however, this may not happen. The QoS implementation then has to be manually cleared. This means opening each node’s attributes, selecting IP->IP QoS Parameter and set the number of rows equal to zero (0) for the following parameters:

Interface information

Traffic classes

Traffic profiles

Ericsson Internal




DWRR profiles

This action will then clear up the QoS implementation of the node. Repeat for other nodes.

8.3 Edge Routers QoS Configuration

Defining IP QoS configuration involves four steps:

Define the traffic classes

Define the DWRR profiles

Define the traffic policy

Set up inbound / outbound traffic policy

Setup traffic classes

Set up DWRR queue profiles

Set up traffic policy to associate traffic classes to queue

profiles

Set up Inbound and Outbound traffic

policies

Figure 96 Performance bottlenecks for FRR operation

Each step is described in the following sub-sections.

8.3.1 Define the traffic classes

4 In the project browser space, select all the edge routers before running the design wizard.

5 Select Design->Configure/Run Design action

6 In the resulting dialog box, click Arrange By: option and select Technology.

7 In the panel on the left, expand the list of IP QoS Design Action by clicking “+” next to IP QoS. Select ip_qos_configuration_dwrr_exp_edge.

Ericsson Internal




Figure 97 DWRR QoS design wizard selection for edge routers

8 Click on “SaveAs..” to make a copy of this setup action. Save as mpbn_edge_design.

It will be modified for application to the current network. In the context of the following discussion, the modified design action will be used.

Ericsson Internal




Figure 98 IP QoS Template Traffic Classes

9 Double-click the value field for Traffic Classes (see Figure 98).

This action brings up the Traffic Classes Table, as shown in Figure 99.

10 Increment the number of classes as required, in this case 5, and configure each type. See Figure 99.

In the new rows, enter the class names as shown in Figure 95 and set the Match Mode to Any.

Ericsson Internal




Figure 99 DWRR QoS design wizard Traffic Classes

Figure 100 DWRR profiles

Ericsson Internal




11 Enter the Match Info details for the three classes as shown in the three dialogs on the right.

Figure 99 shows configuration of AF and NC classes. BE, BE1 and EF classes can be configured in a similar fashion.

12 Click OK all the way until you come back to the Design Action. Click Save.

8.3.2 Define the DWRR profiles

13 In the IP QoS Template select DWRR Profiles.

Double click the value field for DWRR Profiles to bring up the table shown in Figure 100.

Figure 101 QoS traffic policies

Ericsson Internal




14 Bandwidth requirement will be later resized according to the traffic requirements. For the time being, set EF bandwidth requirement as 70%; AF as 20% and NC as 5%. BE gets the rest of the 5% share.

15 Set also the scheduling priorities as per Mobile-PBN requirements.

16 Click OK to return to design wizard.

8.3.3 Define the traffic policy

In this step, each row in the traffic policy configuration is tied to the physical queue on the interface.

Re-open the attributes dialog for design action.

17 Select IP QoS Templates->Traffic Policies. See Figure 101.

All the traffic policies are grouped intro two broad policies:

Outbound-queue-assignments

Inbound-forwarding-class-and-exp-assignments

18 Double-click on Row 0->Configuration to open the configuration table for Outbound-queue-assignments.

Left hand side of Figure 102 shows the table with 5 sub-policies.

Double-click on the Set-Info to open the Set-Info tables. These are on the right hand side of Figure 102.

Two sub-policies are shown, one for EF and the other for AF.

It can be seen now that each defined class is now tied to the DWRR scheduler queue.

The rest of the classes are set up in a similar manner.

19 Click Ok to come back to the design action.

20 Double-click on Row 1->Configuration to open the configuration table for inbound-forwarding-class-and-exp-assignments.

Ericsson Internal




Figure 102 QoS Outbound traffic policy

Note: This is the step where MPLS mapping is imposed.

Left hand side of Figure 103 shows the table with 5 sub-policies.

21 Double-click on the Set-Info to open the Set-Info tables.

22 These are on the right hand side of Figure 103.

Two sub-policies are shown, one for EF and the other for AF.

It can be seen now that each defined class is now set for MPLS EXP imposition.

For DSCP classes this imposition needs to be done.

23 The rest of the classes are setup in the similar manner.

24 Click OK and return to design action window.

Ericsson Internal




Figure 103 QoS Inbound traffic policy

8.3.4 Drop Profiles

Drop profiles are set up for AF and BE queues. In SPGuru 14.0 the drop setting up of drop profiles in the IP QoS Design Wizards are not working properly.

These are to be configured on individual routers. The four drop files are shown in Figure 104:

STR-Tail-Drop

SIG-Tail-Drop

BG-RED-Drop

IA-RED-Drop

Ericsson Internal




Figure 104 Drop profiles

Ericsson Internal




25 These are configured in DWRR queues. Select IP->IP QoS Parameters->Drop Profiles.

26 The Drop Profiles are then tied to DWRR queues. Select IP->IP QoS Parameters->DWRR Profiles.

27 Select the queue and set up the drop profile. See Figure 105.

Ericsson Internal




Figure 105 Drop profiles associated with DWRR profiles

Using this method, drop profiles can be set for any arbitrary queue.

This step has to be repeated or all nodes.

8.3.5 Edge QoS Design Action

28 Make sure that all the edge routers are selected.

In the Design Action window, select Input Node Set Name as SELECTED. See Figure 106.

Figure 106 Application of Design Action on Selected nodes

This ensures that the newly set QoS Design Template is applied to the edge routers only.

29 It is also important to make the following two changes:

Ericsson Internal




Set Inbound Traffic Policy as inbound_forwarding-class-from-exp-assignments

Set Outbound Traffic Policy as outbound-queue-assignments

30 See Figure 106

31 Click OK. Click Save. Click Run.

Close the “Action Completed” dialog box that appears at the end of the Design Action’s execution. The IP QoS configuration is now deployed on all edge nodes.

8.4 Core Routers QoS Configuration

The IP QoS template for core routers is similar to edge routers. Therefore open the mpbn_edge_design design template and save it as mpbn_core_design. This can then be modified and applied to the core routers.

Except for the redefinition of inbound and outbound policies, and selection of core routers all the rest of steps are similar to edge routers. Therefore only necessary details are discussed here.

8.4.1 Define the traffic classes

Same as sub-section 8.3.1

8.4.2 Define the DWRR profiles

Same as sub-section 8.3.2

8.4.3 Define the traffic policy

The outbound policy remains the same as edge routers. The inbound policy for core routers does not need to make MPLS EXP imposition as this is done on the edge routers. This is the only difference between the QoS implementation of traffic policies.

32 Inbound Traffic Policy is set as inbound-forwarding-class-from-exp-assignments. Open Inbound policy configuration and remove the MPLS EXP Imposition statement from the definitions.

8.4.4 Core QoS Design Action

33 Make sure that all the core routers are selected.

Ericsson Internal




In the Design Action window, select

Input Node Set Name as SELECTED. See Figure 106.

This ensures that the newly set QoS Design Template is applied to the core routers only.

Figure 107 Diffserv scheduling setup

34 It is also important to make the following two changes:

Set Inbound Traffic Policy as inbound-forwarding-class-from-exp-assignments

Set Outbound Traffic Policy as outbound-queue-assignments

35 Click OK. Click Save. Click Run.

Ericsson Internal




Close the “Action Completed” dialog box that appears at the end of the Design Action’s execution. The IP QoS configuration is now deployed on all core nodes.

8.5 QoS Verification

36 Run Flow Analysis

37 Open Results. Open Flow Analysis Tables tab.

Select Configuration->Diffserv-Scheduling. See Figure 107. The figure shows that Diffserv framework has been setup successfully over all active interfaces. Note the bandwidth share as well as the correct setting of DSCP classes.

38 Two types of traffic were modeled. One with EF marking and the other with AF11 marking. To see how queue scheduling is handling the two traffic type, select Configuration->Diffserv-Queue Statistics.

See Figure 108. The shown report gives details of mean delay across the queue, standard deviation, etc. This information is important for analyzing and optimizing traffic performance.

Ericsson Internal




Figure 108 Diffserv queue statistics

Figure 109 Diffserv queue usage

39 Select Configuration->Diffserv-Queue Usage.

Figure 109 shows the total bandwidth available at each interface, the share of each queue and its utilization. For example, the EF queue in RTR05 GE interface towards core routers is 51.55% utilized.

This is the utilization for primary traffic flows. It is probable that in case of failure this queue is not appropriately dimensioned. Therefore in the last part of this chapter, we deal with the topic of queue sizing.

Ericsson Internal




8.6 Queue Sizing

1 Duplicate the existing QoS scenario, and rename it Queue Sizing scenario.

2 In the new scenario, bring up the design action attributes dialog.

3 Click Design->Configure/Run Design Action to bring up the design dialog

4 Arrange the design actions by Technology, and select IP QoS-> ip_qos_queu_sizing. See Figure 110.

5 Click Edit Attributes to bring up the attribute window

Figure 110 Queue sizing design action

The Target Queue Configuration to bring up the configuration table.

Ericsson Internal




6 Increment the number of rows to 5 by double-clicking on 2 and typing in 5. See Figure 111.

7 In the rows enter the values of the queues that need dimensioning.

Figure 111 Queue sizing attribute window

Figure 112 Target queue configuration

Ericsson Internal




The five classes already setup in the nodes are now targeted for optimization.

See Figure 112. Leave the settings for Target Bandwidth (%), Max Utilization (%), etc. as it is.

8 Click OK.

9 Return to the design wizard, and click Run.

10 Close the “Action Completed” dialog box that appears at the end of Design action.

Measure Initial Value Final Value

Number of Queues 134 134

Queues Out of Range 1 2

Max Queue Util (%) 105.7 88.33

Avg Queue Util (%) 10.57 11.58

Bw Avg Queue Util (%) 7.42 7.6

Queues Increased 1

Queues Decreased 16

Total Queues Changed 17

Table 2: Assured Forwarding Queue Optimization

Measure Initial Value Final Value

Number of Queues134 134

Queues Out of Range16 9

Max Queue Util (%)112.79 92.88

Avg Queue Util (%)36.43 34.86

Bw Avg Queue Util (%)25.38 25.21

Ericsson Internal




Queues Increased16

Queues Decreased1

Total Queues Changed17

Table 3: Expedited Forwarding Queue Optimization

Node NameInterfac

e

Total Interfac

e Utilization (%) Queue Name

Interface Utilizatio

n (%)

Initial Queue BW Spec.

Initial Queue

Utilization (%)

Final Queue BW Spec.

Final Queue

Utilization (%)

Compliant

Imported Network.RTR08-KHI01-M10i-RE0 as0 77.28 EF_classifier 77.28

70 (%) 110.4

85 (%) 90.92 No

AF1x_classifier 020 (%) 0 5 (%) 0 Yes

Imported Network.RTR09-ISB01-M10i-RE0 as0 78.95 EF_classifier 78.95

70 (%) 112.79

85 (%) 92.88 No


Imported Network.RTR14-KHI02-M10i as0 76.31 EF_classifier 76.31

70 (%) 109.01

85 (%) 89.78 No


Imported Network.RTR19-QUTO1-M10i-RE0 so-0/2/0 65.88 EF_classifier 65.39

70 (%) 93.41

82 (%) 79.74 Yes

AF1x_classifier 0.4920 (%) 2.45 8 (%) 6.13 Yes

Imported Network.RTR20-QUTO1-M10i-RE0 so-0/2/0 65.39 EF_classifier 65.39

70 (%) 93.41

82 (%) 79.74 Yes


Imported Network.RTR23-LHR01-M320-RE0 as1 68.72 EF_classifier 47.58

70 (%) 67.97

63 (%) 75.52 Yes

AF1x_classifier 21.1420 (%) 105.7

27 (%) 78.3 Yes

as5 59.9 EF_classifier 57.4470 (%) 82.06

72 (%) 79.78 Yes

AF1x_classifier 2.4620 (%) 12.3

18 (%) 13.67 Yes

Imported Network.RTR2 so-1/1/0 67.66 EF_classifier 59.83

70 (%) 85.47

75 (%) 79.77 Yes

Ericsson Internal




4-KHI01-M320-RE0


15 (%) 52.2 Yes

so-2/1/1 68.32 EF_classifier 68.3270 (%) 97.6

85 (%) 80.38 No


as2 69.61 EF_classifier 56.5770 (%) 80.81

71 (%) 79.68 Yes


19 (%) 68.63 Yes

Imported Network.RTR25-ISB01-M320-RE0 so-3/2/1 69.97 EF_classifier 68.09

70 (%) 97.27

85 (%) 80.11 No


Imported Network.RTR28-KHI02-M320-RE0 so-1/1/0 77.57 EF_classifier 66.97

70 (%) 95.67

78 (%) 85.86 No

AF1x_classifier 10.620 (%) 53

12 (%) 88.33 No

so-2/1/1 68.81 EF_classifier 68.3270 (%) 97.6

85 (%) 80.38 No


Imported Network.RTR29-ISB02-M320-RE0 so-3/1/1 68.09 EF_classifier 68.09

70 (%) 97.27

85 (%) 80.11 No


as2 74.72 EF_classifier 70.3270 (%) 100.46

85 (%) 82.73 No

AF1x_classifier 4.420 (%) 22 5 (%) 88 No

Imported Network.RTR30-FSB02-M320-RE0 as1 64.26 EF_classifier 63.34

70 (%) 90.49

80 (%) 79.18 Yes


10 (%) 9.2 Yes

as2 65.76 EF_classifier 65.7670 (%) 93.94

83 (%) 79.23 Yes


Table 4: Queue Optimization summary

11 Open the results of design action. Table 2 and Table 2 give a summary of design action for each AF and EF queues.

Ericsson Internal




Table 4 gives a Queues Changed summary. It shows that the design algorithm right-sizes the queues from initial EF = 70% and AF = 20% to new values, some lower, some higher.

For example, in the first row, the EF has been resized to 85% and AF as 5%. This is based on the actual traffic flowing using the two queues.

Whereas this is a valuable tool in correcting the queue sizing issues, one point must be kept in mind when dimensioning queues in real networks

These utilizations are optimized for primary paths of LSPs. In case of failure the queues will get doubly loaded

Voice traffic is load-balanced over two PE routers while Sigtran traffic is not load-balanced and just routes over one PE pair towards the core. This means that for each pair of routers, considerations should be given in the light of above recommendation. Let us take the example of one pair of PE routers: RTR05 and RTR08

Queue dimensioning for RTR08 shows a final ratio for EF and AF is 85% to 5%.

The same ratio must be implemented in RTR05.

This takes care of the fact that when Sigtran moves from one PE router to another PE router, enough AF bandwidth is available to handle this traffic.

However, 85% saturation for EF queue that if Voice traffic moves from one PE to another, there is no capacity to take care of the combined traffic. This interface does not have capacity and will performance degradation. Again, the solution to this problem is capacity-expansion, no amount of Diffserv queue sizing will result in better performance for network in resilience mode.

Appropriate dimensioning or optimization measures may be undertaken to make network perform under acceptable thresholds in both working and resilient modes.

9 Physical and Logical Connectivity

Some typical physical and logical connectivity issues are considered in this chapter.

9.1 Physical connectivity

Typical physical connectivity problems are discussed here.

Ericsson Internal




9.1.1 Links

1. RTR25, interface "so-2/2/2" is configured to be part of aggregate interface "as6". However, "as6" is not defined as an aggregate interface on this router.

As per router configuration:

so-2/2/2 { description "@ AS6 linked to RTR40-JLM01-M10 so-0/1/0 @ AS0"; clocking external; sonet-options { aggregate as6; } }

However “as6” aggregate bundle is not defined on the router. One way to resolve this is to configure “as6”. However, since only a single interface is part of the aggregate interface, it is recommended to just remove the reference to “as6” bundle. This can be corrected with the following steps:

Edit Attributes->IP->IP Routing Parameters->Interface Information->”so-2/2/2”

In the attributes of link “so-2/2/2” set

Aggregation Parameters->Aggregate Interface as “Not Configured”.

This makes the link an unbundled link.

Also correct the link name description in the last line of “so-2/2/2” attributes.

2. RTR32, interfaces "so-0/3/0" and “so-0/3/1” are configured to be part of aggregate interface "as1". However, "as1" is not defined as an aggregate interface on this router.

As per router config:

so-0/3/0 { sonet-options { aggregate as1; } } so-0/3/1 { sonet-options { aggregate as1; }

Both links are used for connectivity. These can be removed from configuration to avoid ambiguity.

Edit Attributes->IP->IP Routing Parameters->Interface Information.

Ericsson Internal




Right click on “so-0/3/0” and then “delete row”. Repeat for the other link.

9.1.2 Ports

3. Different cities should be terminated on different FPC’s

4. Port allocations for Intra-city links should be distributed on PIC’s on separate FPC’s

This is a large undertaking in terms of reconnectivity of physical links to different FPCs etc. This has to be agreed with the customer. Here, the two main steps relevant to optimization in OPNET are given.

9.1.2.1 Port allocation of each link

Right-click on a link, and choose Edit Ports.

From the tabs, choose the relevant port.

It is possible that the required port is allocated to another link and may not be visible in the drop down list. In this case, the port must be unassigned from its present allocation.

Find out, to which link the port is assigned.

Edit Attributes->IP->IP Routing Parameters->Interface Information.

Choose the specific link in the topology browser (right click),

Edit Ports

click the tab and set “unassign”. This will make the port available for reallocation to another link.

9.1.2.2 Assigning interface/link to a link-bundle

Use Edit Attributes->IP->IP Routing Parameters->Interface Information

Pick the relevant interface, and then set

Aggregation Parameters->Aggregate Interface

to the required bundle name. Simply click on the value field, and a drop-down list of all configured aggregate links will pop up. Choose the required bundle.

Ericsson Internal




9.2 OSPF parameters

9.2.1 OSPF link metrics

OSPF metrics are calculated from dividing a constant bandwidth by the interface bandwidth as in 108/(interface bandwidth in bps).

Interface Bandwidth [bit/s] OSPF Metric10 GE 10 000 000 000 101 GE 1 000 000 000 100OC-3c/STM-1c 155 520 000 650STM-4 622 080 000 160STM-16 2 488 320 000 40STM-64 9 953 280 000 10FE 100 000 000 1 000E3 34 368 000 3 000E1 2 048 000 50 000

Table 2 OSPF Link Metrics

Set the reference bandwidth to 100Gbps. This can be done in the following way. Edit->Select All in Subnet.

This will select all the links and nodes in the topology. Then, Protocols->OSPF->Configure Interface Costs.

This will open the following picture. Set reference bandwidth as 100,000,000,000, and click OK.

Figure 113 OSPF link metric setup for all links

The above link metrics are to be configured as a default, with the exception of specific cases in which modifications are needed to preserve path diversity for LDP with one-hop RSVP-TE tunnels [8].

Ericsson Internal




9.2.2 OSPF export policy

5. In RTR118 and RTR117 use export ospf-redist_statics statement to redistribute static routes into OSPF

Even though, the policy is defined it is not used in the OSPF processs. The statement export ospf-redist_statics is missing. This can be configured in the following way.

Open node attributes, select IP Routing Protocols->OSPF Parameters->Processes->1->Process Parameters->Redistribution

Ericsson Internal




Figure 114 OSPF static routes redistribution

Ericsson Internal




Then in the Route Attribute click and choose the already configured policy. This is shown in Figure 114.

It is to be noted that if the policy is not configured, this can be done in the following way. In the node attributes, click IP Routing Protocols->Route Map Configurations

Then define the policy, for example, as shown in Figure 115.

Figure 115 Route map/policy definition

Ericsson Internal




9.2.3 Sham Links

6. To avoid creating a backdoor through the GSN nodes, an OSPF sham link should be introduced between the VRFs serving the logical networks for Gn, Gom, IuPS, Gb and Gi interfaces [8].

Sham links are the OSPF logical links between VRFs on the relevant PE routers. For example, Figure 116 shows definition of sham link on one RTR43 PE router. Open node attributes and then

IP Routing Protocols->OSPF Parameters->Processes->1->Process Parameters->Sham Links

Source and Destination IP addresses have to be entered. The same will have to be done to RTR44, the other PE router on the site. Same procedure will have to be repeated for PE pairs on other sites.

Figure 116 OSPF sham link definition

Ericsson Internal




9.3 IS-IS Process

9.3.1 IS-IS metrics

Like OSPF, IS-IS metrics are also calculated from dividing a constant bandwidth by the interface bandwidth as in 108/(interface bandwidth in bits/s). These settings are the same as given in Table 1.

This can be done in the by choosing Protocols->ISIS->Configure Interface Costs, or setting on individual nodes. Open node attributes, and choose:

IP Routing Protocols->IS-IS Parameters->Interface Information

Then click open an interface and set Metrics, as required, as shown in Figure117.

Ericsson Internal




Figure 117 IS-IS link metric setup for individual link on a node

The above link metrics are to be configured as a default, with the exception of specific cases in which modifications are needed to preserve path diversity for LDP with one-hop RSVP-TE tunnels [8]. This discussion is done in sub-section 5.2.

9.3.2 IS-IS area

IS-IS area can be set with the following steps.

Select Scenarios->Switch to Scenario and choose Network Baseline Model scenario.

Then Scenarios->Duplicate scenario. Rename the new scenario it to IS-IS Convergence.

Edit->Select All in Subnet.

This will select all the links and nodes in the topology. Then,

Protocols->ISIS->Configure System Type.

This will open the window as shown in Figure 118.

Set area as Level-2 and click OK.

Figure 118 IS-IS Level-2 for MPLS backbone

9.4 BGP Tuning

The mechanisms in place at the moment of writing this document allow for a convergence time in the order of seconds for a worst case scenario.

Ericsson Internal




9.4.1 Graceful Start

The separation of the control and forwarding plane allows a router to stay on the forwarding plane while a routing process or the complete routing engine is re-starting. This behavior is called graceful restart.

It is enabled by default in OPNET for Juniper routers.

9.4.2 Next-Hop Tracking

BGP next-hop tracking enabled by default, and no extra configuration is needed.

9.4.3 Next-Hop Self

The local router as the Next Hop for the all routes is advertised to this BGP speaking peer. When a BGP speaker advertises a route to a speaker within its own AS, the NEXT HOP value is not changed unless this attribute is set to Enabled. An exception to this is the exchange of VPNv4 routes, where the next hop value is always set to local address.

By default, the next hop of routes advertised to EBGP peers is always set to the local address irrespective of the value of this attribute.

9.4.4 Policies for BPG/MPLS IP VPNs

7. Policy l2-export needs to have a match clause in term a

8. Policy RAN-export needs to have a match clause in term a

The routing policies can be corrected using the procedure given in sub-section 9.2.

10 Conclusion

In this document, various methods to optimize MPLS network performance have been discussed. We started the discussion with study of IGP protocols convergence and IGP optimization, and then moved on to MPLS Traffic Engineering and Resilience methodologies from a performance perspective. In the last part of the document QoS implementation and optimization were considered.

Ericsson Internal




Performance optimization is a vast subject. There are many topics that have not been touched, for example, Shared Risk Groups, for optimizing capacity requirements in Resilience mode. Topics like these are subject of future work and expansion.

It was also shown that Optimization can not fix all performance problems in a network. For moderate to heavily loaded networks that are relatively well-balanced, capacity expansion may well be the solution. However, the road to such a decision must be through a detailed evaluation giving clear evidence of performance issues. This service is then useful for not only MPLS performance optimization, but also for making strategic capacity expansion decisions.

Ericsson Internal




11 Abbreviations

This is a comprehensive list of abbreviations relevant for MPLS Backbone network.

AAL2 ATM Adaptation Layer 2 L2TP Layer 2 Tunneling protocolAAL5 ATM Adaptation Layer 5 L3 Layer 3ACL Access Control List LAN Local Area NetworkADM Add Drop Multiplexer LAPF Link Access Procedure Frame

Bearer ServicesAF Assured Forwarding LCAS Link capacity Adjustment

SchemeAFI Address Family Identifier LCT Local Craft TerminalALS Automatic Laser Shutdown LDP Label Distribution ProtocolAPS Automatic Protection Switching LER Label Edge RouterARP Address Resolution Protocol LFI Link Forwarding and

InterleavingAS Autonomous System LI Lawful Intercept or Lawful

InterceptionATM Asynchronous Transfer Mode LLC Logical Link ControlAXE Ericsson product name LLF Link Loss ForwardingBB Backbone LLQ Low Latency QueuingBE Best Effort LMI Link Management InterfaceBECN Backward Explicit Congestion

NotificationLSA Link State Advertisement

BFD Bidirectional Forwarding Detection LSP Label Switched PathBGP Border Gateway Protocol LSQ Link Services IQ InterfaceBSC Base Station Controller LSR Label Switching RouterCBC Central Building Clock LTU Line Tributary UnitCBR Constant Bit Rate MAC Medium Access ControlCBWFQ Class-Based Weighted Fair

QueuingMBGP Multiprotocol BGP

CE Customer Edge Device MCML Multi-Class MLPPPCLI Command Line Interface MLPPP Multi Link Point to Point

ProtocolCLNS Connectionless Network Service MPLS Multi Protocol Label SwitchingCoS Class Of Service MSER Multi-Service Edge RouterCPU Central Processor Unit or Central

Processing UnitMTTR Mean Time To Repair

CSC Class Selector Codepoint MTU Maximum Transmission UnitCSPF Constraint Shortest Path First NAT Network Address TranslationCWDM Coarse Wavelength Division

MultiplexingNC Network Control

Ericsson Internal




DE Discard Eligibility NET Network Entity TitleDLCI Data Link Connection Identifier NHOP Next HopDNS Domain Name System NLRI Network layer Reachability

InformationDoS Denial of Service NNHOP Next Next HopDSCP Differentiated Services Code

PointNSAP Network Service Access Point

DWDM Dense Wavelength Division Multiplexing

NSEL NSAP Selector

EBGP External BGP NSF Non Stop ForwardingECN Explicit Congestion Notification OSPF Open Shortest Path FirstEDRR Enhanced Deficit Round Robin PD Packet DescriptorEF Expedited Forwarding PDH Plesiochrone Digital HierarchyEoS Ethernet over SDH PDP Packet Data ProtocolEPL Ethernet Private Line PDU Protocol Data UnitEPLAN Ethernet Private LAN PE Provider Edge RouterER Extended Range PFE Packet Forwarding EngineES End System PHB Per Hop BehaviorEVPL Ethernet Virtual Private Line PHP Penultimate-Hop-PoppingEVPLAN Ethernet Virtual Private LAN PIC Physical Interface CardEXP Experimental Bits (in MPLS

header)PLP Packet Loss Priority

FCS Frame Check Sum PLR Point of Local RepairFE Fast Ethernet PMA Packet Mesh ASICFEB Forwarding Engine Board PoS Packet over SONETFEC Forwarding Equivalence Class PPA Packet Processing ASICFECN Forward Explicit Congestion

NotificationPPP Point-to-Point Protocol

FIB Forwarding Information Base PQ Priority QueuingFPC Flexible PIC Concentrator QoS Quality of ServiceFR Frame Relay RD Route DistinguisherFRR Fast ReRoute RFC Request for CommentsFTP File Transfer Protocol RE Routing EngineFW Firewall RIB Routing Information BaseGE Gigabit Ethernet RIP Routing Information ProtocolGFP Generic Framing ProcedureGenRD Generic Routing Domain RPS Router Path SupervisionGGSN Gateway GPRS Support Node RSVP Reservation ProtocolGRD see GenRD RSVP-

TEReservation Protocol with Traffic Engineering Extensions

GRES Graceful Routing Engine Switchover

RTP Real-time Transport Protocol

GTP GPRS Tunneling Protocol SAA Service Assurance AgentHDLC High-level Data Link Control SAFI Subsequent Address Family

Identifier

Ericsson Internal




IAC Internet Access SAR Segmentation And ReassemblyIBGP Internal BGP Protocol SCTP Stream Control Transmission

ProtocolICMP Internet Control Message SDH Synchronous Digital Hierarchy

(ITU)IBGP Internal BGP SNMP Simple Network Management

ProtocolIFG Inter-Frame Gap SPF Shortest Path FirstIGP Interior Gateway Protocol SSH Secure ShellICMP Internet Control Message Protocol TCP Transport Control ProtocolIOS Internet Operating System TED Traffic Engineering DatabaseIGP Interior Gateway Protocol UBR Unspecified Bit RateIP Internet Protocol UDB User Data BaseIP-II Internet Processor II UDP User Datagram ProtocolIPv4 Internet Protocol version 4 VC Virtual ContainerIPv6 Internet Protocol version 6 VCAT Virtual ConcatenationIQ Intelligent Queuing VCC Virtual Channel Connection

(ATM)IR Intermediate Range VLAN Virtual Local Area NetworkIS-IS Intermediate System to

Intermediate SystemVPC Virtual Path Connection

ISO International Organization for Standardization

VPI Virtual Path Identifier

ISP Internet Service Provider or In Service Performance

VPN Virtual Private Network

JTAC Juniper Technical Assistance Center

VRRP Virtual Router Redundancy Protocol

JUNOS Juniper Operating System WRED Weighted Random Early Discard

L1 Layer 1 WRR Weighted Round RobinL2 Layer 2

12 References

[1] Audit for IP Core Network Service - 00021-FAF 102 072

[2] Routing Protocols Review – TBD

[3] MPLS Review and Verification – TBD

[4] IP Network Performance Optimization – TBD

[5] OPNET simulation tool – www.opnet.com

[6] OPNET Documentation (Note:documentation should be installed and updated, use correct hyperlink)

http://www.opnet.com/

http://gask2web.ericsson.se/pub/get?DocNo=00021-FAF102072&HighestFree=Y

Ericsson Internal




[7] Troubleshooting the Import, OPNET product documentation

[8] Mobile-PBN – IP Backbone Design, 1/102 62-4/IPM 101 20/6 Uen

[9] MPLS Performance Optimization

[10]S. Malik, “Aggregate Internet Traffic: Considerations for the Planning of High Speed IP Networks”

[11] Network Working Group, Draft “Considerations for Benchmarking Link-State IGP Data Plane Route Convergence” http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app- 15.txt

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-

1 10260 faf10296-en_a_msword2003

Documents

Transcript of 1 10260 faf10296-en_a_msword2003