MPLS MP Training Session

MPLS Design M&P Training Session
Ahmet Akyamac Benjamin Tang Ramesh Nagarajan
Bell Laboratories Advanced Technologies
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
LWS Training, Oct. 24, 2005
Lucent Technologies 2005 - All Rights Reserved - Proprietary
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
IP Network Design Methods and Procedures

The high level workflow of this service is as follows:
Set Scheduling, Policing Policies
Topology Information
IP Capacity Planning and Bandwidth Provisioning
Reports
Traffic Matrix and Profiles
Performance Analysis, Failure Analysis
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 customers 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
8
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
10
Greenfield MPLS Design Methods and Procedures

Node Information
Other options (utilization, protection)
Candidate Link and Cost Data
Greenfield Design
Reports
Traffic and/or LSP Info
Performance Analysis
Reports
11
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
12
Converged MPLS Network Design Service
13
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 LSPs vs. multiple single-class LSPs, 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.
14
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 Multi-Class traffic and/or LSP information, (VoIP, VPN, 3G, IA, etc.), protection options (Path, FRR, etc.)
Input Network topology and link class partitioning info
TE constraints (subscription, hops, delay, etc.)
MPLS Multi-Class Network Design
Reports
Routing and Performance Analysis

Reports
15
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
16
Network Configuration Assessment
17
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
18
SP Guru Demos
19
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 providers 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
20
China Unicom Study Demo
21
China Unicom (CU) Design Study

Study was for a carriers 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 LSPs to be routed using traffic engineering VPN LSPs to be protected using link disjoint backup paths Customer requested MPLS network design solutions with the
objective of minimizing subscribed TE bandwidth
22
CU: Design Parameters

Customer requested comparison of three MPLS architectures: Classless design Class partitioned link capacities with VPN traffic carried on single class E-LSPs Class partitioned link capacities with VPN traffic carried on multi class E-LSPs Some implications of these architectures: Single class LSPs represent a more granular routing, thus making better use of available capacity From a service providers 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
23
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 LSPs Run flow analysis to route flows and analyze performance data
24
CU: Network View: Multi-Class MPLS Design
25
CU: Example Reports: Multi-Class MPLS Design

LSP explicit routes
Link class type subscription
Link utilization report and GUI link utilization view LWS Training, Oct. 24, 2005
26
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
27
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 model
Initial number of IP-VPN Customers IP VPN Customers Yearly Growth Rate 500 5% Large 10% 50 NxDS0 T1 T3 OC3 Avg. IP-VPN Traffic (as % of access speed) NxDS0 T1 T3 OC3
IP-VPN Customer Distribution Avg. Number of Nodes per IP VPN Customer Access Speed Distribution
Medium 30% 30 65% 25% 10% 0%
Small 60% 10 80% 20% 0% 0%
50% 30% 20% 0% 50% 30% 30% 0%
28
CU: Design Scenario Common Properties

The following are common to all scenarios: LSP properties:
For Internet Access, LSPs request 0 TE bandwidth
For other types, LSPs 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 LSPs 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
29
CU: Core Link Utilization and TE Subscription Results Comparison

Design Min Fwd Util (%) Avg Fwd Util (%) Max Fwd Util (%) Total Fwd Traffic Capacity (Mbps) 14,520 12,816 12,816 Min Rtn Util (%) 0.00 0.00 0.00 Avg Rtn Util (%) 52.52 49.00 49.00 Max Rtn Util (%) 116.19 Total Rtn Traffic Capacity (Mbps) 13,737
Scenario 1 Scenario 2 Scenario 3
12.36 55.51 117.84 12.36 49.00 112.03 12.36 49.00 112.03
102.35 12,816 102.35 12,816
Design
Primary TE BW Subscribed (%) Min Avg Max
Backup TE BW Subscribed (%) Min Avg Max
Total TE BW Subscribed (%) Min Avg Max
Scenario 1 0.00
Scenario 2 0.00 Scenario 3 0.00
41.32 98.86 0.00

36.30 96.85 0.00 36.30 96.85 0.00
35.78 64.63 52.73 77.02 99.90

18.68 54.59 23.67 54.98 99.37 38.07 85.87 52.29 74.37 97.81
30
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 LSPs were fully protected using link disjoint backup paths without requiring additional capacity
31
Bell Canada Study Demo
32
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
33
BC: Core Network Views

Imported using core node configuration files showing isolated router with no
apparent connection
Not connected
34
BC: Core Network Views, Contd

Network view after grouping nodes into subnets based on OSPF areas
Backbone Area
35
BC: Unreachable Interfaces

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

Overlapping subnets, unadvertised interfaces and network statements
referencing invalid interfaces:
May provide information about reasons for unreachable interfaces
37
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
core1-grandprairie[ATM0/0/0.33]: core2-edmonton[ATM8/0.42]:
64.230.251.164/30:
64.230.251.166/30 64.230.251.165/30
ii) Overlapping address range

core1-victoria[FastEthernet0/1/0.10]: core2-victoria[FastEthernet0/1/0.10]:
64.230.251.160/28:
64.230.251.161/28 64.230.251.164/28
38
BC: Static Routes with Unreachable Next Hops Flow Analysis Details
Router Name
core2-montreal02
Destination Address
67.69.180.0/27 67.69.180.0/27
Next Hop Address

206.108.107.97/30 206.108.99.101/30
Next Hop Node Outgoing Interface

? ?
core3-toronto63
172.16.0.0/12 64.230.244.52/32 10.0.0.0/8 127.0.0.0/8 192.168.0.0/16
Null0 64.230.207.102/30* Null0 Null0 Null0 dis27-toronto63 GigabitEthernet5/2.
core2-torontodc
172.16.0.0/12 64.230.243.96/27 10.0.0.0/8 127.0.0.0/8 192.168.0.0/16
Null0 206.108.108.9/32 Null0 Null0 Null0 ?
core1-fortmcmurray
172.16.0.0/12 127.0.0.0/8 10.0.0.0/8 192.168.0.0/16 206.108.96.170/32 199.243.35.0/24 199.243.35.241/32
Null0 Null0 Null0 Null0 64.230.251.3/32 64.230.251.18/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. LWS Training, Oct. 24, 2005
39
BC: Static Routes with Unreachable Next Hops Flow Analysis Details, Cont.d
Router Name
core1-grandprairie
Destination Address
172.16.0.0/12 127.0.0.0/8 10.0.0.0/8 192.168.0.0/16 ` 206.108.96.172/32 199.243.34.0/24
Next Hop Address

Null0 Null0 Null0 Null0 64.230.251.35/32 64.230.251.50/32
? ?
core1-abbotsford
0.0.0.0/0 206.172.102.0/24
64.230.248.157/30 64.230.214.82/32
core2-vancouve ATM0/0/0.33 ?
core1-kamloops
172.16.0.0/12
Null0
127.0.0.0/8
10.0.0.0/8 192.168.0.0/16 206.108.96.218/32 199.243.32.0/24
Null0
Null0 Null0 64.230.251.67/32 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
40
BC: Static Routes with Unreachable Next Hops Flow Analysis Details, Cont.d
Router Name
core1-medicinehat
Destination Address
172.16.0.0/12 127.0.0.0/8 10.0.0.0/8 192.168.0.0/16 199.243.33.0/24 199.243.33.241/32
Next Hop Address

Null0 Null0 Null0 Null0 64.230.251.114/32 64.230.251.114/32
? ?
core1-reddeer
172.16.0.0/12 127.0.0.0/8 10.0.0.0/8 192.168.0.0/16
Null0 Null0 Null0 Null0
199.243.31.0/24
199.243.31.241/32
64.230.251.146/32
64.230.251.146/32
?
?
41
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:
Area 0.0.0.107: Area 0.0.0.122: Area 0.0.0.124:
Area 0.0.0.191:
Area 0.0.0.208: Area 0.0.0.232: Area 0.0.0.244: Area 0.0.1.64:
dis1-toronto46 cooksville17 bx1-toronto63 dis1-streetsville39 dis3-toronto01 bx2-montreal02 dis3-montreal42 bx1-montrealak dis1-hull20
42
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
43
PaeTec Design Study Demo
44
PaeTec (PT) Study Demo

Study was for a VoIP service providers 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 LSPs
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
45
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
46
PT: Network View in Network Design Tool
47
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
2.14
489.68
187.95
Note: Link utilization includes background data traffic
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

48
PT: Example Reports From SP Guru
Route information GUI view of routes
Link utilization information LWS Training, Oct. 24, 2005

49
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.
# of Routed LSPs/ demands 23/56 Total Consumed Voice BW (Mbps) 3456.79 Max. LSP Hop Length (Links) 3 Avg. LSP Hop Length (Links) 1.61 Max. Link Sub. (%) 93.84 Avg. Link Sub. (%) 58.44
Note: Link subscription includes background data traffic
The Y1 network topology with 6 OC-12 and 12 OC-3 links
does not have enough capacity to route all 56 LSPs to carry all VoIP traffic demands
50
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

# of Routed VoIP Demands 56/56 Total Consumed Voice BW (Mbps) 10870.06 Max. Hop Length (Links) 4 Avg. Hop Length (Links) 2.14 Max. Link Util. (%) 127.84 Avg. Link Util. (%) 69.29
Note: Link utilization includes background data traffic
The augmented Y2 capacity is still not sufficient to route
all VoIP traffic demands without overloading links if IP routing is used

51
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
52
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
# of Routed LSPs/ demands 56/56 Total Consumed Voice BW (Mbps) 11526.75 Max. LSP Hop Length (Links) 5 Avg. LSP Hop Length (Links) 2.27 Max. Link Sub. (%) 99.91 Avg. Link Sub. (%) 72.54
Note: Link subscription includes background data traffic
For Y2, all traffic engineered LSPs 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

53
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 LSPs 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
54
PaeTec Performance Study Demo
55
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
56
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
57
PT: Node Model For Performance Analysis

Node6 Model
Blue lines represent analyzed target VoIP traffic demands
VoIP traffic origination/ termination
Aggregation Router
Red lines represent other VoIP traffic demands

58
PT: Sample Performance Analysis Results

Network Capacity Shortest Path IP Routing Traffic Engineering Avg. EndMax. EndAvg. Max. MOS To-End To-End Packet Packet Score Delay (ms.) Delay (ms.) Loss (%) Loss (%) Range 208.21 41.42 281.36 194.84 2.87 0.34 4.86 1.64 1.44 3.64 2.91 4.43
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
59
FY06 Service Development Plan
60
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 carriers 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
61
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
62
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.
63
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)
64
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 Gurus DES feature over the designed and optimized MPLS network
65
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
66
Potential Customers for FY06 Developed Service Capabilities

CUSTOMER China Unicom OPPORTUNITY AND POTENTIAL SOW Incremental MPLS network design and optimization. Potential to carry VoIP and 3G traffic in the future MPLS network design and optimization PS if Lucent wins Juniper MPLS sales Consolidation of separate IP and MPLS backbones. Minimal-cost MPLS evolution strategy Incremental IP/MPLS network design and optimization for VoIP and data traffic Redundant configuration of OSPF areas. Minimal-cost redundant MPLS network design Reducing maintenance cost of IP networks. Potential consolidation of multiple IP networks to reduce CapEx and OpEx MPLS WORK ITEMS LEVERAGED A, B, C, D
Optus NTT
A, B A, B
Paetec Bell Canada
A, B, D A, B
Sprint
67
Potential Customers for FY06 Developed Services Capabilities (Contd)

CUSTOMER Bell South OPPORTUNITY AND POTENTIAL SOW Assess readiness of existing IP networks for being upgrade to MPLS supporting Ethernet services Potential VoIP over MPLS network design Potential MPLS core design and optimization. Network under study will carry all existing service types, voice, data, and multimedia. MPLS network design to carry GSM/UMTS signaling traffic. Migrating exiting wireless core to MPLS Network capacity planning. Potential need for incremental IP/MPLS network design and optimization to assure quality of VoIP traffic and minimize network cost. Re-design and optimization of the existing MPLS network Capacity planning for IP backbone MPLS WORK ITEMS LEVERAGED A, B
US Cellular BT 21 Century
B, D B, D
T-Mobile UK
A, B, C
UPC
A, B, D
AUNA KBW
A, B A, D
68
Q&A
69
Supporting Information
70
Contacts
Ahmet Akyamac akyamac@lucent.com (732) 949-5413
Ben Tang btang@lucent.com (732) 949-6477

Rafal Szmidt Szmidt@lucent.com +48 22 692 38 86 Ramesh Nagarajan rameshn@lucent.com (732) 949-2761
71
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 beginners guide Other documentation available at http://www.opnet.com/support Opnet Technical Support Email at support@opnet.com 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
72
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
73

MPLS MP Training Session

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MPLS MP Training Session

Transféré par

Droits d'auteur :

Formats disponibles

MPLS Design M&P Training Session

Ahmet Akyamac Benjamin Tang Ramesh Nagarajan

Bell Laboratories Advanced Technologies

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

IP/MPLS Design and Optimization Services

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

IP/MPLS Network Design Service Overview

design and optimization services

These services are provided using a combination of custom

commercial software such as SP Guru* and Bell Labs algorithms

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

IP Network Design and Analysis

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

IP Network Design Service

planning and performance analysis

and performance requirements, this service provides:

packet loss, etc. Routing and failure analysis

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

IP Network Design Methods and Procedures

Set Scheduling, Policing Policies

IP Capacity Planning and Bandwidth Provisioning

Traffic Matrix and Profiles

Performance Analysis, Failure Analysis

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

IP Network Design M&P, Cont.d

This design service uses routing/flow analysis to perform capacity planning

Greenfield MPLS Network Design

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

Greenfield MPLS Network Design

Greenfield MPLS Design Methods and Procedures

Other options (utilization, protection)

Candidate Link and Cost Data

Traffic and/or LSP Info

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

Greenfield MPLS Design M&P, Cont.d

arrive at a minimum cost quality design that meets customer requirements

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

Converged MPLS Network Design Service

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary

Converged MPLS Network Design Service

delivers the following:

Converged MPLS Network Design Methods and Procedures

Input Network topology and link class partitioning info

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

MPLS Multi-Class Network Design

Routing and Performance Analysis

Converged MPLS Network Design M&P, Cont.d

This service employs mathematical techniques and algorithms to arrive at a

minimum cost quality design that meets customer requirements

Network Configuration Assessment

LWS Training, Oct. 24, 2005

Lucent Technologies 2005 - All Rights Reserved - Proprietary