MPLS MP Training Session.ppt

MPLS Design M&PTraining Session

Bell Laboratories Advanced Technologies

Ahmet Akyamac

Benjamin Tang

Ramesh Nagarajan

2 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005

Training Agenda

Overview of IP/MPLS Design and Optimization Services

SP Guru Demo– MPLS TE Design Example (China Unicom)– MPLS Network Assessment Example (Bell Canada)– MPLS TE Design Example for VoIP (PaeTec)– Performance Analysis Example for VoIP (PaeTec)

FY06 Service Development Plan

Q&A

Supporting Information– Contacts– Supporting Documents & Information– SP Guru 11.5 Installation Instructions


IP/MPLS Design and Optimization Services


IP/MPLS Network Design Service Overview

Tools, methods and procedures for IP and MPLS network design and optimization services

Current IP and MPLS service capabilities:– IP network design and analysis

– Greenfield MPLS network design

– Converged MPLS network design

– Network configuration assessment

These services are provided using a combination of custom commercial software such as SP Guru* and Bell Labs algorithms

* The commercial software was customized for Lucent Technologies in support of the IP and MPLS service capabilities


IP Network Design and Analysis


IP Network Design Service

For multi-class IP networks, perform network design, capacity planning and performance analysis

Also includes features such as failure analysis and configuration analysis

Given a network topology and a set of traffic demands, profiles and performance requirements, this service provides:– Capacity planning and link dimensioning

– Class-based link bandwidth provisioning and allocation

– Setting of policing and scheduling policies to meet performance requirements

– Simulation based performance analysis including end-to-end delay, packet loss, etc.

– Routing and failure analysis


Performance Analysis, Failure Analysis

IP Network Design Methods and Procedures

The high level workflow of this service is as follows:

Set Scheduling, Policing Policies

Traffic Matrix and Profiles

IP Capacity Planning and Bandwidth Provisioning

Topology Information

Reports

Reports


IP Network Design M&P, Cont.’d Typical inputs from customer:

– Node locations, capacity/configurations– Link types, connections and weight– Traffic matrices and profiles – if not provided by customer or only subscriber density is

available, we can use internal tools such as INDT and Lucent Toolbox with gravity modeling to forecast end-to-end traffic demands and traffic profiles

– Initial scheduling, policing, link bandwidth allocation policies (optional, as this can also be a typical deliverable)

– Traffic performance requirements

This design service uses routing/flow analysis to perform capacity planning and failure analysis, and discrete event simulation for performance evaluation.

Typical deliverables:– Class based link bandwidth allocation– Recommendations for scheduling, policing policies, network changes to achieve

customer’s performance requirements– Simulation based performance analysis including end-to-end delay, packet loss, jitter,

etc.– Routing and failure analysis– Network configuration reports showing errors/misconfigurations etc.– Detailed reports, logs, graphical views


Greenfield MPLS Network Design


Greenfield MPLS Network Design

Used for designing an MPLS network from scratch

Given node locations, forecasted traffic and/or LSP requirements and candidate link types (OC-3, OC-12, etc.) and other requirements, design minimum cost link placement

Cost can be represented and combined in numerous ways:– Fixed link costs, for example $1000 per OC-3 link deployed– Mileage costs, for example $100/mile– Bandwidth costs, for example $5 per Mbps of subscribed LSP

bandwidth– Costs can also be based on tariffs if the links are to be leased,

these could be obtained from tariff tables– Even more general non-currency metrics such as number of hops

and link distance can be used

The design service also supports additional requirements including:– Maximum link utilization/subscription– Protection options determined through failure analysis


Greenfield MPLS Design Methods and Procedures


Node Information

Traffic and/or LSP Info

Greenfield Design

Candidate Link and Cost Data

Reports

Performance Analysis Reports

Other options (utilization, protection)


Greenfield MPLS Design M&P, Cont.’d

Typical inputs from customer:– Node locations, capacity/configurations– Traffic and/or LSP information– Candidate link types, cost/tariff information, – Other requirements such as utilization/subscription, protection

This service employs mathematical techniques and algorithms to arrive at a minimum cost quality design that meets customer requirements

Typical deliverables:– Network design, link placement, cost information– Traffic and/or LSP routes– Simulation based performance analysis including end-to-end delay,

packet loss, jitter, failure analysis etc.– Detailed reports, logs, graphical views


Converged MPLS Network Design Service


Converged MPLS Network Design Service

For MPLS networks that carry multiple classes of traffic (e.g., VoIP, VPN, 3G, Internet Access etc.) with different service requirements, perform multi-class traffic engineering, design and optimization

Typical service requirements include bandwidth allocation per class, multi-class LSP’s vs. multiple single-class LSP’s, protection schemes (for example, path based, FRR facility bypass, FRR 1+1), hop and delay constraints, performance requirements, etc.

The design service provides a minimum cost network design and delivers the following:– Allocation and partitioning of link capacity

– LSP dimensions and routes

– Simulation based performance analysis including end-to-end delay, packet loss, failure analysis etc.


Converged MPLS Network Design Methods and Procedures The MPLS network design and optimization service offers

network design and performance analysis for multi-class traffic-engineered MPLS networks


Input Network topology and link class partitioning info

Input Multi-Class traffic and/or LSP information, (VoIP, VPN, 3G, IA, etc.), protection options (Path, FRR, etc.)

MPLS Multi-Class Network Design

TE constraints (subscription, hops, delay, etc.)

Routing and Performance Analysis

Reports

Reports


Converged MPLS Network Design M&P, Cont.’d

Typical inputs from customer:– Node locations, capacity/configurations– Link types, connections, class type partition (optional, as this can also be a typical

deliverable) and subscription constraints– Multi-class traffic and/or LSP information, protection options – If traffic or LSP information not provided by customer or only subscriber density is

available, we can use internal tools such as INDT and Lucent Toolbox with gravity modeling to forecast end-to-end traffic demands and traffic profiles

– Traffic engineering constraints, design objectives

This service employs mathematical techniques and algorithms to arrive at a minimum cost quality design that meets customer requirements

Typical deliverables:– Multi-class MPLS network design solution– Detailed reports, analyses, graphical views– Routing and performance analysis– Comparison of different architectures, design objectives and parameters in terms of cost

and performance– Recommendations to improve network cost and performance


Network Configuration Assessment


Network Configuration Assessment

This service is used to check for network configuration and setup errors and inefficiencies

Typical inputs from customer:– Network configuration through Cisco or Juniper configlet files or

text import files

The following features are currently supported:– Identify unreachable interfaces: Creates demands between all pairs

of interfaces and checks whether or not the demand is routable. Unroutable demands may indicate configuration errors.

– SP Guru NetDoctor: Used to analyze configuration errors, policy violations and inefficiencies in a network. Numerous check rules are pre-defined for IP and MPLS, custom configuration rules can also be defined.

– Flow Analysis: Generate routing and forwarding information and detailed reports to further diagnose NetDoctor findings


SP Guru Demos


SP Guru Demonstration

China Unicom study demo– MPLS network design study to compare different MPLS TE design options

for a core network carrying internet access and VPN traffic– Performed using SP Guru version 11.0 Beta3

Bell Canada study demo– Network configuration assessment for a large service provider network– Performed using SP Guru version 11.0 Beta3

PaeTec design study demo– Multi-year design study for VoIP service provider’s MPLS/IP core network

comparing different voice codes and architectural options– Performed using SP Guru version 11.0 Beta3

PaeTec performance study demo– VoIP performance study for PaeTec network– Performed using SP Guru version 11.0 Beta3


China Unicom Study Demo


China Unicom (CU) Design Study

Study was for a carrier’s core network consisting of 7 core nodes (Juniper T-640 routers), 10 OC-48 network links

Two types of traffic are present: Internet Access (IA) and VPN traffic

IA traffic is best effort, LDP based and VPN traffic has four classes with different priorities

VPN LSP’s to be routed using traffic engineering

VPN LSP’s to be protected using link disjoint backup paths

Customer requested MPLS network design solutions with the objective of minimizing subscribed TE bandwidth


CU: Design Parameters

Customer requested comparison of three MPLS architectures:– Classless design– Class partitioned link capacities with VPN traffic carried on single

class E-LSP’s– Class partitioned link capacities with VPN traffic carried on multi

class E-LSP’s

Some implications of these architectures:– Single class LSPs represent a more granular routing, thus making

better use of available capacity– From a service provider’s point of view, multi class LSPs could

present operational advantages– While partitioning bandwidth may result in under-utilization of

existing resources, it also creates fairness in that a certain bandwidth is always available for each class type


CU: Design Methodology

The study involved the following steps in SP Guru:– Network topology import from Juniper configlet files– Topology modification and export to text files – Modify text files to represent the three design scenarios– Create LSP text files for the three scenarios– For each scenario, import node, link and LSP text files– Routing of LSPs using the mpls_ds_te design action with the

objective of minimizing subscribed bandwidth (primary LSPs protected by link disjoint backup LSPs)

– Generate traffic flows using traffic characterization for VPN traffic, and base IA traffic on previous studies with published growth information

– Import of traffic flows from spreadsheets– Routing of traffic onto the LSP’s– Run flow analysis to route flows and analyze performance data


CU: Network View:Multi-Class MPLS Design


CU: Example Reports:Multi-Class MPLS Design

Link utilization report and GUI link utilization view

LSP explicit routes

Link class type subscription


CU: Design Scenario Descriptions The following are common to all scenarios:

5 classes of traffic: – Internet Access: Best Effort (CT 0), 16 demands

– VPN Class 0: Excellent Effort (CT 3), 42 demands

– VPN Class 1: Streaming Multimedia (CT 4), 42 demands

– VPN Class 2: Interactive Multimedia (CT 5), 42 demands

– VPN Class 3: Interactive Voice (CT 6), 42 demands

Traffic intensity:– Total Internet Access (IA) traffic is 5508 Mbps

IA demands are from the non-gateway locations (Chengdu, Xian, Wuhan, Shenyang) to the closest two gateways, in each direction

– Total VPN traffic is 15,655 Mbps, partitioned according to the following: Class 0: 50%, Class 1: 25%, Class 2: 20%, Class 3: 5% VPN demands are between each pair of nodes, in each direction


CU: Estimation of IA and IP VPN Traffic

Internet Access– Based on previous IA traffic carried by China Unicom ATM

network in 2003 and estimated growth rate since 2003

IP VPN– Calculated based on the following customer modelInitial number of IP-VPN Customers 500 IP VPN Customers Yearly Growth Rate 5%

Large Medium SmallIP-VPN Customer Distribution 10% 30% 60%Avg. Number of Nodes per IP VPN Customer 50 30 10 Access Speed Distribution

NxDS0 50% 65% 80%T1 30% 25% 20%T3 20% 10% 0%

OC3 0% 0% 0%Avg. IP-VPN Traffic (as % of access speed)

NxDS0 50%T1 30%T3 30%

OC3 0%


CU: Design Scenario Common Properties The following are common to all scenarios:

LSP properties:– For Internet Access, LSP’s request 0 TE bandwidth

– For other types, LSP’s request bandwidth equal to the sum of the traffic rates to be carried, plus the required MPLS overhead

– The type of LSP (single/multi class) depends on the design scenario

– LSP’s are configured with link disjoint backup paths

Link properties:– 100% of link bandwidth is available to TE subscription

– The partitioning of the bandwidth depends on the design scenario

– A second OC-48 link between Shenyang and Beijing is added to allow for backup paths


CU: Core Link Utilization and TE Subscription Results Comparison

Design

Min Fwd Util (%)

Avg Fwd Util (%)

Max Fwd Util (%)

Total Fwd Traffic Capacity (Mbps)

Min Rtn Util (%)

Avg Rtn Util (%)

Max Rtn Util (%)

Total Rtn Traffic Capacity (Mbps)

Scenario 1 12.36 55.51 117.84 14,520 0.00 52.52 116.19 13,737

Scenario 2 12.36 49.00 112.03 12,816 0.00 49.00 102.35 12,816

Scenario 3 12.36 49.00 112.03 12,816 0.00 49.00 102.35 12,816

Design

Primary TE BW Subscribed (%)

Backup TE BW Subscribed (%)

Total TE BW Subscribed (%)

Min Avg Max Min Avg Max Min Avg Max

Scenario 1 0.00 41.32 98.86 0.00 35.78 64.63 52.73 77.02 99.90

Scenario 2 0.00 36.30 96.85 0.00 18.68 54.59 23.67 54.98 99.37

Scenario 3 0.00 36.30 96.85 0.00 38.07 85.87 52.29 74.37 97.81


CU: Design Conclusions

As a general technical summary:– Scenario 1 is best in terms of minimum hop counts (not shown on

previous slide).– Scenario 2 is best if all LSPs are to be successfully protected.– Scenario 2 is best in terms of overall TE subscription.– Scenarios 2 and 3 are best in terms of link utilization.

Some design conclusions:– Extra link was suggested for feasible protection design– Single class E-LSP design with class partitioned link capacities

resulted in overall minimum subscribed TE bandwidth and lowest consumed link capacity, while maintaining only slightly higher LSP primary and backup hop counts compared to the other solutions.

– Furthermore, single class E-LSP design was the only case in which all VPN LSP’s were fully protected using link disjoint backup paths without requiring additional capacity


Bell Canada Study Demo


Bell Canada (BC) Study Demo

The aim of the study was to analyze network provided by Bell Canada for configuration errors or inconsistencies

Bell Canada provided 540 sanitized router configuration files – the part of the study presented here focused on the core network

The study involved the following steps:– Import network into SP Guru from Cisco configuration files– Run Identify Unreachable Interfaces to see if there are any

unreachable destinations in the network– Run NetDoctor with IP routing rules selected to analyze

network for configuration errors or inconsistencies– Gather further information using Flow Analysis and the

associated routing reports


BC: Core Network Views

• Imported using core node configuration files showing isolated router with no apparent connection

Not connected


BC: Core Network Views, Cont’d

• Network view after grouping nodes into subnets based on OSPF areas

Backbone Area


BC: Unreachable Interfaces

• Of 27690 source-destination pairs, 422 (2%) are unreachable with destination interfaces on the following list of 6 routers:


BC: NetDoctor Analysis

May provide information about reasons for unreachable interfaces

• Overlapping subnets, unadvertised interfaces and network statements referencing invalid interfaces:


BC: Unadvertised Interfaces & Overlapping Subnets

• Further routing analysis reveals that some interfaces are not advertised by these 5 routers:

– On core1-toronto12: interface [POS3/3] (64.230.203.109/30)

– On core1-toronto63: interface [POS3/2] (64.230.203.250/30)

– On core2-hamilton14: interface [POS1/2] (64.230.203.110/30)

– On core2-london14: interface [POS1/3] (64.230.203.249/30)

– On core2-victoria: [FastEthernet 0/1/0.10] (64.230.251.164), [FastEthernet 0/1/0.25] (64.230.251.179), [FastEthernet 0/1/0.80] (69.158.202.146), [FastEthernet 2/0/0.10] (64.230.251.193), [FastEthernet 2/0/0.25] (64.230.251.209), to core1-victoria

Note: in all cases no routing protocol is running on the interface, which could be a possible explanation for the unreachable interfaces

• The following 2 pairs of interfaces have overlapping IP ranges:i) Overlapping address in the range 64.230.251.164/30:

core1-grandprairie[ATM0/0/0.33]: 64.230.251.166/30core2-edmonton[ATM8/0.42]: 64.230.251.165/30

ii) Overlapping address range 64.230.251.160/28:core1-victoria[FastEthernet0/1/0.10]: 64.230.251.161/28core2-victoria[FastEthernet0/1/0.10]: 64.230.251.164/28


BC: Static Routes with Unreachable Next Hops – Flow Analysis Details

Router NameRouter Name Destination AddressDestination Address Next Hop AddressNext Hop Address Next Hop NodeNext Hop NodeOutgoing InterfaceOutgoing Interface

core2-montreal02 67.69.180.0/27 206.108.107.97/30 ?

67.69.180.0/27 206.108.99.101/30 ?

core3-toronto63 172.16.0.0/12 Null0

64.230.244.52/32 64.230.207.102/30* dis27-toronto63 GigabitEthernet5/2.

10.0.0.0/8 Null0

127.0.0.0/8 Null0

192.168.0.0/16 Null0

core2-torontodc 172.16.0.0/12 Null0

64.230.243.96/27 206.108.108.9/32 ?

10.0.0.0/8 Null0

127.0.0.0/8 Null0

192.168.0.0/16 Null0

core1-fortmcmurray 172.16.0.0/12 Null0

127.0.0.0/8 Null0

10.0.0.0/8 Null0

192.168.0.0/16 Null0

206.108.96.170/32 64.230.251.3/32 ?

199.243.35.0/24 64.230.251.18/32 ?

199.243.35.241/32 64.230.251.18/32 ?

* Note: This is an unreachable next hop when only the core network is considered. However, reachable next hop exists when whole network is considered.


BC: Static Routes with Unreachable Next Hops – Flow Analysis Details, Cont.’d


core1-grandprairie 172.16.0.0/12 Null0

127.0.0.0/8 Null0

10.0.0.0/8 Null0

192.168.0.0/16 Null0

` 206.108.96.172/32 64.230.251.35/32 ?

199.243.34.0/24 64.230.251.50/32 ?

core1-abbotsford 0.0.0.0/0 64.230.248.157/30 core2-vancouve ATM0/0/0.33

206.172.102.0/24 64.230.214.82/32 ?

core1-kamloops 172.16.0.0/12 Null0

127.0.0.0/8 Null0

10.0.0.0/8 Null0

192.168.0.0/16 Null0

206.108.96.218/32 64.230.251.67/32 ?

199.243.32.0/24 64.230.251.82/32 ?

core1-kelowna 206.172.198.0/24 64.230.214.18/32 ?

core1-princegeorge 199.243.37.0/24 64.230.214.50/32 ?

core1-vernon 199.243.36.0/24 64.230.251.242/32 ?


BC: Static Routes with Unreachable Next Hops – Flow Analysis Details, Cont.’d


core1-medicinehat 172.16.0.0/12 Null0

127.0.0.0/8 Null0

10.0.0.0/8 Null0

192.168.0.0/16 Null0

199.243.33.0/24 64.230.251.114/32 ?

199.243.33.241/32 64.230.251.114/32 ?

core1-reddeer 172.16.0.0/12 Null0

127.0.0.0/8 Null0

10.0.0.0/8 Null0

192.168.0.0/16 Null0

199.243.31.0/24 64.230.251.146/32 ?

199.243.31.241/32 64.230.251.146/32 ?


BC: Single Router OSPF Areas – Obtained From Flow Analysis

• List of “Routers on a Stick” – single gateway router OSPF areas

– Area 0.0.0.104: bx3-toronto12

– Area 0.0.0.105: dis1-toronto46

– Area 0.0.0.107: cooksville17

– Area 0.0.0.122: bx1-toronto63

– Area 0.0.0.124: dis1-streetsville39

– Area 0.0.0.191: dis3-toronto01

– Area 0.0.0.208: bx2-montreal02

– Area 0.0.0.232: dis3-montreal42

– Area 0.0.0.244: bx1-montrealak

– Area 0.0.1.64: dis1-hull20


BC: Some Analysis Results

• 2% (422) interfaces/ports appear to be inaccessible– Possibly due to some interfaces being unadvertised however, that would only account

for 5 of the 6 devices involved

• Unreachable next hops on some static routes– 12 nodes have a total of 18 Static Routes defined to apparently unreachable next hops

(though for one static route, the next hop exists if the entire network is considered)

• Overlapping subnets & unadvertised interfaces– There appear to be at least two overlapping subnets

• Network statements referencing invalid interfaces– OSPF errors indicate 157 statements referencing invalid interfaces (these interfaces

may exist on a device not imported for the purposes of the analysis)

• Isolated Backbone Router discovered - not connected– Note: There is a router that is not directly linked to another core router

• Single OSPF Area Gateways (SPOF)– These are areas where a single OSPF Gateway manages the connectivity between

that area and area 0


PaeTec Design Study Demo


PaeTec (PT) Study Demo

Study was for a VoIP service provider’s MPLS/IP core network with 11 nodes (Cisco 12410 routers), and an initial mix of OC-3 and OC-12 links

Voice traffic (originating/terminating at 8 of the nodes) to be carried over this network with existing data traffic

Voice traffic to be carried on 56 LSP’s

Customer provided Y1 and Y2 network link augmentation plans, along with expected data background traffic

Customer wanted to compare the following design scenarios:– G.711 codec-based traffic vs. G.729a codec-based traffic

– Y1 vs. Y2 network topology and background traffic

– Primary LSP routes, optional link disjoint secondary LSP routes

– Shortest path design, TE based MPLS design


PaeTec (PT) Study Methodology

The study involved the following steps:– Import network into SP Guru using text import files

– Import data flows into SP Guru using spreadsheet import files

– Convert VoIP service location and subscriber density data to projected VoIP traffic flow

– Create LSPs in SP Guru to carry VoIP traffic

– Design network using shortest path (LDP) or Traffic Engineering using mpls_ds_te module in SP Guru

– Analyze network design


PT: Network View in Network Design Tool


PT: Can Current Y1 Network Handle VoIP Traffic?

We first use shortest path IP routing to route VoIP traffic demands

# of Routed VoIP Demands

Total Consumed Voice BW (Mbps)

Max. Hop Length (Links)

Avg. Hop Length (Links)

Max. Link Util. (%)

Avg. Link Util. (%)

56/56 10870.27 4 2.14 489.68 187.95

Results showed that there are numerous links that are over-utilized. This would severely degrade VoIP performance.

IP routing based design shows that Y1 capacity is not sufficient to route all VoIP traffic demands without overloading links

Note: Link utilization includes background data traffic


PT: Example Reports From SP Guru

Route information

Link utilization information

GUI view of routes


PT: Use Traffic Engineering for Y1 Network?

Using MPLS, perform a traffic engineering design where VoIP traffic is carried over LSPs.

With traffic engineering based LSPs, we set the link reservable bandwidth to 100% of the link capacity in order to find a solution with no over-subscribed links.

The Y1 network topology with 6 OC-12 and 12 OC-3 links does not have enough capacity to route all 56 LSP’s to carry all VoIP traffic demands

# of Routed LSPs/ demands


Max. LSP Hop Length (Links)

Avg. LSP Hop Length (Links)

Max. Link Sub. (%)

Avg. Link Sub. (%)

23/56 3456.79 3 1.61 93.84 58.44

Note: Link subscription includes background data traffic


PT: Augment Network For Y2

Augment network capacity in Y2 upgrading all links to OC-12 (note background data traffic increases by 40%)

We first use shortest path IP routing to route VoIP traffic demands to determine if Y2 capacity will be enough

The augmented Y2 capacity is still not sufficient to route all VoIP traffic demands without overloading links if IP routing is used

# of Routed VoIP Demands


Max. Hop Length (Links)

Avg. Hop Length (Links)

Max. Link Util. (%)

Avg. Link Util. (%)

56/56 10870.06 4 2.14 127.84 69.29

Note: Link utilization includes background data traffic


PT: Augment Network For Y2: Add More Link Capacity?

There are 6 links that are over-utilized:– Node10 – Node11

– Node6 – Node7

– Node8 – Node 10

– Node9 – Node 10

– Node3 – Node4

– Node7 – Node9

One option is to add more link capacity at the above locations– Add parallel OC-12 or upgrade these links to OC-48? Would depend

on link costs, tariffs etc.

There are numerous under-utilized links in the network. Another option is to use traffic engineering to be able to better make use of existing resources


PT: Use Traffic Engineering for Y2 Network?

This time for Y2, we set the link reservable bandwidth to 100% of the link capacity in order to find a solution with no over-subscribed links using traffic engineering

For Y2, all traffic engineered LSP’s can be successfully routed to carry the voice traffic within the existing network capacity, without having to add or upgrade links

The increase in total consumed bandwidth and hop length (vs. IP routing) is minimal

# of Routed LSPs/ demands


Max. LSP Hop Length (Links)

Avg. LSP Hop Length (Links)

Max. Link Sub. (%)

Avg. Link Sub. (%)

56/56 11526.75 5 2.27 99.91 72.54

Note: Link subscription includes background data traffic


PT: Capacity Analysis Conclusions

Y1 capacity is not sufficient to carry all expected VoIP traffic without over-utilization

The upgraded Y2 capacity (all OC-12 links) is also not sufficient to carry all VoIP traffic without over-utilization using IP routing

One option is to add/upgrade 6 links

Another option is to use traffic engineering and route VoIP traffic over MPLS LSP’s while maintaining link utilization at less than 100%

The traffic engineering option enables all traffic to be carried on existing capacity without capacity upgrade expenditures, with minimal increase in total bandwidth consumed and hop length


PaeTec Performance Study Demo


PaeTec (PT) Performance Study Demo

Subsequent to network design, conduct end-to-end performance analysis to estimate VoIP quality measures such as end-to-end delay, packet loss, etc. (then translate to MOS scores)

The study involved the following steps:– Import network into SP Guru using text import files

– Import data flows into SP Guru using spreadsheet import files

– Prepare network for VoIP performance simulation

– Create detailed VoIP traffic flows for G.711 or G.729a codec using traffic flow generator in SP Guru for performance simulation

– Run performance simulation for selected VoIP demands to estimate VoIP call quality rating


PT: Performance Analysis

For end-to-end performance analysis, a more detailed node model was generated, shown on next page

We analyze performance for selected target user traffic indicated by the “-user” tag on next page (blue)

Other voice traffic (red) and background data traffic (not shown) is also included, but performance data is not collected for these


PT: Node Model For Performance Analysis

VoIP traffic origination/ termination

Aggregation Router

Blue lines represent analyzed target VoIP traffic demands

Red lines represent other VoIP traffic demands

Node6 Model


PT: Sample Performance Analysis Results

For acceptable end-to-end performance, links should not be over-utilized after VoIP traffic is introduced

This can be achieved by upgrading/adding links to the Y2 network, or using MPLS based traffic engineering

Network Capacity

Avg. End-To-End Delay (ms.)

Max. End-To-End Delay (ms.)

Avg. Packet Loss (%)

Max. Packet Loss (%)

MOS Score Range

Shortest Path IP Routing

208.21 281.36 2.87 4.86 1.44 – 3.64

Traffic Engineering

41.42 194.84 0.34 1.64 2.91 – 4.43


FY06 Service Development Plan


FY06 Service Capability Development

A. MPLS protection design – Mix of protected (end-to-end path protection or FRR) and unprotected traffic for various classes of services according to carrier’s protection policy

B. MPLS cost optimization – Address minimal-cost network design considering both CapEx and OpEx for existing MPLS networks

C. 3G over MPLS – Consider network design and optimization issues specific to carrying and evolving 3G applications over MPLS

D. VoIP over MPLS – Address MPLS network design and optimization for VoIP

E. NetInventory - SP Guru Interface – Feature to import NetInventory configuration data into SP Guru


MPLS Protection Design

Deliverables– Differentiating algorithms for MPLS Fast Re-Route (FRR) and

Hybrid MPLS protection created by Bell Labs will be integrated with SP Guru

– M&P for FRR and Hybrid protection using SP Guru and integrated Bell Labs algorithms


MPLS Cost Optimization

Deliverables– The cost re-optimization and re-design will create new M&P

and, if necessary, new algorithms to enable CAPEX/OPEX reduction by eliminating equipment and capacity.

– Numerous modes of operation could be supported including constraints on where and how much equipment/capacity can be removed, required spare capacity and acceptable traffic performance (in terms of loss, delay etc.) following equipment/capacity removal.


3G Over MPLS

Deliverables– Traffic profiles covering most common 3G applications (web

browsing, IM, video streaming, VoIP, etc) and their bandwidth and performance requirements

– Traffic modeling that converts 3G application demands to point-to-point traffic as input to MPLS design and optimization

– Guidelines for class of service design for 3G applications– M&P for 3G over MPLS design and optimization and

performance assessment using SP Guru (FLAN, DES)


VoIP Over MPLS

Deliverables– Traffic modeling and generation of VoIP traffic (from Erlang

to p2p VoIP traffic)

– Design of multiple CT to assure quality of VoIP in the presence of other data traffic, protection of VoIP traffic, and assessment of VoIP quality using SP Guru’s DES feature over the designed and optimized MPLS network


NetInventory – SP Guru Interface

Deliverables– Scripts developed on NetInventory or SP Guru to allow for

the import of NetInventory discovered network data into OPNET for further analysis and design


Potential Customers for FY06 Developed Service Capabilities

CUSTOMER OPPORTUNITY AND POTENTIAL SOW

MPLS WORK ITEMS LEVERAGED

China Unicom Incremental MPLS network design and optimization. Potential to carry VoIP and 3G traffic in the future

A, B, C, D

Optus MPLS network design and optimization PS if Lucent wins Juniper MPLS sales

A, B

NTT Consolidation of separate IP and MPLS backbones. Minimal-cost MPLS evolution strategy

A, B

Paetec Incremental IP/MPLS network design and optimization for VoIP and data traffic

A, B, D

Bell Canada Redundant configuration of OSPF areas. Minimal-cost redundant MPLS network design

A, B

Sprint Reducing maintenance cost of IP networks. Potential consolidation of multiple IP networks to reduce CapEx and OpEx

B


Potential Customers for FY06 Developed Services Capabilities (Cont’d)

CUSTOMER OPPORTUNITY AND POTENTIAL SOW

MPLS WORK ITEMS LEVERAGED

Bell South Assess readiness of existing IP networks for being upgrade to MPLS supporting Ethernet services

A, B

US Cellular Potential VoIP over MPLS network design

B, D

BT 21 Century Potential MPLS core design and optimization. Network under study will carry all existing service types, voice, data, and multimedia.

B, D

T-Mobile UK MPLS network design to carry GSM/UMTS signaling traffic. Migrating exiting wireless core to MPLS

A, B, C

UPC Network capacity planning. Potential need for incremental IP/MPLS network design and optimization to assure quality of VoIP traffic and minimize network cost.

A, B, D

AUNA Re-design and optimization of the existing MPLS network

A, B

KBW Capacity planning for IP backbone A, D


Q & A


Supporting Information


Contacts

Ahmet Akyamac– [email protected]– (732) 949-5413

Ben Tang– [email protected]– (732) 949-6477

Rafal Szmidt– [email protected]– +48 22 692 38 86

Ramesh Nagarajan– [email protected]– (732) 949-2761


Supporting Documents & Information

Separate accompanying documents to this session:– MPLS Design and Optimization Methods and Procedures– Service Provider MPLS Network Design Study– Greenfield MPLS Network Design Using SP Guru

SP Guru Product Documentation– Online Product Documentation available in SP Guru by clicking Help-

>Product Documentation or by pressing F1 anywhere within the tool– The SP Guru User Guide (accessible from the online Product

Documentation main page) is a good beginner’s guide– Other documentation available at http://www.opnet.com/support

Opnet Technical Support– Email at [email protected] or open ticket at

http://www.opnet.com/support– Technical support is free for Lucent users– Must establish account first to access most files and features

available on the support web site, as well as technical support


SP Guru 11.5 Installation Instructions

Go to http://www.opnet.com/support

Go to installation instructions and download the following files for SP Guru 11.5:– spguru_115A_PL1_3352_win32.exe– models_11.5.A_21-Sep-2005_win32.exe– spguru_docs_21-Sep-2005_win32.exe

Install the files on your machine in the order shown above

When the installation asks for license server, choose obtain license from license server with the following information:– License port: port_a– License server: usil100014svr23.ih.lucent.com

When you first run SP Guru, it will create the op_admin and op_models directories– op_admin contains the log files and administrative information– op_models contains the project and model files and is the initial

default directory

MPLS MP Training Session.ppt

Documents

Transcript of MPLS MP Training Session.ppt