Upload
jgs9
View
120
Download
5
Tags:
Embed Size (px)
Citation preview
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
3 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
IP/MPLS Design and Optimization Services
4 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
5 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
IP Network Design and Analysis
6 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
7 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
8 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
9 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Greenfield MPLS Network Design
10 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
11 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Greenfield MPLS Design Methods and Procedures
The high level workflow of this service is as follows:
Node Information
Traffic and/or LSP Info
Greenfield Design
Candidate Link and Cost Data
Reports
Performance Analysis Reports
Other options (utilization, protection)
12 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
13 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Converged MPLS Network Design Service
14 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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.
15 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
The high level workflow of this service is as follows:
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
16 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
17 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Network Configuration Assessment
18 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
19 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
SP Guru Demos
20 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
21 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
China Unicom Study Demo
22 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
23 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
24 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
25 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
CU: Network View:Multi-Class MPLS Design
26 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
CU: Example Reports:Multi-Class MPLS Design
Link utilization report and GUI link utilization view
LSP explicit routes
Link class type subscription
27 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
28 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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%
29 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
30 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
31 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
32 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Bell Canada Study Demo
33 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
34 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
BC: Core Network Views
• Imported using core node configuration files showing isolated router with no apparent connection
Not connected
35 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
BC: Core Network Views, Cont’d
• Network view after grouping nodes into subnets based on OSPF areas
Backbone Area
36 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
BC: Unreachable Interfaces
• Of 27690 source-destination pairs, 422 (2%) are unreachable with destination interfaces on the following list of 6 routers:
37 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
BC: NetDoctor Analysis
May provide information about reasons for unreachable interfaces
• Overlapping subnets, unadvertised interfaces and network statements referencing invalid interfaces:
38 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
39 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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.
40 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
BC: Static Routes with Unreachable Next Hops – Flow Analysis Details, Cont.’d
Router NameRouter Name Destination AddressDestination Address Next Hop AddressNext Hop Address Next Hop NodeNext Hop NodeOutgoing InterfaceOutgoing Interface
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 ?
41 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
BC: Static Routes with Unreachable Next Hops – Flow Analysis Details, Cont.’d
Router NameRouter Name Destination AddressDestination Address Next Hop AddressNext Hop Address Next Hop NodeNext Hop NodeOutgoing InterfaceOutgoing Interface
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 ?
42 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
43 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
44 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
PaeTec Design Study Demo
45 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
46 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
47 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
PT: Network View in Network Design Tool
48 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
49 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
PT: Example Reports From SP Guru
Route information
Link utilization information
GUI view of routes
50 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
Total Consumed Voice BW (Mbps)
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
51 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
Total Consumed Voice BW (Mbps)
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
52 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
53 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
Total Consumed Voice BW (Mbps)
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
54 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
55 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
PaeTec Performance Study Demo
56 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
57 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
58 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
59 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
60 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
FY06 Service Development Plan
61 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
62 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
63 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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.
64 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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)
65 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
66 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
67 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
68 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
69 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Q & A
70 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
Supporting Information
71 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
72 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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
73 © Lucent Technologies 2005 - All Rights Reserved - Proprietary LWS Training, Oct. 24, 2005
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