MODULE3 - NIB II Project 1 PDF

Bharat Sanchar Nigam Limited Hkkjr lapkj fuxe fyfeVsM
JTO Ph-II DATA NETWORK

WEEK-3 (NIB II Project 1)
BSNL
ES & IT FACULTY
COURSE CODE – BRBCOIF114
BHARAT RATNA BHIMRAO AMBEDKAR

INSTITUTE OF TELECOM TRAINING,
RIDGE ROAD, JABALPUR – 482 001
(ISO-9008 : 2008 Certified)
―DATA NETWORK‖ FOR JTOs PH-II
PHASE II SPECIALIZATION TRAINING

ON
―DATA NETWORKS‖ FOR JTOs
INDEX
Week-III NIB-II Project 1
S No Topic Page No.

1. NIB-II Overview 2
2. Overview of MPLS Technology MPLS based Layer-2 VPN, 24
Basic MPLS Lab & MPLS based Layer-2 VPN
Configuration and QOS
3. Label Distribution Protocol 148
4. RSVP-TE 166
5. MPLS Based Layer-3 VPN 220
6. Cisco Router Configuration: MPLS based Layer-3 VPN 225
Configuration using MP-iBGP/eBGP, MP-iBGP/OSPF &
MP-iBGP/Static/Default
7. NMS & EMS (Project-1) OSS/BS as part of Project 3 232
8. NGN, Wi-MAX, Voip, IMS 245
BRBRAITT : June-2011 1
NIB-II OVERVIEW
OVERVIEW OF NATIONAL INTERNET BACKBONE-II (NIB-II)
Introduction
BSNL has planned to setup NIB-II to provide world class infrastructure to offer
various value added services to a broader customer base county-wide that will help to
accelerate the Internet revolution in India. Moreover the NIB-II will create a platform,
which enables e-governance, e-banking, e-learning, etc. with the key point of Service
Level Agreements & Guarantee in tune with Global standards and customer
expectations.
NIB-II has been grouped into following three major projects.
Project 1: - MPLS based IP Network infrastructure covering 71 cities along

with associated NMS, PMS, Firewall and Caching platforms.
Project 2.1: Access Gateway platform using Dialup comprising of narrow
band RAS and DSL equipment.
Project 2.2: Access Gateway platform comprising of Broadband RAS and
DSL equipment.
Project 3: Messaging and Storage platform and Provisioning, Billing and
Customer care and Enterprise management system.
The network shall seamlessly integrate with the already existing network
infrastructure comprising of the TCP/IP based NIB-I and MPLS VPN network. The
NIB-II project comprises of Technology solutions from different product
manufacturers with the provision for future expansion.
SERVICES PLANNED IN NIB-II
Internet Access
Dialup access services/ Leased Access Services.
Digital Subscriber Line (DSL) Access Services: Broadband ―always-on-
internet‖ access over copper cables.
Direct Ethernet Access Services: Broadband ―always-on-internet‖ access
using Fiber-to-the-building.
Virtual Private Network (VPN) Services
Layer 2 MPLS VPN Services: Point-to-point connectivity between corporate
LAN sites.
Layer 3 MPLS VPN Intranet and Extranet Services: LAN interconnectivity
between multiple Corporate LAN sites.
Managed Customer Premises Equipment (CPE) Services.
Value Added Services
Encryption Services: One of the end-to-end data security features.
Firewall Services: One of the security features provided to customer.
Network Address Translation (NAT) Services: Service that will enable private
users to access public networks.
Messaging Services
Data Centre Services at Bangalore, Delhi and Mumbai
Broadband Services through DSL & Direct Ethernet
Fast Internet Access Services
Terminating Dialup and DSL/Direct Ethernet Customers on MPLS VPNs
Multicast Video Streaming Services.
Video on Demand Services
Network Architecture:
Core Network:The NIB-II shall constitute an integrated 2-layer IP and MPLS
network. The Layer 1 network will constitute the high speed Backbone comprising of
Core routers with built in redundancies supporting both TCP/IP and MPLS protocols
with link capacities in accordance with the traffic justification. Its function will
primarily be limited to high-speed packet forwarding between the core nodes. All the
A nodes in the NIB-I shall form the Core layer. The five major nodes at Mumbai,
Bangalore, Delhi, Kolkata and Chennai are configured in the full mesh with link
bandwidth of STM-16. The remaining 9 nodes of Pune, Hyderabad, Ahemdabad,
Luchnow, Jullundhar, Jaipur, Indore, Ernakulam and Patna are configured in dual
mesh with link bandwidths of STM-16, (Refer Figure 1(a),1(b) & 1(c)).
Figure (a)
A1 + A2 + A3 POPS
IP MPLS Core Network
Jullunder
Core
A3
Del Lucknow
Jaipur
Core
hi Core
A3
Core A1
A3
Patn
Ahmedabad a
Indore Core
Core A3
A2
Core
A3
Pune Core
Core
A1
A1 Hyderaba Kolkatta
Mumbai Core
A2
d Core
A2
Mangalor STM –16 link

e
Bangalore Core Core
Cisco 12416
Core (P) Router
A1
A1 Cisco 12410
Core
Chennai A2 Router
Core Core
Cisco 12410
Ernakulam
A3 A3 Router
Figure 1(b)
A1 + A2 + A3 + A4 POPS
IP MPLS Core Network
Jullunder Chandigarh
Core
Core
A4
A3
Delhi Lucknow
Jaipur Allahabad Guwahati
Core Core
A3
Core A1 Core
A3 Core
A4
A4
Ahmedabad
Patna
Core
Core A3 Core
A2 Indore A4
Ranchi
Core Nagpu
A3
r Core
A4
Raipur Core
Core
A1
A1 Pun Hyderabad Core
Mumba Core Kolkatt
A4
A2 e
i Core Core a
A2 A4
Core Bhubaneshw STM -1 LINK
Core
A4
Mangalor A4 ar
Vijayawa STM-16 LINK
e
da Core
Cisco 12416
Core
BangalorA1 Core (P) Router
A1
e Core Cisco 12410
Chenn A2
ai
Router
Ernakula Core Core Coimbatore Core Cisco 12410
A3 A4 A3
m Router
Juniper M40e
Core
A4 Router
Project 1
(MPLS based IP Network infrastructure covering 71 cities along with associated
NMS, PMS, Firewall and Caching platforms.)
MPLS based networks provide a cost effective way to enhance customer networking
quality, rather than setting up and managing individual point-to-point circuits between
each office, customers need to provide only one connection from their office router to
a service-provider edge router. The service-provider edge router either forwards the IP
packets in the IP network or in the case of MPLS configured access labels the packets
and routes them through its MPLS core to the edge closest to destination. IP/TCP
connectivity shall be provided through Provider (P) routers and Provider Edge (PE)
routers. The city-wise categorization of nodes under NIB-II Project 1 is given in Table
1.
Table 1: City-wise categorization of nodes under NIB-II Project 1
Node type No of Cities Name of cities Devices
A1 5 Chennai, Mumbai, Core router - Cisco 12416

Bangalore, Delhi and
Kolkata Edge Router Cisco 7613
A2 3 Hyderabad, Pune and Core router - Cisco 12410

Ahemdabad
Edge Router Cisco 7613
A3 6 Lucknow, Jullundhar, Core router - Cisco 12410

Jaipur, Indore, Ernakulam
and Patna Edge Router Cisco 7613
A4 10 Coimbtore, Chandigarh, Core router - Juniper M40

Allahabad, Guwahati,
Ranchi, Bhuvneshwar, Edge Router Cisco 7613
Raipur, Mangalore,
Nagpur, and Vijaivwada
B1 21 -- Edge Router Cisco 7613
B2 26 -- Edge Router Cisco 7613
MPLS based network is a 2-layer centrally managed IP backbone network designed to

provide reliable routes to cover all possible designations within and outside the
country.
Network Architecture of Project 1:
The Layer - 1 Core network (A1, A2, and A3 cities) constitutes the high speed
Backbone (STM-16) as shown in Figure 1. The Layer - 1 nodes consist of high end
fully redundant Core routers, and are interfaced to Edge routers through Gigabit
Ethernet interfaces.
The Layer - 2 Edge network is the second layer of the IP backbone network and
primarily supports MPLS edge functionality. The function of this layer is to enforce
QoS and other administrative policies. This layer provides customer access through
following three mechanisms,
Dialup
Dedicated Access and
Broadband access.
This layer provides connectivity to secure VPNs as well as to Internet Data Centers.
Edge routers in 71 cities are connected to the Core layer either locally through the
Gigabit Ethernet interfaces or remotely through dual homed STM-1 links.
The network is envisaged to provide QoS features associated with MPLS technology
with all traffic shaping and traffic engineering features. It provides peering interfaces
to other domains and serves as an Internet Exchange to ISPs. It supports IP
networking and Border Gateway Protocol (BGP)/ Multi Protocol Label Switching
(MPLS) technology. The network supports data, voice and video applications over
Layer 2 and Layer 3 MPLS VPNs.
The network architecture of NIB-II provides for integration of other networks such as
NIB-I and MPLS VPN of BSNL. It shall provide a common Network Management
System (NMS) and VPN / Bandwidth Provisioning System for the entire integrated IP
network infrastructure. The network infrastructure for NIB-II is intended to provide IP
network access, both on retail as well as wholesale basis, to dialup, DSL and leased
access customers. The network provides a common IP infrastructure that supports all
smaller open networks and sub-networks.
The Primary objectives in setting up the MPLS based IP network
Building a common IP infrastructure that shall support all smaller networks
and sub networks. The platform is intended to be used for convergent services,
integrating data, voice and video and shall be the primary source of Internet
bandwidth for ISPs, Corporate, Institutions, Government bodies and retail
users.
Making the service very simple for customers to use even if they lack
experience in IP routing, along with Service Level Agreement (SLA)
offerings.
Make a service very scalable and flexible to facilitate large-scale deployment.
Capable of meeting a wide range of customer requirements, including security,
quality of service (QoS), and any-to-any connectivity.
Capable of offering fully managed services to customers.
Caching Platform:
The Caching platform makes the contents (HTTP, MMS, FTP etc.) available at the
POP/ Core locations and saves upstream International bandwidth. The Caching
platform enables faster responses from web.
The web caching solution needs to be deployed at 8 cities with International

Gateways. The web caching solution should meet the bandwidth requirements and
shall be scalable to future expansions of bandwidth at these locations.
Services planned to be offered under Project 1:

The following services shall be offered to customers using the MPLS based IP
networks.
Layer 3 MPLS VPN Services
Intranet-Managed & Unmanaged
Extranet Managed & Unmanaged
Internet Access services
Layer 2 MPLS VPN Services
Ethernet over MPLS
Frame relay over MPLS
PPP over MPLS
Cisco HDLC over MPLS (Optional)
VPLS (Virtual Private LAN service)
Layer 2 Any-to-Any Interworking (Except ATM)
1. Encryption Services
2. Multicast Services
3. Firewall Services
4. Network Address Translation (NAT) Services
Project 2
(Access Gateway Platform)
The NIB-II Access Gateway platform shall provide Internet Access at any time of the
day, from any place, using any device such as PC, analog phone, wireless or mobile
phone, or Personal Digital Assistant (PDA). The Access Gateway Platform (AGP) is
built around two distinct platforms, one supporting a unified dialing network
architecture that delivers voice, data and fax services through an open programmable
gateway and the other supporting a unified always-on Internet Access platform on
Ethernet-IP. The open programmable dialing gateway is dimensioned to provide 80%
plain data RAS and 20% Universal RAS ports. The always-on Internet Access
platform is built around the DSL technology using ADSL, SHDSL and VDSL that
delivers voice, data and video services over increasingly larger bandwidths directly on
Ethernet-IP local networks to residential and corporate users, enabling applications
like Broadcast TV, Video on Demand, Pay per View, Content Delivery, Interactive
gaming, Music Services, Video-Conferencing, IP-Multicasting Services, Education on
Demand, Interactive distant learning, Remote Medical Treatment, GIS based
applications, IP PBX, IP Centrex, VoIP, VoDSL, High speed Internet, MPLS VPN
etc.
NIB-II Universal Access Gateway infrastructure is conceived as an open

infrastructure for carrying various services.
The following services are proposed to be provided as part of the scope of work.
Dial VPN/Internet Access service
ADSL, SHDSL & VDSL IP-Ethernet High speed services (0.5 to 50 Mbps
over existing Copper cables)
Wholesale Dial or port retailing service
Internet Call Waiting service
IP based Unified Messaging Service
Teleconferencing Service
Internet Telephony Service
Hosted voice services / IP Centrex.
The implementation of the Project 2 shall be deployed in two phases.

Project 2.1 is for narrow band access
Project 2.2 is for broadband access
Project 2.1: - This project is for the deployment of narrow band services in 71 Cities.
Including validation nodes Kolkata (A1), Mumbai (A3), Agra (B1) and Shimla (B2).
City-wise classification of Nodes under Project 2.1 of NIB-II is given in Tables 2 and
3.
Table 2: City-wise classification of Nodes under Project 2.1 of NIB-II for L2 Bidder
(M/s. UTStarcom Inc.)
Type of Number Name of City

Node of Cities
A1 1 Kolkata
A2 0 --
A3 5 Jallandhar, Mumbai, New Delhi, Lucknow, Patna,
A4 3 Chandigarh, Guwahati,
Ranchi
B1 6 Agra, Noida, Jammu, Amritsar, Ludhiana, Shilong
B2 8 Jamshedpur, Durgapur, Siliguri, Dehradun, Ferozpur, Shimla,

Ghaziabad, Meerut
Table 3: City-wise classification of Nodes under Project 2.1 of NIB-II for L1 Bidder
(M/s. ITI LTD.)
Type of Number Name of City

Node of Cities
A1 2 Chennai, Bangalore
A2 3 Hyderabad, Ahemedabad, Pune
A3 3 Ernakulam, Indore, Jaipur
A4 7 Coimbatore, Maangalore, Vijaywada (Krishana),

Bhuvaneswar, Raipur, Allahabad, Nagpur
B1 15 Madurai, Trivandrum, Mysore, Vizag, Bhopal, Gwalior,

Rajkot, Surat, Vadodara, Faridabad, Gurgoan, Kanpur,
Varanasi, Jodhpur, Nasik
B2 18 Trichy, Pondicherry, Cannanore, Palghat, Trichur, Belgaum,

Hubli, Kakinada, Cuddapah, Dimapur, Jabalpur, Mehsana,
Ambala, Ajmer, Kalyan, Aurangabad, Panjim, Kolhapur
Components of Narrow Band Access Network

Narrow Band Remote Access Server
LAN Switch
eMS Server
Project 2.2:
This Project is for the deployment of broadband services in 198 cities with 69
important cities where Digital Subscriber Line Access Multiplexer (DSLAM) shall be
deployed. The cities are categorized under A1 (3 cites), A2 (3 cites), A3 (6 cites), A4
(10 cites), B1 (21 cites), B2 (26 cites), and others (129 cities). Delhi and Mumbai will
not have any broadband equipment under Project 2.2 of NIB-II.
Services planned through Project 2.2
Primary source of Internet bandwidth for retail users for application such as
Web browsing, e-commerce etc
Multicast video services, video on demand etc through Broadband Remote
Access Server (BRAS).
Allow wholesale BRAS ports to be assigned to smaller ISPs through the
franchises model wherein the later has a separate network of DSLAMs, AAA,
LDAP through a revenue scheme of BSNL.
Dialup VPN (VPDN) user connects to NIB-II through the Narrow band RAS
and is connected to its private network through a secure L2TP tunnel
established between Narrowband RAS and Broadband RAS.
Support for both prepaid and postpaid Broadband services.
Components of Broad Band Access Network

Broad Band Remote Access Server (BBRAS)
Gigabit and Fast Ethernet Aggregation Switches (LAN Switches)
Digital Subscriber Line Access Multiplexers (DSLAMs)
SSSS/SSSC (Subscriber Service Selection System/ Centre)

Servers for AAA, LDAP at Pune
Provisioning and configuration management at NOC
Broadband connectivity Diagram in A cities
Broadband connectivity Diagram in B cities
Project 3:
[Messaging and Storage Service Platform, Provisioning, Billing & Customer care,
Enterprise Management System (EMS) and Security System.]
The Core messaging system shall be the heart of NIB-II that will enable BSNL to add
users across varied value added services. This shall envisage design and up gradation
of the current messaging system to grow from the existing infrastructure in NIB-I
supporting 650,000 users to support the increasing user base. The messaging systems
and associated Storage will be implemented in phases, in accordance with phased
induction of Access equipment.
The system shall be an integrated provisioning, billing, customer care and accounting
platform and shall support billing for the complete range of IP based services
mentioned and meet next-generation requirements as well.
The salient aspects of the projects are summarized as follows:
Setting up proven, robust, scalable Messaging Solution with best in class
security components.
Roll out across the country supported by 5 Messaging & associated storage
systems at Delhi, Mumbai, Bangalore, Chennai and Kolkata.
Designed with High Availability architecture with no single point of failure.
Components of the Solution:

The proposed solution shall consist of the following components with the items of
functionality listed below:
(i) Messaging
a) DNS, AAA
b) MMP
c) LDAP (Consumer, Replicator Hub, Primary and Secondary)
d) SMTP IN & OUT
e) Messaging Servers
f) Address Book Servers, etc.
(ii) Storage
a) SAN Switch & SAN Storage
b) Tape Library
c) Staging Servers, etc.
Storage platform
Various Applications servers placed at the 5 Messaging Storage locations like LDAP,
AAA, EMS, Messaging, UMS & Billing etc. would require Data storage capacities
for storing User‘s mailboxes, Billing data etc. Such huge storage requirements need to
be met with the Fast, Reliable & Scalable storage devices that would be deployed as
―End to End High Performance Switched Architecture Fiber Channel SAN (Storage
Area Networks) providing No Single Point of Failure‖.
Such storage device should be compatible with all the Servers of major companies
such as HP, IBM, SUN, Dell etc. so that choice of Application Servers Platform
remains independent of the storage device.
System Dimensioning:
The user base will be serviced through 5 Messaging and associated Storage systems
that will be set up in the 5 cities. Each of the cities will be connected through the IP
Backbone. Since the proposed user base is envisaged to increase in a phased manner,
the associated messaging system is also proposed to be upgraded in phases
correspondingly.
The system should be designed to support:
On-line services such as Internet, pay-per-view TV and video on demand or a
combination of all or some of the above.
Periodic charges, such as telephone line and cable TV rental.
One-time costs, such as connection fees.
Events, such as telephone calls, data service usage, pay-per-view TV
selections, home shopping purchases, utility metered usage – such as
electricity supply (live site example)
Financial services ASP services.
Telephony services.
Enterprise Backup Systems.
The billing system shall be capable of
Providing electronic versions of bills to customers over the Internet.
Creation/modification of service.
Processing Service requests in real time and non-real time and accounting in
real time.
Producing flexible billing depending upon the use of service.
Security Systems
These include the following.
Load Balancers
Firewall Appliances
Intrusion Detection System
Antivirus system, etc.
Network Operation Center (NOC)

The NOC shall provide facility for centralized Network Management and end-to-end
Provisioning of multiple services, giving a single view of the entire network services
being delivered countywide. The servers for the NOC shall be connected through a
Gigabit Ethernet link from Core router with three zones of firewall within the Centre.
The network shall be centrally managed from Network Operation Centre (NOC)
located at two sites, one of them being master and the other the disaster recovery site.
The main NOC is at Bangalore with Disaster Recovery is at Pune. Interface to the
NMS back-office facility shall be provided along with Firewall security in the Data
Centre. All customer databases shall reside centrally at NOC.
The NMS of NIB-II project 1 is the comprehensive NMS for entire NIB-II including
NIB-I, MPLS VPN, Project 2.1, Project 2.2, which will support entire F (Fault), C
(Configuration), A (Accounting including Access/Inventory), P (Performance) and S
(Security functionality). The conceptual view of eMS, NMS OSS/BSS for NIB-II is
given in figure 4 and the connectivity Architecture of NOC at Bangalore is shown in
figure 5.
Conceptual view of eMS, NMS, EMS OSS/BSS for NIB-II
Fig. 5: Bangalore NOC Connectivity Architecture.
Service Level Agreement (SLA):
It shall be possible to support SLA i.e. the level of service that the customer can
expect together with any penalties to be levied by the service provider for failure to
deliver. It should be possible to provide at least 4 classes of services. The SLA
parameters shall include measurements of service delivery, availability, latency,
throughput and restoration time etc. It should be possible to generate management
reports providing information on customer node configuration and charges, faults and
achievement against the SLAs. It shall be possible to deliver network management
reports via a secure Website.
Implementation of OSS, Messaging, Storage, Billing, EMS & Security Solutions
Messaging
Messaging Solution of NIB-II will provide the SMTP, POP3, IMAP4,
WEBMAIL, WAPMAIL and Notifications services as a Class Of Service to
all the customers of NIB-II and NIB-I
Will support for Country wide roaming for dial up and message store access
through any data center.
The Messaging Server will support Wireless messaging and Directory services
to WAP enabled phones and laptop users
Message store will be content aware to support different types of services to
be created by BSNL ranging from text email to multi-media messaging service
Will provide Family Mailbox where the head of the family can manage
options for Family members. Options will include setting of allowed and block
senders and recipients and control of Anti-SPAM settings.
Messaging solution shall provide flexible control of message aging to define
the conditions under which messages are automatically erased
Web mail interface will support multimedia message types for voice and fax
mail, providing unified messaging interface in future
Message Transfer Agent (MTA) will be designed to handle peak loads without
service degradation or message loss
MTAs will be designed to handle large message queues. There will be
capability available to analyze and manage large message queues generated
due to unreachability of message store (internal) and mail exchangers of other
ISPs (external) or SPAM
Web Hosting
Web space (Data Storage) on servers based on UNIX and Microsoft for
hosting HTML pages with browser
Ftp access for uploading and downloading pages as per the plan. Restriction
on simultaneous ftp sessions
FrontPage etc. access for Web-publishing
Multiple Email Ids per domain with flexible email quota, as per the plan
Web Interface for centralized administration by user and administrators for
services, usage reports, invoice and other reports
It will provide access to customers for analyzing the Web-site performance
through analysis tools
Interface for online registration of domain name
Web Collocation
Necessary Security measures will be implemented both from customer and
BSNL‘s perspective
Billing for this will be done on the basis of usage
One of the service differentiator will be bandwidth on which the server is
collocated.
Security Solution
Anti-Virus solution: It will provide a mechanism to detect unknown virus. The
solution will protect any Gateway and SMTP traffic from virus
Notification: For mails containing repeated complaints regarding abuse from
the same IP address, mail will be sent automatically to the technical contact of
the assignee of that IP address
Network Intrusion detection System: The NIDS will detect unauthorized
internal/external intrusion attempts into the data centers of NIB-II and will
enable to apply appropriate policies on the firewall so as to prevent such
attacks in real time. Suitable alarms will also be sent to the Security Control
Console
Anti Control System: It is provided for Database servers, Messaging Stores,
Web-Hosting Servers and NIDS
Self-protection: Must be able to prevent hackers with root/administrator access
from circumventing or shutting down the security engine
Resource protection: Must allow controlling of access to all system resources
including data files, devices, processes/services and audit files
Rights delegation: Must provide the ability to designate specific users as
administrators, auditors and password managers etc with appropriate rights
Program Controls: Must provide protection against Back Doors and Trojan
Horses
Enterprise Management System
Objective of EMS is to provide a snap-shot graphical view of the health of
NIB-II IT infrastructure as a whole including networking equipment, servers
and services (business and process view)
Reporting system will be able to generate customized reports such as event-
level, performance -level and service-level reports grouped by specific data
fields such as time period, location, customer, series type, device type etc
Security Management will display alarm and events specified by the criteria
such as alarm type, vendor, service, location, source of attack, type of attack
and impacted services
Event Management will capture all the events that are being generated across
the complete IT infrastructure, correlates them and initiate corrective actions
automatically, as defined
System& Application Management will measure the availability and
performance of heterogeneous host systems on a 24x7x365 basis and initiate
preventive and corrective actions automatically
System& Application Management will monitor and manage multiple
attributes (such as status, memory usage, size and resident size, process time,
threads, response time, average throughput and CPU utilization etc) of a
running process and problems and perform restart when processes go down. It
will generate reports on QOS and capacity planning
OSS ARCHITECTURE
WEB SELF CARE PORTAL/IVRS (CTI)
Database DB
Rating
Billing & Wholesale

Remittance settlement
OM work Flow
ticketing/Help desk
DB
management
Provisioning Payment Reporting

Accounting
Subscriber
Trouble
Order
GL &
others
MIDDLEWARE-ENTERPRISE APPLICATION INTEGRATION (EAI)

Performance Management
Enterprise Management
Database
Voucher Management
Fault Management
Service Activation
Network Inventory
Mediation
Database
system
system
NIB-II Network Infrastructure (NE&NEManagers) All NIB-II Servers (Networking and

procured in project 1,2.1,2.2 Security Appliances and their Element
Managers)
Web Portal
Web Portal will be the gateway for customer and CSR based on their
authorizations for accessing various system, services etc
Portal will have an integration, with NMS, EMS and OSS for providing
services to the BSNL‘s customer service representatives (direct, indirect,
helpdesk, supervisor) and account managers
Portal services Ranging from business, process, network, customer specific
maps/views, trouble-ticketing, pre-sales query, post-sales order-booking, order
tracking, trouble –shooting etc
Portal will integrate with components like Service Provisioning, Order
Management, Billing, Customer Care, EMS and Messaging etc. to provide a
unified view of the network and services to the customers and CSRs for all the
front office functions and some back office functions
Order status and history provide both subscribers and the customer service
representatives with sufficient data to fully manage and monitor the service
selection and delivery process
It will be possible to provide a user friendly interface for customers to plan
and schedule their bandwidth for Band width on Demand services
Services provided by portal to the customers

Customer registration services for both pre-paid and post-paid customer
Self-registration for getting information about products and services
Self-registration for availing services such as post-paid dialup service based on
telephone number authentication
Shopping cart for procuring services
Access to services such as messaging, web-hosting, storage and content-
services etc. This will include on demand services like video on demand and
online gaming etc
Booking an order for services. Allow the user to submit, and track service
requests online at any time
View current bill status in real time including billed, unbilled and pre-billed
services, payment-details and other related information
Reporting a problem by opening a fault docket and tracking its solution
View the status of related network and services subscribed
View the status of SLA compliance, SLA resolution and rebates applied
through integration with billing and NMS
ORDER MANAGEMENT
OM will have
Customer Interface Management
Order Entry and Validation
Workflow Management
Customer Interface Management &Order Entry and Validation:

Order will be entered through Web-portal by CSR or Customer directly
CSR will accept the order after completion of signed order form by the
customer. He will scan it and attach it with the online order form
All orders will be checked against the feasibility from the RMS For all
committed orders, check will be made for customers credit worthiness/default
and the billing system will generate a unique ID for the customer
It will be possible to query the status of order, service, billing etc. on the basis
of unique ID
OM will track the order status
OM will inform the billing system of successful provisioning or else it will
roll back all the steps
Record all the transactions between OM and customer
Record the details of the services provisioned for the customer
Purge customer data from RDBMS and LDAP databases based on pre-defined
and configurable policies when the customer surrenders service
Work Flow Management:

Work Flow Management will automate the process that controls and monitors
the execution of an order according to the customer requirements. This
involves the steps of qualification, reservation, configuration and verification

of a service fulfillment instance
Work Flow Management will integrate OM and provisioning Management
systems (PMS) being procured under project-1, project –2.2 and Whole-sale
Dial Application being procured under project-2.1
Subscriber Provisioning Management System (SPMS)

SPMS will cover the provisioning of following services under project 2.1 and project
3 through configurations in files. Subscriber Provisioning will be fully flexible to
support all the requirements of services
Dial up Internet Access with different variants
Messaging with different Variants
Web Hosting
Web Collocation
Domain Hosting
Broadband Internet Access with Content delivery through SSSC.
Mediation
Billing mediation will be responsible for collecting usage and other charging
data from the various network nodes, normalize the data into a consistent
format and distribute it to other applications and billing system for processing
this information
System will collect different parameters from different sources to provide
Cflow and Netflow based collection and mediation for usage based billing of
different services including MPLS-VPN, Web-hosting, Message-Hosting etc
Parameters are
Bandwidth
Volume
Time of day/ day of week/ month (Peak/off peak)
Application (WWW, Email (POP3/IMAP4), Video, E-commerce etc )
Destination
Type of Service (Gold, Silver, Bronze/best efforts) etc
DATABASE
Latest Oracle RDBMS will be used with all applications
RDBMS will work in fail over mode over geographical locations
RDBMS will work in a distributed mode across multiple servers
RDBMS will work in a cluster mode
Provisioning will be made for data replication to or from databases of project
1,2.1 and 2.2
HELP DESK AND TROUBLE TICKETING

Whenever a customer reports a problem, a unique trouble ticket-ID will be
generated by the system. This will be intimated to the customer, so that he can
track the status on the basis of this ID
It will be possible for customers to submit and check the status of reported
problems through web interface
System will automatically track, log and escalate user interactions and
requests
CSRs will be able to view, change the status of the calls, reassign/ transfer the
trouble tickets to others CSRs or technical specialist through the web interface
Will be able to generate various customized Service Level Reports e.g. Open
Call Reports, closed Call Reports, problem area/ Location Specific Reports
Will have the capability for accepting queries through various sources
including Telephone, email or Web interface
System will check for tickets status and escalation and notify the management
or next level of support staff based on predefined Service Level Agreement
(SLA) which will include criteria like Service application, Severity and
customer etc
It will have bulletin board to allow CSRs, Managers and Customers to post
and review messages about critical issues
It will be possible to track the time spent on specific case
It will be possible to generate work orders for field staff or technicians for
fault repair
Trouble ticketing system will interface with SLA and performance
management systems to account for the period of network or service
unavailability
Trouble ticketing system will be able to extract all incidents, resolution
progress reports and all affected services via its interface with the inventory
system
The trouble tickets will be attached to a work-flow where ever there are
multiple steps required for resolution
It will be possible to include information about the equipment, circuit built up
details etc in the trouble ticket automatically after obtaining the same from
inventory
Will integrate with web-portal for report trouble ticket status
System will allow CSR to check the network fault status as part of problem
investigation
Billing
Billing engine will cater to all the billing requirements of BSNL include Retail
Billing (Prepaid and Postpaid), Wholesale and third party billing, Inter connect
and content billing, Dealers and Agents Commissions etc
Billing system will support the preparation of detailed bill, Differential tariff,
Cross product discounting, Sponsored/split billing. Bundled accounting, Hot
billing/On-demand billing, Hierarchy/ Corporate billing, Discounts &
Promotions, Taxes, Notification system, Dealers and Agent commissions,
Content Billing
Billing system will allow customers the option of receiving complete event
details along with their invoice or view them online through the Web portal.
Provision will also be available for the customer to print the event-details from
the Web portal in a printable format
Content Billing
System will provide BSNL subscribers to access services provided by external
content providers and be able to handle the revenue sharing with the content
provider within the single billing platform
System will allow content providers who do not have their own customer care
and billing system to use the billing system of BSNL
Authentication, Authorization and Accounting

Irrespective of mode of access (such as Dial-up Internet access, outsourced
remote access, managed VPNs, Broadband etc), it will manage the
Authentication of all users/customers- both locally and via proxy RADIUS-
and deliver the appropriate level of service to each customer
It will enable defining access schemes by time-of days, days-of-week, call
type (PSTN, ISDN and DSL etc.), calling number and called number etc
It will be capable of authenticating through CLI, DNIS, Voucher number, pin
code etc
Radius server will be able to handle at least 10,000 concurrent sessions per
second
It will integrate with Billing server for providing real time pre-paid balance
management and session management across multiple sessions of multiple
services of a user.
OVERVIEW OF MPLS TECHNOLOGY AND QOS
Basic MPLS VPN Overview and Configuration

MPLS technology is being widely adopted by service providers worldwide to
implement VPNs to connect geographically separated customer sites. Previous
chapters introduce the basic concepts of MPLS and its operation, as well as
configuring MPLS for data forwarding. This chapter builds on that foundation and
shows how to use MPLS to provide VPN services to customers. This chapter also
presents the terminology and operation of various devices in an MPLS network used
to provide VPN services to customers.
The following topics will be covered in this chapter:

Overlay and peer-to-peer VPN models
Overview of MPLS VPN components and architecture
VRFs, route distinguishers, and route targets
MP-BGP operation and interaction
Control plane and data plane operation in MPLS VPN
Configuration of basic MPLS VPN
Quality of Service
VPN Categories
VPNs were originally introduced to enable service providers to use common physical
infrastructure to implement emulated point-to-point links between customer sites. A
customer network implemented with any VPN technology would contain distinct
regions under the customer's control called the customer sites connected to each other
via the service provider (SP) network. In traditional router-based networks, different
sites belonging to the same customer were connected to each other using dedicated
point-to-point links. The cost of implementation depended on the number of customer
sites to be connected with these dedicated links. A full mesh of connected sites would
consequently imply an exponential increase in the cost associated.
Frame Relay and ATM were the first technologies widely adopted to implement
VPNs. These networks consisted of various devices, belonging to either the customer
or the service provider, that were components of the VPN solution. Generically, the
VPN realm would consist of the following regions:
Customer network— Consisted of the routers at the various customer sites. The
routers connecting individual customers' sites to the service provider network were
called customer edge (CE) routers.
Provider network— Used by the service provider to offer dedicated point-to-point

links over infrastructure owned by the service provider. Service provider devices to
which the CE routers were directly attached were called provider edge (PE) routers.
In addition, the service provider network might consist of devices used for forwarding
data in the SP backbone called provider (P) routers.
Depending on the service provider's participation in customer routing, the VPN

implementations can be classified broadly into one of the following:
Overlay model
Peer-to-peer model
When Frame Relay and ATM provided customers with emulated private networks,
the provider did not participate in customer routing. The service provider was only
responsible for providing the customer with transport of customer data using virtual
point-to-point links. As a result, the service provider would only provide customers
with virtual circuit connectivity at Layer 2; this implementation was referred to as the
Overlay model. If the virtual circuit was permanent or available for use by the
customer at all times, it was called a permanent virtual circuit (PVC). If the circuit
was established by the provider on-demand, it was called a switched virtual circuit
(SVC). The primary drawback of an Overlay model was the full mesh of virtual
circuits between all customer sites for optimal connectivity (except in the case of hub
and spoke or partial hub and spoke deployments). If the number of customer sites was
N, N(N-1)/2 was the total number of circuits that would be necessary for optimal
routing.
Overlay VPNs were initially implemented by the SP by providing either Layer 1

(physical layer) connectivity or a Layer 2 transport circuit between customer sites. In
the Layer 1 implementation, the SP would provide physical layer connectivity
between customer sites, and the customer was responsible for all other layers. In the
Layer 2 implementation (depicted in Figure ), the SP was responsible for
transportation of Layer 2 frames (or cells) between customer sites, which was
traditionally implemented using either Frame Relay or ATM switches as PE devices.
Therefore, the service provider was not aware of customer routing or routes. Later,
overlay VPNs were also implemented using VPN services over IP (Layer 3) with
tunneling protocols like L2TP, GRE, and IPSec to interconnect customer sites. In all
cases, the SP network was transparent to the customer, and the routing protocols were
run directly between customer routers.
Figure 3-1. Overlay and Peer-to-Peer Models

[View full size image]
The peer-to-peer model was developed to overcome the drawbacks of the Overlay
model and provide customers with optimal data transport via the SP backbone. Hence,
the service provider would actively participate in customer routing. In the peer-to-peer
model, routing information is exchanged between the customer routers and the service
provider routers, and customer data is transported across the service provider's core,
optimally. Customer routing information is carried between routers in the provider
network (P and PE routers) and customer network (CE routers). The peer-to-peer
model, consequently, does not require the creation of virtual circuits. As illustrated in
Figure , the CE routers exchange routes with the connected PE routers in the SP
domain. Customer routing information is propagated across the SP backbone between
PE and P routers and identifies the optimal path from one customer site to another.
Separation of customer-specific routing information is achieved by implementing

packet filters at the routers connecting to the customer network. Additionally, IP
addressing for the customer is handled by the service provider. This process is also
referred to as the shared PE peer-to-peer implementation. Figure 3-2 depicts the
various implementations of the peer-to-peer model.
Figure. Peer-to-Peer Model Implementations
Controlled route distribution was another method of implementing the peer-to-peer

model; routers in the core of the service provider's network contained network layer
reachability information for all customers' networks. The PE routers (connecting
customer network to provider network) in the provider network would contain only
information pertaining to their connected customers. A dedicated PE router was
required for each customer's site connecting to the provider network, and controlled
route distribution would occur between P and PE routers in the SP backbone network.
Only pertinent customer routes would be propagated to PE routers that were
connected to sites belonging to a specific customer. BGP with communities was
usually used in the SP backbone because it offered the most versatile route-filtering
tools. This implementation is often referred to as the dedicated PE peer-to-peer
model. This implementation, however, did not prove to be a viable operating business
model due to the higher equipment costs that were incurred by the provider to
maintain dedicated edge routers for customer sites connecting into the provider
backbone. A need arose for deploying efficient VPN architectures that could
implement a scalable peer-to-peer model.
MPLS VPN Architecture and Terminology

In the MPLS VPN architecture, the edge routers carry customer routing information,
providing optimal routing for traffic belonging to the customer for inter-site traffic.
The MPLS-based VPN model also accommodates customers using overlapping
address spaces, unlike the traditional peer-to-peer model in which optimal routing of
customer traffic required the provider to assign IP addresses to each of its customers
(or the customer to implement NAT) to avoid overlapping address spaces. MPLS
VPN is an implementation of the peer-to-peer model; the MPLS VPN backbone and
customer sites exchange Layer 3 customer routing information, and data is forwarded
between customer sites using the MPLS-enabled SP IP backbone.
The MPLS VPN domain, like the traditional VPN, consists of the customer network
and the provider network. The MPLS VPN model is very similar to the dedicated PE
router model in a peer-to-peer VPN implementation. However, instead of deploying a
dedicated PE router per customer, customer traffic is isolated on the same PE router
that provides connectivity into the service provider's network for multiple customers.
The components of an MPLS VPN shown in Figure are highlighted next.
Figure 3-3. MPLS VPN Network Architecture

The main components of MPLS VPN architecture are

Customer network, which is usually a customer-controlled domain consisting
of devices or routers spanning multiple sites belonging to the customer. In
Figure , the customer network for Customer A consists of the routers CE1-A
and CE2-A along with devices in the Customer A sites 1 and 2.
CE routers, which are routers in the customer network that interface with the
service provider network. In Figure , the CE routers for Customer A are CE1-
A and CE2-A, and the CE routers for Customer B are CE1-B and CE2-B.
Provider network, which is the provider-controlled domain consisting of
provider edge and provider core routers that connect sites belonging to the
customer on a shared infrastructure. The provider network controls the traffic
routing between sites belonging to a customer along with customer traffic
isolation. In Figure , the provider network consists of the routers PE1, PE2,
P1, P2, P3, and P4.
PE routers, which are routers in the provider network that interface or
connect to the customer edge routers in the customer network. PE1 and PE2
are the provider edge routers in the MPLS VPN domain for customers A and
B in Figure .
P routers, which are routers in the core of the provider network that interface
with either other provider core routers or provider edge routers. Routers P1,
P2, P3, and P4 are the provider routers in Figure .
MPLS VPN Routing Model
An MPLS VPN implementation is very similar to a dedicated router peer-to-peer
model implementation. From a CE router's perspective, only IPv4 updates, as well as
data, are forwarded to the PE router. The CE router does not need any specific
configuration to enable it to be a part of a MPLS VPN domain. The only requirement
on the CE router is a routing protocol (or a static/default route) that enables the router
to exchange IPv4 routing information with the connected PE router.
In the MPLS VPN implementation, the PE router performs multiple functions. The PE
router must first be capable of isolating customer traffic if more than one customer is
connected to the PE router. Each customer, therefore, is assigned an independent
routing table similar to a dedicated PE router in the initial peer-to-peer discussion.
Routing across the SP backbone is performed using a routing process in the global
routing table. P routers provide label switching between provider edge routers and are
unaware of VPN routes. CE routers in the customer network are not aware of the P
routers and, thus, the internal topology of the SP network is transparent to the
customer. Figure depicts the PE router's functionality.
Figure 3-4. MPLS VPN Architecture

The P routers are only responsible for label switching of packets. They do not carry
VPN routes and do not participate in MPLS VPN routing. The PE routers exchange
IPv4 routes with connected CE routers using individual routing protocol contexts. To
enable scaling the network to large number of customer VPNs, multiprotocol BGP is
configured between PE routers to carry customer routes.
VRF: Virtual Routing and Forwarding Table

Customer isolation is achieved on the PE router by the use of virtual routing tables or
instances, also called virtual routing and forwarding tables/instances (VRFs). In
essence, it is similar to maintaining multiple dedicated routers for customers
connecting into the provider network. The function of a VRF is similar to a global
routing table, except that it contains all routes pertaining to a specific VPN versus the
global routing table. The VRF also contains a VRF-specific CEF forwarding table
analogous to the global CEF table and defines the connectivity requirements and
protocols for each customer site on a single PE router. The VRF defines routing
protocol contexts that are part of a specific VPN as well as the interfaces on the local
PE router that are part of a specific VPN and, hence, use the VRF. The interface that
is part of the VRF must support CEF switching. The number of interfaces that can be
bound to a VRF is only limited by the number of interfaces on the router, and a single
interface (logical or physical) can be associated with only one VRF.
The VRF contains an IP routing table analogous to the global IP routing table, a CEF
table, list of interfaces that are part of the VRF, and a set of rules defining routing
protocol exchange with attached CE routers (routing protocol contexts). In addition,
the VRF also contains VPN identifiers as well as VPN membership information (RD
and RT are covered in the next section). Figure shows the function of a VRF on a PE
router to implement customer routing isolation.
Figure 3-5. VRF Implementation on PE Router
As shown in Figure , Cisco IOS supports a variety of routing protocols as well as

individual routing processes (OSPF, EIGRP, etc.) per router. However, for some
routing protocols, such as RIP and BGP, IOS supports only a single instance of the
routing protocol. Therefore, to implement per VRF routing using these protocols that
are completely isolated from other VRFs, which might use the same PE-CE routing
protocols, the concept of routing context was developed.
Routing contexts were designed to support isolated copies of the same VPN PE-CE
routing protocols. These routing contexts can be implemented as either separated
processes, as in the case of OSPF, or as multiple instances of the same routing
protocol (in BGP, RIP, etc.). If multiple instances of the same routing protocol are in
use, each instance has its own set of parameters.
Cisco IOS currently supports either RIPv2 (multiple contexts), EIGRP (multiple
contexts), OSPFv2 (multiple processes), and BGPv4 (multiple contexts) as routing
protocols that can be used per VRF to exchange customer routing information
between CE and PE.
Note that the VRF interfaces can be either logical or physical, but each interface can
be assigned to only one VRF.
Route Distinguisher, Route Targets, MP-BGP, and Address Families
In the MPLS VPN routing model, the PE router provides isolation between customers
using VRFs. However, this information needs to be carried between PE routers to
enable data transfer between customer sites via the MPLS VPN backbone. The PE
router must be capable of implementing processes that enable overlapping address
spaces in connected customer networks. The PE router must also learn these routes
from attached customer networks and propagate this information using the shared
provider backbone. This is done by the association of a route distinguisher (RD) per
virtual routing table on a PE router.
A RD is a 64-bit unique identifier that is prepended to the 32-bit customer prefix or

route learned from a CE router, which makes it a unique 96-bit address that can be
transported between the PE routers in the MPLS domain. Thus, a unique RD is
configured per VRF on the PE router. The resulting address, which is 96-bits total
(32-bit customer prefix + 64-bit unique identifier or RD), is called a VPN version 4
(VPNv4) address.
VPNv4 addresses are exchanged between PE routers in the provider network in

addition to IPv4 (32-bit) addresses. The format of an RD is shown in Figure . As
shown in Figure , RD can be of two formats. If the provider does not have a BGP AS
number, the IP address format can be used, and, if the provider does have an AS
number, the AS number format can be used. Figure also shows the same IP prefix,
172.16.10.0/24, received from two different customers, is made unique by prepending
different RD values, 1:100:1 and 1:101, prior to propagating the addresses as VPNv4
addresses on the PE router.
Figure . RD Operation in MPLS VPN

The protocol used for exchanging these VPNv4 routes between PE routers is
multiprotocol BGP (MP-BGP). BGP capable of carrying VPNv4 (96-bit) prefixes in
addition to other address families is called MP-BGP. The IGP requirement to
implement iBGP (internal BGP) still holds in the case of an MPLS VPN
implementation. Therefore, the PE router must run an IGP that provides NLRI
information for iBGP if both PE routers are in the same AS. Cisco currently supports
both OSPFv2 and ISIS in the MPLS provider network as the IGP. MP-BGP is also
responsible for assignment of a VPN label. Packet forwarding in an MPLS VPN
mandates that the router specified as the next hop in the incoming BGP update is the
same router that assigns the VPN label. Scalability was a primary reason for the
choice of BGP as the protocol to carry customer routing information. In addition,
BGP enables the use of VPNv4 address in an MPLS VPN router environment that
enables overlapping address ranges with multiple customers.
An MP-BGP session between PE routers in a single BGP AS is called an MP-iBGP

session and follows rules as in the implementation of iBGP with regards to BGP
attributes. If the VPN extends beyond a single AS, VPNv4 routes will be exchanged
between AS at the AS boundaries using an MP-eBGP session.
Route targets (RTs) are additional identifiers used in the MPLS VPN domain in the
deployment of MPLS VPN that identify the VPN membership of the routes learned
from that particular site. RTs are implemented by the use of extended BGP
communities in which the higher order 16 bits of the BGP extended community (64
total bits) are encoded with a value corresponding to the VPN membership of the
specific site. When a VPN route learned from a CE router is injected into VPNv4
BGP, a list of VPN route target extended community attributes is associated with it.
The export route target is used in identification of VPN membership and is associated
to each VRF. This export route target is appended to a customer prefix when it is
converted to a VPNv4 prefix by the PE router and propagated in MP-BGP updates.
The import route target is associated with each VRF and identifies the VPNv4 routes
to be imported into the VRF for the specific customer. The format of a RT is the same
as an RD value. The interaction of RT and RD values in the MPLS VPN domain as
the update is converted to an MP-BGP update is shown in Figure .
Figure . RT and RD Operation in an MPLS VPN

When implementing complex VPN topologies, such as extranet VPN, Internet access
VPNs, network management VPN, and so on, using MPLS VPN technology, the RT
plays a pivotal role. A single prefix can be associated to more than one export route
target when propagated across the MPLS VPN network. The RT can, as a result, be
associated to sites that might be a member of more than one VPN.
The following processes occur during route propagation in an MPLS VPN, as shown
in Figure :
The prefix 172.16.10.0/24 is received from CE1-A, which is part of VRF

CustomerA on PE1-AS1.
PE1 associated an RD value of 1:100 and an export RT value of 1:100 as

configured in the VRF definition on the PE1-AS1 router.
Routes learned from connected CE routers CE1-A are redistributed into the MP-
BGP process on PE1-AS1 where the prefix 172.16.10.0/24 is prepended with the
RD value of 1:100 and appended with the route target extended community value
(export RT) of 1:100 prior to sending the VPNv4 prefix as part of the MP-iBGP
update between PE routers.
The VPN label (3 bytes) is assigned for each prefix learned from the connected
CE router's IGP process within a VRF by the PE router's MP-BGP process. MP-
BGP running in the service provider MPLS domain thus carries the VPNv4 prefix
(IPv4 prefix + prepended RD) in addition to the BGP route target extended
community. Note that although the RT is a mandatory configuration in an MPLS
VPN for all VRFs configured on a router, the RT values can be used to
implement complex VPN topologies in which a single site can be a part of more
than one VPN. In addition, RT values can also be used to perform selective route
importing into a VRF when VPNv4 routes are learned in MP-iBGP updates. The
VPN label is only understood by the egress PE (data plane) that is directly
connected to the CE router advertising the prefix. Note that the next hops on PE
routers must not be advertised in the BGP process but must be learned from the
IGP for MPLS VPN implementation. The VPN label has been depicted by the
entries V1 and V2 in Figure .
The MP-BGP update is received by the PE router PE2, and the route is stored in
the appropriate VRF table for Customer A based on the VPN label.
The received MP-BGP routes are redistributed into the VRF PE-CE routing
processes, and the route is propagated to CE2-A.
In addition, other BGP extended community attributes such as site of origin (SoO) can
also be applied to the MP-iBGP update prior to propagation. The SoO attribute is used
to identify the specific site from which the PE learns the route and is used in the
identification and prevention of routing loops. The SoO extended community is a
BGP extended community attribute used to identify routes that have originated from a
site so that the re-advertisement of that prefix back to the source site can be prevented,
thus preventing routing loops. The SoO extended community uniquely identifies the
site from which a PE router has learned a route. SoO enables filtering of traffic based
on the site from which it was originated. SoO filtering manages MPLS VPN traffic
and prevents routing loops from occurring in complex and mixed network topologies
in which the customer sites might possess connectivity across the MPLS VPN
backbone as well as possess backdoor links between sites.
The implementation of a MPLS VPN in which all VPN sites belonging to a customer
can speak to all other sites in the same customer domain is called a simple VPN
implementation or intranet VPN. As mentioned earlier, RTs can be used to implement
complex VPN topologies in which certain sites that are part of one customer's domain
are also accessible by other customers' VPN sites. This implementation is called an
extranet VPN. In addition, variants of extranet VPN, such as network management
VPN as well as central services VPN and Internet access VPN, can also be deployed.
It is important to understand the concept of address families and their place in the
operation of MP-BGP to enable the transport of VPNv4 routes with extended
community attributes. Prior to RFC 2283, "Multiprotocol Extensions for BGP-4,"
BGP version 4 was capable of carrying routing information only pertaining to IPv4.
RFC 2283 defines extensions to BGP-4 that enable BGP-4 to carry information for
multiple network layer protocols. RFC 2283 states that to enable BGP-4 to support
routing for multiple network layer protocols, the additions to BGP-4 must account for
the ability of a particular network layer protocol to be associated with a next hop as
well as the NLRI (network layer reachability information). The two new attributes
that were added to BGP were Multiprotocol Reachable NLRI (MP_REACH_NLRI),
and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). MP_REACH_NLRI

carries the set of reachable destinations together with the next-hop information to be
used for forwarding to these destinations. MP_UNREACH_NLRI carries the set of
unreachable destinations. Both of these attributes are optional and nontransitive.
Therefore, a BGP speaker that does not support these multiprotocol capabilities will
just ignore the information carried in these attributes and will not pass it to other BGP
speakers.
An address family is a defined network layer protocol. An address family identifier

(AFI) carries an identity of the network layer protocol associated with the network
address in the multiprotocol attributes in BGP. (Address family identifiers for network
layer protocols are defined in RFC 1700, "Assigned Numbers.")
The PE router, in essence, is an Edge LSR and performs all the functions of an Edge
LSR. The PE router requires LDP for label assignment and distribution as well as
forward labeled packets. In addition to the functions of an Edge LSR, the PE
implements a routing protocol (or static routes) with connected CE routers per virtual
routing table and requires MP-BGP to propagate prefixes learned from CE routers as
VPNv4 prefixes in MP-iBGP updates to other PE routers along with the VPN label.
The P router's requirements are to run an IGP (either OSPF or ISIS) as well as have
MPLS enabled to forward labeled packets (data plane) between PE routers. The IGP
is used to provide, as well as propagate, NLRI to connected P and PE routers to
implement an MP-iBGP session between PE routers (control plane). As explained in
Chapters 1 and 2, LDP is run on the P router for label assignment and distribution.
MPLS VPN Control Plane Operation
The control plane in MPLS VPN implementation contains all the Layer 3 routing
information and the processes within to exchange reachability information for a
specific Layer 3 IP prefix in addition to label assignment and distribution using LDP
(as explained in Chapter 1). The data plane performs the functions relating to the
forwarding of both labeled as well as IP packets to the next hop toward a destination
network. Figure outlines the interactions of protocols in the control plane in an MPLS
VPN implementation.
Figure . Control Plane Interactions in MPLS VPN

The CE routers are connected to the PE routers, and an IGP, BGP, or static route is
required on the CE routers in conjunction with attached PE routers to gather and
advertise NLRI information. In the MPLS VPN backbone consisting of P and PE
routers, an IGP (usually either OSPF or ISIS) in addition to LDP is used between PE
and P routers. LDP is used for allocation as well as distribution of labels in the MPLS
domain. The IGP is used for NLRI information exchange as well as to map this NLRI
into MP-BGP. MP-BGP sessions are maintained between PE routers in an MPLS
VPN domain and exchange MP-BGP updates consisting of unique VPNv4 addresses
in addition to BGP extended community attributes associated with specific VPNv4
addresses.
Packets from CE to PE are always propagated as IPv4 packets. Operation of the

MPLS VPN control plane is shown in Figure . Figure shows a simple VPN
implementation with two sites belonging to Customer A connected to one another
across a service provider's MPLS backbone.
Figure 3-9. Control Plane Operation

The following are the steps for control plane operation in MPLS VPN. The steps are
outlined for prefixes advertised by the CEA-1 router and are shown in Figure :
Step 1. IPv4 update for network 172.16.10.0 is received by the egress PE router
(data plane).
Step 2. PE1-AS1 accepts and transforms the IPv4 route, 172.16.10.0/24, to a

VPNv4 route by assigning an RD 1:100, SoO, and RT 1:100 based on the
VRF configuration on PE1-AS1. It then allocates a VPNv4 label V1 to the
172.16.10.0/24 update and rewrites the next-hop attribute to the PE1-AS1
loopback0 IP address 10.10.10.101. PE1-AS1 loopback 10.10.10.101 is
reachable via IGP (OSPF) and LDP. Figure shows the control plane
operation and the label propagation for prefix 10.10.10.101/32 from PE1-
AS1 to PE2-AS1 inside the provider network. This propagation takes place
as soon as the MPLS VPN provider network is established and is always in
place prior to any VPNv4 prefix being propagated across the MPLS VPN
provider network. The following steps are performed in the label
propagation process for prefix 10.10.10.101/32. This operation is shown
for clarity:
2a: In Figure , Edge LSR PE2-AS1 requests a label for the
10.10.10.101/32 prefix using the LDP label mapping request from
its downstream neighbor, LSR P2-AS1. P2-AS1 requests a label
for the 10.10.10.101/32 prefix using the LDP label mapping
request from its downstream neighbor LSR P1-AS1. P1-AS1, in
turn, requests a label for the 10.10.10.101/32 prefix using the LDP
label mapping request from its downstream neighbor, Edge LSR
PE1-AS1. Edge LSR PE1-AS1 allocates a label of implicit-null
(penultimate hop popping) to 10.10.10.101/32, modifies the entry
in the LFIB corresponding to 10.10.10.101/32, and sends it to P1-
AS1 using an LDP reply.
2b: P1-AS1 uses the implicit-null label received from PE1-AS1 as
its outbound label value, allocates a label (L1) to prefix
10.10.10.101/32, and modifies the LFIB entry for 10.10.10.101/32.
P1-AS1 then sends this label value to P2-AS1 via an LDP reply.
2c: P2-AS1 uses the label (L1) received from P1-AS1 as its
outbound label value, allocates a label (L2) to prefix
10.10.10.101/32, and modifies the LFIB entry for 10.10.10.101/32.
P2-AS1 then sends this label value to PE2-AS1 via an LDP reply.
Step 3. PE1-AS1 has the VRF configured to accept routes with RT 1:100 and
therefore translates the VPNv4 update to IPv4 and inserts the route in VRF
for Customer A. It then propagates this route to the CE2-A.
MPLS VPN Data Plane Operation

The prior section discussed update propagation along with the label assignment and
distribution, both for MPLS packet forwarding as well as the VPN label. MPLS VPN
data plane operation involves the usage of the label stack in which the top label in the
label stack is the label assigned for the egress PE routers (data plane) next-hop
address, and the second label in the label stack is the VPN label as assigned by the
egress PE router connected to the CE router advertising the prefix. When using the
label stack in an MPLS VPN implementation, the ingress/upstream PE router thus
labels the incoming IP packet for a remote VPN destination with two labels.
The second label in the stack points toward an outgoing interface whenever the CE
router is the next hop of the VPN route. The second label in the stack points to the
VRF table for aggregate VPN routes, VPN routes pointing to null interface, and
routes for directly connected VPN interfaces. This will be explained in more detail in
the section "MPLS VPN Basic Configuration." P routers perform label switching on
the LDP-assigned label toward the egress PE router. The egress PE router identifies
the VPN label assigned with a VRF (that it has previously assigned) and either
forwards the IP packet toward the CE router or performs another IP lookup in the
VRF table to identify the next hop toward the destination.
Figure depicts the various steps in the data plane forwarding of customer data from
one customer site CE2-A to CE1-A connected using the SP's infrastructure.
Figure . MPLS VPN Data Plane Operation

When data is forwarded to a specific prefix belonging to a VPN across the MPLS-
enabled core, the top label in the label stack is the only one swapped as the packet
traverses the backbone. The VPN label is kept intact and is removed only in the
egress/downstream PE router. The resulting prefix is associated with an outgoing
interface belonging to a specific VRF on the router depending on the value in the
VPN label.
Here are the steps in the data plane forwarding shown in Figure :
Step 1. CE2-A originates a data packet with the source address of 172.16.20.1 and
destination of 172.16.10.1.
Step 2. PE2-AS1 receives the data packet and appends the VPN label V1 and
LDP label L2 and forwards the packet to P2-AS1.
Step 3. P2-AS1 receives the data packet destined to 172.16.10.1 and swaps LDP
label L2 with L1.
Step 4. P1-AS1 receives the data packet destined to 172.16.10.1 and pops the top
label because it receives an implicit-null label mapping for
10.10.10.101/32 from PE1-AS1. The resulting labeled packet (with VPN
Label V1) is forwarded to PE1-AS1.
Step 5. PE1-AS1 pops the VPN label and forwards the data packet to CE1-A
where the 172.16.10.0 network is located.
The key to understanding the operation of MPLS VPN is that the VPN label is never
touched until it reaches the egress PE router toward the FEC. All the forwarding of
traffic is done as explained in Chapter 1; the next-hop label mapping to the
downstream PE router's loopback is used to forward the packet (in this case, labeled
IP because of the presence of a VPN label) through the MPLS domain.
MPLS VPN Basic Configuration
This section outlines the generic configurations required on the routers in the service
provider domain to implement MPLS VPN. The configurations of the PE and P
routers will be covered in this section. The subsequent sections in this chapter delve
into each of the configuration blocks on the PE and P routers alone. The
configurations required to implement PE-CE routing sessions are discussed in
Chapters 4 through 6, depending on the PE-CE protocol in use.
All configurations outlined in the following sections are performed in the network
shown in Figure . For simplicity, only connected networks that are part of the VRF
will be redistributed into the MP-BGP processes.
Figure . Network Topology: MPLS VPN PE and P Configuration

The topology in Figure 3-11 attempts to implement a simple intranet VPN between
two sites belonging to Customer A, site 1 and site 2. The customer network consists
of the CE routers CE1-A and CE2-A. In addition, two loopbacks (loopback 1) on
PE1-AS1 and PE2-AS1 will be configured as part of the VRF CustomerA and be
redistributed into the MP-BGP routing contexts.
Configuration of CE Routers
The configuration of route exchange between PE and CE routers involves the
implementation of a routing protocol (or static/default routes) on the CE routers. No
specific configuration other than the regular routing protocol configuration is required
on the CE routers. On the PE router, VRF routing contexts (or address family
contexts) are required for route exchange between the PE and CE. These routes are
then mutually redistributed with the MP-BGP process per VRF. Configurations for
the above based on protocol choice between PE and CE will be covered in Chapters 4
through 6.
Configuring MPLS Forwarding and VRF Definition on PE Routers
Configuring MPLS forwarding is the first step to provision the service provider's
MPLS VPN backbone. This step ensures the service provider's readiness to provide
MPLS-related services to prospective customers. At a minimum, the steps to
configure MPLS forwarding on PE routers are
Step 1. Enable CEF.
Step 2. Configure IGP routing protocol on the PE router.
Step 3. Configure MPLS or label forwarding on the PE interfaces connected to P.
These steps have already been discussed in Chapters 1 and 2 and thus have not been
shown.
In this section, we configure VRFs on the PE routers. Figure 3-12 shows the
configuration steps on the PE routers to configure VRF definition.
Figure 3-12. VRF Definition on PE Routers: Configuration Steps

Step 1. Configure VRF on PE router—Configure the VRF CustomerA on PE1

and PE2-AS1 router. This results in the creation of a VRF routing table
and a Cisco Express Forwarding (CEF) table for CustomerA. Example 3-
1 shows CustomerA VRF being configured on PE1-AS1 router. Note the
VRF name is case sensitive.
Example 3-1. VRF Definition
PE1-AS1(config)#ip vrf CustomerA
Note that creation or deletion of a VRF results in removal of the IP address
from the interface. Example 3-2 illustrates the message that occurs on VRF
deletion.
Example 3-2. VRF Deletion
PE1-AS1(config-vrf)#no ip vrf CustomerA
% IP addresses from all interfaces in VRF CustomerA have been removed
Step 2. Configure the RD—The RD creates routing and forwarding tables. The
RD is added to the beginning of the customer's IPv4 prefixes to convert
them into globally unique VPNv4 prefixes. Example 3-3 shows the
configuration for defining the RD under the VRF.
Example 3-3. Configuring VRF Parameters: RD
PE1-AS1(config-vrf)#rd 1:100
The RD can be used in either of these formats:

- 16-bit AS number: Your 32-bit number (for example, 1:100)
- 32-bit IP address: Your 16-bit number (for example,
10.10.10.101:1)
RD for an existing VRF can be changed only after deletion of that VRF.
Example 3-4 illustrates the concept.
Example 3-4. Redefining VRF RD Value
% Do "no ip vrf " before redefining the VRF
RD has to be unique for that particular VRF. No two VRFs on the same
router can have similar RD. Trying to set the same RD on the VRF on the
same router results in the message shown in Example 3-5.
Example 3-5. RD Uniqueness
% Cannot set RD, check if it's unique
Step 3. Configure the import and export policy—Configure the import and
export policy for the MP-BGP extended communities. The policy is used
for filtering routes for that particular RT. Example 3-6 provides the
relevant configuration for defining import and export policy.
Example 3-6. Configuring VRF Parameters: RT
PE1-AS1(config-vrf)#route-target both 1:100
The both keyword in the previous command results in the configuration of

import and export policy, and the configuration output is shown in
Example 3-7.
Example 3-7. RT Configuration Options
PE1-AS1#sh run
Building configuration...
ip vrf CustomerA
rd 1:100
route-target export 1:100
route-target import 1:100
Step 4. Associate VRF with the interface—Associate virtual routing/forwarding

instance (VRF) with an interface or subinterface in this CustomerA.
Associating the VRF to an interface results in removal of the IP address
from that interface. This is only if VRF was associated to an interface that
had the IP address already configured. This means that the IP address will
have to be reconfigured after the VRF is associated with that interface.
Example 3-8 shows the configuration for associating the VRF to an
interface. Example 3-9 shows the removal of the IP address when no ip
vrf forwarding vrfname is configured on the interface.
Example 3-8. Associating VRF with Interface
PE1-AS1(config)#interface serial4/0
PE1-AS1(config-if)#ip add 172.16.1.1 255.255.255.252
PE1-AS1(config-if)# ip vrf forwarding CustomerA
% Interface Serial4/0 IP address 172.16.1.1 removed due to enabling VRF

CustomerA
PE1-AS1(config-if)#ip add 172.16.1.1 255.255.255.252

Example 3-9. VRF Association to Interface IP Address
PE1-AS1(config-if)#no ip vrf forwarding CustomerA
% Interface Serial4/0 IP address 172.16.1.1 removed due to disabling VRF

CustomerA
Final VRF Configuration on PE1-AS1 Router
Example 3-10 shows the VRF configuration on the PE1-AS1 router.
Example 3-10. VRF Configuration of PE1-AS1
ip vrf CustomerA
rd 1:100
interface Serial1/0
description PE-CE link to CE1-A
ip vrf forwarding CustomerA
ip address 172.16.1.1 255.255.255.0
Interface Loopback1
ip vrf forwarding CustomerA
ip address 172.16.100.1 255.255.255.255

Verification of VRF Configuration on PE Routers
The show ip vrf command is used to verify if the correct VRF exists on the interface.
Example 3-11 indicates that the correct VRF CustomerA is configured on the
Serial1/0 interface on the PE1 router.
Example 3-11. show ip vrf on PE1-AS1
PE1-AS1#show ip vrf
Name Default RD Interfaces
CustomerA 1:100 Se1/0
Lo1
The show ip vrf interfaces command provides the listing of interfaces that are
activated for a particular VRF. Example 3-12 shows that Serial1/0 is active for VRF
VRF-Static.
Example 3-12. show ip vrf interfaces on PE1-AS1
PE1-AS1#show ip vrf interfaces
Interface IP-Address VRF Protocol
Serial1/0 172.16.1.1 CustomerA up
Lo1 172.16.100.1 CustomerA up
Configuration of BGP PE-PE Routing on PE Routers

Configuring BGP PE-PE routing between the PE routers is the next step in an MPLS
VPN deployment. The purpose of this step is to ensure that VPNv4 routes can be
transported across the service provider backbone using MP-iBGP. The P router is
transparent to this entire process and, therefore, does not carry any customer routes.
Figure 3-13 illustrates the steps for configuring BGP PE-PE routing sessions between
the PE routers.
Figure 3-13. BGP PE-PE Routing Configuration Steps

Step 1. Configure BGP routing on PE routers—Enable BGP routing and identify the AS on
the PE1-AS1 and PE2-AS1 routers. Example 3-13 highlights the configuration.
Example 3-13. Configuring BGP Routing on PE Routers
PE1-AS1(config)#router bgp 1
________________________________________________________________
PE2-AS1(config)#router bgp 1
Step 2. Configure the MP-iBGP neighbors—Configure the remote MP-iBGP neighbor and use
the loopback interface as the source of BGP messages and updates. Note that you have to
use the update-source command only when the neighbor is peering to your loopback
address. This is irrespective of whether it is an iBGP or eBGP neighbor. Example 3-14
shows the configuration for the PE1-AS1 and PE2-AS1 router.
Example 3-14. Configuring MP-iBGP Neighbors
PE1-AS1(config-router)#neighbor 10.10.10.102 remote-as 1
PE1-AS1(config-router)#neighbor 10.10.10.102 update-source loopback0
____________________________________________________________
PE2-AS1(config-router)#neighbor 10.10.10.101 remote-as 1
PE2-AS1(config-router)#neighbor 10.10.10.101 update-source loopback0
Step 3. Configure the VPNv4 address family—Configure the address family for VPNv4 under
the BGP configuration process. This step allows you to enter the VPNv4 address family
to activate the VPNv4 neighbors. Activate the iBGP neighbor, which is essential for
transporting VPNv4 prefixes across the service provider backbone. Using next-hop-self is
optional and is primarily used when the service provider has an eBGP PE-CE routing
with the customers, because internal BGP (iBGP) sessions preserve the next-hop attribute
learned from eBGP peers, which is why it is important to have an internal route to the
next hop. Otherwise, the BGP route is unreachable. To make sure you can reach the
eBGP next hop, include the network that the next hop belongs to in the IGP or use the
next-hop-self neighbor command to force the router to advertise itself, rather than the
external peer, as the next hop.
In addition, configure the propagation of the extended communities with BGP routes so
as to enable RT propagation, which identifies the VPNs that the routes have to be
imported into. The configuration of the VPNv4 address family for PE1-AS1 and PE2-
AS1 is shown in Example 3-15. Note that on some versions of IOS, adding the neighbor
for VPNv4 route exchange using the neighbor ip-address activate command also
automatically adds the neighbor ip-address send-community extended command. If the
neighbor needs to be configured for both standard and extended community exchange,
you will explicitly have to configure the neighbor ip-address send-community both
command under the VPNv4 address family.
Example 3-15. Configuring BGP VPNv4 Address Family
PE1-AS1(config-router)#address-family vpnv4
PE1-AS1(config-router-af)# neighbor 10.10.10.102 activate
PE1-AS1(config-router-af)# neighbor 10.10.10.102 send-community extended
________________________________________________________________________
PE2-AS1(config-router)#address-family vpnv4
PE2-AS1(config-router-af)# neighbor 10.10.10.101 activate
PE2-AS1(config-router-af)# neighbor 10.10.10.101 send-community extended
Step 4. Configure the IPv4 address family—Configure the peer VRF IPv4 address family
under the BGP configuration process. This step allows you to enter the IPv4 networks
that will be converted to VPNv4 routes in MP-BGP updates. In Chapters 4, 5, and 6, the
individual PE-CE routing protocol interaction configuration involving redistribution of
PE-CE routing protocol contexts or instances will be configured in the IPv4 address
family per VRF under the BGP process. For simplicity, redistribution of all connected
networks is configured into the MP-BGP process. Example 3-16 shows the configuration
on PE1-AS1 and PE2-AS1 routers.
Example 3-16. Configuring BGP per VRF IPv4 Address Family (Routing Context)
PE1-AS1(config-router)#address-family ipv4 vrf CustomerA
PE1-AS1(config-router-af)# redistribute connected
PE1-AS1(config-router-af)# exit-address-family
_________________________________________________________
PE2-AS1(config-router)#address-family ipv4 vrf CustomerA
PE2-AS1(config-router-af)# redistribute connected
PE2-AS1(config-router-af)# exit-address-family
BGP PE-PE Routing Final Configuration on PE1-AS1 and PE2-AS1 Router
Example 3-17 shows the final BGP PE-PE routing configuration on the PE1-AS1 and
PE2-AS1 router.
Example 3-17. BGP PE-PE Configurations of PE1-AS1 and PE2-AS1 Routers
!PE1-AS1 Router:
router bgp 1
no synchronization
neighbor 10.10.10.102 remote-as 1
no auto-summary
address-family vpnv4
neighbor 10.10.10.102 activate
neighbor 10.10.10.102 send-community extended
exit-address-family
address-family ipv4 vrf CustomerA
redistribute connected
no auto-summary
no synchronization
exit-address-family
_____________________________________________________________________
!PE2-AS1 Router:
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 10.10.10.101 update-source Loopback0
no auto-summary
exit-address-family
address-family ipv4 vrf CustomerA
no auto-summary
no synchronization
exit-address-family
Verification and Monitoring of BGP PE-PE Routing on PE Routers

After configuring BGP PE-PE routing between the PE routers, you can verify that the
MP-iBGP neighbors are operational by issuing any of the following commands:
show ip bgp vpnv4 * summary
show IP bgp vpnv4 all
show ip bgp summary
show ip bgp neighbor ip-address
Example 3-18 shows that the VPNv4 neighbor relationship is formed.
Example 3-18. VPN Neighbor Relationship Verification
PE1#show ip bgp vpnv4 all summary
BGP router identifier 10.10.10.101, local AS number 1
BGP table version is 7, main routing table version 7
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd
10.10.10.102 4 1 202 200 7 0 0 00:00:39 0

_____________________________________________________________________
PE2#show ip bgp vpnv4 all summary
BGP router identifier 10.10.10.102, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd
10.10.10.101 4 1 11 11 1 0 0 00:07:16 0
Configuration of P Router
No special configurations need to be performed on the P routers P1-AS1 and P1-AS2
for MPLS VPN support. Because the P routers only participate in MPLS labeled
packet forwarding, the only requirements are those of an LSR in an MPLS network,
namely, IGP for NLRI exchange and LDP for label assignment and distribution. As
always, CEF needs to be enabled on all interfaces configured for MPLS forwarding.
Configuration of the P1-AS1 router is shown in Example 3-19.
Example 3-19. P1-AS1 Configuration
mpls ldp router-id loopback0
interface Serial0/0
ip address 10.10.10.2 255.255.255.252
mpls ip
interface Serial1/0
ip address 10.10.10.5 255.255.255.252
mpls ip
Interface loopback0
ip address 10.10.10.200 255.255.255.255
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
Label Verification and Control and Data Plane Operation

After configuring devices in the network as per the previous steps, the verification of
label allocation and propagation can be performed on the PE and P routers using the
commands described in Figure 3-14.
Figure 3-14. Label Allocation Verification and Control/Data Plane Operation

The control plane and data plane operation for network 172.16.100.1 as part of VRF
CustomerA is depicted in Figure 3-14. Note that the outgoing label mapped to prefix
172.16.100.1 on PE1-AS1 is aggregate and not untagged. For all networks that are
directly connected to the PE router (like loopbacks or interface IP networks) that are
part of a VRF, the outgoing label mapped in the LFIB is the aggregate label. If,
however, the incoming VPN packet is to be forwarded to a next-hop address (like that
of a connected CE router), the outgoing label mapping is untagged. Thus, aggregate
and untagged labels that were explained in Chapter 1 are encountered in MPLS VPN
implementations.
Outbound Route Filters
When implementing large-scale MPLS VPN networks, sites belonging to different
customers might not be connected to all the PE routers in the MPLS VPN domain.
The PE router in the MPLS VPN network can, therefore, conserve resources by
importing only VPNv4 routes that are to be imported into VRF instances configured
on the PE router. To enable such filtering of VPNv4 route information, the PE router
must be capable of filtering MP-iBGP updates so that information pertaining to these
superfluous routes is not received. The procedure for filtering routes based on the
VRF configuration on the PE routers is called automatic route filtering. Automatic
route filtering is enabled by default on all Cisco routers that are configured as PE
routers. The exception is in the case of a PE router also performing the functions of a
route-reflector. The route-reflector must be capable of receiving routes that might not
be associated to any locally configured VRFs and reflect them to clients. Therefore,
on a PE router functioning as a route-reflector, the automatic route filtering process is
disabled to enable propagation of VPNv4 routes between route-reflector clients.
Automatic route filtering enables the PE router to reduce resource consumption by

rejecting information not pertaining to the VRFs configured on the router. Automatic
route filtering, however, does not avoid the superfluous routes from being received by
the PE routers.
Outbound route filtering (ORF) enables a PE router to advertise to its peers, outbound
route filters that peering PE routers can use while sending information to a PE router.
The ORF feature on PE routers works in conjunction with the route-refresh BGP
capability. The route-refresh BGP capability enables the PE router to request routing
updates from its MP-iBGP peers after undergoing a configuration change. In the event
of an addition, deletion, or modification of VRFs or their associated configurations on
a PE router, the route-refresh capability enables the PE router to update its routing
tables. The route-refresh feature is enabled by default on all Cisco routers configured
for PE functionality. The ORF entries are exchanged during session establishment
between two PE routers through the use of the BGP OPEN message as part of the
route-refresh message. The format of a route-refresh message is shown in Figure 3-15.
Figure 3-15. Route-Refresh Message and Working of ORF
In large networks, the PE router might receive updates and then filter a list of
unwanted routes based on its local inbound route filter. The ORF feature enables a PE
router to push its inbound route filter to a remote peer and apply a filter from a remote
peer as its outbound route filter. ORFs can be either prefix-based or extended-
community based in VPNv4 route filtering. The prefix-based ORF allows a PE to
export and/or receive the inbound route filter information with a peer based on the
prefix associated with the route. In the extended-community based ORF, the PE can
export/receive inbound route filter based on the extended community attributes
associated with a VPNv4 route. Because the RT values are coded as part of the
extended-community attributes in VPNv4 routes, the ORF feature can be used to
advertise a subset of RTs for which the PE router can receive VPNv4 routing
information. This process essentially reduces the burden of superfluous routing
information being propagated in the MP-iBGP backbone as the peering PE router
does not send VPNv4 routes pertaining to the subset of RTs configured as part of the
ORF.
Figure 3-16 shows the operation and sample configuration for implementation of a
prefix-based ORF. PE1-AS1 is configured with an inbound prefix-list that is
propagated using the ORF capability configuration to PE2-AS1. PE2-AS1 will not
accept this filter if the command neighbor 10.10.10.1 capability orf prefix-list
receive is configured under the VPNv4 address-family. The verification of the ORF
application on PE2-AS1 is also illustrated in Figure 3-16 with the output of the show
ip bgp neighbor command. The output of this command depicts the ORF has been
received with two entries. Note that because this ORF applies only to VPNv4 routes
learned from PE2-AS1, this will not affect regular IPv4 route exchanges between
PE1-AS1 and PE2-AS1.
Figure 3-16. ORF Operation and Configuration

Command Reference
Command Description
Router(config)#router bgp as-number Configures the BGP routing

process.
Router(config-router)#neighbor {ip-address | Specifies a remote BGP neighbor

peer-group-name} remote-as as-number to establish a BGP session.
Router(config-router)#neighbor {ip-address | Allows the BGP sessions to use any

ipv6-address | peer-group-name} update-source operational interface for TCP
interface-type interface-number connections. The loopback
interface is used frequently.
Router(config-router)#address-family vpnv4 Places the router in address family

[unicast] configuration mode, from which
you can configure routing sessions
that use VPN Version 4 address
prefixes.
Router(config-router-af)#neighbor {ip-address | Enables the exchange of

peer-group-name | ipv6-address} activate information with a BGP
neighboring router.
Router(config)#neighbor {ip-address | peer- Configures the router as the next

group-name} next-hop-self hop for a BGP-speaking neighbor
or peer group.
Router#show ip bgp neighbors [neighbor- Displays information about the

address] [received-routes | routes | advertised- TCP and BGP connections to
routes | {paths regexp} | dampened-routes | neighbors.
received prefix-filter]
Router#show ip bgp summary Displays the status of all BGP

connections.
Router(config)#ip vrf vrf-name Configures a VPN

routing/forwarding instance (VRF)
routing table.
Router(config-vrf)#rd route-distinguisher Creates routing and forwarding

tables for a VPN VRF.
Router(config-vrf)#route-target {import | Creates a route target extended

export | both} route-target-ext-community community for a VPN VRF. route-
target-ext-community adds the
Command Description
route target extended community

attributes to the VRF's list of
import, export, or both (import and
export) route target extended
communities.
Router(config-if)#ip vrf forwarding vrf-name Associates a VRF with an interface

or subinterface.
Router#show ip vrf [brief | detail | interfaces | Displays the set of defined VPN
id] [vrf-name] [output-modifiers] VRFs and associated interfaces.
Router(config-router-af)#neighbor ip-address Enables the ORF capability to be

capability orf prefix-list [receive | send | both] sent as part of BGP open message
or and route-refresh messages to
Router(config-router)# neighbor ip-address configured neighbors.
capability orf prefix-list [receive | send | both]
Router(config-router-af)# neighbor ip-address Associates a prefix list to a

prefix-list prefix-list-name [in | out] configured BGP neighbor.
or
Router(config-router)# neighbor ip-address
prefix-list prefix-list-name [in | out]
Router(config)# ip prefix-list list-name [seq Creates a prefix list with

seq-value] {deny network/length | permit configured entries in which len <
network/length}[ge ge-value] [le le-value] ge-value < le-value <= 32.
Router#show ip bgp vpnv4 {all | rd route- Displays VPN address information

distinguisher | vrf vrf-name} [rib-failure] [ip- from the BGP table.
prefix/length [longer-prefixes] [output-
modifiers]] [network-address [mask] [longer-
prefixes] [output-modifiers]] [cidr-only]
[community] [community-list] [dampened-
paths] [filter-list] [flap-statistics]
[inconsistent-as] [neighbors] [paths [line]]
[peer-group] [quote-regexp] [regexp]
[summary] [labels]
Quality of Service Deficiencies in IP Networks

In order to have guaranteed QoS in a network, all of the data packets sent in each
direction, during each session, must follow the same path (in network jargon,
beconnection oriented) and some means for reserving resources along that path
mustexist. IP is not connection oriented, and IP routers don't generally have
sophisticated mechanisms for committing resources at each hop; that's why ensuring
a specified QoS is so difficult over an IP network. Two mechanisms have attempting
to solve this problem unsuccessfully.
The Differentiated Services (DiffServ) protocol was defined to enable different levels
of services to be provided across IP networks, Their protocol uses a space in the IP
header to indicate different traffic types and priorities. Routers in the network are able
to look at this information and prioritize traffic accordingly while DiffServ provides
no guarantees. For example, congestion and queuing can increase latency, reduce
available bandwidth, and thereby reduce voice quality. By itself, DiffServ is not
adequate for VoIP.
The Resource Reservation Protocol (RSVP) is a signaling protocol used in IP

networks to reserve resources for certain specified data flows. Although RSVP can
reserve theresources, it cannot guarantee that traffic will flow along the path on which
the resource was reserved: as nodes and links are added or removed in an IP network,
the path along which data flows can change. RSVP attempts to recover and create an
updated path reflecting the new technology, but there can be no guarantee that the
QoS will be maintained, and it is possible that RSVP will fail to create an updated
path.
Working towards QoS
Transport services are concerned with the transfer of user and control-plane data
across networks. The services are provided by wireline or wireless access networks. A
major problem at the transport layer is how to ensure reliable, predictable QoS for
timesensitive applications across an IP infrastructure originally designed for best-
effort data transport. Today the problem is generally solved, by running IP-over-
ATM, and using the built-in ATM QoS mechanisms. The limitations of this approach
are obvious for carriers that do not intend to implement ATM.
The alternative has been to over-provision the IP network so that in the absence of
congestion, traffic can be forwarded through the network with minimum latency, jitter
and packet loss. Throwing bandwidth at the problem is certainly not a sustainable
solution fora large-scale network. To deliver IP QoS, embryonic stage intelligence
service layers schemes such as MPLS are in development. With MPLS, service
providers can define specific packet delivery paths for traffic through the IP networks,
rather than allow intermediate routers to make the packet-forwarding decisions.
Conventional packet routing sends traffic along the shortest available path through the
network. By moving traffic flows onto less congested paths, MPLS can better balance
a networks traffic load and overall network response time and throughput.
Multi-Protocol Label Switching (MPLS) solves the QoS issue by setting up explicit
paths through the network. MPLS is a technique that facilitates high-performance
transport of IP traffic across Wide Area Networks. In particular, it marries
connectionless IP technology to connection-oriented technologies like ATM. MPLS
assigns labels to IP flows placing them in IP frames. The frames can then be
transported across packet or cell-based networks and switched on the labels rather
then being routed using IP address lookup. Using MPLS techniques it is possible to
set up explicit routes for data flows that are constrained by path, resource availability
and requested Quality of Service.
The path is defined by the sequence of IP addresses of the nodes to be traversed. All
of the data that constitutes a flow is given the same label (fixed format data field
inserted at the front of each packet) on entry into the MLPS network. At each node
the packet is routed based on the label value and incoming interface and sent on its
way with a new label value on the outgoing interface. The paths are referred to as
label-switched paths (LSP). Since an LSP is a well-defined path through an IP
network, it provides a means for ensuring a specified quality of service where QoS is
provided by the underlying infrastructure. The multi-protocol nature of MPLS means
it can be used to support IP networks over any Layer 2 infrastructure – Asynchronous
Transfer mode (ATM), packetover-SONET, Gigabit Ethernet, frame relay, etc.
The Constraint-based Routing Label Distribution protocol (CR-LDP) has been co

developed from the ground up by ITEF specifically for MPLS networks. Companies
are just beginning to provide MPLS devices based on the new technology. Labels-
RSVP and CR-LDP both have strong advocates. However, the market is initially
focused on RSVP, although it is likely that CR-LDP implementations will become
available.
MPLS-VPN Lab
1. Click Start, Run
2. Type ‗‘cmd‘‘ in the command window and press ok to get C:\> (Command
Prompt)
3. Enter the telnet command as shown in the following table against your Router.
Eg. to access PE-3 Router:
C:\> telnet 210.212.90.11 2007
PE-3>
4. Enter the enable command and the enable password as shown in the following
table
PE-3>enable
Password:xxxxx
PE-3#
Old New Telnet command from C:\> Telnet Enable

hostname of hostname of prompt password password
the Router the Router
P-1 Kolkata-PE telnet 210.212.90.11 2001 alttc alttc
P-2 Pune-PE telnet 210.212.90.11 2002 alttc alttc
P-3 Hyderabad telnet 210.212.90.11 2003 alttc alttc
P-4 Bangalore telnet 210.212.90.11 2004 alttc alttc
PE-1 Guwahati telnet 210.212.90.11 2005 alttc alttc
PE-2 Ahmedabad telnet 210.212.90.11 2006 alttc alttc
PE-3 Chennai-PE telnet 210.212.90.11 2007 alttc alttc
PE-4 Trivandrum telnet 210.212.90.11 2008 alttc alttc
Core-1 Delhi-P telnet 210.212.90.11 2009 alttc alttc
Core-2 Mumbai-P telnet 210.212.90.11 2010 alttc alttc
MPLS-VPN Lab Module: 1

(Preliminery Configuration for MPLS)
Kolkata-PE (Old hostname: P-1) Preliminary configuration
User Access Verification
Password:xxxxx
P-1>en
Password:xxxxx
P-1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
P-1(config)#hostname Kolkata-PE
Kolkata-PE(config)#interface GigabitEthernet2/2
Kolkata-PE(config-if)# ip address 172.16.16.46 255.255.255.252
Kolkata-PE(config-if)#no shut
Kolkata-PE(config-if)#end
Kolkata-PE#write memory
[OK]
Kolkata-PE#
PUNE-PE (Old hostname: P-2) Preliminary configuration
Password:xxxxx
P-1>en
Password:xxxxx
P-1# conf t
P-1(config)#hostname PUNE-PE
PUNE-PE(config)#interface GigabitEthernet2/2
PUNE-PE(config-if)# ip address 172.16.16.50 255.255.255.252
PUNE-PE(config-if)#no shut
PUNE-PE(config-if)#end
PUNE-PE#write memory
[OK]
PUNE-PE#
YDERABAD (Old hostname: P-3) Preliminary configuration
Password:xxxxx
P-2>en
Password:xxxxx
P-2# conf t
P-2(config)#hostname HYDERABAD
HYDERABAD(config)#interface GigabitEthernet2/2
HYDERABAD(config-if)# no shutdown
HYDERABAD(config-if)#ip add 172.16.16.33 255.255.255.252
HYDERABAD(config-if)#end
HYDERABAD#write memory
[OK]
HYDERABAD#
BANGALORE (Old hostname: P-4) Preliminary configuration

Password:xxxxx
P-2>en
Password:xxxxx
P-2# conf t
P-2(config)#hostname BANGALORE
BANGALORE(config)#interface GigabitEthernet2/2
BANGALORE(config-if)#no shutdown
BANGALORE(config-if)#ip add 172.16.16.37 255.255.255.252
BANGALORE(config-if)#end
BANGALORE#write memory
[OK]
BANGALORE#
GUWAHATI (Old hostname: PE-1) Preliminary configuration
Password:xxxxx
PE-1>en
Password:xxxxx
PE-1# conf t
PE-1(config)#hostname GUWAHATI
GUWAHATI(config)#interface GigabitEthernet3/1
GUWAHATI(config-if)#no shutdown
GUWAHATI(config-if)#ip add 172.16.16.54 255.255.255.252
GUWAHATI(config-if)#interface GigabitEthernet2/2
GUWAHATI(config-if)# description ** P-3-PE-1 GigE link **
GUWAHATI(config-if)# ip address 172.16.16.34 255.255.255.252
GUWAHATI(config-if)# no shutdown
GUWAHATI(config-if)# end
GUWAHATI#write memory
[OK]
GUWAHATI#
AHMEDABAD (Old hostname: PE-2) Preliminary configuration
Password:xxxxx
PE-1>en
Password:xxxxx
PE-1# conf t
PE-1(config)#hostname AHMEDABAD
AHMEDABAD(config)#interface GigabitEthernet3/1
AHMEDABAD(config-if)#no shutdown
AHMEDABAD(config-if)#ip add 172.16.16.58 255.255.255.252
AHMEDABAD(config-if)#interface GigabitEthernet2/2
AHMEDABAD(config-if)# description ** P-3-PE-1 GigE link **
AHMEDABAD(config-if)# ip address 172.16.16.38 255.255.255.252
AHMEDABAD(config-if)# no shutdown
AHMEDABAD(config-if)# end
AHMEDABAD#write memory
[OK]
AHMEDABAD#
CHENNAI (Old hostname: PE-3) Preliminary configuration
Password:xxxxx
PE-2>en
Password:xxxxx
PE-2# conf t
PE-2(config)#hostname CHENNAI
CHENNAI(config)#controller e1 4/0/0
CHENNAI(config- controller)#channel group 0 time-slot 1-31
CHENNAI(config- controller)#exit
CHENNAI(config)#interface serial 4/0/0:0
CHENNAI(config-if)# no shutdown
CHENNAI(config-if)# ip add 172.16.16.65 255.255.255.252
CHENNAI#write memory
[OK]
CHENNAI#
TRIVANDRUM (Old hostname: PE-4) Preliminary configuration
Password:xxxxx
PE-2>en
Password:xxxxx
PE-2# conf t
PE-2(config)#hostname TRIVANDRUM
TRIVANDRUM(config)#controller e1 4/0/0
TRIVANDRUM(config- controller)#channel group 0 time-slot 1-31
TRIVANDRUM(config- controller)#exit
TRIVANDRUM(config)#interface serial 4/0/0:0
TRIVANDRUM(config-if)# no shutdown
TRIVANDRUM(config-if)# ip add 172.16.16.66 255.255.255.252
TRIVANDRUM#write memory
[OK]
TRIVANDRUM#
DELHI-P Preliminary configuration
Password:xxxxx
P-3>en
Password:xxxxx
P-3# conf t
P-3(config)# hostname DELHI-P
DELHI-P(config)# interface GigabitEthernet 7/0/0
DELHI-P(config-if)# ip address 172.16.16.41 255.255.255.252
DELHI-P(config-if)# no shutdown
DELHI-P(config-if)# interface GigabitEthernet 7/0/1
DELHI-P(config-if)# interface loopback 0
DELHI-P(config-if)#end
DELHI-P#wr
[OK]
DELHI-P#
MUMBAI-P Preliminary configuration
Password:xxxxx
P-3>en
Password:xxxxx
P-3# conf t
P-3(config)# hostname MUMBAI-P
MUMBAI-P(config)# interface GigabitEthernet 7/0/0
MUMBAI-P(config-if)# ip address 172.16.16.42 255.255.255.252
MUMBAI-P(config-if)# no shutdown
MUMBAI-P(config-if)# interface GigabitEthernet 7/0/1
MUMBAI-P(config-if)# interface loopback 0
MUMBAI-P(config-if)#end
MUMBAI-P#wr
[OK]
MUMBAI-P#

(Basic MPLS Lab using LDP)
DELHI-P
Password:xxxxx
DELHI-P >en
Password:xxxxx
DELHI-P # conf t
Configuring OSPF 9829:-
DELHI-P (config)#router ospf 9829
DELHI-P (config-router)#auto-cost reference-bandwidth 1000
DELHI-P (config-router)#network 172.16.16.40 0.0.0.3 area 0
DELHI-P (config-router)#passive-interface loopback 0
DELHI-P (config-router)#exit
DELHI-P (config)#
Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-
DELHI-P(config)# ip cef distributed
DELHI-P(config)#mpls ip
DELHI-P(config)#mpls label protocol ldp
DELHI-P(config)# interface GigabitEthernet 7/0/0
DELHI-P(config-if)# mpls ip
DELHI-P(config-if)# mpls label protocol ldp
DELHI-P(config-if)#end
DELHI-P#wr
[OK]
DELHI-P#
MUMBAI-P
Password:xxxxx
MUMBAI-P >en
Password:xxxxx
MUMBAI-P # conf t
MUMBAI-P (config)#router ospf 9829
MUMBAI-P (config-router)#auto-cost reference-bandwidth 1000
MUMBAI-P (config-router)#network 172.16.16.40 0.0.0.3 area 0
MUMBAI-P (config-router)#passive-interface loopback 0
MUMBAI-P (config-router)#exit
MUMBAI-P (config)#
MUMBAI-P(config)# ip cef distributed
MUMBAI-P(config)#mpls ip
MUMBAI-P(config)#mpls label protocol ldp
MUMBAI-P(config)# interface GigabitEthernet 7/0/0
MUMBAI-P(config-if)# mpls ip
MUMBAI-P(config-if)# mpls label protocol ldp
MUMBAI-P(config-if)#end
MUMBAI-P#wr
[OK]
MUMBAI-P#
KOLKATA-PE
Password:xxxxx
KOLKATA-PE >en
Password:xxxxx
KOLKATA-PE # conf t

KOLKATA-PE (config)#router ospf 9829
KOLKATA-PE (config-router)#auto-cost reference-bandwidth 1000
KOLKATA-PE (config-router)#network 172.16.16.0 0.0.0.3 area 0
KOLKATA-PE (config-router)#passive-interface loopback 0
KOLKATA-PE (config-router)#exit
KOLKATA-PE (config)#
KOLKATA-PE(config)# ip cef distributed
KOLKATA-PE(config)#mpls ip
KOLKATA-PE(config)#mpls label protocol ldp
KOLKATA-PE(config)# interface pos 3/2
KOLKATA-PE(config-if)# mpls ip
KOLKATA-PE(config-if)# mpls label protocol ldp
KOLKATA-PE(config-if)# interface pos 3/1
KOLKATA-PE(config-if)# interface GigabitEthernet 2/1
KOLKATA-PE(config-if)# interface GigabitEthernet 2/2
KOLKATA-PE(config-if)#end
KOLKATA-PE#wr
[OK]
KOLKATA-PE#
PUNE-PE
Password:xxxxx
PUNE-PE >en
Password:xxxxx
PUNE-PE # conf t

PUNE-PE (config)#router ospf 9829
PUNE-PE (config-router)#auto-cost reference-bandwidth 1000
PUNE-PE (config-router)#network 172.16.16.0 0.0.0.3 area 0
PUNE-PE (config-router)#passive-interface loopback 0
PUNE-PE (config-router)#exit
PUNE-PE (config)#
PUNE-PE(config)# ip cef distributed
PUNE-PE(config)#mpls ip
PUNE-PE(config)#mpls label protocol ldp
PUNE-PE(config)# interface pos 3/2
PUNE-PE(config-if)# mpls ip
PUNE-PE(config-if)# mpls label protocol ldp
PUNE-PE(config-if)# interface pos 3/1
PUNE-PE(config-if)# interface GigabitEthernet 2/1
PUNE-PE(config-if)# interface GigabitEthernet 2/2
PUNE-PE#wr
[OK]
PUNE-PE#
GUWAHATI
Password:xxxxx
GUWAHATI >en
Password:xxxxx
GUWAHATI # conf t

GUWAHATI (config)#router ospf 9829
GUWAHATI (config-router)#auto-cost reference-bandwidth 1000
GUWAHATI (config-router)#network 172.16.16.52 0.0.0.3 area 0
GUWAHATI (config-router)#passive-interface loopback 0
GUWAHATI (config-router)#exit
GUWAHATI (config)#
GUWAHATI(config)# ip cef distributed
GUWAHATI(config)#mpls ip
GUWAHATI(config)#mpls label protocol ldp
GUWAHATI(config)# interface gigabitEthernet 3/1
GUWAHATI(config-if)# mpls ip
GUWAHATI(config-if)# mpls label protocol ldp
GUWAHATI(config-if)# interface GigabitEthernet 2/1
GUWAHATI(config-if)# interface GigabitEthernet 2/2
GUWAHATI(config-if)#end
GUWAHATI#wr
[OK]
GUWAHATI#
AHMEDABAD
Password:xxxxx
AHMEDABAD >en
Password:xxxxx
AHMEDABAD # conf t

AHMEDABAD (config)#router ospf 9829
AHMEDABAD (config-router)#auto-cost reference-bandwidth 1000
AHMEDABAD (config-router)#network 172.16.16.56 0.0.0.3 area 0
AHMEDABAD (config-router)#passive-interface loopback 0
AHMEDABAD (config-router)#exit
AHMEDABAD (config)#
AHMEDABAD(config)# ip cef distributed
AHMEDABAD(config)#mpls ip
AHMEDABAD(config)#mpls label protocol ldp
AHMEDABAD(config)# interface gigabitEthernet 3/1
AHMEDABAD(config-if)# mpls ip
AHMEDABAD(config-if)# mpls label protocol ldp
AHMEDABAD(config-if)# interface GigabitEthernet 2/1
AHMEDABAD(config-if)# interface GigabitEthernet 2/2
AHMEDABAD(config-if)#end
AHMEDABAD#wr
[OK]
AHMEDABAD#
HYDERABAD
Password:xxxxx
HYDERABAD >en
Password:xxxxx
HYDERABAD # conf t
HYDERABAD (config)#router ospf 9829
HYDERABAD (config-router)#auto-cost reference-bandwidth 1000
HYDERABAD (config-router)#network 172.16.16.8 0.0.0.3 area 0
HYDERABAD (config-router)#passive-interface loopback 0
HYDERABAD (config-router)#exit
HYDERABAD (config)#

HYDERABAD(config)# ip cef distributed
HYDERABAD(config)#mpls ip
HYDERABAD(config)#mpls label protocol ldp
HYDERABAD(config)# interface pos 3/2
HYDERABAD(config-if)# mpls ip
HYDERABAD(config-if)# mpls label protocol ldp
HYDERABAD(config-if)# interface pos 3/1
HYDERABAD(config-if)# interface GigabitEthernet 2/1
HYDERABAD(config-if)# interface GigabitEthernet 2/2
HYDERABAD(config-if)#end
HYDERABAD#wr
[OK]
HYDERABAD#
BANGALORE
Password:xxxxx
BANGALORE >en
Password:xxxxx
BANGALORE # conf t

BANGALORE (config)#router ospf 9829
BANGALORE (config-router)#auto-cost reference-bandwidth 1000
BANGALORE (config-router)#network 172.16.16.4 0.0.0.3 area 0
BANGALORE (config-router)#passive-interface loopback 0
BANGALORE (config-router)#exit
BANGALORE (config)#
BANGALORE(config)# ip cef distributed
BANGALORE(config)#mpls ip
BANGALORE(config)#mpls label protocol ldp
BANGALORE(config)# interface pos 3/2
BANGALORE(config-if)# mpls ip
BANGALORE(config-if)# mpls label protocol ldp
BANGALORE(config-if)# interface pos 3/1
BANGALORE(config-if)# interface GigabitEthernet 2/1
BANGALORE(config-if)# interface GigabitEthernet 2/2
BANGALORE(config-if)#end
BANGALORE#wr
[OK]
BANGALORE#
CHENNAI-PE
Password:xxxxx
CHENNAI-PE >en
Password:xxxxx
CHENNAI-PE # conf t

CHENNAI-PE (config)#router ospf 9829
CHENNAI-PE (config-router)#auto-cost reference-bandwidth 1000
CHENNAI-PE (config-router)#network 172.16.16.24 0.0.0.3 area 0
CHENNAI-PE (config-router)#passive-interface loopback 0
CHENNAI-PE (config-router)#exit
CHENNAI-PE (config)#
CHENNAI-PE(config)# ip cef distributed
CHENNAI-PE(config)#mpls ip
CHENNAI-PE(config)#mpls label protocol ldp
CHENNAI-PE(config)# interface GigabitEthernet 2/1
CHENNAI-PE(config-if)# mpls ip
CHENNAI-PE(config-if)# mpls label protocol ldp
CHENNAI-PE(config-if)# interface serial 4/0/0:0
CHENNAI-PE(config-if)# mpls ip
CHENNAI-PE(config-if)# mpls label protocol ldp
CHENNAI-PE(config-if)#end
CHENNAI-PE#wr
[OK]
CHENNAI-PE#
TRIVANDRUM
Password:xxxxx
TRIVANDRUM >en
Password:xxxxx
TRIVANDRUM # conf t

TRIVANDRUM (config)#router ospf 9829
TRIVANDRUM (config-router)#auto-cost reference-bandwidth 1000
TRIVANDRUM (config-router)#network 172.16.16.28 0.0.0.3 area 0
TRIVANDRUM (config-router)#passive-interface loopback 0
TRIVANDRUM (config-router)#exit
TRIVANDRUM (config)#
TRIVANDRUM(config)# ip cef distributed
TRIVANDRUM(config)#mpls ip
TRIVANDRUM(config)#mpls label protocol ldp
TRIVANDRUM(config)# interface GigabitEthernet 2/1
TRIVANDRUM(config-if)# mpls ip
TRIVANDRUM(config-if)# mpls label protocol ldp
TRIVANDRUM(config-if)# interface serial 4/0/0:0
TRIVANDRUM(config-if)# mpls ip
TRIVANDRUM(config-if)# mpls label protocol ldp
TRIVANDRUM(config-if)#end
TRIVANDRUM#wr
[OK]
TRIVANDRUM#
MPLS-VPN LAB MODULE: 3

MPLS Traffic-engineering Tunnels using RSVP
DELHI-P
Global Configuration Commands on all MPLS-TE Routers:
DELHI-P#conf t
DELHI-P(config)#mpls traffic-eng tunnels

Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
DELHI-P(config)#int gigabitethernet 7/0/0
DELHI-P(config-if)# mpls traffic-eng tunnels
DELHI-P(config-if)#ip rsvp bandwidth 100000
DELHI-P(config)#int gigabitethernet 7/0/1
DELHI-P(config-if)# mpls traffic-eng tunnels
DELHI-P(config-if)#ip rsvp bandwidth 100000

OSPF Configuration for traffic-eng:
DELHI-P(config)#router ospf 9829
DELHI-P(config-router)#mpls traffic-eng area 0
DELHI-P(config-router)#mpls traffic-eng router-id loopback 0
DELHI-P(config- router)#end
DELHI-P#wr
[OK]
DELHI-P#
MUMBAI-P
MUMBAI-P#conf t
MUMBAI-P(config)#mpls traffic-eng tunnels

Tunnels:
MUMBAI-P(config)#int gigabitethernet 7/0/1
MUMBAI-P(config-if)# mpls traffic-eng tunnels
MUMBAI-P(config-if)#ip rsvp bandwidth 100000
MUMBAI-P(config-if)#int gigabitethernet 7/0/1
MUMBAI-P(config-if)# mpls traffic-eng tunnels
MUMBAI-P(config-if)#ip rsvp bandwidth 100000

MUMBAI-P(config)#router ospf 9829
MUMBAI-P(config-router)#mpls traffic-eng area 0
MUMBAI-P(config-router)#mpls traffic-eng router-id loopback 0
MUMBAI-P(config- router)#end
MUMBAI-P#wr
[OK]
MUMBAI-P#
KOLKATA-PE
KOLKATA-PE#conf t
KOLKATA-PE(config)#mpls traffic-eng tunnels

Tunnels:
KOLKATA-PE(config)#int gigabitethernet 7/0/1
KOLKATA-PE(config-if)# mpls traffic-eng tunnels
KOLKATA-PE(config-if)#ip rsvp bandwidth 100000
KOLKATA-PE(config-if)#int pos 3/1

KOLKATA-PE(config)#router ospf 9829
KOLKATA-PE(config-router)#mpls traffic-eng area 0
KOLKATA-PE(config-router)#mpls traffic-eng router-id loopback 0

Create Tunnel Interface (At the tunnel headend)
KOLKATA-PE(config)#interface tunnel 2
KOLKATA-PE(config-if)#ip unnumbered to loopback 0
KOLKATA-PE(config-if)#tunnel destination 192.168.2.254
KOLKATA-PE(config-if)#tunnel mode mpls traffic-eng
KOLKATA-PE(config-if)#tunnel mpls traffic-eng bandwidth 40000
KOLKATA-PE(config-if)#tunnel mpls traffic-eng path-option 1 explicit name secret1
KOLKATA-PE(config-if)#tunnel mpls traffic-eng path-option 2 dynamic
KOLKATA-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to

use tunnel interface to calculate spf
Creating Explicit Path for tunnel (Headend)
KOLKATA-PE(config)#ip explicit path name secret1
KOLKATA-PE(chg-ip-expl-path)#next-address 172.16.16.13
KOLKATA-PE(chg-ip-expl-path)#end
KOLKATA-PE#wr
PUNE-PE
PUNE-PE#conf t
PUNE-PE(config)#mpls traffic-eng tunnels

Tunnels:
PUNE-PE(config)#int gigabitethernet 7/0/1
PUNE-PE(config-if)# mpls traffic-eng tunnels
PUNE-PE(config-if)#ip rsvp bandwidth 100000
PUNE-PE(config-if)#int pos 3/1

PUNE-PE(config)#router ospf 9829
PUNE-PE(config-router)#mpls traffic-eng area 0
PUNE-PE(config-router)#mpls traffic-eng router-id loopback 0

PUNE-PE(config)#interface tunnel 2
PUNE-PE(config-if)#ip unnumbered to loopback 0
PUNE-PE(config-if)#tunnel destination 192.168.0.254
PUNE-PE(config-if)#tunnel mode mpls traffic-eng
PUNE-PE(config-if)#tunnel mpls traffic-eng bandwidth 40000
PUNE-PE(config-if)#tunnel mpls traffic-eng path-option 1 explicit name open-secret1
PUNE-PE(config-if)#tunnel mpls traffic-eng path-option 2 dynamic
PUNE-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use

tunnel interface to calculate spf
PUNE-PE(config)#ip explicit path name open-secret1
PUNE-PE(chg-ip-expl-path)#next-address 172.16.16.6
PUNE-PE(chg-ip-expl-path)#end
PUNE-PE#wr
HYDERABAD
HYDERABAD#conf t
HYDERABAD(config)#mpls traffic-eng tunnels

Tunnels:
HYDERABAD(config)#int pos 3/1
HYDERABAD(config-if)# mpls traffic-eng tunnels
HYDERABAD(config-if)#ip rsvp bandwidth 100000
HYDERABAD(config-if)#int pos 3/2
HYDERABAD(config-if)# mpls traffic-eng tunnels
HYDERABAD(config-if)#ip rsvp bandwidth 100000

HYDERABAD(config)#router ospf 9829
HYDERABAD(config-router)#mpls traffic-eng area 0
HYDERABAD(config-router)#mpls traffic-eng router-id loopback 0

HYDERABAD(config)#interface tunnel 1
HYDERABAD(config-if)#ip unnumbered to loopback 0
HYDERABAD(config-if)#tunnel destination 192.168.6.254
HYDERABAD(config-if)#tunnel mode mpls traffic-eng
HYDERABAD(config-if)#tunnel mpls traffic-eng bandwidth 70000
HYDERABAD(config-if)#tunnel mpls traffic-eng path-option 1 explicit name long-

path
HYDERABAD(config-if)#tunnel mpls traffic-eng path-option 2 dynamic
HYDERABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to


HYDERABAD(config)#ip explicit path name long-path
HYDERABAD(chg-ip-expl-path)#next-address 172.16.16.14
HYDERABAD(chg-ip-expl-path)#end
HYDERABAD#wr
BANGALORE
BANGALORE#conf t
BANGALORE(config)#mpls traffic-eng tunnels

Tunnels:
BANGALORE(config)#int pos 3/1
BANGALORE(config-if)# mpls traffic-eng tunnels
BANGALORE(config-if)#ip rsvp bandwidth 100000
BANGALORE(config-if)#int pos 3/2
BANGALORE(config-if)# mpls traffic-eng tunnels
BANGALORE(config-if)#ip rsvp bandwidth 100000

BANGALORE(config)#router ospf 9829
BANGALORE(config-router)#mpls traffic-eng area 0
BANGALORE(config-router)#mpls traffic-eng router-id loopback 0

BANGALORE(config)#interface tunnel 1
BANGALORE(config-if)#ip unnumbered to loopback 0
BANGALORE(config-if)#tunnel destination 192.168.4.254
BANGALORE(config-if)#tunnel mode mpls traffic-eng
BANGALORE(config-if)#tunnel mpls traffic-eng bandwidth 70000
BANGALORE(config-if)#tunnel mpls traffic-eng path-option 1 explicit name very-

long-path
BANGALORE(config-if)#tunnel mpls traffic-eng path-option 2 dynamic
BANGALORE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to

BANGALORE(config)#ip explicit path name very-long-path
BANGALORE(chg-ip-expl-path)#next-address 172.16.16.5
BANGALORE(chg-ip-expl-path)#end
BANGALORE#wr
CHENNAI-PE
No Configuration
TRIVANDRUM
No Configuration
MPLS-VPN Lab Module: 3a

MPLS Traffic-Engineering enabling Forwarding-Adjacency
Note : - The configuration is to be done only at head-end of the tunnel. The tunnels
has to be bi-directional i.e same forward & return path for IGP to advertise to other
routers.
KOLKATA-PE
KOLKATA-PE#conf t
KOLKATA-PE(config)#interface tunnel 2
KOLKATA-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to

KOLKATA-PE#wr
PUNE-PE
PUNE-PE#conf t
PUNE-PE(config)#interface tunnel 2
PUNE-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use

HYDERABAD
HYDERABAD#conf t
HYDERABAD(config)#interface tunnel 1
HYDERABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to

BANGALORE
BANGALORE#conf t
BANGALORE(config)#interface tunnel 1
BANGALORE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to


MPLS Traffic-Engineering Node Protection
AHMEDABAD
AHMEDABAD#conf t
AHMEDABAD(config)#mpls traffic-eng tunnels

Tunnels:
AHMEDABAD(config)#int gigabitethernet 2/1
AHMEDABAD(config-if)# mpls traffic-eng tunnels
AHMEDABAD(config-if)#ip rsvp bandwidth 100000
AHMEDABAD(config)#router ospf 9829
AHMEDABAD(config-router)#mpls traffic-eng area 0
AHMEDABAD(config-router)#mpls traffic-eng router-id loopback 0
AHMEDABAD(config)#interface tunnel 1
AHMEDABAD(config-if)#ip unnumbered to loopback 0
AHMEDABAD(config-if)#tunnel destination 192.168.1.254
AHMEDABAD(config-if)#tunnel mode mpls traffic-eng
AHMEDABAD(config-if)#tunnel mpls traffic-eng bandwidth 50000
AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 1 explicit name

MAINPATH
AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 2 dynamic
AHMEDABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to


NODE_PROTECTION_FOR_PUNE


NODE_PROTECTION_FOR_KOLKATA

AHMEDABAD(config)#ip explicit path name MAINPATH
AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.21
AHMEDABAD(chg-ip-expl-path)#exit
AHMEDABAD(config)#ip explicit path name NODE_PROTECTION_FOR_PUNE
AHMEDABAD(chg-ip-expl-path)#exit
AHMEDABAD(config)#ip explicit path name

AHMEDABAD(chg-ip-expl-path)#end
AHMEDABAD#wr
GUWAHATI
GUWAHATI#conf t
GUWAHATI(config)#mpls traffic-eng tunnels

Tunnels:
GUWAHATI(config)#int gigabitethernet 2/1
GUWAHATI(config-if)# mpls traffic-eng tunnels
GUWAHATI(config-if)#ip rsvp bandwidth 100000
GUWAHATI(config)#router ospf 9829
GUWAHATI(config-router)#mpls traffic-eng area 0
GUWAHATI(config-router)#mpls traffic-eng router-id loopback 0
GUWAHATI(config)#interface tunnel 1
GUWAHATI(config-if)#ip unnumbered to loopback 0
GUWAHATI(config-if)#tunnel destination 192.168.3.254
GUWAHATI(config-if)#tunnel mode mpls traffic-eng
GUWAHATI(config-if)#tunnel mpls traffic-eng bandwidth 50000
GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 1 explicit name

MAINPATH
GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 2 dynamic
GUWAHATI(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use




NODE_PROTECTION_FOR_PUNE


GUWAHATI(config)#ip explicit path name MAINPATH
GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.17
GUWAHATI(chg-ip-expl-path)#exit
GUWAHATI(config)#ipexplicitpathname
GUWAHATI(chg-ip-expl-path)#exit
GUWAHATI(config)#ip explicit path name NODE_PROTECTION_FOR_PUNE
GUWAHATI(chg-ip-expl-path)#end
GUWAHATI#wr
PUNE-PE

Tunnels:
PUNE-PE(config)#int gigabitethernet 2/1
PUNE-PE(config)#int pos 3/2
PUNE-PE#wr
KOLKATA-PE

Tunnels:
KOLKATA-PE(config)#int gigabitethernet 2/1
KOLKATA-PE(config)#int pos 3/2
KOLKATA-PE#wr

(MPLS based L3 VPN using MP-BGP/ eBGP Lab)
DELHI-P:
Enabling & disabling interfaces:-
DELHI-P(config)#int gi 7/1/1
DELHI-P(config-if)#no shut
DELHI-P(config-if)#int gi 7/1/0
DELHI-P(config-if)#shut
Re-configuring OSPF 9829:-
DELHI-P#conf t
DELHI-P(config)#no router ospf 9829
DELHI-P(config-router)#auto-cost reference-bandwidth 1000
DELHI-P(config-router)#network 172.16.16.40 0.0.0.3 area 0
DELHI-P(config-router)#passive-interface loopback 0
DELHI-P(config-router)#end
DELHI-P#write memory
[OK]
DELHI-P#
Note: Re-configuring MPLS/Cisco Express Forwarding(cef) on all interfaces is not

required for P router
MUMBAI-P:
MUMBAI-P(config-if)#int gi 7/1/0
MUMBAI-P(config-if)#shut
MUMBAI-P#conf t
MUMBAI-P(config)#no router ospf 9829
MUMBAI-P(config-router)#auto-cost reference-bandwidth 1000
MUMBAI-P(config-router)#network 172.16.16.40 0.0.0.3 area 0
MUMBAI-P(config-router)#passive-interface loopback 0
MUMBAI-P(config-router)#end
MUMBAI-P#write memory
[OK]
MUMBAI-P#
Note: Re-configuring MPLS/Cisco Express Forwarding(cef) on all interfaces is not

required for P router
KOLKATA-PE: MPLS based L3 VPN configuration using MP-

BGP/eBGP:-
KOLKATA-PE (config-if)#int pos 3/2
KOLKATA-PE (config-if)#shut
KOLKATA-PE#conf t
KOLKATA-PE(config)#no router ospf 9829
KOLKATA-PE(config-router)#auto-cost reference-bandwidth 1000
KOLKATA-PE(config-router)#network 172.16.16.44 0.0.0.3 area 0
KOLKATA-PE(config-router)#passive-interface loopback 0
KOLKATA-PE(config-router)#exit
KOLKATA-PE(config)#
Disabling MPLS on interfaces (not in MPLS Domain):-
KOLKATA-PE(config)#interface GigabitEthernet2/1
KOLKATA-PE(config-if)#no mpls ip
KOLKATA-PE(config-if)# no mpls label protocol ldp
KOLKATA-PE(config-if)#exit
KOLKATA-PE(config)#interface POS 3/1
KOLKATA-PE(config-if)# no mpls label protocol ldp
KOLKATA-PE#write memory
[OK]
KOLKATA-PE#
Creation of VPN (vrf-table) and assigning Route-distinquisher/Route-target:-
KOLKATA-PE#conf t
KOLKATA-PE(config)#ip vrf ibm
KOLKATA-PE(config-vrf)#rd 9829:1
KOLKATA-PE(config-vrf)#route-target both 9829:10
KOLKATA-PE(config-vrf)#exit
KOLKATA-PE(config)#ip vrf sun
KOLKATA-PE(config-vrf)#rd 9829:2
KOLKATA-PE(config-vrf)#route-target both 9829:20
KOLKATA-PE(config-vrf)#exit
KOLKATA-PE(config)#
Assigning an interface to the VRF table:-
KOLKATA-PE(config)#interface pos 3/1
KOLKATA-PE(config-if)#ip vrf forwarding ibm
% Interface GigabitEthernet2/2 IP address 172.16.16.14 removed due to enabling

VRF ibm
KOLKATA-PE(config-if)#ip address 172.16.16.14 255.255.255.252
KOLKATA-PE(config)#interface gigabitEthernet 2/1
KOLKATA-PE(config-if)#ip vrf forwarding sun
% Interface GigabitEthernet2/1 IP address 172.16.16.17 removed due to enabling

VRF sun
KOLKATA-PE(config-if)#ip address 172.16.16.17 255.255.255.252
KOLKATA-PE#write memory
[OK]
KOLKATA-PE#
Configuring MP-BGP
KOLKATA-PE#conf t
KOLKATA-PE(config)#router bgp 9829
KOLKATA-PE(config-router)#neighbor 192.168.5.254 remote-as 9829
KOLKATA-PE(config-router)#neighbor 192.168.5.254 update-source loopback 0
KOLKATA-PE(config-router)#neighbor 192.168.2.254 update-source loopback 0
KOLKATA-PE(config-router)#no bgp default ipv4-unicast
KOLKATA-PE(config-router)#address-family ipv4 vrf ibm
KOLKATA-PE(config-router-af)#neighbor 172.16.16.13 remote-as 20
KOLKATA-PE(config-router-af)#neighbor 172.16.16.13 next-hop-self
KOLKATA-PE(config-router-af)#exit-address-family
KOLKATA-PE(config-router)#address-family ipv4 vrf sun
KOLKATA-PE(config-router-af)#neighbor 172.16.16.18 remote-as 50
KOLKATA-PE(config-router)#address-family vpnv4
KOLKATA-PE(config-router-af)#neighbor 192.168.5.254 activate
KOLKATA-PE(config-router-af)#neighbor 192.168.5.254 send-community both
KOLKATA-PE(config-router-af)#neighbor 192.168.2.254 activate

KOLKATA-PE(config-router-af)#neighbor 192.168.2.254 send-community both
KOLKATA-PE(config-router)#no synchronization
KOLKATA-PE(config-router)#no auto-summary
KOLKATA-PE(config-router)#end
KOLKATA-PE#wr
04:49:30: %SYS-5-CONFIG_I: Configured from console by console
[OK]
KOLKATA-PE#
PUNE-PE: MPLS based L3 VPN configuration using MP-

BGP/eBGP:-
Enabling & disabling interfaces & configuring controller:-
PUNE-PE (config)#controller e1 4/0/0
PUNE-PE (config-controller)#channel-group 0 time-slot 1-31
PUNE-PE (config-c0ntroller)#exit
PUNE-PE (config)#int pos 3/2
PUNE-PE (config-if)#shut
PUNE-PE (config)#int gi 2/1
PUNE-PE (config-if)#shut
PUNE-PE#conf t
PUNE-PE(config)#no router ospf 9829

PUNE-PE(config-router)#auto-cost reference-bandwidth 1000
PUNE-PE(config-router)#network 172.16.16.48 0.0.0.3 area 0
PUNE-PE(config-router)#passive-interface loopback 0
PUNE-PE(config-router)#exit
PUNE-PE(config)#
PUNE-PE(config)#interface POS 3/1
PUNE-PE(config-if)#no mpls ip
PUNE-PE(config-if)# no mpls label protocol ldp
[OK]
PUNE-PE#
PUNE-PE#conf t
PUNE-PE(config)#ip vrf ibm
PUNE-PE(config-vrf)#rd 9829:1
PUNE-PE(config-vrf)#route-target both 9829:10
PUNE-PE(config-vrf)#exit
PUNE-PE(config)#ip vrf sun
PUNE-PE(config-vrf)#rd 9829:2
PUNE-PE(config-vrf)#route-target both 9829:20
PUNE-PE(config-vrf)#exit

PUNE-PE(config)#
PUNE-PE(config)#interface serial 4/0/0:0
PUNE-PE(config-if)#ip vrf forwarding ibm
PUNE-PE(config-if)#ip address 172.16.16.69 255.255.255.252
PUNE-PE(config-if)#exit
PUNE-PE(config)#interface pos 3/1
PUNE-PE(config-if)#ip vrf forwarding sun
% Interface GigabitEthernet2/1 IP address 172.16.16.5 removed due to enabling VRF

sun
PUNE-PE(config-if)#ip address 172.16.16.5 255.255.255.252
[OK]
PUNE-PE#
Configuring MP-BGP
PUNE-PE#conf t
PUNE-PE(config)#router bgp 9829
PUNE-PE(config-router)#neighbor 192.168.5.254 remote-as 9829
PUNE-PE(config-router)#neighbor 192.168.5.254 update-source loopback 0
PUNE-PE(config-router)#neighbor 192.168.0.254 update-source loopback 0
PUNE-PE(config-router)#no bgp default ipv4-unicast
PUNE-PE(config-router)#address-family ipv4 vrf ibm
PUNE-PE(config-router-af)#neighbor 172.16.16.70 remote-as 10

PUNE-PE(config-router-af)#neighbor 172.16.16.70 next-hop-self
PUNE-PE(config-router-af)#exit-address-family
PUNE-PE(config-router)#address-family ipv4 vrf sun
PUNE-PE(config-router-af)#neighbor 172.16.16.6 remote-as 40
PUNE-PE(config-router)#address-family vpnv4
PUNE-PE(config-router-af)#neighbor 192.168.5.254 activate
PUNE-PE(config-router-af)#neighbor 192.168.5.254 send-community both
PUNE-PE(config-router-af)#neighbor 192.168.0.254 activate
PUNE-PE(config-router-af)#neighbor 192.168.0.254 send-community both
PUNE-PE(config-router)#no synchronization
PUNE-PE(config-router)#no auto-summary
PUNE-PE(config-router)#end
PUNE-PE#wr
[OK]
PUNE-PE#

CHENNAI-PE:
CHENNAI-PE (config)#int gi 2/1
CHENNAI-PE (config-if)#shut
CHENNAI-PE#conf t
CHENNAI-PE(config)#no router ospf 9829
CHENNAI-PE(config)#router ospf 9829
CHENNAI-PE(config-router)#auto-cost reference-bandwidth 1000
CHENNAI-PE(config-router)#network 172.16.16.60 0.0.0.3 area 0
CHENNAI-PE(config-router)#passive-interface loopback 0
CHENNAI-PE(config-router)#exit
CHENNAI-PE(config)#
CHENNAI-PE(config)#interface GigabitEthernet2/1
CHENNAI-PE(config-if)#no mpls ip
CHENNAI-PE(config-if)# no mpls label protocol ldp
CHENNAI-PE(config-if)#exit
CHENNAI-PE#conf t

CHENNAI-PE(config)#ip vrf ibm
CHENNAI-PE(config-vrf)#rd 9829:1
CHENNAI-PE(config-vrf)#route-target both 9829:10
CHENNAI-PE(config-vrf)#exit
CHENNAI-PE(config)#
CHENNAI-PE(config)#interface serial 4/0/0:0
CHENNAI-PE(config-if)#ip vrf forwarding ibm
CHENNAI-PE(config-if)#ip address 172.16.16.65 255.255.255.252
CHENNAI-PE(config-if)#end
CHENNAI-PE#write memory
[OK]
CHENNAI-PE#
Configuring MP-BGP
CHENNAI-PE#conf t
CHENNAI-PE(config)#router bgp 9829
CHENNAI-PE(config-router)#neighbor 192.168.0.254 remote-as 9829
CHENNAI-PE(config-router)#neighbor 192.168.0.254 update-source loopback 0
CHENNAI-PE(config-router)#neighbor 192.168.2.254 update-source loopback 0
CHENNAI-PE(config-router)#no bgp default ipv4-unicast
CHENNAI-PE(config-router)#address-family ipv4 vrf ibm
CHENNAI-PE(config-router-af)#neighbor 172.16.16.66 remote-as 20
CHENNAI-PE(config-router-af)#neighbor 172.16.16.66 next-hop-self

CHENNAI-PE(config-router-af)#exit-address-family
CHENNAI-PE(config-router)#address-family vpnv4
CHENNAI-PE(config-router-af)#neighbor 192.168.0.254 activate
CHENNAI-PE(config-router-af)#neighbor 192.168.0.254 send-community both
CHENNAI-PE(config-router-af)#neighbor 192.168.2.254 activate
CHENNAI-PE(config-router-af)#neighbor 192.168.2.254 send-community both
CHENNAI-PE(config-router)#no synchronization
CHENNAI-PE(config-router)#no auto-summary
CHENNAI-PE(config-router)#end
CHENNAI-PE#wr
[OK]
CHENNAI-PE#
IBM-CE-1 : eBGP configuration:-
IBM-CE-1 (config)#controller e1 4/0/0
IBM-CE-1 (config-controller)#channel-group 0 time-slot 1-31
IBM-CE-1 (config-c0ntroller)#exit
IBM-CE-1 (config)#int pos 3/2
IBM-CE-1 (config-if)#shut
IBM-CE-1 (config-if)#int serial 4/0/0:0
IBM-CE-1 (config-if)#ip add 172.16.16.70 255.255.255.252

IBM-CE-1 (config-if)#exit
Removing OSPF 9829:-
IBM-CE-1# conf t
IBM-CE-1(config)#no router ospf 9829
IBM-CE-1(config)#
Configuring BGP 10 & creating loopback 1 interface:-
IBM-CE-1# conf t
IBM-CE-1(config)#interface loopback 1
IBM-CE-1(config-if)#ip address 10.10.0.1 255.255.0.0
IBM-CE-1(config-if)#exit
IBM-CE-1(config)#router bgp 10
IBM-CE-1(config-router)#no synchronization
IBM-CE-1(config-router)#no auto-summary
IBM-CE-1(config-router)#neighbour 172.16.16.33 remote-as 9829
IBM-CE-1(config-router)#network 10.10.0.0 mask 255.255.0.0
IBM-CE-1(config-router)#end
IBM-PE#write memory
[OK]
IBM-CE-1#

IBM-CE-2 (config)#int pos 3/2
IBM-CE-2 (config-if)#shut
IBM-CE-2# conf t
IBM-CE-2(config)#
IBM-CE-2# conf t

IBM-PE#write memory
[OK]
IBM-CE-2#
IBM-CE-3 (config)#controller e1 4/0/0
IBM-CE-3 (config-controller)#channel-group 0 time-slot 1-31
IBM-CE-3 (config-c0ntroller)#exit
IBM-CE-3 (config-if)#int serial 4/0/0:0
IBM-CE-3# conf t
IBM-CE-3(config)#
IBM-CE-3# conf t

IBM-PE#write memory
[OK]
IBM-CE-3#
SUN-CE-1 : eBGP configuration:-
SUN-CE-1# conf t
SUN-CE-1(config)#no router ospf 9829
SUN-CE-1(config)#
SUN-CE-1(config)#no ip cef distributed
SUN-CE-1(config)#no mpls ip
SUN-CE-1(config)#no mpls label protocol ldp
SUN-CE-1(config)#no mpls ldp router-id loopback 0
SUN-CE-1(config)#interface pos 3/1
SUN-CE-1(config-if)#no mpls ip
SUN-CE-1(config-if)#no mpls label protocol ldp
SUN-CE-1(config-if)#end
SUN-PE#write memory

[OK]
SUN-CE-1#
SUN-CE-1# conf t
SUN-CE-1(config)#interface loopback 1
SUN-CE-1(config-if)#ip address 20.40.0.1 255.255.0.0
SUN-CE-1(config-if)#no shutdown
SUN-CE-1(config-if)#exit
SUN-CE-1(config)#router bgp 40
SUN-CE-1(config-router)#no synchronization
SUN-CE-1(config-router)#no auto-summary
SUN-CE-1(config-router)#neighbour 172.16.16.5 remote-as 9829
SUN-CE-1(config-router)#network 20.40.0.0 mask 255.255.0.0
SUN-CE-1(config-router)#end
SUN-PE#write memory
[OK]
SUN-CE-1#
SUN-CE-2 : eBGP configuration:-
SUN-CE-2# conf t

SUN-CE-2(config)# no router ospf 9829
SUN-CE-2(config)#
Configuring Controller & Disabling MPLS on interfaces (not in MPLS

Domain):-
SUN-CE-2(config)#controller e1 4/0/0
SUN-CE-2(config-controller)#channel-group 0 time-slot 1-31
SUN-CE-2(config-controller)#exit
SUN-CE-2(config)#no ip cef distributed
SUN-CE-2(config)#no mpls ip
SUN-CE-2(config)#no mpls label protocol ldp
SUN-CE-2(config)#no mpls ldp router-id loopback 0
SUN-CE-2(config)#interface GigabitEthernet2/1
SUN-CE-2(config-if)#no mpls ip
SUN-CE-2(config-if)#no mpls label protocol ldp
SUN-CE-2(config-if)#int serial 4/0/0:0
SUN-CE-2(config-if)#ip add 172.16.16.66 255.255.255.252
SUN-CE-2(config-if)#end
SUN-CE-2#write memory
[OK]
SUN-CE-2#
SUN-CE-2# conf t
SUN-CE-2(config)#interface loopback 1

SUN-CE-2(config-if)#ip address 20.50.0.1 255.255.0.0
SUN-CE-2(config-if)#no shutdown
SUN-CE-2(config-if)#exit
SUN-CE-2(config)#router bgp 50
SUN-CE-2(config-router)#no synchronization
SUN-CE-2(config-router)#no auto-summary
SUN-CE-2(config-router)#neighbour 172.16.16.29 remote-as 9829
SUN-PE#write memory
[OK]
SUN-CE-2#
Verification commands:-
Eg. For PUNE-PE router
PUNE-PE#show ip vrf
PUNE-PE#show ip vrf detail
PUNE-PE#show ip vrf interfaces
PUNE-PE#show ip protocols vrf ibm
PUNE-PE#show ip route vrf ibm
PUNE-PE#show ip bgp vpnv4 vrf ibm
PUNE-PE#show ip bgp vpnv4 vrf ibm neighbors
PUNE-PE#show ip bgp vpnv4 all summary
PUNE-PE#show ip bgp neighbors
PUNE-PE#show mpls forwarding vrf ibm

PUNE-PE#show ip cef vrf ibm
PUNE-PE#ping vrf ibm 10.20.0.1
PUNE-PE#trace vrf ibm 10.20.0.1
PUNE-PE#telnet 10.20.0.1 /vrf ibm


(MPLS based L3 VPN using MP-BGP/ OSPF Lab)
Delhi-P:
Note: No configuration needed in P-router
Mumbai-P:
PUNE-PE:
Configuring OSPF Process 10 for CE-PE link:-
PUNE-PE# conf t
PUNE-PE(config)#router ospf 10 vrf ibm
PUNE-PE(config-router)#redistribute bgp 9829 subnets
PUNE-PE(config)#
PUNE-PE(config)#router ospf 40 vrf sun
PUNE-PE(config-router)#redistribute bgp 9829 subnets
PUNE-PE(config)#

Modifying the MP-BGP configuration:-
PUNE-PE#conf t
PUNE-PE(config-router-af)#no neighbor 172.16.16.70 remote-as 10
PUNE-PE(config-router-af)#no neighbor 172.16.16.70 next-hop-self
PUNE-PE(config-router-af)#redistribute ospf 10 match internal external 1 external 2
PUNE-PE(config-router-af)#no neighbor 172.16.16.6 remote-as 40
PUNE-PE(config-router-af)#no neighbor 172.16.16.6 next-hop-self
PUNE-PE(config-router-af)#redistribute ospf 40 match internal external 1 external 2
PUNE-PE#wr
[OK]
PUNE-PE#
KOLKATA-PE:
KOLKATA-PE# conf t
KOLKATA-PE(config)#router ospf 20 vrf ibm

KOLKATA-PE(config-router)#redistribute bgp 9829 subnets
KOLKATA-PE(config)#
KOLKATA-PE(config)#router ospf 50 vrf sun
KOLKATA-PE(config-router)#redistribute bgp 9829 subnets
KOLKATA-PE(config)#
KOLKATA-PE#conf t
KOLKATA-PE(config-router-af)#no neighbor 172.16.16.13 remote-as 20
KOLKATA-PE(config-router-af)#no neighbor 172.16.16.13 next-hop-self
KOLKATA-PE(config-router-af)#redistribute ospf 20 match internal external 1

external 2
KOLKATA-PE(config-router-af)#no neighbor 172.16.16.18 remote-as 50
KOLKATA-PE(config-router-af)#no neighbor 172.16.16.18 next-hop-self
KOLKATA-PE(config-router-af)#redistribute ospf 50 match internal external 1

external 2

KOLKATA-PE#wr
[OK]
KOLKATA-PE#
CHENNAI-PE:
CHENNAI-PE# conf t
CHENNAI-PE(config)#router ospf 30 vrf ibm
CHENNAI-PE(config-router)#auto-cost reference-bandwidth 1000
CHENNAI-PE(config-router)#redistribute bgp 9829 subnets
CHENNAI-PE(config-router)#exit
CHENNAI-PE(config)#
CHENNAI-PE#conf t
CHENNAI-PE(config-router)#address-family ipv4 vrf ibm
CHENNAI-PE(config-router-af)#no neighbor 172.16.16.66 remote-as 30
CHENNAI-PE(config-router-af)#no neighbor 172.16.16.66 next-hop-self

CHENNAI-PE(config-router-af)#redistribute ospf 30 match internal external 1

external 2
CHENNAI-PE#wr
[OK]
CHENNAI-PE#
IBM-CE-1 : OSPF configuration:-
Removing BGP 10 and configuring OSPF 10:-
IBM-CE-1# conf t
IBM-CE-1(config)#no router bgp 10
IBM-CE-1(config)#router ospf 10
IBM-CE-1(config-router)#auto-cost reference-bandwidth 1000
IBM-CE-1(config-router)#network 172.16.16.68 0.0.0.3 area 0
IBM-CE-1(config-router)#passive-interface loopback 1
IBM-CE-1#write memory
[OK]
IBM-CE-1#clear ip ospf 10 process
Reset OSPF process? [no]: y

IBM-CE-1#
IBM-CE-2# conf t
[OK]
IBM-CE-2#
IBM-CE-3# conf t

[OK]
IBM-CE-2#
SUN-CE-1 : OSPF configuration:-
SUN-CE-1# conf t
SUN-CE-1(config)#no router bgp 40
SUN-CE-1(config)#router ospf 40
SUN-CE-1(config-router)#auto-cost reference-bandwidth 1000
SUN-CE-1(config-router)#network 172.16.16.4 0.0.0.3 area 0
SUN-CE-1(config-router)#passive-interface loopback 1
[OK]
SUN-CE-1#clear ip ospf 2100 process

SUN-CE-1#
SUN-CE-2 : OSPF configuration:-
SUN-CE-2# conf t
SUN-CE-2(config)#no router bgp 50
SUN-CE-2(config)#router ospf 50
SUN-CE-2(config-router)#auto-cost reference-bandwidth 1000
SUN-CE-2(config-router)#passive-interface loopback 1
[OK]
SUN-CE-2#
SUN-CE-2#clear ip ospf 50 process
SUN-CE-2#


(MPLS based L3 VPN using MP-BGP/ Static Lab)
Delhi-P:
Mumbai-P:
PUNE-PE:
Removing OSPF Process & configuring Static Route:-
PUNE-PE (config)#no router ospf 10 vrf ibm
PUNE-PE (config)#no router ospf 40 vrf sun
PUNE-PE (config)#ip route vrf ibm 10.10.0.0 255.255.0.0 172.16.16.70
PUNE-PE (config)#ip route vrf sun 20.40.0.0 255.255.0.0 172.16.16.6
PUNE-PE (config)#
PUNE-PE#conf t
PUNE-PE(config-router-af)#network 10.10.0.0 mask 255.255.0.0
PUNE-PE(config-router-af)#no redistribute ospf 10 match internal external 1 external

2


2
PUNE-PE#wr
[OK]
PUNE-PE#
KOLKATA-PE:
KOLKATA-PE (config)#no router ospf 20 vrf ibm
KOLKATA-PE (config)#no router ospf 50 vrf sun
KOLKATA-PE (config)#ip route vrf ibm 10.20.0.0 255.255.0.0 172.16.16.13
KOLKATA-PE (config)#ip route vrf sun 20.40.0.0 255.255.0.0 172.16.16.18
KOLKATA-PE (config)#
KOLKATA-PE#conf t
KOLKATA-PE(config-router-af)#network 10.20.0.0 mask 255.255.0.0
KOLKATA-PE(config-router-af)#no redistribute ospf 10 match internal external 1

external 2

KOLKATA-PE(config-router-af)#no redistribute ospf 40 match internal external 1

external 2
KOLKATA-PE#wr
[OK]
KOLKATA-PE#
PUNE-PE:
PUNE-PE (config)#no router ospf 30 vrf ibm
PUNE-PE (config)#ip route vrf ibm 10.30.0.0 255.255.0.0 172.16.16.66
PUNE-PE (config)#
PUNE-PE#conf t


2
PUNE-PE#wr
[OK]
PUNE-PE#
IBM-CE-1 :
Removing OSPF & Configuring Default route:-
IBM-CE-1# conf t
IBM-CE-1(config)#ip route 0.0.0.0 0.0.0.0 se 4/0/0:0
IBM-CE-1(config)#end
[OK]
IBM-CE-1#
IBM-CE-2 :
IBM-CE-2# conf t
IBM-CE-2(config)# ip route 0.0.0.0 0.0.0.0 pos 3/1

[OK]
IBM-CE-2#
IBM-CE-3 :
IBM-CE-3# conf t
IBM-CE-3(config)# ip route 0.0.0.0 0.0.0.0 Serial 4/0/0:0
[OK]
IBM-CE-2#
SUN-CE-1 :
SUN-CE-1# conf t
SUN-CE-1(config)# ip route 0.0.0.0 0.0.0.0 pos 3/1
SUN-CE-1(config)#end
[OK]

SUN-CE-1#
SUN-CE-2 :
SUN-CE-2# conf t
SUN-CE-2(config)# ip route 0.0.0.0 0.0.0.0 pos 3/1
SUN-CE-2(config)#end
[OK]
SUN-CE-2#


(MPLS L-2 VPN using X-connect & Frame-Relay)
Delhi-P:
Mumbai-P :
Chennai-PE:
Configuring pos link for up link connection
CHENNAI-PE#conf t
CHENNAI-PE(config)#int pos 3/1
CHENNAI-PE(config-if)#no shut
CHENNAI-PE(config-if)#encapsulation ppp
CHENNAI-PE(config-if)#clock source internal
CHENNAI-PE(config-if)#ip add 172.16.16.74 255.255.255.252
CHENNAI -PE(config-if)#mpls ip
CHENNAI -PE(config-if)#mpls label protocol ldp
CHENNAI-PE(config)#
Global Configuration for frame relay interface
CHENNAI-PE(config)#frame-relay switching
Configuring Serial link for frame relay interface

CHENNAI-PE(config)#int serial 4/0/0:0
CHENNAI-PE(config-if)# encapsulation frame-relay
CHENNAI-PE(config-if)# frame-relay interface-dlci 18 switched
CHENNAI-PE(config-if)# frame-relay lmi-type ansi
CHENNAI-PE(config-if)# frame-relay intf-type dce
CHENNAI-PE(config)#
Binding interface with virtual-circuit VC
CHENNAI-PE(config)#connect ibm-site1 serial 4/0/0:0 18 l2transport
CHENNAI-PE(config-psw-)#xconnect 192.168.2.254 321 encapsulation mpls
CHENNAI-PE(config-psw-)#end
CHENNAI-PE#wr
PUNE-PE:
PUNE-PE(config)#frame-relay switching
PUNE-PE(config)#int serial 4/0/0:0
PUNE-PE(config-if)#no ip address
PUNE-PE(config-if)# encapsulation frame-relay
PUNE-PE(config-if)# frame-relay interface-dlci 19 switched
PUNE-PE(config-if)# frame-relay lmi-type ansi
PUNE-PE(config-if)# frame-relay intf-type dce
PUNE-PE(config)#
Binding interface with virtual-circuit VC

PUNE-PE(config)#connect ibm-site1 serial 4/0/0:0 19 l2transport
PUNE-PE(config-psw-)#xconnect 192.168.5.254 321 encapsulation mpls
PUNE-PE(config-psw-)#end
PUNE-PE#wr
Binding fast-ethernet interface with virtual-circuit VC for sun
PUNE-PE(config)#int fast-ethernet 1/1
PUNE-PE(config-if)#no ip add
PUNE-PE(config-if)# xconnect 192.168.0.254 123 encapsulation mpls
PUNE-PE#wr
KOLKATA-PE:
Binding fast-ethernet interface with virtual-circuit VC for sun
KOLKATA-PE(config)#int gigabitethernet 2/1
KOLKATA-PE(config-if)#no shut
KOLKATA-PE(config-if)#no ip add
KOLKATA-PE(config-if)# xconnect 192.168.2.254 123 encapsulation mpls
KOLKATA-PE#wr
IBM-CE-1 :
IBM-CE-1(config)#frame-relay switching

IBM-CE-1 (config)#int serial 4/0/0:0
IBM-CE-1 (config-if)#encapsulation frame-relay ietf
IBM-CE-1 (config)#int serial 4/0/0:0.1 point-to-point
IBM-CE-1 (config-if)# frame-relay interface-dlci 19 ietf
IBM-CE-1 (config-if)#end
IBM-CE-1#wr
IBM-CE-2 :
IBM-CE-1(config)#frame-relay switching
IBM-CE-1 (config)#int serial 4/0/0:0
IBM-CE-1 (config-if)#encapsulation frame-relay ietf
IBM-CE-1 (config)#int serial 4/0/0:0.1 point-to-point
IBM-CE-1 (config-if)# frame-relay interface-dlci 18 ietf
IBM-CE-1 (config-if)#end
IBM-CE-1#wr
SUN-CE-1 :
Configuring fast-ethernet interface
SUN-CE-1 (config)#int fast-ethernet 1/1
SUN-CE-1 (config-if)#no shut

SUN-CE-1 (config-if)# ip add 10.0.0.1 255.255.255.0
SUN-CE-1 (config-if)#end
SUN-CE-1#wr
SUN-CE-2 :
Configuring gigabit-ethernet interface
SUN-CE-2 (config)#int gigabit-ethernet 2/1
SUN-CE-2 (config-if)#no shut
SUN-CE-2 (config-if)# ip add 10.0.0.2 255.255.255.0
SUN-CE-2 (config-if)#end
SUN-CE-2 #wr


(Carrier Support Carrier)
Delhi-P:
DELHI-P#conf t
DELHI-P(config)#mpls ip
DELHI-P(config)#mpls label pro ldp
DELHI-P(config)#ip cef distri
DELHI-P(config-if)#mpls ip
DELHI-P(config-if)#mpls label pro ldp
DELHI-P(config-if)#no mpls ip
DELHI-P(config-if)#no mpls label pro ldp
DELHI-P(config-if)#exit
DELHI-P(config)#ip vrf mtnl
DELHI-P(config)#rd 9829:1
DELHI-P(config)#route-target 9829:1
DELHI-P(config)#exit
DELHI-P(config)#int gi 7/0/1
DELHI-P(config-if)#ip vrf forwarding mtnl
DELHI-P(config-if)#ip add 172.16.16.45 255.255.255.252
DELHI-P(config-if)#exit

DELHI-P(config)#no router ospf 9829
DELHI-P(config-router)#net 172.16.16.40 0.0.0.3 ar 0
DELHI-P(config-router)#net 192.168.8.254 0.0.0.0 ar 0
DELHI-P(config-router)#exit
DELHI-P(config)#router bgp 9829
DELHI-P(config-router)#neighbor 192.168.9.254 remote-as 9829
DELHI-P(config-router)#neighbor 192.168.9.254 update lo0
DELHI-P(config-router)#address-family ipv4 vrf mtnl
DELHI-P(config-router-af)#neigbor 172.16.16.46 remote-as 1000
DELHI-P(config-router-af)#neigbor 172.16.16.46 send-com extended
DELHI-P(config-router-af)#address-family vpnv4
DELHI-P(config-router-af)#neighbor 192.168.9.254 activate
DELHI-P(config-router-af)#neighbor 192.168.9.254 next-hop-self
DELHI-P(config-router-af)#neighbor 192.168.9.254 send-com extended
DELHI-P(config-router-af)#end
DELHI-P# wr
Mumbai-P :
MUMBAI-P#conf t
MUMBAI-P(config)#mpls ip
MUMBAI-P(config)#mpls label pro ldp
MUMBAI-P(config)#ip cef distri
MUMBAI-P(config-if)#mpls ip
MUMBAI-P(config-if)#mpls label pro ldp

MUMBAI-P(config-if)#no mpls ip
MUMBAI-P(config-if)#no mpls label pro ldp
MUMBAI-P(config-if)#exit
MUMBAI-P(config)#ip vrf mtnl
MUMBAI-P(config)#rd 9829:1
MUMBAI-P(config)#route-target 9829:1
MUMBAI-P(config)#exit
MUMBAI-P(config)#int gi 7/0/1
MUMBAI-P(config-if)#ip vrf forwarding mtnl
MUMBAI-P(config-if)#ip add 172.16.16.49 255.255.255.252
MUMBAI-P(config-if)#exit
MUMBAI-P(config)#no router ospf 9829
MUMBAI-P(config-router)#net 172.16.16.40 0.0.0.3 ar 0
MUMBAI-P(config-router)#net 192.168.9.254 0.0.0.0 ar 0
MUMBAI-P(config-router)#exit
MUMBAI-P(config)#router bgp 9829
MUMBAI-P(config-router)#neighbor 192.168.8.254 remote-as 9829
MUMBAI-P(config-router)#neighbor 192.168.8.254 update lo0
MUMBAI-P(config-router)#address-family ipv4 vrf mtnl
MUMBAI-P(config-router-af)#neigbor 172.16.16.50 remote-as 2000
MUMBAI-P(config-router-af)#neigbor 172.16.16.50 send-com extended
MUMBAI-P(config-router-af)#address-family vpnv4
MUMBAI-P(config-router-af)#neighbor 192.168.8.254 activate
MUMBAI-P(config-router-af)#neighbor 192.168.8.254 next-hop-self

MUMBAI-P(config-router-af)#neighbor 192.168.8.254 send-com extended
MUMBAI-P(config-router-af)#end
MUMBAI-P# wr
KOLKATA-PE:
KOLKATA-PE#conf t
KOLKATA-PE(config)#mpls ip
KOLKATA-PE(config)#mpls label pro ldp
KOLKATA-PE(config)#ip cef distri
KOLKATA-PE(config-if)#int gi 2/1
KOLKATA-PE(config-if)#mpls ip
KOLKATA-PE(config-if)#mpls label pro ldp
KOLKATA-PE(config-if)#int gi 2/2
KOLKATA-PE(config-if)#no mpls label pro ldp
KOLKATA-PE(config)#no router ospf 9829
KOLKATA-PE(config-router)#net 172.16.16.16 0.0.0.3 ar 0
KOLKATA-PE(config-router)#net 192.168.0.254 0.0.0.0 ar 0

KOLKATA-PE(config-router)#neighbor 192.168.1.254 update lo0
KOLKATA-PE(config-router)#neighbor 192.168.1.254 next-hop-self
KOLKATA-PE(config-router)#neighbor 192.168.4.254 update lo0
KOLKATA-PE(config-router)#network 192.168.0.254 mask 255.255.255.255
KOLKATA-PE# wr
PUNE-PE:
PUNE-PE#conf t
PUNE-PE(config)#mpls ip
PUNE-PE(config)#mpls label pro ldp
PUNE-PE(config)#ip cef distri
PUNE-PE(config-if)#int gi 2/1
PUNE-PE(config-if)#mpls ip
PUNE-PE(config-if)#mpls label pro ldp
PUNE-PE(config-if)#int gi 2/2
PUNE-PE(config-if)#no mpls ip
PUNE-PE(config-if)#no mpls label pro ldp
PUNE-PE(config)#no router ospf 9829

PUNE-PE(config-router)#net 172.16.16.20 0.0.0.3 ar 0
PUNE-PE(config-router)#net 192.168.2.254 0.0.0.0 ar 0
PUNE-PE(config-router)#neighbor 192.168.3.254 update lo0
PUNE-PE(config-router)#neighbor 192.168.3.254 next-hop-self
PUNE-PE(config-router)#neighbor 192.168.6.254 update lo0
PUNE-PE(config-router)#network 192.168.2.254 mask 255.255.255.255
PUNE-PE# wr
GUHAWATI:
GUHAWATI#conf t
GUHAWATI(config)#mpls ip
GUHAWATI(config)#mpls label pro ldp
GUHAWATI(config)#ip cef distri
GUHAWATI(config-if)#int gi 2/1
GUHAWATI(config-if)#mpls ip
GUHAWATI(config-if)#no shut
GUHAWATI(config-if)#mpls label pro ldp
GUHAWATI(config-if)#int gi 2/2

GUHAWATI(config-if)#no shut
GUHAWATI(config-if)#mpls ip
GUHAWATI(config-if)#mpls label pro ldp
GUHAWATI(config-if)#exit
GUHAWATI(config)#no router ospf 9829
GUHAWATI(config)#router ospf 1000
GUHAWATI(config-router)#net 172.16.16.32 0.0.0.3 ar 0
GUHAWATI(config-router)#exit
GUHAWATI(config)#router bgp 1000
GUHAWATI(config-router)#neighbor 192.168.0.254 remote-as 1000
GUHAWATI(config-router)#neighbor 192.168.0.254 update lo0
GUHAWATI(config-router)#neighbor 192.168.0.254 next-hop-self
GUHAWATI(config-router)#neighbor 192.168.4.254 remote-as 1000
GUHAWATI(config-router)#neighbor 192.168.4.254 update lo0
GUHAWATI(config-router)#neighbor 192.168.4.254 next-hop-self
GUHAWATI(config-router)#network 192.168.1.254 mask 255.255.255.255
GUHAWATI(config-router)#end
GUHAWATI# wr
AHMEDABAD:
AHMEDABAD#conf t
AHMEDABAD(config)#mpls ip
AHMEDABAD(config)#mpls label pro ldp
AHMEDABAD(config)#ip cef distri

AHMEDABAD(config-if)#int gi 2/1
AHMEDABAD(config-if)#mpls ip
AHMEDABAD(config-if)#no shut
AHMEDABAD(config-if)#mpls label pro ldp
AHMEDABAD(config-if)#int gi 2/2
AHMEDABAD(config-if)#no shut
AHMEDABAD(config-if)#mpls ip
AHMEDABAD(config-if)#mpls label pro ldp
AHMEDABAD(config-if)#exit
AHMEDABAD(config)#no router ospf 9829
AHMEDABAD(config)#router ospf 2000
AHMEDABAD(config-router)#net 172.16.16.20 0.0.0.3 ar 0
AHMEDABAD(config-router)#exit
AHMEDABAD(config)#router bgp 1000
AHMEDABAD(config-router)#neighbor 192.168.2.254 remote-as 1000
AHMEDABAD(config-router)#neighbor 192.168.2.254 update lo0
AHMEDABAD(config-router)#neighbor 192.168.2.254 next-hop-self
AHMEDABAD(config-router)#neighbor 192.168.6.254 remote-as 1000
AHMEDABAD(config-router)#neighbor 192.168.6.254 update lo0
AHMEDABAD(config-router)#neighbor 192.168.6.254 next-hop-self
AHMEDABAD(config-router)#network 192.168.3.254 mask 255.255.255.255
AHMEDABAD(config-router)#end
AHMEDABAD# wr

HYDERABAD:
HYDERABAD#conf t
HYDERABAD(config)#mpls ip
HYDERABAD(config)#mpls label pro ldp
HYDERABAD(config)#ip cef distri
HYDERABAD(config)#ip vrf sun
HYDERABAD(config)#rd 1000:1
HYDERABAD(config)#route-target both 1000:1
HYDERABAD(config-if)#int gi 2/1
HYDERABAD(config-if)#no mpls ip
HYDERABAD(config-if)#no shut
HYDERABAD(config-if)#no mpls label pro ldp
HYDERABAD(config-if)#ip vrf forwarding sun
HYDERABAD(config-if)#ip add 172.16.16.25 255.255.255.252
HYDERABAD(config-if)#int gi 2/2
HYDERABAD(config-if)#no shut
HYDERABAD(config-if)#mpls ip
HYDERABAD(config-if)#mpls label pro ldp
HYDERABAD(config-if)#exit
HYDERABAD(config)#no router ospf 9829
HYDERABAD(config)#router ospf 1000
HYDERABAD(config-router)#net 172.16.16.32 0.0.0.3 ar 0
HYDERABAD(config-router)#net 192.168.4.254 0.0.0.0 ar 0
HYDERABAD(config-router)#exit
HYDERABAD(config)#router bgp 1000
HYDERABAD(config-router)#neighbor 192.168.0.254 remote-as 1000

HYDERABAD(config-router)#neighbor 192.168.0.254 update lo0
HYDERABAD(config-router)#neighbor 192.168.0.254 next-hop-self
HYDERABAD(config-router)#neighbor 192.168.1.254 next-hop-self
HYDERABAD(config-router)#neighbor 192.168.6.254 ebgp-multihop
HYDERABAD(config-router)#network 192.168.4.254 mask 255.255.255.255
HYDERABAD(config-router)#address-family ipv4 vrf sun
HYDERABAD(config-router-af)#neighbor 172.16.16.26 remote-as 50
HYDERABAD(config-router-af)#neighbor 172.16.16.26 next-hop-self
HYDERABAD(config-router-af)#exit
HYDERABAD(config-router)#address-family vpnv4
HYDERABAD(config-router-af)#neighbor 192.168.6.254 activate
HYDERABAD(config-router-af)#neighbor 192.168.6.254 next-hop-self
HYDERABAD(config-router-af)#neighbor 192.168.6.254 send-community extended
HYDERABAD(config-router-af)#end
HYDERABAD# wr
BANGALORE:
BANGALORE#conf t
BANGALORE(config)#mpls ip
BANGALORE(config)#mpls label pro ldp
BANGALORE(config)#ip cef distri
BANGALORE(config)#ip vrf sun
BANGALORE(config)#rd 1000:1

BANGALORE(config)#route-target both 1000:1
BANGALORE(config-if)#int gi 2/1
BANGALORE(config-if)#no mpls ip
BANGALORE(config-if)#no shut
BANGALORE(config-if)#no mpls label pro ldp
BANGALORE(config-if)#ip vrf forwarding sun
BANGALORE(config-if)#ip add 172.16.16.29 255.255.255.252
BANGALORE(config-if)#int gi 2/2
BANGALORE(config-if)#no shut
BANGALORE(config-if)#mpls ip
BANGALORE(config-if)#mpls label pro ldp
BANGALORE(config-if)#exit
BANGALORE(config)#no router ospf 9829
BANGALORE(config)#router ospf 2000
BANGALORE(config-router)#net 172.16.16.36 0.0.0.3 ar 0
BANGALORE(config-router)#net 192.168.6.254 0.0.0.0 ar 0
BANGALORE(config-router)#exit
BANGALORE(config)#router bgp 2000
BANGALORE(config-router)#neighbor 192.168.2.254 remote-as 2000
BANGALORE(config-router)#neighbor 192.168.2.254 update lo0
BANGALORE(config-router)#neighbor 192.168.2.254 next-hop-self
BANGALORE(config-router)#neighbor 192.168.3.254 next-hop-self
BANGALORE(config-router)#network 192.168.6.254 mask 255.255.255.255

BANGALORE(config-router)#neighbor 192.168.4.254 ebgp-multihop
BANGALORE(config-router)#address-family ipv4 vrf sun
BANGALORE(config-router-af)#neighbor 172.16.16.30 remote-as 40
BANGALORE(config-router-af)#neighbor 172.16.16.30 next-hop-self
BANGALORE(config-router-af)#exit
BANGALORE(config-router)#address-family vpnv4
BANGALORE(config-router-af)#neighbor 192.168.4.254 activate
BANGALORE(config-router-af)#neighbor 192.168.4.254 next-hop-self
BANGALORE(config-router-af)#neighbor 192.168.4.254 send-community extended
BANGALORE(config-router-af)#end
BANGALORE# wr
CHENNAI-PE:
CHENNAI-PE#conf t
CHENNAI-PE(config)#int lo0
CHENNAI-PE(config-if)#ip add 200.0.0.0 255.0.0.0
CHENNAI-PE(config-if)#int gi 2/1
CHENNAI-PE(config-if)#no mpls ip
CHENNAI-PE(config-if)#no shut
CHENNAI-PE(config-if)#no mpls label pro ldp
CHENNAI-PE(config-if)#int gi 2/2
CHENNAI-PE(config-if)#shut
CHENNAI-PE(config)#no router ospf 9829

CHENNAI-PE(config-router)#neighbor 172.16.16.25 next-hop-self
CHENNAI-PE(config-router)#network 192.168.5.254 mask 255.255.255.255
CHENNAI-PE(config-router)#network 200.0.0.0 255.0.0.0
CHENNAI-PE# wr
TRIVANDRUM:
TRIVANDRUM#conf t
TRIVANDRUM(config)#int lo0
TRIVANDRUM(config-if)#ip add 100.0.0.0 255.0.0.0
TRIVANDRUM(config-if)#int gi 2/1
TRIVANDRUM(config-if)#no mpls ip
TRIVANDRUM(config-if)#no shut
TRIVANDRUM(config-if)#no mpls label pro ldp
TRIVANDRUM(config-if)#int gi 2/2
TRIVANDRUM(config-if)#shut
TRIVANDRUM(config-if)#exit
TRIVANDRUM(config)#no router ospf 9829
TRIVANDRUM(config)#router bgp 40
TRIVANDRUM(config-router)#neighbor 172.16.16.29 remote-as 2000
TRIVANDRUM(config-router)#neighbor 172.16.16.29 next-hop-self
TRIVANDRUM(config-router)#network 192.168.7.254 mask 255.255.255.255
TRIVANDRUM(config-router)#network 100.0.0.0 255.0.0.0
TRIVANDRUM(config-router)#end
TRIVANDRUM# wr

LABEL DISTRIBUTION PROTOCOL

Label Distribution Protocols

 Label distribution protocol is a set of rules and procedures that one LSR
can use to inform another LSR about which label will be used to forward MPLS
traffic between and through them
 The path set up by these bilateral agreement is called label switched path(LSP

 MPLS architecture does not assume a single label distribution protocol.
 A number of protocols have been standarised
 Label Distribution Protocol
 LDP
 Constraint-based Routing with LDP
 CR-LDP
 RSVP with TE extensions
 RSVP-TE
 Distributing labels with BGP-4


  Label distribution protocol is a set of rules and procedures that one LSR can
use to inform another LSR about which label will be used to to forward
MPLS traffic between and through them
 The path set up by these bilateral agreement is called label switched path
(LSP)
 MPLS architecture does not assume a single label distribution protocol.
 A number of protocols have been standarised
 Label Distribution Protocol
LDP

 Constraint-based Routing with LDP
CR-LDP

 RSVP with TE extensions
RSVP-TE

 Distributing labels with BGP-4
 Labels assigned by downstream peer

Limitations
LSPs follow the conventional IGP path
Does not support explicit routing

Label Distribution Protocol

 Set of procedures and messages by which LSRs create LSPs through a
network by mapping network layer routing information directly to data link
layer switched paths
 LSPs may have their end point
 At a directly attached LSR
 At a network egress LSR i.e. number of LSRs away
 A FEC be defined for each of the LSP

 Each EFC contains one or more FEC elements
 Each element identifies which set of incoming packets will be mapped to an
LSP at the ingress
LDP Messages
 LDP communicate using messages
 There are 4 categories of LDP messages
 Discovery Messages
Announce and maintain the presence of an LSR


 Session Messages
Establish, maintain and terminate session between LDP peers


 Advertisement Messages
Create, change and delete label mappings for FECs


 Notification Messages
Advisory and signal error notification



LDP Messages
 Discovery messages provide a mechanism by which the LSRs indicate their
presence in a network by sending Hello message periodically
 This is transmitted as a UDP packet
 When an LSR chooses to establish a session with another LSR learned via
Hello message, uses LDP initialisation procedure over TCP transport
 When multiple sessions are required between two LSRs there is one TCP
session for each LDP session
LDP Messages
 Upon successful completion of the initialisation procedure, the two LSRs
are LDP peers and may exchange advertisement messages
 LDP peers communicate over an LDP session created between them
 An LSP can be viewed as a series of LDP peers and their associated sessions
 Correct operation of LDP requires reliable and in order delivery of messages
 Uses the TCP transport for Session, Advertisement and Notification
messages(Port-646)
 Uses UDP transport for Discovery messages(Port-646)

A LDP Discovery Msg Session Msgs
T UDP TCP
N IP
D To/From Physical Layer
LDP Messages

LDP Messages & Codes
S.No. Message Name Message Value

1. Notification 0001H
2. Hello 0100H
3. Intialisation 0200H
4. Keep Alive 0201H
5. Address 0300H
6. Address Withdraw 0301H
7. Label Mapping 0400H
8. Label Request 0401H
9. Label Withdraw 0402H
10. Label Release 0403H
11. Label Abort Request 0404H

 LDP Message Exchange

 LDP message exchanges are accomplished by sending LDP protocol data
units (PDUs) over LDP session TCP connections
 Each LDP PDU can carry one or more messages
 Messages in an LDP PDU need not be related to one another
LDP PDU Message Format

LDP Header (10Bytes)
 Version(2B)
 Present version is 1
 Length(2B)
 Total PDU length in octets
 Exclusive of the version and length fields
 Negotiated during session intialisation
 Maximum allowable length is 4096 Bytes
LDP Header (10Bytes)

 LDP Identifier(6B)
 Uniquely identifies the label space of the sending LSR
 Router ID (4B)
 Identifies the LSR and must be a globally unique value
 Router ID is the IP address of this LSR
 Label Space ID (2B)
 Identifies the label space within the LSR
LDP Message Format

 U bit-Unknown message bit
 Upon receipt of an unknown message, if
 U=0, a notification must be returned to the message originator
 U=1, the unknown message is silently ignored and the rest of message
is processed

LDP Messages
 Message Type (15 b)

 Identifies the type of message
 Message Length (2B)

 Length in octets of the Message ID, Mandatory Parameters &
Optional Parameters
 Message ID (4B)
 Notification messages, if to be sent, in response to this message carry
this value back in the Status TLV

 Mandatory Parameters-Variable
 Optional Parameters-Variable
Type-Length-Value Encoding
 LDP messages carry information, encoded in Type-Length-Value (TLV)
format
 Maximum allowable length is 4096 Bytes
 U bit-Unknown TLV bit
 Upon receipt of an unknown TLV, if
U=0, a notification must be returned to the message originator and

ENTIRE message must be ignored
U=1, the unknown TLV is silently ignored and the rest of message is
processed
 F bit-Forward Unknown TLV bit

 Applies only when U=1, if
 F=0, the unknown TLV is NOT forwarded with the containing

message
 F=1, the unknown TLV is forwarded with the containing message

 Type (14b)

 Identifies the various message types
 Length (2B)
 Length in octets of ONLY the value field
 Value-Variable
 String of octets that encodes the information
 TLVs can be nested i.e. Value field itself may contain further TLV
encodings
LDP OPERATION
 LDP Discovery
 Session Establishment
 Label Distribution
 Error Notification
LDP Discovery
 LDP discovery is a mechanism that enables an LSR to discover potential
LDP peers
 Basic discovery
To discover LSR neighbors that are directly connected at the link level
LSR periodically sends LDP link hellos out the interface as UDP
packets using group multicast address
 Extended discovery
To discover LSRs that are not directly connected at the link level
LSR periodically sends LDP targeted hellos as UDP packets to a
specific address

Hello Message

 Hold Time-Seconds
 0000-Default time of 15 sec for Link Hello and 45 sec for Targeted
Hello
 FFFF-Means infinite
 T-Bit-Target Hello Bit

 0-Link Hello
 1-Targeted Hello
 R-Bit-Request Send Target Hello

 0-No Request
 1-Request the receiver to send Target Hello
LDP Discovery
 LSR receiving hellos from another LSR maintains a hello adjacency
 If the parameters contained in the hello are acceptable
 LSRs proceed for LDP session establishment
 If the parameters contained in the hello are not acceptable

 LSRs ignore it and LDP session can not be established

LDP Session Establishment


 Session establishment is a 2 step process:
 Transport connection establishment
 Session intialisation
 Transport connection establishment

 TCP connection will be established for a new LDP session by the
Active LSR
 LSRs will compare the Transport Address exchanged in the optional
parameter of Hellos
 The LSR with greater Transport Address will become Active LSR
 If NO Transport Addresses are negotiated LSR with greater Router
ID will become Active LSR
LDP Session Establishment

 Session intialisation
 Active LSR starts negotiating session parameters by exchanging LDP
intialisation messages
 LDP Protocol version
 Label Distribution Method
 Timer Values etc.
 If the parameters are acceptable the session is established and keep-
alive messages are periodically exchanged

 If the parameters are NOT acceptable the session can not be
established and TCP connection is closed

Initialisation Message
 Protocol Version (2B)

 LDP protocol version
 Keep-alive Time (2B)

 Time in seconds that may elapse between the receipt of successive
PDUs from the LDP peer on the session TCP connection

 A-Bit-Label Advertisement Discipline
 0-Downstream Unsolicited Advertisement
 1-Downstream on demand
 D-Bit-Loop Detection
 0-Loop Detection Disabled
 1-Loop Detection enabled
Initialisation Message
 PV Limit-Path Vector Limit (1B)
 Configured maximum path vector length
 Must be 0 if loop detection is disabled
 Maximum PDU Length (2B)

 Maximum allowable length for LDP PDUs
 Default is <=255 Octets
 Maximum is 4096 Octets
 Maximum PDU Length (2B)

 Identifies the receiver’s label space
 This together with sender’s LDP identifier in the PDU header
enables the receiver to match the initialisation message with its hello
adjacencies

LDP Session Monitoring

 LDP includes mechanism to monitor the integrity of LDP session

 An LSR maintains a Keep-Alive timer for each peer session
 If Keep-Alive timer expires without receipt of an LDP-PDU, LDP session is
terminated and TCP connection is closed
Keep Alive Message

 An LSR must arrange that its peer receive an protocol message or a Keep-
Alive message from it at least every Keep-Alive time
LDP Identifiers & NH Addresses

 An LSR maintains learned labels in a LIB (Label Information Base)
 When the next hop for a prefix changes the LSR must retrieve the label
advertised by the new next hop from the LIB for use in forwarding
 To enable LSRs to map between a peer LDP identifier and the peer‘s
addresses, LSRs advertise their addresses using LDP Address and Address
Withdraw messages

Address Message
 An LSR sends the address message to advertise the interface address.

Address Withdraw Message

 An LSR sends to withdraw previously advertised interface addresses
LDP Label Distribution

 MPLS label distribution and management can be done in 2 ways
 Downstream on Demand Label Distribution
 FEC-Label bindings are distributed in response to an explicit request
from another LSR

 Downstream Unsolicited
 FEC-Label bindings are distributed to LSRs that have not explicitly
requested them
 Both of these techniques may be used in the same network at the same time
LDP Label Distribution

 Each interface on an LSR is configured to operate in either Downstream on
Demand Label Distribution or Downstream Unsolicited
 For any given session, each LSR must be aware of the label distribution
method used by its peer
 LSRs exchange advertisement modes during initialisation
 Label Request and Label Mapping messages are exchanged for label
distribution
 Loop Detection mechanism is used to prevent these messages going into
loop

Label Distribution Control Mode

 The
Labelbehavior of the initial setup of LSPs is determined by the label
Request Message

distribution control
 An upstream mode
LSR sends this message to a downstream LDP peer to
 Independent Label Distribution
assign and advertise Control for a FEC
a binding (mapping)
 Label Each LSRMessage
Mapping may advertise label mappings to its neighbor at any time
without waiting
 A downstream for asends
LSR label this
mapping fromto
message thethe
nextupstream
hop LSR for a
 Ordered
FEC Label Distribution Control
 An The LSRreceiving
LSR must wait thisuntil message
a label from a downstream
should not use LSR
the islabel
received
for
before mapping
forwarding unlesstheitsFEC and passing
routing corresponding
table contains labelsthat
an entry to upstream
exactly
LSRs the FEC element
matches
 Label Abort Request Message
 An upstream LSR sends this message to abort an outstanding Label
Request Message for FEC sent to downstream LSR

 Label Withdraw Message
 A downstream LSR sends this message to an upstream LSR that the
peer may not continue to use specific FEC-Label mappings the LSR
had previously advertised
Label Retention
Distribution Mode
 Specifies whether
Label Release an LSR maintains a label binding for a FEC learned from
Message
aneighbor that is LSR
An upstream not itssends
next hop
this for the FEC
message to a downstream LSR that the
 Conservative
peer no longer Labelneeds
Retention Mode
specific FEC-Label mappings previously
Label mapping advertisements of all routes are received from all peers
requested

 Loop but only isthose

detection mappings option
a configurable will be retained which will be used to
forward
 Path Vectorpackets
TLV
 Liberal
 Label propagated
A message Retention Mode
by an LSR adds its LSR ID to the path vector
 Label mapping advertisements of all routes are received and retained
list
 fromLSR
An all peers regardless
receiving of whether
a message the LSR
containing is the
its LSR IDnext hopthat
detects for the
advertising
message hasmapping
traversed a loop
 Also an LSR that detects a path vector has reached the maximum
configured length treats as if the message has traversed a loop
 Hop Count TLV
 A message propagated by an LSR increments the hop count

 An LSR that detects a hop count has reached the configured value
treats as if the message has traversed a loop
Error Notification
 Sent by LSR to inform LDP peer of a significant event

 Two types of Notification Messages
 Error Notification
 Signal fatal errors
Expiration of a keep-alive timer


Shutdown by a node

Failure of an LSP session initialisation


 Advisory Notification
 Outcome of processing an LDP message
 State of the LDP session
Notification Message
 Status TLV
 Indicates the event being signaled
 Malformed PDU
 Malformed TLV
 Expiry of Session Keep-alive Timer
 Unilateral Session Shutdown ……….


 Status TLV
 U-Bit
 0-Status TLV is sent in notification message

 1-Status TLV is sent in some other message
 F-Bit
 Same as F-Bit in Status Code field

 Status Code
 E-Bit- Fatal Error Bit
 0-Advisory Notification
 1-Fatal Error Notification
 F-Bit- Forward Bit
 0-Notification should not be forwarded

 1-Notification should be forwarded to the NH LSR

RSVP-TE

MPLS TRAFFIC ENGINEERING

MPLS Traffic Engineering (MPLS TE) is a growing implementation in today's
service provider networks. MPLS adoption in service provider networks has increased
manifold due to its inherent TE capabilities. MPLS TE allows the MPLS-enabled
network to replicate and expand upon the TE capabilities of Layer 2 ATM and Frame
Relay networks. MPLS uses the reachability information provided by Layer 3 routing
protocols and operates like a Layer 2 ATM network. With MPLS, TE capabilities are
integrated into Layer 3, which can be implemented for efficient bandwidth utilization
between routers in the SP network.
This chapter provides you with information on the operation and configuration of
MPLS TE on Cisco routers.
TE Basics
TE is the process of steering traffic across to the backbone to facilitate efficient use of
available bandwidth between a pair of routers. Prior to MPLS TE, traffic engineering
was performed either by IP or by ATM, depending on the protocol in use between two
edge routers in a network. Though the term "traffic engineering" has attained
popularity and is used more in the context of MPLS TE today, traditional TE in IP
networks was performed either by IP or by ATM.
TE with IP was mostly implemented by manipulation of interface cost when multiple

paths existed between two endpoints in the network. In addition, static routes enabled
traffic steering along a specific path to a destination. Figure outlines a basic IP
network with two customers, A and B, connected to the same service provider.
Figure Traditional IP Networks
As illustrated in Figure, two paths exist between customer routers CE1-A and CE2-A
via the provider network. If all links between the routers in Figure were of equal cost,
the preferred path between customer routers CE1-A and CE2-A would be the one

with the minimum cost (via routers PE1-AS1, P3-AS1, and PE2-AS1) or PATH1. The
same would apply for the customer routers CE1-B and CE2-B belonging to Customer
B. If all the links were T3 links, for example, in the event of CE1-A sending 45 Mbps
of traffic and CE1-B simultaneously sending 10 Mbps of traffic, some packets will be
dropped at PE1-AS1 because the preferred path for both customers is using PATH1.
The path PATH2 will not be utilized for traffic forwarding; therefore, TE can utilize
this available bandwidth. To implement TE using IP whereby the paths PATH1 and
PATH2 are either load balanced or used equally, we will need to implement IGP
features such as maximum paths with variance or change the cost associated with the
suboptimal path, PATH2, to make it equal to the current optimal path, PATH1. In an
SP environment, this is often cumbersome to implement as the number of routers is
much larger.
With ATM networks, the solution is a lot more feasible; PVCs can be configured
between routers PE1-AS1 and PE2-AS1 with the same cost, but this would create a
full mesh of PVCs between a group of routers. Implementing ATM for TE, however,
has an inherent problem when a link or a node goes down. During link or node failure
used in conjunction with ATM for TE, messages are flooded on the network. The
Layer 3 topology must be predominantly fully meshed to take advantage of the Layer
2 TE implementation. Often, this might prove to be a scalability constraint for the IGP
in use, due to issues with reconvergence at Layer 3.
The main advantage of implementing MPLS TE is that it provides a combination of

ATM's TE capabilities along with the class of service (CoS) differentiation of IP. In
MPLS TE, the headend router in the network controls the path taken by traffic to any
particular destination in the network. The requirement to implement a full mesh of
VCs, as in ATM, does not exist when implementing MPLS TE. Therefore, when
MPLS TE is implemented, the IP network depicted in Figure transforms into the label
switched domain, as shown in Figure, in which the TE label switched paths or TE
tunnels (Tunnel1 and Tunnel2) define paths that can be used by traffic between PE1-
AS1 and PE2-AS1.

MPLS TE
MPLS TE Theory
This section introduces you to the theoretical nuances in the implementation of MPLS
TE. The primary topics covered will be the components of MPLS TE as well as RSVP
and its function in the implementation of MPLS TE.
MPLS TE Overview
In a traditional IP forwarding paradigm, packets are forwarded on a per-hop basis
where a route lookup is performed on each router from source to destination. As cited
earlier, the destination-based forwarding paradigm leads to suboptimal use of
available bandwidth between a pair of routers in the service provider network.
Predominantly, the suboptimal paths are under-utilized in IP networks. To avoid
packet drops due to inefficient use of available bandwidth and to provide better
performance, TE is employed to steer some of the traffic destined to follow the
optimal path to a suboptimal path to enable better bandwidth management and
utilization between a pair of routers. TE, hence, relieves temporary congestion in the
core of the network on the primary or optimal cost links. TE maps flows between two
routers appropriately to enable efficient use of already available bandwidth in the core
of the network. The key to implementing a scalable and efficient TE methodology in
the core of the network is to gather information on the traffic patterns as they traverse
the core of the network so that bandwidth guarantees can be established. As illustrated
in Figure, TE tunnels, Tunnel1 and Tunnel2, can be configured on PE1-AS1 that can
map to separate paths (PATH1, PATH2), enabling efficient bandwidth utilization.
TE tunnels configured on routers are unidirectional. Therefore, to implement

bidirectional TE deployment between routers PE1-AS1 and PE2-AS1 in Figure, a pair
of tunnels must also be configured on PE2-AS1 in addition to Tunnel1 and Tunnel2
configured on PE1-AS1. In an MPLS network, all pertinent tunnel configurations are
always performed or provider edge (PE) routers. The TE tunnels or LSPs will be used
to link the edge routers across the core of the service provider network.

MPLS TE can also map to certain classes of traffic versus destinations. If Customer A
CE routers are connected into the SP network using OC3 links versus Customer B
connecting into the SP network using a 64 K dialup link, preferential treatment can be
configured on TE tunnels so that TE Tunnel1 can carry Customer A traffic and
Tunnel2 can carry Customer B traffic. This is shown in Figure. Also note that Figure
illustrates tunnels configured on both PE1-AS1 and PE2-AS1.
TE Tunnels Based on Customer CoS
TE tunnels are, thus, data flows between a specific source and destination that might
have properties or attributes associated with them. The attributes associated with a
tunnel, in addition to the ingress (headend) and egress (tailend) points of the network,
can include the bandwidth requirements and the CoS for data that will be forwarded
utilizing this tunnel. Traffic is forwarded along the path defined as the TE tunnel by
using MPLS label switching. Hence, TE tunnels are assigned specific label switched
paths (LSPs) in the network from source to destination, which are usually PE routers.
MPLS LSPs have a one-to-one mapping with TE tunnels, and TE tunnels are not
bound to a specific path through the SP network to a destination PE router. Unless
configured explicitly, TE tunnels can reroute packets via any path through the
network associated with an MPLS LSP. This path might be defined by the IGP used
in the core, which are discussed in the section on MPLS TE extensions.
The primary reason for the implementation of MPLS TE is to control paths along
which traffic flows through a network. MPLS TE also lends itself to a resilient design
in which a secondary path can be used when the primary path fails between two
routers in a network. Data plane information is forwarded using label switching; a
packet arriving on a PE from the CE router is applied labels and forwarded to the
egress PE router. The labels are removed at the egress router and forwarded out to the
appropriate destination as an IP packet.
OSPF or IS-IS with extensions for TE is used to carry information pertaining to the
tunnel configured on a router. The extensions carry information on available resources

for building a tunnel, like bandwidth on a link. As a result, a link that does not have
the requested resources (like bandwidth) is not chosen to be a part of the LSP tunnel
or TE tunnel. Signaling in an MPLS TE environment uses resource reservation
protocol (RSVP) with extensions to support TE tunnel features.
The data plane ingress (headend) router in the MPLS domain requires information
pertaining to the resource availability on all links capable of being a part of the MPLS
TE tunnel. This information is provided by IGPs like OSPF and IS-IS due to the
inherent operation of flooding information about links to all routers in the IGP
domain. In IS-IS, a new TLV (type 22) has been developed to transmit information
pertaining to resource availability and link status in the LS-PDUs. In OSPF, the type
10 LSA provides resource and links status information. When this information is
flooded in IGP updates, the ingress (headend) router gathers information on all the
available resources in the network along with the topology, which defines tunnels
through the network between a set of MPLS-enabled routers.
The inspiration behind MPLS TE is Constraint Based Routing (CBR), which takes
into account the possibility of multiple paths between a specific source/destination
pair in a network. With CBR, the operation of an IP network is enhanced so the least
cost routing can be implemented as well as variables to find paths from a source to
destination. CBR requires an IGP, like OSPF or IS-IS, for its operation. CBR is the
backbone of the TE tunnel definition and is defined on the ingress routers to the
MPLS domain when implementing MPLS TE. Resource availability and link status
information are calculated using a constrained SPF calculation in which factors such
as the bandwidth, policies, and topology are taken into consideration to define
probable paths from a source to destination.
CSPF calculation results with an ordered set of IP addresses that map to next-hop IP
addresses of routers forming an LSP, in turn mapping to the TE tunnel. This ordered
set is defined by the headend router that is propagated to other routers in the LSP. The
intermediate routers, thus, do not perform the function of path selection. RSVP with
TE extensions is used to reserve resources in the LSP path as well as label association
to the TE tunnel. The operation of RSVP for MPLS TE is introduced in the next
section.
RSVP with TE Extensions: Signaling
RSVP reserves bandwidth along a path from a specific source to destination. RSVP
messages are sent by the headend router in a network to identify resource availability
along the path from a specific source to destination. The headend router is always the
source of the MPLS TE tunnel, and the tailend router is the router that functions as the
endpoint for the TE tunnel. After the RSVP messages are sent, the status of routers in
the path (resource availability) information is stored in the path message as it
traverses the network. RSVP, therefore, communicates the requirements of a specific
traffic flow to the network and gathers information about whether the requirements
can be fulfilled by the network.
The four main messages used in implementation of RSVP for TE are the RSVP PATH
message, the RSVP RESERVATION message, RSVP error messages, and RSVP tear
messages. In MPLS TE, RSVP is used to ensure and verify resource availability, as
well as apply the MPLS labels to form the MPLS TE LSP through the routers in the
network:

RSVP PATH message— Generated by the headend router and is forwarded through
the network along the path of a future TE LSP. At each hop, the PATH message
checks the availability of requested resources and stores this information. In our
network, shown in Figure 9-4, the PATH message is generated by Router PE1-AS1,
the headend router, and is forwarded downstream where it checks resource
availability at each hop (P1-AS1 and PE2-AS1). The RSVP PATH message functions
as a label request in MPLS TE domain. Because all TE domains function with
downstream-on-demand label allocation mode, the request to assign a label is
generated at the headend router and propagated downstream.
RSVP PATH and RESERVATION Messages
RSVP RESERVATION message— Created by the tailend router in the MPLS TE

domain and used to confirm the reservation request that was sent earlier with the
PATH messages. In the network depicted in Figure , PE2-AS1 will generate the
RSVP RESERVATION message in response to the PATH message. Therefore,
PATH messages function as reservation requests and RESERVATION messages
function as reservation confirmations for the availability of requested resources. The
RSVP RESERVATION message performs the function of label assignment for a
particular LSP mapping to the TE tunnel. As the MPLS domain label allocation and
distribution is performed downstream-on-demand, the label mapping to a TE LSP is
first generated by the tailend router or egress Edge LSR and then propagated
upstream. This process is repeated at each hop upstream where local labels mapping
to a TE tunnel are assigned and propagated upstream until the headend router is
reached.
RSVP error messages— In the event of unavailability of the requested resources, the
router generates RSVP error messages and sends them to the router from which the
request or reply was received. If Router P1-AS1 is unable to accommodate requested
resources as defined in the PATH message generated by PE1-AS1 (headend router),
the router generates a PATH ERROR (PATHERR) message and sends it to its
upstream LSR PE1-AS1, as depicted in Figure 9-5.

RSVP PATH Error and RESERVATION Error Messages
If the RSVP PATH message successfully reaches the tailend router, the tailend Router
PE2-AS1 generates a RESERVATION message. If in the time lapsed between P1-
AS1 receiving the PATH message from PE1-AS1 to receiving the RESERVATION
message from PE2-AS1, P1-AS1 identifies a lack of resources to confirm the request,
P1-AS1 will send a RESERVATION ERROR (RESVERR) message to its
downstream LSR PE2-AS1 denying the reservation, as depicted in Figure 9-5.
RSVP tear messages— RSVP creates two types of tear messages, namely, the PATH
tear message and the RESERVATION tear message. These tear messages clear the
PATH or RESERVATION states on the router instantaneously. The process of
clearing a PATH or RESERVATION state on a router using tear messages enables
the reuse of resources on the router for other requests. The PATH tear messages are
usually generated in inter-area LSP creation where the inter-area LSP is not
configured to be fast reroutable, and if a link failure occurs within an area, the LSR to
which the failed link is directly attached will generate an RSVP PATH error and an
RESV tear message to the headend. The headend will then generate an RSVP PATH
tear message. The corresponding path option will be marked as invalid for a certain
amount of time and the next path option will be immediately evaluated if it exists.
RSVP Operation in MPLS TE
As mentioned earlier, the result of a CSPF or CBR calculation on the headend router
is an ordered list of IP addresses that identifies the next hops along the path of the TE
tunnel or LSP. This list of routers is computed and is known only to the headend
router that is the source of the TE tunnel. Other routers in the domain do not perform
a CBR calculation. The headend router provides information to the routers in the TE
tunnel path via RSVP signaling to request and confirm resource availability for the
tunnel. RSVP with extensions for TE reserves appropriate resources on each LSR in
the path defined by the headend router and assigns labels mapping to the TE tunnel
LSP.

The RSVP extensions to enable RSVP use for signaling in an MPLS environment to
implement TE are defined in Table 9-1. The functions of each of these
extensions/objects in the messages are also outlined.
Table RSVP Objects
Object Message Function
LABEL_REQUEST PATH Used to request a label mapping to the

TE tunnel or LSP; generated by the
headend router in the PATH message.
LABEL RESERVATION Used to allocate labels mapping to the

TE tunnel or LSP; generated by the
tailend router in the RESERVATION
message and propagated upstream.
EXPLICIT_ROUTE PATH Carried in PATH messages and is used

to either request or confirm a specific
path/route for the tunnel.
RECORD_ROUTE PATH, Similar to a record option with ICMP

RESERVATION ping. It is added to the PATH or
RESERVATION messages to notify
the originating node about the actual
route/path that the LSP TE tunnel
traverses.
SESSION_ATTRIBUTE PATH Used to define specific session

parameters local to the TE LSP tunnel.
During the path setup process for LSP TE tunnels, RSVP messages containing one or
more of these extensions are used to identify the significance of each message type
and its contents.
The path message contains the information outlined in Table
RSVP Objects in Path Message
Object Message
SESSION Defines the source and the destination of the LSP tunnel.
Usually identified by IP addresses of corresponding
loopback interfaces on headend and tailend routers.

RSVP Objects in Path Message
Object Message
SESSION_ATTRIBUTE Defines the characteristics of the specific LSP tunnel, such

as the bandwidth requirements and resources that would
need to be allocated to the tunnel.
EXPLICIT_ROUTE Populated by the list of next hops that are either manually
specified or calculated using constraint-based SPF. The
previous hop (PHOP) is set to the router's outgoing
interface address. The Record_Route (RRO) is populated
with the same address as well.
RECORD_ROUTE Populated with the local router's outgoing interface address

in the path of the LSP tunnel.
SENDER_TEMPLATE In addition to the previously mentioned attributes, the

sender template object in the path message depicts the
interface address that will be used as the LSP-ID for the
tunnel. This value is defined by the headend router.
The steps in the PATH and RESV message propagation in Figure are depicted here:
Step 1. The appropriate values for the fields mentioned in Table 9-1 applied by the
headend Router PE1-AS1 and the PATH message is sent to the next-hop
router in the LSP tunnel path.
Step 2. When P1-AS1 receives this PATH message, the router checks the
EXPLICIT_ROUTE object to see if the next hop is a directly connected
network. This is checked in the L-bit of the RSVP path message. If the L-bit
is set, the local router is not directly connected to the next hop in the LSP
tunnel path. Therefore, the router would perform a constrained-SPF
calculation to identify the next hop in the tunnel path.
If the L-bit is unset, the Router P1-AS1 knows that it is directly connected to
the next hop in the LSP tunnel path. It then removes all entries in the
EXPLICIT_ROUTE mapping to the local router (P1-AS1) and forwards the
PATH message to the next hop as defined in the EXPLICIT_ROUTE object.
In addition, P2-AS1 updates and appends the RECORD_ROUTE object to
depict the local outgoing interface in the path of the LSP tunnel. Figure 9-6
depicts the PATH message values as the PATH message is forwarded from
P1-AS1 to P2-AS1 after the appropriate values are updated. As previously
mentioned, P1-AS1 removes references to its local interface in the
EXPLICIT_ROUTE object and adds the outgoing interface in the
RECORD_ROUTE object.

RSVP PATH/RESERVATION Messages and Object Values

Step 3. The process is repeated at P2-AS1 in which references to its local interface in
the EXPLICIT_ROUTE object are removed and appends the outgoing
interface in the RECORD_ROUTE object.
Step 4. After the RSVP PATH message is received by the tailend Router PE2-AS1, it
triggers the creation of a RESERVATION message. The key concept to note
is that the label allocation process begins at the tailend router upon
generation of the RESERVATION message upstream. Therefore, when PE2-
AS1 generates a RESERVATION message, the router assigns a POP label to
the LSP tunnel (penultimate hop popping). The RESERVATION message
now has the RECORD_ROUTE object pointing to the outgoing interface on
the tailend router toward the headend router. Therefore, the
RECORD_ROUTE object is reinitiated in the RESERVATION message. The
values are depicted in Figure 9-6.
Step 5. When this reservation message reaches P2-AS1, the RECORD_ROUTE is

prepended with the outgoing interface and the local label mapping to the LSP
is also generated and mapped in the LABEL object. An arbitrary value of 3
has been depicted for this LABEL value in Figure 9-6.
Step 6. This process is again repeated on P1-AS1 and the RESERVATION message
is then received by PE1-AS1.
Step 7. When PE1-AS1 receives the RESERVATION message, the

RECORD_ROUTE identifies the traffic engineered LSP associated to a
specific bandwidth or resource requirement as defined in the SESSION
object. The labels mapped to the LSP are thus used as in regular MPLS in
which a local label is mapped to a next-hop label at each router that now
maps to an RSVP-learned TE LSP versus a normal LSP.

In the implementation of RSVP for MPLS TE, RSVP with extensions for TE requests
as well as confirms the LSP, reserves resources as requested on all LSP path routers,
and applies MPLS labels to form the MPLS LSP through the network. Note that the
routers store a copy of the PATH request as the request is forwarded to the next-hop
LSR. This information identifies the interface as reservation messages are received on
the same LSR to an egress interface to the headend router. In the next section, you
will be introduced to the constraint-based SPF calculation process and the need for a
link-state protocol to enable MPLS TE dynamically in a service provider core.
Constraint-Based Routing and Operation in MPLS TE
The most important requirement of TE is that the characteristics, as well as resource
availability, on links on the network (in addition to bandwidth that would be used for
cost computations) be propagated across the network to allow efficient choice of
possible TE LSP paths. In link-state routing protocols, the preferred path still
predominantly takes into consideration the bandwidth on the link between any two
routers to compute the cost or metric associated with that path, prior to preferred path
allocation. Enabling the use of link-state routing protocols to efficiently propagate
information pertaining to resource availability in their routing updates is performed by
additional extensions to the actual operation of the link-state routing protocol. The
mechanics of operation of a link-state routing protocol involves the flooding of
updates in the network upon link-state or metric change or, in better terms, bandwidth
availability from a TE perspective. The resource attributes are flooded by the routers
in the network to make them available by the headend router in the TE tunnel during
LSP path computation (dynamic tunnels). Link-state announcements carry
information that lists that router's neighbors, attached networks, network resource
information, and other relevant information pertaining to the actual resource
availability that might be later required to perform a constraint-based SPF calculation.
OSPF and IS-IS have been provided with extensions to enable their use in an MPLS
TE environment to propagate information pertaining to resource availability and in
dynamic LSP path selection.
Maximum Versus Available Bandwidth
Available bandwidth (AB) is a key value taken into consideration during the LSP path
computation process to identify the preferred path for the TE tunnel. The available
bandwidths on interfaces are configured on a priority basis. The number of priorities
that can be configured in conjunction with the available bandwidth is 8: 0–7, where 0
represents the highest priority. When the available bandwidth for a certain priority
level on an interface is configured, it is subtracted from the available bandwidth on
all priority levels below the one it is configured on.
If Router PE1-AS1 has a serial interface (T1-1.544 Mbps), 1 Ethernet interface (10
Mbps) and one Fast Ethernet interface (100 Mbps), the actual bandwidths on the
interfaces map to the maximum bandwidth (MB) values on the respective links. The
available bandwidth is usually the bandwidth of the required reservation subtracted
from the maximum bandwidth. However, this does not hold true if the available
bandwidth value on the link is configured to be higher than the maximum bandwidth
value on the link. Though the available bandwidth on the link can be configured to be
higher than the max-bandwidth value, reservations exceeding the maximum
bandwidth value are rejected.

When Router PE1-AS1 initially propagates information on the maximum bandwidth

and the available bandwidth on all its links, the values for the available bandwidth at
each priority level (P) for each link would be equal to their maximum bandwidth
values (1.544 Mbps for serial, 10 Mbps for Ethernet, and 100 Mbps for Fast Ethernet).
When a tunnel request is accepted and the bandwidth deducted from the available
bandwidth at a certain priority, it is also deducted from all the priorities lower than the
priority at which the resource request was performed. If an LSP tunnel creation on
PE1-AS1 consumes 40 Mbps of bandwidth on the Fast Ethernet interface at a priority
level of 5, the available bandwidth values at the appropriate priorities on the Fast
Ethernet interface would change for priorities 5 and above (100 – 40 = 60 Mbps).
Let us now consider the following sequence of requests:

1. Request for 10 Mbps of bandwidth on Ethernet interface at priority 1
2. Request for 20 Mbps of bandwidth on Fast Ethernet interface at priority 0
3. Request for 1 Mbps of bandwidth on serial interface at priority 0
4. Request for 2 Mbps of bandwidth on Ethernet interface at priority 3
This sequence will reduce the AB values, as depicted in Table 9-3.
PE1-AS1: Maximum Bandwidth and Available Bandwidth—All Interfaces
AB AB AB AB AB AB AB AB
P = 0 P = 1 P = 2 P = 3 P = 4 P = 5 P = 6 P = 7
Interface (Mbps) (Mbps) (Mbps) (Mbps) (Mbps) (Mbps) (Mbps) (Mbps)
Serial 1.544 - 1.544 - 1.544 - 1.544 - 1.544 - 1.544 - 1.544 - 1.544 -

1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 =
.544 .544 .544 .544 .544 .544 .544 .544
Ethernet 10 10 - 10 10 - 10 10 - 10 10 - 10 10 - 10 10 - 10 10 - 10
=0 =0 =0 =0 =0 =0 =0
Fast 100 - 100 - 100 - 100 - 100 - 60 - 20 60 - 20 60 - 20

Ethernet 20 = 80 20 = 80 20 = 80 20 = 80 20 = 80 = 40 = 40 = 40
The outputs of Table do not reflect the request for 2 Mbps of bandwidth on the
Ethernet interface at priority 3. This request is rejected due to unavailable bandwidth
at this priority level on the interface when the request is received. Link-state updates
pertaining to resource availability are flooded when the status of the link changes,
during manual reconfiguration of parameters mapping to the resource availability on
the link, periodic updates on links and their status, and when the LSP path setup fails
due to unavailability of requested resources for the LSP TE tunnel.
If the resources pertaining to the link change constantly, it will trigger update
generation, which clearly must be avoided. During the instant when the resources

pertaining to the links change constantly, the headend router might view the link as a
probable link in the LSP path. Therefore, this probable nonupdated link might be used
in path computation even though the link might not have the resources required for
LSP path setup. However, after LSP path computation when the LSP path
establishment is attempted, the router containing the link with the unavailable
resources generates an update with information affirming a lack of resources.
Thresholds can be set up on a per interface or link basis on a router whereby updates
are generated within a configured range of resource availabilities. Therefore, the
upper limit, as well as the lower limit, when an update will be generated on the router
containing the link, can be configured. For example, if the lower limit was configured
to be 50% of link bandwidth with steps at 60, 70, 80, and 90 with the upper limit
configured at 100%, updates with regards to link resource availability are generated
and flooded in the network when 50%, 60%, 70%, 80%, 90%, and 100% of
bandwidth are achieved.
Constraint-Based SPF
In the normal SPF calculation process, a router places itself at the head of the tree
with shortest paths calculated to each of the destinations, only taking into account the
least metric or cost route to the destination.
During regular SPF operation in the network, illustrated in Figure 9-7, only the cost is
taken into consideration, and the least cost path from a loopback on PE1-AS1 to a
loopback on PE2-AS1 is PE1-AS1->P1-AS1->PE2-AS1. In this calculation, a key
concept to note is no consideration to the bandwidth of the links on the other paths
from PE1-AS1 to PE2-AS1, namely via routers P3-AS1->P4-AS1 and P2-AS1. The
bandwidth of the links is shown as an ordered pair in Figure 9-7 with the first value
showing the cost of the link and the second showing the bandwidth across the link.
SPF
If the parameters chosen for the preferred path are not the least cost alone but also a
requirement to support a bandwidth of 50 Mbps in Figure 9-7, we can eliminate the

links that do not allow for the mentioned requirement. The network capable of
supporting the requirement would look like what's shown in Figure 9-8.
CSPF
With the just mentioned constraints, the only path capable of being used as an LSP for
TE is the path from PE1-AS1 to PE2-AS1 via P3-AS1 and P4-AS1. If any of the links
between P1-AS1, P2-AS1, and PE2-AS1 were to support a bandwidth more than the
requirement, they would become a part of the CSPF tree structure with Router PE1-
AS1 or the headend router as the root of the tree.
With CSPF, we use more than the link cost to identify the probable paths that can be
used for TE LSP paths. The decision as to which path is chosen to set up a TE LSP
path is performed at the headend router after ruling out all links that do not meet a
certain criteria, such as bandwidth requirements in addition to the cost of the link. The
result of the CSPF calculation at the headend router is an ordered set of IP addresses
that maps to the next-hop addresses of routers that form the TE LSP. Therefore,
multiple TE LSPs could be used by the use of CSPF to identify probable links in the
network that meet the criteria. In addition, the user can configure a static TE tunnel or
LSP on the headend router that outlines the next hops in the TE LSP path and,
therefore, can use the statically defined LSP as the backup LSP path in the event of
the primary TE LSP failing.
The result of the CSPF calculation is then passed over to the RSVP process to begin
the RSVP request and reservation process, as mentioned in the earlier section. RSVP
thus is used along with the result computed by CSPF or list of next hops configured
by the user for LSP signaling and final establishment of the TE LSP. Note the TE LSP
formed as a result of this process is unidirectional in nature.
Constraint-based SPF can use either administrative weights or IGP metric (also called
TE metric) during the constraint-based computation. In the event of a tie, the path

with the highest minimum bandwidth takes precedence, followed by the least number
of hops along the path. If all else is equal, CSPF picks a path at random and chooses
the same to be the TE LSP path of preference.
Therefore, the sequence of steps in the creation of an MPLS TE tunnel LSP in the
network is as follows:
Step 1. CSPF calculation is performed from the headend router based on the
constraints defined in the tunnel definition and requirements. This
calculation is performed by the IGP in use, either OSPF or IS-IS.
Step 2. After the LSP path is calculated using the CSPF process, the output of the
CSPF process, which is an ordered set of IP addresses mapping to next-
hop addresses in the TE LSP, is passed to RSVP.
Step 3. RSVP now performs the resource reservation request and confirmation on
the LSP, as defined by the CSPF process, to determine if the LSP meets
the requirements of the specific resources requested by the tunnel
definition.
Step 4. After the RSVP process receives a reservation message, it signals that the
LSP is now established.
Step 5. At this juncture, the TE tunnel is available for the IGP to use. By default,
the tunnel information is not added into the routing table; however, the
router can be configured so that the tunnel interface is added to the routing
table. You will be introduced to the configurations involved for TE on
Cisco routers in the next section.
Link admission control performs a check at each hop in the desired LSP path to see if
the resources requested are available prior to TE tunnel creation. The link admission
control function is performed on a per hop basis with each router in the LSP path
checking resource availability. If the requested resources are available, bandwidth is
reserved and the router waits for the RESERVATION message to confirm this
resource allocation. If, however, the resources requested are unavailable, the IGP in
use sends messages stating resource unavailability. Link admission control then
informs RSVP about lack of resources, and RSVP sends PATHERR messages to the
headend requesting the resources and notifying a lack of resources.
When setting up TE LSP paths in link admission control, it is important that the
priorities assigned to the available bandwidths are checked. Therefore, if the
requested bandwidth is in use by a lower priority session (priorities 0–7, with 0
having highest priority), the lower priority session can be preempted. If preemption is
supported, each preempted reservation leads to creation of PATHERR and RESVERR
messages because the preempted session no longer fits the profile of the resource
allocation.
OSPF Extension for MPLS TE
OSPF can be used as the link-state protocol of choice in MPLS TE for resource
allocation information flooding through the network by implementing OSPF

extensions or Opaque LSAs. The type of Opaque LSA in use is defined by the
flooding scope of the LSA. OSPF also now possesses TLV and sub-TLV attributes
that can be configured to propagate resource availability information in link-state
routing updates.
Opaque LSAs are of Type 9, 10, and 11 and differ in the flooding scope. Type 9 LSAs
are not flooded beyond the local subnet and are of link-local scope. Type 10 LSAs are
not flooded beyond the ABR and have an area-local scope. Type 11 LSAs are flooded
throughout the autonomous system (AS). Cisco currently supports only Type 10 LSAs
that have area-local scopes and are flooded within the area.
The Type 10 LSA, which is used in MPLS TE, has a number of TLV and sub-TLV
values that map to specific resources in a TE domain. Figure 9-9 depicts the TLV and
sub-TLV values and the appropriate values that they map to enable OSPF use for
MPLS TE.

OSPF TLV/Sub-TLV TE Extensions
The most important sub-TLV values pertaining to TE are 6, 7, and 8. Values for sub-
TLVs 6 and 7 are received from the RSVP configuration on the specific interface.
Sub-TLV 8 defines the bandwidth available for reservation on each of the eight
priorities. The value for sub-TLV 8 is received from the reservations active on the
specific interface.
IS-IS Extensions for MPLS TE
Similar to OSPF, IS-IS can also be used as the link-state protocol of choice in the TE
domain. IS-IS with extensions and newly defined TLVs can be used to propagate
information pertaining to resource allocation in an MPLS TE domain. The following
TLVs have been defined for the use of IS-IS as the link-state IGP in a MPLS TE
domain:
TLV22: Extended IS reachability— This TLV propagates information about
the state of links in the network and allows the use of "wide" metrics. In
addition, this TLV provides information on resource availability, like link
bandwidths.
TLV134: Router ID— This TLV is used to identify the router with a distinct
IP address, usually a loopback address. The source and destination IP
addresses used to identify and define the tunnel endpoints must match the
router ID.
TLV135: Extended IP reachability— This TLV uses "wide" metrics and
determines if a prefix is a level-1 or level-2 prefix. It also allows the flagging
of routes when a prefix is leaked from level 2 into level 1.
In addition to the just mentioned TLVs, sub-TLVs have been defined that affix
information pertaining to TE resource allocations to updates. Each sub-TLV consists
of three octets except those explicitly mentioned in Figure 9-10. Most of the sub-
TLVs are defined in draft-ietf-isis-traffic-xx.txt. Figure 9-10 depicts the TLVs and
sub-TLVs in use by IS-IS to support MPLS TE functionality.

IS-IS TLV/Sub-TLVs for MPLS TE
The key TLVs to note are Sub-TLV 6 and 8, which map to the tunnel endpoints or
source and destination IP addresses that are usually loopback addresses; Sub-TLV 9
and 10, which map to the RSVP settings on a specific interface; and Sub-TLV 11,
which maps to the unreserved bandwidth per priority on an interface after current
resource allocations for active sessions have been established.
Configuring MPLS TE
This section introduces you to the steps involved in the configuration of Cisco routers
to implement MPLS TE. The first subsection identifies the stepwise procedure
involved in the configuration of Cisco routers for TE. It is then followed by a
subsection depicting the actual configuration process on a topology consisting of six
routers in which multiple paths can be used for TE purposes from a headend to tailend
router.

MPLS TE Configuration Flowchart

The configuration of Cisco routers for MPLS TE support can be described in a
systematic flowchart as depicted in the top row of Figure..It is assumed that the
network is already configured with an IGP for NLRI exchange as well as MPLS
forwarding on the appropriate interfaces prior to performing the following steps:
Step 1. Configure a loopback interface for tunnel association to the TE tunnel, as

depicted in Figure
MPLS TE Configuration: Step 1
Step 2. The next step is the first configuration performed in relevance to enabling TE
on the Cisco router. Figure 9-12 outlines the configurations performed on the
Cisco router to enable TE functions globally on the router as well as interfaces
that are possible candidates to be chosen for TE LSP paths.
Step 3. Configure RSVP bandwidth parameters that will be used on the interface for
signaling purposes and resource allocation for traffic engineered sessions.
Figure outlines the configurations that need to be performed on the interface.

Figure 9-13. MPLS TE Configuration: Step 3
Step 4. After the interfaces that can be chosen to be a part of the LSP have been
enabled for TE as well as RSVP parameters configured, the next step is to
configure the tunnel interface. The main configurations of the tunnel interface
would be association of the tunnel interface IP address to the loopback address
configured earlier, the mode of the tunnel operation, and the destination
address of the tunnel endpoint, which would map to the IP address of a
loopback on the tailend router as well as the process by which the tunnel LSP
path is chosen. In this step, if the path chosen for the LSP is done using the
IGP and CSPF, the path option is chosen to be dynamic. Figure depicts the
configuration involved in setting up the tunnel interface.
Figure 9-14. MPLS TE Configuration: Step 4
Step 5. In addition to using the IGP for LSP path setup, the user can also define an
explicit-path that will be used for the TE LSP. This optional step can be
performed on the headend router so that the dynamic tunnel can be chosen to
be the tunnel of choice for traffic forwarding and the explicit-path tunnel or
user-defined static tunnel can be the backup path. In some cases, load
balancing can also be achieved between the two types. Figure depicts the
configurations to set up an explicit-path LSP.

Step 6. By default, the tunnel interface is not announced into the IGP for use in the
routing table. This will have to be configured explicitly for the tunnel interface
to be used as the next hop in the routing table by the IGP. Figure outlines the
configurations that will have to be performed on the headend router to enable
tunnel interface use as the next-hop address in the routing table for TE.
Step 7. The final step in the configuration of MPLS TE is the configuration of the IGP
for TE support. The IGP in use can be either OSPF or IS-IS. The IGP process
used for TE is the same as what's defined for NLRI reachability. The
configurations involved for enabling TE extensions for both these protocols
are outlined in Figure 9-17.

Configuring Dynamic Paths and Explicit Paths with MPLS TE

Figure outlines the layout of the devices in the network that will be used to configure
MPLS TE using dynamic and explicit paths. Prior to the following configurations, the
devices shown in Figure are configured with appropriate IP addresses on the
interfaces as well as OSPF as the IGP. In addition, MPLS forwarding has been
enabled on all interfaces in the network, as shown in Figure
MPLS TE Configuration Topology

The following steps show how to configure dynamic paths and explicit paths with
MPLS TE:
Step 1. Configure a loopback interface for tunnel association. This IP address can
be used as the router ID in the various processes on the router (see
Example
Configure Loopback Interface for Tunnel Association
PE1-AS1(config)#interface loopback 0
PE1-AS1(config-if)# ip address 10.10.10.101 255.255.255.255
Step 2. Enable TE globally on the router and per interface. Because we want the
headend router to take all links in the network as possible links for LSP
path setup, this interface-specific configuration is performed on all links in
the network topology shown in Figure. Only the configuration pertaining
to PE1-AS1 is shown in Example .
Enable TE on the Router and per Interface
PE1-AS1(config)#mpls traffic-eng tunnels
PE1-AS1(config)#interface serial 2/0
PE1-AS1(config-if)#mpls traffic-eng tunnels
PE1-AS1(config-if)#interface serial 3/0
Step 3. Configuring RSVP bandwidth parameters—Because we have chosen to

include all interfaces in the network topology to be considered for LSP
path setup, this configuration is performed on all interfaces. The chosen
RSVP bandwidth configured on all interfaces is 256 K with the maximum
that can be allotted to a single flow also 256 K. The configuration of
headend Router PE1-AS1 is shown in Example
Configure RSVP Parameters per Interface
PE1-AS1(config)#interface serial 2/0
PE1-AS1(config-if)#ip rsvp bandwidth 256 256

Step 4. Configuring tunnel interface parameters on the headend router—On

headend Router PE1-AS1, the tunnel destination is the loopback on Router
PE2-AS1 (10.10.10.103). First, dynamic tunnels are configured in which
the IGP performs a CSPF calculation and identifies the appropriate LSP
path. Therefore, the path-option for this tunnel creation would be
dynamic. The tunnel is defined with a priority of 1 and a bandwidth
requirement of 100 K. In addition, the tunnel is also provided a setup and
hold priority of 1 to define that this is the most preferred tunnel LSP in the
domain. See Example
Configure Tunnel Interface Parameters on PE1-AS1
PE1-AS1(config)#interface Tunnel0
PE1-AS1(config-if)# ip unnumbered Loopback0
PE1-AS1(config-if)# tunnel destination 10.10.10.103
PE1-AS1(config-if)# tunnel mode mpls traffic-eng
PE1-AS1(config-if)# tunnel mpls traffic-eng priority 1 1
PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 100
PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic
Step 5. Configuring dynamic tunnel announcement into IGP—In this step, the
tunnel interface is configured to be added into the IGP routing table to
enable traffic forwarding along the tunnel. See Example
Announce Tunnel Interface into IGP
PE1-AS1(config-if)#tunnel mpls traffic-eng autoroute announce
Step 6. Configure explicit-path tunnel—In this step, an explicit-path tunnel

named LSP1 is configured via P2-AS1 between PE1-AS1 and PE2-AS1.
Configure the tunnel interface with appropriate parameters. The tunnel is
configured with association to the same loopback address as used earlier
with the same destination address on PE2-AS1. The resource requirements
of the tunnel are also maintained. However, the tunnel priorities are
configured to be 2 versus 1 in the prior dynamic tunnel configuration so
that the dynamic tunnel is not chosen over the explicit tunnel for
establishing primary LSP. Also, the path-option maps to the name of an
explicit-path are configured on the headend router that maps to next-hop
addresses in the LSP path. See Example.

Configure Tunnel Interface on PE1-AS1

PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit

name LSP1
Step 7. Configure the explicit-path with next-hop IP addresses of routers in the

LSP path, as depicted in Example .
Configuration of Explicit LSP Path
PE1-AS1(config)#ip explicit-path name LSP1
PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.10
Explicit Path name LSP1:
1: next-address 10.10.10.10
3: next-address 10.10.10.103
Step 8. Configure the tunnel interface to be announced into IGP to be the preferred
path for traffic engineered traffic in the domain. See Example
Announce Tunnel Interface into IGP

PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce
Step 9. Enable IGP for MPLS TE—The configurations on Router PE1-AS1 to

enable OSPF for MPLS TE are shown in Example. The router ID
configured under the MPLS TE module in OSPF and IS-IS is the loopback
interface on the local router. This configuration needs to be performed on
all routers in the TE domain.
Configure IGP for MPLS TE
PE1-AS1(config)#router ospf 100
PE1-AS1(config-router)#mpls traffic-eng area 0
PE1-AS1(config-router)#mpls traffic-eng router-id loopback 0

Verification of MPLS TE Tunnel Creation
The following steps outline the various commands that can be entered on PE1-AS1
(after the just mentioned configuration) to determine if the TE tunnel has been created
successfully on the router (headend):
Step 1. Perform a show mpls traffic-eng tunnels brief on the headend Routers PE1-
AS1 and P1-AS1 in the LSP path, as well as the tailend Router PE2-AS1 to
verify the tunnel state is up/up. The output of the command also gives us
information on the LSP path in the tunnel setup. UP IF defines the upstream
interface for the tunnel, and DOWN IF defines the downstream interface for
the tunnel. See Example .
Example show mpls traffic-eng tunnels brief on Tunnel LSP Path Routers
PE1-AS1#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3206 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 206 seconds

TUNNEL NAME DESTINATION UP IF DOWN IF

STATE/PROT
PE1-AS1_t0 10.10.10.103 - Se3/0 up/up
PE1-AS1_t1 10.10.10.103 - Se2/0 up/up
Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails
________________________________________________________________
______________
P1-AS1#show mpls traffic-eng tunnels brief
Signalling Summary:
Forwarding: enabled

STATE/PROT
PE1-AS1_t0 10.10.10.103 Se2/0 Se4/0 up/up
Displayed 1 (of 1) heads, 1 (of 1) midpoints, 0 (of 0) tailsPE2-AS1#show mpls

traffic-eng tunnels brief
Signalling Summary:
Forwarding: enabled


STATE/PROT
PE1-AS1_t0 10.10.10.103 Se3/0 - up/up
PE1-AS1_t1 10.10.10.103 Se2/0 - up/up
Step 2. A view of the actual parameters of the tunnel can be retrieved by performing a
show mpls traffic-eng tunnels destination ip-address (only Tunnel 0 depicted
in Example ) or a show mpls traffic-eng tunnels tunnel interface-number. As
illustrated in Example , the output shows the status of the tunnel and the
information about the parameters associated with the tunnel. In addition, it
shows the preferred path chosen by the CSPF process under the explicit-path
field in the output of the command, as shaded in Example
Example MPLS TE Verification: Tunnel Parameters
PE1-AS1#show mpls traffic-eng tunnels destination 10.10.10.103
Name: PE1-AS1_t0 (Tunnel0) Destination: 10.10.10.103
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 20)
Config Parameters:
Bandwidth: 100 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : Serial3/0, 26
RSVP Signalling Info:
Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71

RSVP Path Info:
My Address: 10.10.10.101
Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103
Record Route: NONE
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
History:
Tunnel:
ime since created: 3 hours, 42 minutes
Time since path change: 33 minutes, 26 seconds
Current LSP:
Uptime: 33 minutes, 26 seconds
PE1-AS1#show mpls traffic-eng tunnels tunnel 0
Name: PE1-AS1_t0 (Tunnel0) Destination: 10.10.10.103
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 20)
Config Parameters:
Bandwidth: 100 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based

Au
to-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : Serial3/0, 26
RSVP Signalling Info:
Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71
RSVP Path Info:
My Address: 10.10.10.101
Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103
Record Route: NONE
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103
History:
Tunnel:
Time since created: 3 hours, 42 minutes
Time since path change: 33 minutes, 47 seconds

Current LSP:
Uptime: 33 minutes, 47 seconds
Step 3. Verify that the next hop to the destination IP address points to the tunnel
interfaces in the IGP routing table. Only routes to network 10.10.10.103
(destination) pointing to the tunnel interface as the next hop are shown for
brevity. See Example 9-12. Because we have two tunnels configured on Router
PE1-AS1 (dynamic and explicit) with the same parameters, the traffic to
destination 10.10.10.103 is load balanced equally among the two paths, as
shown in, because the bandwidths configured on the TE tunnels are the same.
Traffic from PE1-AS1 to PE2-AS1 is equally load balanced across the two
tunnels.
Example. Verify Next-Hop Mapping to Tunnel Interface (Truncated)
PE1-AS1#show ip route 10.10.10.103
Routing entry for 10.10.10.103/32
Known via "ospf 100", distance 110, metric 97, type intra area
Routing Descriptor Blocks:
directly connected, via Tunnel0
Route metric is 97, traffic share count is 1
Step 4. By performing an extended ping to the destination loopback address on PE2-

AS1, we see that the packets are load balanced across the two tunnel paths. See
Example
Example Extended Ping Verification for MPLS TE Tunnel Path
PE2-AS1#ping
Protocol [ip]:
Target IP address: 10.10.10.103
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y

Source address or interface: 10.10.10.101
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]: 4
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 10.10.10.103, timeout is 2 seconds:
Reply to request 0 (28 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(10.10.10.103)
(10.10.10.6)
(10.10.10.2)
(10.10.10.101) <*>
End of list
Reply to request 1 (28 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(10.10.10.103)
(10.10.10.14)

(10.10.10.10)
(10.10.10.101) <*>
End of list
Final Configurations for Dynamic and Explicit Tunnels with MPLS TE
Example and Example outline the final configurations for all devices in Figure for
implementation of dynamic and explicit tunnels from PE1-AS1 to PE2-AS1.
Example Final Configurations for PE1-AS1 and PE2-AS1 to Implement Dynamic
and Explicit Tunnels
hostname PE1-AS1
ip cef
mpls traffic-eng tunnels
interface Loopback0
ip address 10.10.10.101 255.255.255.255
interface Tunnel0
ip unnumbered Loopback0
tunnel destination 10.10.10.103
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng path-option 1 dynamic
tunnel MPLS traffic-eng bandwidth 100
interface Tunnel1

tunnel mpls traffic-eng path-option 1 explicit name LSP1
tunnel MPLS traffic-end bandwidth 100
interface Serial2/0
ip address 10.10.10.9 255.255.255.252
tag-switching ip
fair-queue 64 256 48
ip rsvp bandwidth 1000
interface Serial3/0
ip address 10.10.10.1 255.255.255.252
mpls ip
interface Serial4/0
ip address 10.10.10.17 255.255.255.252
MPLS ip

router ospf 100
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
network 10.0.0.0 0.255.255.255 area 0
ip explicit-path name LSP1 enable
next-address 10.10.10.10
end
hostname PE2-AS1
ip cef
interface Loopback0
ip address 10.10.10.103 255.255.255.255
interface Serial2/0
ip address 10.10.10.14 255.255.255.252

mpls ip
interface Serial3/0
ip address 10.10.10.6 255.255.255.252
mpls ip
interface Serial4/0
ip address 10.10.10.22 255.255.255.252
mpls ip
router ospf 100
network 10.0.0.0 0.255.255.255 area 0
end
Example 9-15. Final Configurations for P1-AS1, P2-AS1, and P3-AS1 to Implement
Dynamic and Explicit Tunnels
hostname P1-AS1

ip cef
interface Loopback0
ip address 10.10.10.102 255.255.255.255
interface Serial2/0
ip address 10.10.10.2 255.255.255.252
mpls ip
interface Serial3/0
ip address 10.10.10.26 255.255.255.252
mpls ip
interface Serial4/0
ip address 10.10.10.5 255.255.255.252
mpls ip

router ospf 100
network 10.0.0.0 0.255.255.255 area 0
end
hostname P2-AS1
ip cef
interface Loopback0
ip address 10.10.10.104 255.255.255.255
interface Serial2/0
ip address 10.10.10.10 255.255.255.252
MPLS ip
interface Serial3/0
ip address 10.10.10.13 255.255.255.252
mpls ip

router ospf 100
network 10.0.0.0 0.255.255.255 area 0
end
hostname P3-AS1
ip cef
interface Loopback0
ip address 10.10.10.105 255.255.255.255
interface Serial2/0
ip address 10.10.10.18 255.255.255.252
mpls ip
interface Serial3/0
ip address 10.10.10.25 255.255.255.252

no ip directed-broadcast
mpls ip
interface Serial4/0
ip address 10.10.10.21 255.255.255.252
mpls ip
router ospf 100
network 10.0.0.0 0.255.255.255 area 0
!
end
Unequal Cost Load Balancing Across Multiple TE Tunnels

In this section, we will configure another tunnel via the path PE1-AS1, P3-AS1, and
PE2-AS1 with bandwidth requirements of 50 kbps versus 100 kbps. In every five
packets, load balancing is performed so that two packets are sent on Tunnel 0, two on
Tunnel 1, and one packet on Tunnel 2. In this case, if the source and destination of the
tunnel interfaces are the same, the traffic between the sites performs unequal cost load
balancing among the various tunnels between Routers PE1-AS1 and PE2-AS1. The
configuration on PE1-AS1 (headend router) for another explicit LSP path setup via
the path PE1-AS1, P3-AS1, and PE2-AS1 is shown in Example
Example Unequal Cost Load Balancing Configuration on PE1-AS1

PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce
PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name LSP2
PE1-AS1(config)#ip explicit-path name LSP2 enable
PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.18
3: next-address 10.10.10.103
PE1-AS1(cfg-ip-expl-path)#end
After the configuration is performed, the output of the routing table entry for
10.10.10.103/32 shows the unequal cost load balancing in effect (see Example).
Example. Verification of Unequal Cost Load Balancing
PE1-AS1#show ip route 10.10.10.103
Routing entry for 10.10.10.103/32
Known via "ospf 100", distance 110, metric 97, type intra area
Routing Descriptor Blocks:

* directly connected, via Tunnel0
Therefore, the final configuration for PE1-AS1 includes, in addition to Example 9-14,
the configuration shown in Example.
Example . Additional Configuration on PE1-AS1 for Unequal Cost Load
Balancing
interface Tunnel2
tunnel mpls traffic-eng bandwidth 50
tunnel mpls traffic-eng path-option 1 explicit name LSP2
MPLS TE Fast ReRoute Link Protection

Fast ReRoute (FRR) is a procedure used in conjunction with MPLS TE to reroute
around a link in the case of link failure. Protection in networks can be provided by
SONET, optical protection, or, more recently, MPLS FRR. With MPLS FRR, we can
implement both link and node protection. In addition, different protection policies can
be applied to different classes of traffic traversing the MPLS backbone. In FRR
operation, a backup tunnel is configured to be used if the primary tunnel LSP fails.
The backup tunnel must be configured so that the LSP can get to the next-hop LSR
downstream without attempting to use the failed link.
The configuration for implementing FRR for link protection is simple to implement.
If you use a subset of the network shown in Figure 9-18 to implement link protection,
as illustrated in Figure 9-19, you can configure a backup tunnel on the LSR P1-AS1.
If the primary tunnel from PE1-AS1 via P1-AS1 to PE2-AS1 fails due to link failure
between P1-AS1 and PE2-AS1, the backup tunnel is used to forward traffic.

Figure MPLS FRR Network Topology, Configuration, and Verification
Configuration of the tunnel (Tunnel0 on PE1-AS1) to be protected from a link failure

includes the tunnel mpls traffic-eng fast-reroute command under the tunnel
interface configuration on the headend router (PE1-AS1) to enable FRR protection on
the tunnel. In addition, a backup tunnel, Tunnel100, is configured on the downstream
LSR (in our case, P1-AS1) to reroute traffic if the link between P1-AS1 and PE2-AS1
fails. Configuration is performed following the procedure shown in the earlier
sections with an explicit path from P1-AS1 to PE2-AS1 via P3-AS1. Finally, this
tunnel (Tunnel100) on P1-AS1 is associated to the link to be protected by using the
command mpls traffic-eng backup-path tunnel tunnel100 under the interface to be
protected (Serial 4/0 on P1-AS1).
Verification of FRR capabilities can be performed by issuing the show mpls traffic-
eng fast-reroute database detail command on the downstream LSR configured with
a backup tunnel, as shown in Figure .
Implementing MPLS VPNs over MPLS TE
MPLS was initially adopted due to its inherent properties to deliver VPNs. However,
in recent years, MPLS TE has gained popularity due to the robust TE capabilities it
provides. In this section, we will discuss the configurations involved in the
implementation of MPLS VPN over TE tunnels. TE tunnels can be configured
between PE to PE routers as well as from PE to provider core or P routers. The
configurations involved in both of these implementations of MPLS TE in the provider

core are introduced. The network used to implement MPLS VPN over TE tunnels is
shown in Figure
MPLS VPN Over TE Network Topology/Configuration
For simplicity, the OSPF PE-CE connectivity implementation is used on both PE

Routers PE1-AS1 and PE2-AS1 in Figure. For this section, the IGP used in the core is
OSPF with process-id 100. The process-id for the PE to CE connections is configured
under OSPF 1. All networks are in area 0.
The configurations on Routers P1-AS1, CE1-A, and CE2-A are illustrated in Figure
9-20. Configurations for PE1-AS1 and PE2-AS1 are illustrated in Example 9-19. A
tunnel is already configured with a dynamic path-option between PE1-AS1 and PE2-
AS1.
PE1-AS1 and PE2-AS1 Configuration: MPLS VPN Over TE with PE to PE Tunnels
hostname PE1-AS1
ip cef
ip vrf VPNoverTE
rd 1:100

interface Loopback0
ip address 10.10.10.101 255.255.255.255
interface Tunnel0
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 1 dynamic
interface Serial2/0
ip vrf forwarding VPNoverTE
ip address 172.16.1.1 255.255.255.252
interface Serial3/0
ip address 10.10.10.1 255.255.255.252
mpls ip
ip rsvp bandwidth 256 256

router ospf 1 vrf VPNoverTE
redistribute bgp 100 metric 10 subnets
network 172.16.1.0 0.0.0.3 area 0
router ospf 100
network 10.10.10.0 0.0.0.3 area 0
network 10.10.10.101 0.0.0.0 area 0
router bgp 100
bgp router-id 10.10.10.101
no auto-summary
exit-address-family
address-family ipv4 vrf VPNoverTE
redistribute ospf 1 vrf VPNoverTE metric 2
exit-address-family

end
hostname PE2-AS1
ip cef
ip vrf VPNoverTE
rd 1:100
interface Loopback0
ip address 10.10.10.103 255.255.255.255
interface Serial3/0
ip address 10.10.10.6 255.255.255.252
mpls ip
ip rsvp bandwidth 256 256
interface Serial4/0
ip vrf forwarding VPNoverTE
ip address 172.16.2.1 255.255.255.252

router ospf 1 vrf VPNoverTE
redistribute bgp 100 metric 2 subnets
network 172.16.2.0 0.0.0.3 area 0
router ospf 100
network 10.10.10.4 0.0.0.3 area 0
network 10.10.10.103 0.0.0.0 area 0
router bgp 100
bgp router-id 10.10.10.103
exit-address-family
address-family ipv4 vrf VPNoverTE
redistribute ospf 1 vrf VPNoverTE metric 2
exit-address-family
end

Verification of MPLS VPN over TE with PE to PE Tunnels

Outlines the various verification steps for identifying the operation of MPLS VPNs
over TE with PE to PE tunnels.
MPLS VPN over TE Verification—PE to PE Tunnels
Figure illustrates the routing tables on CE routers in which the CE routers learn the
routes from the remote CEs via the MPLS backbone and place them in their local
routing tables as OSPF IA routes, though all CE routes are in area 0 because sham-
links are not configured.
Figure also shows the routing table on the respective PE routers for the VRF
VPNoverTE to check for route propagation in the MPLS VPN domain. As can be
derived from the output, the appropriate VPN routes obtained from the remote CEs
are learned from the next hop that maps to the remote PE loopback.
A closer look at the prefix 172.16.1.102 (loopback0 on CE2-A), learned across the
MPLS domain one PE1-AS1, indicates a next-hop address of the remote PE loopback
10.10.10.103 (lo0 on PE2-AS1). In the global routing table, if this VPN forwards
traffic over the MPLS TE tunnel configured on PE1-AS1, the next-hop address of
10.10.10.103 must point to the tunnel interface (Tunnel0) as shown in Figure 9-21 by
the output of show ip route 10.10.10.103 on PE1-AS1. In addition, note that in the
label-stack imposed on the packets in the MPLS domain when implementing MPLS
VPN over TE (one label for MPLS VPN and the top label for TE), the top label maps
to the label assigned by RSVP for the traffic engineered LSP path. Therefore, the out-
label value in the output of show MPLS traffic-eng tunnels tunnel0 (16) maps to the

top label in the label stack, as highlighted in the output of show ip cef vrf
VPNoverTE 172.16.1.102 in Figure
For final verification of connectivity, an extended ping is performed between

loopback interfaces on CE routers, as shown in Figure .
Configuration of MPLS VPN over TE with PE to P Tunnels
In the preceding section, MPLS VPN was configured over TE tunnels in which the
TE tunnel was configured between the two PE routers in the MPLS domain. Another
possibility that might arise while deploying MPLS VPN over a TE enabled domain is
a tunnel existing between a PE router and a provider core router. In our existing setup,
the tunnel interface, Tunnel 0, configured on the PE Router PE1, is changed so that
the destination of the tunnel is the loopback address on P1 or 10.10.10.102/32 (see
Example ). This configuration might be used in conjunction with FRR to enable link
protection in the SP backbone for MPLS forwarded traffic belonging to a customer.
Example Configuration on PE1-AS1: Tunnel Destination Changed to
10.10.10.102/32
PE1-AS1(config)#interface tunnel 0

If no other changes in configuration are made on any router, the CE routers no longer
have connectivity to one another because the LSP is broken, as shown in Example
Example CE1-AS1 Cannot Reach CE2 Because LSP Is Broken
CE1-AS1#ping 172.16.1.102 source 172.16.1.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.102, timeout is 2 seconds:
Success rate is 0 percent (0/5)
To enable a complete LSP, MPLS is enabled on the tunnel interface on PE1-AS1.
Also, P1-AS1 is configured to accept directed hellos, as shown in Example
Example Enabling MPLS on the Tunnel Interface and Configuring Directed-
Hello Accept on P1-AS1
PE1-AS1(config)#interface tunnel 0
PE1-AS1(config-if)#mpls ip
P1-AS1(config)#mpls ldp discovery targeted-hello accept
Because the P1-AS1 router can accept directed hellos from neighbors who are not
directly connected, the LSP is now established using the tunnel. This is shown in
Figure where the next hop for the remote CE loopback interfaces point to the interface
tunnel 0 on PE1-AS1.

MPLS VPN Over TE Verification—PE to P Tunnels
Connectivity between CE routers is verified using extended pings between loopback

interfaces on CE routers, as shown in Figure
Command Reference
Command Description
Router(config)#mpls traffic-eng tunnels Configures TE support on router in

the global configuration mode.
Router(config-if)#mpls traffic-eng tunnels Configures MPLS TE support per

interface.
Router(config-if)# ip rsvp bandwidth Configures RSVP bandwidth on the

{reservable bandwidth 1-10000000 kbps} interface-reserved bandwidth with the
{maximum reservable bandwidth per flow 1- largest reservable bandwidth/flow.
1000000 kbps}
Router(config)#interface tunnel {number} Configures tunnel interface.
Router(config-if)#ip unnumbered loopback Configures the loopback interface IP

{number} address to be associated with the
tunnel interface under tunnel interface
configuration.

Command Description
Router(config-if)#tunnel mode mpls traffic- Configures the tunnel mode to be an

eng MPLS traffic-engineered tunnel.
Router(config-if)#tunnel destination {IP Configures the MPLS traffic-

address of remote loopback} engineered tunnel's destination or end-
point.
Router(config-if)#tunnel mpls traffic-eng Configures the LSP path setup to be

path-option {priority} dynamic [bandwidth done by IGP and CSPF (dynamic LSP
{override bandwidth config value} | attributes tunnel creation). The tunnels can be
{lsp attribute list name} | lockdown] configured with the associated priority
and attributes.
Router(config)# ip explicit-path name Configures an explicit path to be

{name} enable associated with a TE tunnel.
or
Router(config)# ip explicit-path identifier

{number} enable
Router(cfg-ip-expl-path)#next-address {ip- Configures the IP next-hop addresses

address} for the explicit MPLS traffic
engineered tunnel.
Router(cfg-ip-expl-path)#exit
Router(config-if)#tunnel mpls traffic-eng Defines the priority of the tunnel

priority {setup priority-value} {hold-priority (used in load balancing).
value}
Router(config-if)#tunnel mpls traffic-eng Configures tunnel interface to be

autoroute announce announced into IGP routing table
(configured under tunnel interface
configuration).
Router(config-router)#mpls traffic-eng area Enables OSPF for TE (under router

number OSPF configuration).
Router(config-router)#mpls traffic-eng Configures the router ID for the TE

router-id interface number process under OSPF or IS-IS.
Router(config-router)#mpls traffic-eng level Configures IS-IS Level1/Level2

[1 | 2] domains for TE.

Command Description
Router(config-router)#metric-style wide Configures IS-IS to accept and use

enhanced TLVs (wide metrics).
Router(config-if)# tunnel mpls traffic-eng Enables the MPLS tunnel for FRR
fast-reroute protection.
Router(config-if)# mpls traffic-eng backup- Configures the backup tunnel to be

path tunnel {interface-number} used during interface failure.

LAYER 3 VPN SERVICES
Layer 3 VPN Services
Layer 3 VPN is without doubt the MPLS application that has caused the most ink to
flow. RFC 2547 proposes a peer architecture in which customer edge (CE) routers
exchange routes with service provider edge routers (universally called PE, for
provider edge). Unlike a Frame Relay or ATM VPN service, there are no point-to-
point connections between customer sites.
Figure shows an MPLS-VPN reference architecture, with two different VPNs.

Customer sites have a CE router that connects to service provider PE routers. PE
devices are connected by LSRs. A single PE can peer with CEs that belong to
different customers, as is the case for PE A. To provide backup routes, a CE can also
peer with different PEs that belong to the same, or even to different, service providers.
Sites in a VPN can communicate only with other sites in the same VPN. Standard IP
traffic runs over the CE-PE link, so this link cannot be shared with other customer
traffic. (By the way, that is a very important point: The CE and PE do not exchange
labels, or labeled packets.) This is identical to existing Layer 2 VPN networks, so an
MPLS-VPN service requires no architecture change to the customer's network.
MPLS-VPN Reference Architecture
Even though each site has just one link into the service provider cloud, thanks to the
MPLS-VPN architecture, there can be a full-mesh connectivity between the sites. In
fact, the intersite IP topology can be of arbitrary complexity. MPLS-VPN
implementations default to full mesh and must be constrained to provide a more
hierarchical connectivity model, such as hub and spoke.
The MPLS-VPN model makes it easier to route between CEs, compared to the costly
approach of using dedicated WAN connections between sites and the relative

difficulty of routing effectively over such point-to-point networks.
For CEs to communicate, the service provider needs to exchange (private and
possibly overlapping) customer IP routes and carry packets to those routes across its
network. MPLS provides a solution that supports customer address-space
independence using a forwarding mechanism that uses a two-label hierarchy in which
the inner label identifies the VPN and the outer label identifies the destination PE
device. RFC 2547 mandates the use of the Border Gateway Protocol (BGP) to
exchange prefixes and labels between PE devices and introduces some new attributes
to provide this functionality.
Speaking of BGP, how are customer routes advertised in an MPLS-VPN network?

Figure 4-13 shows that several different routing protocols are used. The following
sequence explains the operation behind Figure
Routing in an MPLS VPN Network
CE red1 advertises the 192.168.4.0/24 prefix to PE A. A CE can use static or dynamic

routing (RIP, eBGP, or OSPF) to exchange routes with a PE. CE red1 runs eBGP. CE
green2 uses RIPv2.
PE A imports the prefixes announced by the CE into the route table for this VPN. If
other interfaces on the same PE belong to the same VPN, routes are announced to the
local peers. Each VPN has its own routing table.
PE A uses iBGP to announce reachability for each of its attached customer sites. In
Figure PE A has one iBGP session with PE C for the red VPN and another with PE D
for the green VPN. PE C imports the routes into the routing table used for the red
VPN, and PE D imports the routes for the green VPN. The PEs are in a full iBGP
mesh and each can run many different VPNs.
PE C announces the 192.168.4.0 route to CE red2 using RIPv2. A show ip route

command on CE red2 will show 192.168.4.0/24 with a next hop of 192.168.2.1,

which is the address of PE C. Similarly, CE red1 has an entry for 192.168.3.0 with a
next hop of 192.168.1.2. PE A's routing table for the red VPN has an entry for
192.168.4.0 through 192.168.1.1 and another entry for 191.168.3.0 with a next hop
that points to PE C. This is where the MPLS-VPN magic occurs. PE C announces
itself as the next hop for the 192.168.3.0 route. Because this is a BGP route, PE A will
use another lookup to find the route and, this time, the next hop will be 10.0.0.2,
which is the LSR.
When traffic must go between sites, the CE forwards IP packets to the PE as it would
to any other router. Figure shows a packet going from CE green1 to CE green2,
following this sequence:
PE A identifies the next hop (PE D) for this packet as a BGP neighbor.
PE A first imposes a label, 22, that will identify the VPN routing table to PE D. This
label was advertised by the neighbor, PE D, during the exchange of BGP prefixes,
which happened some time before the preceding step.
The packet must now travel across the MPLS network, so PE A imposes another
label, 96, that identifies the next-hop LSR on the IGP path to PE D. This label was
advertised by the downstream LSR (LSR B) from 10.0.0.2.
Each LSR in the core swaps labels and forwards the packet as normal toward PE D.
The penultimate hop pops the outer label. In Figure 4-14, there is only one hop to the
egress LSR, so LSR B removes the outer label.
PE D uses the remaining label, 22, to identify which VPN routing table to use for the
packet, and then pops the label from the packet.
PE D does an IP lookup in the VPN routing table to find the outgoing interface and
then forwards the IP packet to CE green2, which will route it to its destination.
Packet Flow in MPLS-VPN Network

It is very important to understand that the LSRs have no visibility of the VPN traffic.
They forward labeled traffic along LSPs established by whatever routing protocol is
running in the service provider core. Of course, this IGP can be completely different
from the IGPs running on the CE-PE links.
MPLS-VPN Attributes
Defining an MPLS VPN is harder than you might expect. For the longest time, the
Cisco IOS implementation had no single number or string that would define a VPN in
a network. Fortunately, a VPN ID has since been introduced to address this problem.
Note that every VPN on a Cisco router has the following attributes:
Dedicated interfaces, which can be logical or physical
Dedicated routing table
A local name and, optionally, a numeric ID
Rules that determine how VPN routes are advertised to peer routers
Route reachability within an MPLS VPN is established through the selective import
of BGP routes. Several new extended attributes have been added to BGP in
accordance with the specifications in RFC 2547. Figure shows how PEs exchange
these attributes.
iBGP Attribute Exchange
The following are the most important BGP attributes:

route-target Each PE defines a numeric value, called a route-target, that is associated

to all the routes it exports to its BGP peers. PEs also define another value used to filter
incoming routes. In order for a route to be accepted, the route-target export value must
match the import value at the receiving device. Note that the import and export values
do not have to match, which allows topologies other than full mesh to be defined. The
route-targets are carried in BGP updates. In Figure, PE A uses 100:1 for both export
and import route-targets. PE C uses the same values, so routes from the red VPN sites
will be exchanged between these two routers.
route-distinguisher A BGP attribute that is appended to private routes to make them

globally unique. Consider a case in which two networks each use the 10.0.0.0/24
prefix and connect to the same service provider PE. The PE uses different virtual
routing tables because the prefixes belong to different customers, so there is no
conflict in address space when importing the routes into the service provider network.
Now every PE that connects to a CE in the customer's VPN must receive reachability
information for the 10.0.0.0/24 prefix. The PE announces the route to all its PE peers,
but only those with the same VPN and matching route-target import it. The route-
distinguisher (RD) is included in the routing exchange to make sure that each BGP
peer treats the prefixes as belonging to different networks. Returning to Figure , the
red VPN uses an RD of 100:1; the green VPN is configured for 200:1. Although not
necessary, having the same RD throughout a VPN is better, for operational simplicity.
MPLS-VPNs require private routing tables in each VPN so that they can peer with the
CEs in the different domains. In Cisco jargon, these are called VRFs, as shown in
Figure , and the standard routing table is called the global routing table. In the
example given that described the operation of Figure, the VPN routing tables
referenced in the text are VRFs.
VRFs
VRFs are populated by routing processes associated with each VPN. Note that in

other implementations, separate processes run in each VPN, but Cisco IOS does a mix
of both. BGP, for example, is a single process across the whole router, but there are
independent OSPF processes for each VPN. LFIBs are populated using information
from VRFs.
Even though each VPN on a PE router has its very own VRF, no VRFs are required
on CE routers. (There is an optional exception to this called, rather unimaginatively,
multi-VRF CE, but the basic RFC 2547 scenario requires no such thing.)
MPLS-VPN Cisco IOS Configuration
This section gives the extracts necessary to deploy a simple MPLS VPN. Example is
the configuration of a PE. The underlying network topology is the same as used in the
examples in Chapter .
Example 4-3. MPLS-VPN PE Configuration
! Define a VRF for the VPN with route-target and r-ds
! R-T 101:1 is used for both import and export
ip vrf RED
rd 101:1
route-target both 101:1
interface Loopback0
ip address 12.0.0.3 255.255.255.255
! Add each CE-PE link to the VRF
! Remember the IP address must be added after the VRF name
interface Ethernet1/0/0
ip vrf forwarding RED
ip address 11.1.4.1 255.255.255.255
! Core facing links
interface FastEthernet0/0/0
ip address 192.168.1.3 255.255.255.0

tag-switching ip
full-duplex
no cdp enable
! Configure iBGP to the 2 remote PEs
router bgp 101
address-family ipv4 vrf RED
redistribute static
no auto-summary
no synchronization
exit-address-family
exit-address-family

Example shows the first PE configuration. There are three basic sections. The first
global command sets up a VRF for the VPN, with some name, route-distinguisher,
and route-target values. Then, every CE-PE link needs to be added to the VRF. There
is no VRF on core-facing links, which simply do label switching. The final section is
iBGP, which in this example established two sessions to peers at 12.0.0.1 and
12.0.0.2. Each VPN has its own address-family configuration, where you can
configure which networks to announce and so forth. The VPNv4 address-family
establishes the peers as being MPLS-VPN savvy, so BGP peers understand the
necessary extended communities.
Example gives the LSR configuration, which, as you can see, is very straightforward.
Example MPLS LSR Configuration
! Core facing links
ip address 192.168.1.4 255.255.255.0
tag-switching ip
full-duplex
no cdp enable
ip address 192.168.4.2 255.255.255.0
tag-switching ip
full-duplex
no cdp enable
Example gives the PE Configuration at the other side of the network.
Example MPLS-VPN Egress PE Configuration
! Route-target and RD values must match. VRF names don't have to
! but better if it does
ip vrf RED
rd 101:1

interface Loopback0
ip address 12.0.0.1 255.255.255.255
! egress CE-PE link
interface Ethernet1/0/0
ip vrf forwarding RED
ip address 11.2.4.1 255.255.255.255
! Core facing links
ip address 192.168.4.1 255.255.255.0
tag-switching ip
full-duplex
no cdp enable
router bgp 101
address-family ipv4 vrf RED
redistribute static
no auto-summary
no synchronization

exit-address-family
exit-address-family
Note
ping, telnet, and traceroute have VRF options so that they can be used between PEs.
Why don't the standard commands work? Remember that a VRF represents an
entirely private routing space. Commands issued from the Cisco IOS command line
use the global routing table. On a PE, this means that all the LSRs are reachable, but
no device in a VPN address space is. Therefore, these commands need a new
parameter to tell the router which VPN to originate a ping in, for example. Of course,
a ping within a VRF, or from any CE, will not see any LSR, because those are in a
different address space. This makes sense enough in theory, but can take some getting
used to in practice.
MPLS-VPN architecture provides full-mesh configuration by default. In other words,

a PE forwards traffic directly to its destination. It turns out that some enterprise
networks need to change this behavior. A common reason is a security policy that
requires all sites in a certain area to forward traffic through a regional hub, which
might have some expensive virus-checking package for e-mail, or perhaps needs to do
NAT on traffic between sites. Whatever the reason, MPLS VPNs can be deployed as
hub-and-spoke topologies by using route-targets.
If a spoke imports routes only from a hub, then traffic will in turn flow through the
hub to get somewhere else. (Remember, PEs forward to BGP next hops.) Because a
hub must know all the routes, it imports from all spokes. Spokes must never import
from each other. This scenario is shown in Figure, with correct use of route-targets.
Figure Hub-and-Spoke Topology

Examples through show how to configure the route-targets to match the figure.
Example PE A Hub
!Hub imports from Spokes
vrf green
rd 200:1
Example PE B Spoke
!All spokes import from Hub
vrf greenrd 100:1route-target import 200:1route-target export 100:1
Example PE C Spoke
!And export to Hub
vrf greenrd 100:1route-target import 200:1route-target export 100:1
Although the details will not be provided here, route-targets are also used to build
extranets. An extranet is a VPN with limited reachability of destinations inside other
VPNs.


NMS, EMS , OSS / BS , QOS IN NIB II PROJECT-3

NMS, EMS , OSS / BS , QOS IN NIB II PROJECT-3
GENERAL
BSNL has planned to setup NIB-II to provide world class infrastructure to offer
various value added services to a broader customer base county-wide that will help to
accelerate the Internet revolution in India. Moreover the NIB-II will create a platform,
which enables e-governance, e-banking, e-learning, etc. with the key point of Service
Level Agreements & Guarantee in tune with Global standards and customer
expectations.
NIB-II has been grouped into following three major projects.
Project 1: - MPLS based IP Network infrastructure covering 71 cities along

with associated NMS, PMS, Firewall and Caching platforms.
Project 2.1: Access Gateway platform using Dialup comprising of narrow
band RAS and DSL equipment.
Project 2.2: Access Gateway platform comprising of Broadband RAS and
DSL equipment.
Project 3: Messaging and Storage platform and Provisioning, Billing and
Customer care and Enterprise management system.
The network shall seamlessly integrate with the already existing network
infrastructure comprising of the TCP/IP based NIB-I and MPLS VPN network. The
NIB-II project comprises of Technology solutions from different product
manufacturers with the provision for future expansion.
Project
[Messaging and Storage Service Platform, Provisioning, Billing & Customer care,
Enterprise Management System (EMS) and Security System.]
The Core messaging system shall be the heart of NIB-II that will enable BSNL to add
users across varied value added services. This shall envisage design and up gradation
of the current messaging system to grow from the existing infrastructure in NIB-I
supporting 650,000 users to support the increasing user base. The messaging systems
and associated Storage will be implemented in phases, in accordance with phased
induction of Access equipment.
The system shall be an integrated provisioning, billing, customer care and accounting
platform and shall support billing for the complete range of IP based services
mentioned and meet next-generation requirements as well.
The salient aspects of the projects are summarized as follows:

(i) Setting up proven, robust, scalable Messaging Solution with best in class
security components.
(ii) Roll out across the country supported by 5 Messaging & associated storage
systems at Delhi, Mumbai, Bangalore, Chennai and Kolkata.
(iii) Designed with High Availability architecture with no single point of
failure.
Components of the Solution:
The proposed solution shall consist of the following components with the items of
functionality listed below:
(i) Messaging
a) DNS, AAA
b) MMP
c) LDAP (Consumer, Replicator Hub, Primary and Secondary)
d) SMTP IN & OUT
e) Messaging Servers
f) Address Book Servers, etc.
(ii) Storage
a) SAN Switch & SAN Storage
b) Tape Library
c) Staging Servers, etc.
Storage platform
Various Applications servers placed at the 5 Messaging Storage locations like LDAP,
AAA, EMS, Messaging, UMS & Billing etc. would require Data storage capacities
for storing User‘s mailboxes, Billing data etc. Such huge storage requirements need to
be met with the Fast, Reliable & Scalable storage devices that would be deployed as
―End to End High Performance Switched Architecture Fiber Channel SAN (Storage
Area Networks) providing No Single Point of Failure‖.
Such storage device should be compatible with all the Servers of major companies
such as HP, IBM, SUN, Dell etc. so that choice of Application Servers Platform
remains independent of the storage device.
System Dimensioning:
The user base will be serviced through 5 Messaging and associated Storage systems
that will be set up in the 5 cities. Each of the cities will be connected through the IP
Backbone. Since the proposed user base is envisaged to increase in a phased manner,
the associated messaging system is also proposed to be upgraded in phases
correspondingly.
The system should be designed to support:
On-line services such as Internet, pay-per-view TV and video on demand or a
combination of all or some of the above.
Periodic charges, such as telephone line and cable TV rental.
One-time costs, such as connection fees.
Events, such as telephone calls, data service usage, pay-per-view TV
selections, home shopping purchases, utility metered usage – such as
electricity supply (live site example)
Financial services ASP services.
Telephony services.

Enterprise Backup Systems.
The billing system shall be capable of

Providing electronic versions of bills to customers over the Internet.
Creation/modification of service.
Processing Service requests in real time and non-real time and accounting in
real time.
Producing flexible billing depending upon the use of service.
Security Systems
These include the following.
Load Balancers
Firewall Appliances
Intrusion Detection System
Antivirus system, etc.
Network Operation Center (NOC)

The NOC shall provide facility for centralized Network Management and end-to-end
Provisioning of multiple services, giving a single view of the entire network services
being delivered countywide. The servers for the NOC shall be connected through a
Gigabit Ethernet link from Core router with three zones of firewall within the Centre.
The network shall be centrally managed from Network Operation Centre (NOC)
located at two sites, one of them being master and the other the disaster recovery site.
The main NOC is at Bangalore with Disaster Recovery is at Pune. Interface to the
NMS back-office facility shall be provided along with Firewall security in the Data
Centre. All customer databases shall reside centrally at NOC.
The NMS of NIB-II project 1 is the comprehensive NMS for entire NIB-II including
NIB-I, MPLS VPN, Project 2.1, Project 2.2, which will support entire F (Fault), C
(Configuration), A (Accounting including Access/Inventory), P (Performance) and S
(Security functionality). The conceptual view of eMS, NMS OSS/BSS for NIB-II is
given in figure 4 and the connectivity Architecture of NOC at Bangalore is shown in
figure .

Conceptual view of eMS, NMS, EMS OSS/BSS for NIB-II
Bangalore NOC Connectivity Architecture.

Service Level Agreement (SLA):

It shall be possible to support SLA i.e. the level of service that the customer can
expect together with any penalties to be levied by the service provider for failure to
deliver. It should be possible to provide at least 4 classes of services. The SLA
parameters shall include measurements of service delivery, availability, latency,
throughput and restoration time etc. It should be possible to generate management
reports providing information on customer node configuration and charges, faults and
achievement against the SLAs. It shall be possible to deliver network management
reports via a secure Website.
Implementation of OSS, Messaging, Storage, Billing, EMS & Security Solutions

Messaging
Messaging Solution of NIB-II will provide the SMTP, POP3, IMAP4,
WEBMAIL, WAPMAIL and Notifications services as a Class Of Service to
all the customers of NIB-II and NIB-I
Will support for Country wide roaming for dial up and message store access
through any data center.
The Messaging Server will support Wireless messaging and Directory services
to WAP enabled phones and laptop users
Message store will be content aware to support different types of services to
be created by BSNL ranging from text email to multi-media messaging service
Will provide Family Mailbox where the head of the family can manage
options for Family members. Options will include setting of allowed and block
senders and recipients and control of Anti-SPAM settings.
Messaging solution shall provide flexible control of message aging to define
the conditions under which messages are automatically erased
Web mail interface will support multimedia message types for voice and fax
mail, providing unified messaging interface in future
Message Transfer Agent (MTA) will be designed to handle peak loads without
service degradation or message loss
MTAs will be designed to handle large message queues. There will be
capability available to analyze and manage large message queues generated
due to unreachability of message store (internal) and mail exchangers of other
ISPs (external) or SPAM
Web Hosting
Web space (Data Storage) on servers based on UNIX and Microsoft for
hosting HTML pages with browser
Ftp access for uploading and downloading pages as per the plan. Restriction
on simultaneous ftp sessions
FrontPage etc. access for Web-publishing
Multiple Email Ids per domain with flexible email quota, as per the plan
Web Interface for centralized administration by user and administrators for
services, usage reports, invoice and other reports
It will provide access to customers for analyzing the Web-site performance
through analysis tools
Interface for online registration of domain name

Web Collocation
Necessary Security measures will be implemented both from customer and
BSNL‘s perspective
Billing for this will be done on the basis of usage
One of the service differentiator will be bandwidth on which the server is
collocated.
Security Solution
Anti-Virus solution: It will provide a mechanism to detect unknown virus. The
solution will protect any Gateway and SMTP traffic from virus
Notification: For mails containing repeated complaints regarding abuse from
the same IP address, mail will be sent automatically to the technical contact of
the assignee of that IP address
Network Intrusion detection System: The NIDS will detect unauthorized
internal/external intrusion attempts into the data centers of NIB-II and will
enable to apply appropriate policies on the firewall so as to prevent such
attacks in real time. Suitable alarms will also be sent to the Security Control
Console
Anti Control System: It is provided for Database servers, Messaging Stores,
Web-Hosting Servers and NIDS
Self-protection: Must be able to prevent hackers with root/administrator access
from circumventing or shutting down the security engine
Resource protection: Must allow controlling of access to all system resources
including data files, devices, processes/services and audit files
Rights delegation: Must provide the ability to designate specific users as
administrators, auditors and password managers etc with appropriate rights
Program Controls: Must provide protection against Back Doors and Trojan
Horses
Enterprise Management System
Objective of EMS is to provide a snap-shot graphical view of the health of
NIB-II IT infrastructure as a whole including networking equipment, servers
and services (business and process view)
Reporting system will be able to generate customized reports such as event-
level, performance -level and service-level reports grouped by specific data
fields such as time period, location, customer, series type, device type etc
Security Management will display alarm and events specified by the criteria
such as alarm type, vendor, service, location, source of attack, type of attack
and impacted services
Event Management will capture all the events that are being generated across
the complete IT infrastructure, correlates them and initiate corrective actions
automatically, as defined
System& Application Management will measure the availability and
performance of heterogeneous host systems on a 24x7x365 basis and initiate
preventive and corrective actions automatically
System& Application Management will monitor and manage multiple
attributes (such as status, memory usage, size and resident size, process time,
threads, response time, average throughput and CPU utilization etc) of a
running process and problems and perform restart when processes go down. It
will generate reports on QOS and capacity planning

Database Management will be able to manage tables including database, table

space, buffer pool, processes and session summaries. It will be able to look at
thresholds of objects like free space, process page faults, transaction rates and
average wait time
Service Management will be able to measure Availability /response time of
applications (Basic services, Email services, Web services, Mission critical
applications). It will be possible to specify SLA for the applications and
monitor them
EMS will have tool to monitor SLA .It will provide alerts for SLA violations
and violation trends, for proactively correcting service level problems
Asset Management will store hardware and software inventory information of
all the servers and desktops& creating, tracking and maintaining records for
the assets and components
Objective of Operation Support System (OSS)
OSS will allow BSNL to carryout automation of majority of the processes
needed in service definition & provisioning, service activation, authentication,
authorization and accounting, mediation, rating, billing and invoicing etc.
including service assurance and customer care
OSS shall provide an integrated view of all customers and services across the
network for Customer life cycle management
This includes a customizable web-based GUI client tools for configuration and
setup

OSS ARCHITECTURE
WEB SELF CARE PORTAL/IVRS (CTI)
Database DB
Rating
Billing & Wholesale

Remittance settlement
OM work Flow
ticketing/Help desk
DB
management
Payment Reporting
Provisioning
Accounting
Subscriber
Trouble
Order
GL &
others
MIDDLEWARE-ENTERPRISE APPLICATION INTEGRATION (EAI)

Performance Management
Enterprise Management
Database
Voucher Management
Fault Management
Service Activation
Network Inventory
Mediation
Database system
system
NIB-II Network Infrastructure (NE&NEManagers) All NIB-II Servers (Networking and
procured in project 1,2.1,2.2 Security Appliances and their Element
Managers)
Web Portal
Web Portal will be the gateway for customer and CSR based on their
authorizations for accessing various system, services etc
Portal will have an integration, with NMS, EMS and OSS for providing
services to the BSNL‘s customer service representatives (direct, indirect,
helpdesk, supervisor) and account managers
Portal services Ranging from business, process, network, customer specific
maps/views, trouble-ticketing, pre-sales query, post-sales order-booking, order
tracking, trouble –shooting etc
Portal will integrate with components like Service Provisioning, Order
Management, Billing, Customer Care, EMS and Messaging etc. to provide a

unified view of the network and services to the customers and CSRs for all the
front office functions and some back office functions
Order status and history provide both subscribers and the customer service
representatives with sufficient data to fully manage and monitor the service
selection and delivery process
It will be possible to provide a user friendly interface for customers to plan
and schedule their bandwidth for Band width on Demand services
Services provided by portal to the customers
Customer registration services for both pre-paid and post-paid customer
Self-registration for getting information about products and services
Self-registration for availing services such as post-paid dialup service based on
telephone number authentication
Shopping cart for procuring services
Access to services such as messaging, web-hosting, storage and content-
services etc. This will include on demand services like video on demand and
online gaming etc
Booking an order for services. Allow the user to submit, and track service
requests online at any time
View current bill status in real time including billed, unbilled and pre-billed
services, payment-details and other related information
Reporting a problem by opening a fault docket and tracking its solution
View the status of related network and services subscribed
View the status of SLA compliance, SLA resolution and rebates applied
through integration with billing and NMS
ORDER MANAGEMENT
OM will have
Customer Interface Management
Order Entry and Validation
Workflow Management
Customer Interface Management &Order Entry and Validation:
Order will be entered through Web-portal by CSR or Customer directly

CSR will accept the order after completion of signed order form by the
customer. He will scan it and attach it with the online order form
All orders will be checked against the feasibility from the RMS For all
committed orders, check will be made for customers credit worthiness/default
and the billing system will generate a unique ID for the customer
It will be possible to query the status of order, service, billing etc. on the basis
of unique ID
OM will track the order status
OM will inform the billing system of successful provisioning or else it will
roll back all the steps
Record all the transactions between OM and customer
Record the details of the services provisioned for the customer
Purge customer data from RDBMS and LDAP databases based on pre-defined
and configurable policies when the customer surrenders service

Work Flow Management:

Work Flow Management will automate the process that controls and monitors the
execution of an order according to the customer requirements. This involves the steps
of qualification, reservation, configuration and verification of a service fulfillment
instance
Work Flow Management will integrate OM and provisioning Management systems

(PMS) being procured under project-1, project –2.2 and Whole-sale Dial Application
being procured under project-2.1
Subscriber Provisioning Management System (SPMS)
SPMS will cover the provisioning of following services under project 2.1 and project
3 through configurations in files. Subscriber Provisioning will be fully flexible to
support all the requirements of services
Dial up Internet Access with different variants
Messaging with different Variants
Web Hosting
Web Collocation
Domain Hosting
Broadband Internet Access with Content delivery through SSSC.
Mediation
Billing mediation will be responsible for collecting usage and other charging data
from the various network nodes, normalize the data into a consistent format and
distribute it to other applications and billing system for processing this information
System will collect different parameters from different sources to provide
Cflow and Netflow based collection and mediation for usage based billing of
different services including MPLS-VPN, Web-hosting, Message-Hosting etc
Parameters are
Bandwidth
Volume
Time of day/ day of week/ month (Peak/off peak)
Application (WWW, Email (POP3/IMAP4), Video, E-commerce etc )
Destination
Type of Service (Gold, Silver, Bronze/best efforts) etc
DATABASE
Latest Oracle RDBMS will be used with all applications
RDBMS will work in fail over mode over geographical locations
RDBMS will work in a distributed mode across multiple servers
RDBMS will work in a cluster mode
Provisioning will be made for data replication to or from databases of project
1,2.1 and 2.2

HELP DESK AND TROUBLE TICKETING

Whenever a customer reports a problem, a unique trouble ticket-ID will be
generated by the system. This will be intimated to the customer, so that he can
track the status on the basis of this ID
It will be possible for customers to submit and check the status of reported
problems through web interface
System will automatically track, log and escalate user interactions and
requests
CSRs will be able to view, change the status of the calls, reassign/ transfer the
trouble tickets to others CSRs or technical specialist through the web interface
Will be able to generate various customized Service Level Reports e.g. Open
Call Reports, closed Call Reports, problem area/ Location Specific Reports
Will have the capability for accepting queries through various sources
including Telephone, email or Web interface
System will check for tickets status and escalation and notify the management
or next level of support staff based on predefined Service Level Agreement
(SLA) which will include criteria like Service application, Severity and
customer etc
It will have bulletin board to allow CSRs, Managers and Customers to post
and review messages about critical issues
It will be possible to track the time spent on specific case
It will be possible to generate work orders for field staff or technicians for
fault repair
Trouble ticketing system will interface with SLA and performance
management systems to account for the period of network or service
unavailability
Trouble ticketing system will be able to extract all incidents, resolution
progress reports and all affected services via its interface with the inventory
system
The trouble tickets will be attached to a work-flow where ever there are
multiple steps required for resolution
It will be possible to include information about the equipment, circuit built up
details etc in the trouble ticket automatically after obtaining the same from
inventory
Will integrate with web-portal for report trouble ticket status
System will allow CSR to check the network fault status as part of problem
investigation
Billing
Billing engine will cater to all the billing requirements of BSNL include Retail
Billing (Prepaid and Postpaid), Wholesale and third party billing, Inter connect
and content billing, Dealers and Agents Commissions etc
Billing system will support the preparation of detailed bill, Differential tariff,
Cross product discounting, Sponsored/split billing. Bundled accounting, Hot
billing/On-demand billing, Hierarchy/ Corporate billing, Discounts &
Promotions, Taxes, Notification system, Dealers and Agent commissions,
Content Billing
Billing system will allow customers the option of receiving complete event
details along with their invoice or view them online through the Web portal.

Provision will also be available for the customer to print the event-details from
the Web portal in a printable format
Content Billing
System will provide BSNL subscribers to access services provided by external

content providers and be able to handle the revenue sharing with the content
provider within the single billing platform
System will allow content providers who do not have their own customer care
and billing system to use the billing system of BSNL
Authentication, Authorization and Accounting

Irrespective of mode of access (such as Dial-up Internet access, outsourced
remote access, managed VPNs, Broadband etc), it will manage the
Authentication of all users/customers- both locally and via proxy RADIUS-
and deliver the appropriate level of service to each customer
It will enable defining access schemes by time-of days, days-of-week, call
type (PSTN, ISDN and DSL etc.), calling number and called number etc
It will be capable of authenticating through CLI, DNIS, Voucher number, pin
code etc
Radius server will be able to handle at least 10,000 concurrent sessions per
second
It will integrate with Billing server for providing real time pre-paid balance
management and session management across multiple sessions of multiple
services of a user.

NGN, WIMAX, VOIP, IMS

Next Generation Network
Objectives
The objective of this chapter is to: -
To understand the concept of the Next Generation Network
To understand the technological features of the NGN
To understand the Evolution of the NGN
To understand the role of the NGN
To understand the Architecture of the Next Generation Network
INTRODUCTION
NGN, or Next Generation Network, is new communication network architecture. The
principle is to use packet mode transmission technologies, reserved up till now for
data, to transport all the various types of telecommunication services. In addition,
interfaces are separated from the different layers of the communication network
(transmission, control and applications) to allow for a greater evolution of the
network. Finally, NGN uses the new packet technologies to offer broadband services.
The objective of NGN is to have a single network for all the services. The next-
generation network seamlessly blends the public switched telephone network (PSTN)
and the public switched data network (PSDN), creating a single multi service
network. Convergence is the process of interconnection of traditional switched circuit
networks (PSTN and mobile networks) and packet-switched networks based on the
Internet Protocol (IP) for routing. Convergence introduces new requirements.
NGN definition
User perspective
NGN enables users to get the information content they want in any
media/format, over any facilities, anytime, anywhere and in any volume.
Operator-provider perspective
NGN enables simpler, more competitive creation, operation and provisioning
of services of different nature and requirements over a convergent transport
network independently on the access network. [ETSI]
NGN is a model for future telecommunication networks
NGN is not a new network to be build

Concept of Next Generation Network (NGN)

Next Generation Network is a packet-based network able to provide
telecommunication services and able to make use of multiple broadband, QoS-
enabled transport technologies and in which service-related functions are independent
from underlying transport-related technologies. It enables unfettered access for users
to networks and to competing service providers and/or services of their choice. It
supports generalized mobility which will allow consistent and ubiquitous provision of
services to users.
Recommendation #1: The ETSI GA is invited to note the following definition of

NGN:
NGN is a concept for defining and deploying networks, which, due to their formal
separation into different layers and planes and use of open interfaces, offers service
providers and operators a platform which can evolve in a step-by-step manner to
create, deploy and manage innovative services
Key characteristics of the NGN: -

Architecture based on decoupling of services and networks with multiple
layers and planes defined
Provides capabilities to make the creation, deployment and management of all
kinds of services possible
Has functional entities that may be distributed over the infrastructure with
communication via open interfaces
Supports both existing and "NGN aware" End Terminal Devices
Vision of NGN
The vision of the Next Generation Network (NGN) is captured in the following
features:
Packet network transport with adequate Quality of Service is used for real-
time services such as packet telephony and videoconferencing
Internet Protocol (IP) is used as the dominant network layer protocol,
particularly as presented at the network edge and as seen by the end user
(Other protocols such as ATM may be used for backbone transport but will be
transparent to the user)
Voice over IP (VoIP) telephony is seen to be the first service to be
implemented in the NGN with other services following over time
IP access at the customer premises is made available through a standardised
gateway
Intelligence is distributed across the network (initially supported by signalling
interworking rather than a full distributed processing environment);
The NGN must interwork with Switched Circuit Networks (SCN) via media,
trunking and signalling gateways with gateway controllers
Efficient offloading of dial-up data traffic from the PSTN will be achieved by
access servers closely coupled to end exchanges
Because the NGN is basically a packet network and has no intelligence in the
routers, service platforms such as IP telephony servers and billing servers will
be provided as computing nodes in the IP network

VoIP users of the NGN must have access to value added services at least
similar to those available in the PSTN (free phone, call forwarding, call
waiting). Value-added services may be provided by access to classical IN
service platforms in the PSTN or to specialised platforms in the IP network
Full Operations System Support (OSS) is essential to the effective operation of
the NGN
Comprehensive accounting facilities in the network supporting flexible billing.
Standards for NGN is spread over a wide range of different technical committees both
inside and outside ETSI.
Resulting in duplicate work, conflicting requirements and lack of clear
definition of both the nature and scope of the remaining issues that still require
standardization
Situation recognized by many other SDOs and for a
Clear need for consolidation but subject is too huge to be covered by a single
global forum
ETSI should take a leading role in pushing for global consolidation of NGN
standardization. Most useful approach for ETSI is to push for a number of related, but
independent, initiatives. ETSI should become involved in a set of related, but
independent, initiatives covering the field of NGN standards.
The following technical areas require specific action:

Architecture and protocols
End to end QoS
Service platforms
Network management for NGN
Lawful interception
Security
Motivation for NGN
Dedicated networks for specific services
Orientation towards information (knowledge) society
E-government, E-learning, E-medicine, E-commerce
New combined telecom/IT, fixed/mobile applications
Liberalisation of telecom market
Horizontal and vertical
New player and new revenues
Access providers -> Network resources providers -> Service providers (virtual
operators, 3rd parties) -> Content providers -> Users
Dynamic IT development strategy in telecom domain
Dedicated networks for specific services
Circuit switched network
Quality guaranteed real-time communication
Fixed (PSTN) and mobile (GSM) transmission media
Dedicated communication channel
Synchronous communication
Signalling
Creation, modification and termination of connections
Resources reservation
Packet switched network

Best effort, non-real time communication in burst

Fixed (IP ever Ethernet Tx) and mobile (GPRS) transmission media
Independently routed packets
Asynchronous communication
No need for signalling
Convergence efforts
–Data services delivered over PSTN circuit-switched network
ISDN - dedicated limited bandwidth, time based billing
–PSTN services delivered over data packet-switched network
―IP telephony‖ - QoS guaranteed only in separate domains
-Virtual circuits – combination of circuit & packet switched approach
-ATM – expensive and high requirements on network management
Technology development
–Broadband access and transport (xDSL, SDH, …)
–Higher speed routing and QoS guaranties (IPv6, MPLS, …)
–Standardized signalling protocols for IP (SIP, RSVP, H.323, …)
–Service platforms for telecom and IT integration
Technology Evolution of NGN
Telecommunication technologies were evolving from analog to digital, and are
evolving from circuit to packet, connection oriented packet to connectionless packet,
and from narrow band application to broadband application - broadband converged IP
based services network.
The NGN is seen as evolving in a number of ways:

Initially the growth of the PSTN will be capped and, over time, voice band
service will migrate to VoIP in the NGN.
The NGN will evolve to become a multimedia, multi-service network by
addition of specialist servers, thus increasing range of services available.
Networks will be federated to provide services and services will also be
federated to provide more advanced services.
The transport network will evolve toward a full QoS guaranteed network,
probably based on label switching.
Current work indicates that networks and intelligence on customer premises
will interwork increasingly with provider networks to deliver advanced
services.
Distributed intelligence will be applied in a consistent way across the network.
Several independent networks are available for end-to-end communication of various
kinds of telecommunication applications. The technology as a whole is structured
around a reference module consists of series of layered elements. Technology
evolutions to a simplified one network for the convergences of all applications need to
combine these elements: -
Applications Voice, Voice + Data, Voice + Data + Multimedia
Signaling R2, SS7/IN, SIGTRAN/Megaco
Transport TDM, TDM/ATM, IP/ATM
Transmission SDH, SONET/SDH/WDM/OXC/Gbe

Access Link 2W loop, 2W Loop/Dialup, 2W Loop/xDSL
Following diagram describes the convergence of these element in technology

evolution of NGN.
,
NGN provides converged services based on the open common service platform,
Common IP core network combines various access networks and user services.
Legacy service networks were dedicated and isolated network with service specific
signaling and routing for service connection. NGN service networks have common IP
core network and provide a nomadically accessible common IP application regardless
of a specific access link and user devices.

NGN architecture
Next Generation network is designed in layered architecture. It has an Open standard
interfaces. It is consists of the following layers: -
Service layer
Rapid and simple service creation, implementation and provisioning
Secure access to the network capabilities from un-trusted domain
Open access to the network capabilities to large developers community
Basic building blocks of services capabilities
Transparency to the underlying network technology
Possible integration of telecom, IT, enterprise applications
Access to external resources (DB, presence, media servers, …)
Control layer
Signalling for real-time services
Control of other layers
Transport network
High speed backbone with packet switching
Support of services with different requirements (delay, jitter, packet loss, ... )
Independent on the access network (gateways)

How can the Next Generation Network serve the underserved?

The next generation network is an approach of new entrant and incumbent telcos to
roll out cost effective infrastructure in order to capture market share. The question
naturally arises: what is the role of next generation network technology in providing
universal telecommunications and information service and universal access to
services to underserved communities and in developing countries in general.
The rationale for using an IP based transport network is the reduced cost of switching
relative to PSTN exchanges. Also, core network transmission, already inexpensive in
relation to switching in the PSTN, offers greater capacities in future due to
exploitation of the wide bandwidth available on optic fiber and more efficient
methods of carrying packetised traffic. Access is at present the major cost component
in providing PSTN services. Access technologies for the Next Generation Network
include Asynchronous Digital Subscriber Loops (ADSL) and digital radio loop
systems. Fiber based access for low traffic users are a long way in the future. ADSL
uses existing copper subscriber loops. While providing greater bandwidth to the end
user, ADSL is subject to the operational problems of the current copper loop access.
The cost trends of access to the Next Generation Network are not clear and cost is
likely to continue to be a factor in providing services to underserved communities.
Further research is clearly needed in the access area.
In the next section, we take as an example of the Next Generation Network in the
service of underserved communities, namely a proposal for the Next Generation
Telecentre being researched at CeTAS [4].

Softswitch Architecture
In softswitch architecture, the service provider replaces the Class 5 switch with a
softswitch, media gateway, and application server such as BroadWorks. The
Softswitch provides trunking, SS7 networking, translations, routing and network
services, such as local number portability. BroadWorks acts as a peer to a softswitch,
using the SIP connection between the two as an "IP Inter Machine Trunk".
Unlike the class 5 switch, the softswitch and BroadWorks are not involved in the
transport or switching of the packetized voice stream. However, the softswitch does
communicate with BroadWorks for access to the IP Centrex/Hosted PBX features.
Also, if the terminating party is part of the IP Centrex/Hosted PBX group, then the
softswitch instructs the originating and terminating party to establish communications,
and keeps the entire call on the network, and as VoIP. If the terminating party resides
outside the IP Centrex/Hosted PBX group, the softswitch interacts via a network
gateway, with the Public Switched Telephone Network (PSTN). On the PSTN, a
Class 4 or Class 5 switch will handle the transport and switching of voice calls.
Class 5 Extension Architecture
A Class 5 Extension architecture allows service providers to continue to use their
existing voice network, while still offering their customers the advantages of VoIP
and IP Centrex/Hosted PBX. In this architecture, BroadWorks provides dial tone,
calling features, unified messaging, and other features provided by IP Centrex/Hosted
PBX applications. The Class 5 switch provides the network functionality such as 911,
number portability, billing, and SS7 interconnection.
BroadWorks provides the flexibility to introduce IP voice services without the need to
invest softswitch infrastructure. In this architecture, a single BroadWorks system can
leverage existing voice infrastructure, and support multiple points of presence (POP).
Providers seeking a region-by-region rollout can launch service one POP at a time,
starting with smaller capacity gateways as needed.
For financial planning, the Class 5 Extension offers a cost-effective migration to IP

voice. BroadWorks allows incremental investments in IP voice assets that limits risk
and reduces upfront outlay. BroadWorks not only interconnects with TDM
infrastructure but also extends capacity. By moving business customers to IP voice,
providers increase capacity as part of a "cap-and-grow" migration.
NGN Drivers
A key driver for implementing or migrating to a NGN is cost. It is impossible to
generalise on the extent of cost savings since business specific issues such as service
strategy, legacy infrastructure, operational model, and scale all play a part in this
complex equation. For many businesses however the potential capital and operational
cost savings of running multiple services on a single infrastructure are too good to
ignore.
Another important driver is service differentiation. The initial focus of many NGNs is
to support traditional data/voice services, but today, there are service providers
building complete business strategies around new converged service platforms. They
are taking advantage of the benefits convergence provides them today and investing in

future proven technology that they believe shall provide a platform for application
growth.
NGN Equipment Types
Along with traditional voice and data equipment the NGN architecture contains
converged network equipment types such as Call Agents (e.g. Media Gateway
Controller - MGC, Gatekeeper - GK, SIP Server and Softswitch - SS), Media
Gateways (MG), Signalling Gateways (SG), Feature Servers, Application Servers,
Media Servers and provides Management, Provisioning and Billing interfaces.
The Softswitch
Softswitches are a software-based call control device that plays one of the most
significant parts in the NGN. The Softswitch provides call control interworking
between NGN protocols such as MGCP, H.248 / Megaco, SIP, H.323, and Sigtran as
well as more traditional telephony protocols such as CAS, ISDN, SS7, TCAP, and
INAP. The Softswitch can contain multiple call agent functions (e.g. MGC, SIP
Server & GK) and in some cases a SG function.
One of the many roles of a Softswitch is interfacing to the PSTN (Public Switched
Telephony Network). It does this by interworking signalling systems via SGs and the
voice circuits via MGs from PSTN switches and Intelligent Network platforms.
The choice of softswitch today is large and is influenced by factors such as target
market, scale of deployment, required functionality, available budget and service
strategy.
Who are implementing NGNs
Traditional carriers with traditional legacy equipment and services must carefully
address how they migrate to a NGN. They must decide whether to replace current
operational infrastructures, cap investment & grow organically or implement a new
parallel platform & migrate over time. Whatever the decision the scale of network
infrastructure involved will lead to significant costs and protracted timescales for
migration activities.
New operators with less legacy infrastructure and greenfield networks can plan for,
design and implement the NGN more readily. Their IP network can be designed to
provide some level of quality, a vendor can be chosen to provide an end-to-end
solution and interconnects to the PSTN and Internet can be put in place. Advances
Operational Support Systems can be utilised effectively to monitor, control, police
and bill with less integration than with traditional operators.
ISPs are looking at a potential change in their business model. Converged services
will allow the ISP to differentiate themselves while entering into a new
telecommunications market without the capital outlay of traditional networks.
Bandwidth increases brought about by DSL to the home will play a major part and so
ISPs can offer more bandwidth hungry services without the constraints of slower
speed access.

WiMAX
WiMAX is a single wireless technology that can:
Bridge the digital divide by delivering broadband in low-density areas,
Connect enterprises and residential users in urban and suburban environments
where access to copper plant is difficult,
Make portable Internet a reality by extending public WLAN hotspots to city
hotzones,
Further expand hotzones to metropolitan area coverage for mobile data-centric
service delivery.
WiMAX is state-of-the-art radio technology, offers Broadband wireless access at data
rates of several tens of Mbit/s (up to 75 Mbit/s per base station) and within a range of
several tens of kilometers (up to 50 km). This same radio technology offers high-
speed data services to all nomadic terminals (laptops, PDAs, etc.) at a better cost :
performance ratio than 3G, given an optimized trade off between throughput and
mobility. Finally, WiMAX incorporates Quality of Service elements to offer
multimedia services, including voice. Given its huge benefits, WiMAX will develop
as a self-standing radio access solution in the global network architecture. WiMAX
will also enable end-users to benefit from an "Always Best Connected" experience
when accessing their applications via the best available network, at home, on the
pause, or on the move. A technology with such enormous potential is destined for a
bright future.
Introduction
Broadband Wireless Access (BWA) has been serving enterprises and operators for
years, to the great satisfaction of its users. However, the new IP-based standard
developed by the IEEE 802.16 is likely to accelerate adoption of the technology. It
will expand the scope of usage thanks to: the possibility of operating in unlicensed
frequency bands, unique performance under Non-Line-of-Sight (NLOS) conditions,
Quality of Service (QoS) awareness, extension to mobility, and more. In parallel, the
WiMAX forum, backed by industry leaders, will encourage the widespread adoption
of broadband wireless access by establishing a brand for the technology and pushing
interoperability between products. The purpose of this White Paper is to highlight and
assess the value of WiMAX as the right solution to:
Bridge the digital divide in low-density areas where technical and economic
factors make broadband deployment very challenging,
Offer fixed broadband access in urban and suburban areas where copper
quality is poor or unbundling difficult,
Extend the currently limited coverage of public WLAN (hotspots) to citywide
coverage (hotzones) – the same technology being usable at home and on the
move,
Blanket metropolitan areas for mobile data-centric service delivery.
In addition to these uses, it has other potential applications, such as telephony or an
effective point-to-multipoint backhauling solution for operators or enterprises.

Standards associated to WiMAX

Worldwide Interoperability for Microwave Access (WiMAX) is the common name
associated to the IEEE 802.16a/REVd/e standards. These standards are issued by the
IEEE 802.16 subgroup that originally covered the Wireless Local Loop (WLL)
technologies with radio spectrum from 10 to 66 GHz. Recently, these specifications
were extended below 10 GHz:
In January 2003, the IEEE approved 802.16a as an amendment to IEEE
802.16- 2001, defining (Near) Line-Of- Sight capability,
Mid-2004, IEEE 802.16REVd, which should be published under the name
IEEE 802.16-2004, will introduce support for indoor CPE (NLOS) and
nomadicity through additional radio capabilities such as antenna beam
forming and OFDM sub-channeling,
Early 2005, an IEEE 802.16e variant will introduce support for mobility.
See Figure for the applications associated with each of these standards.
The WiMAX Forum intends to do for 802.16 what the Wi-Fi Alliance did for 802.11:
Harmonize standards and certify interoperability between equipment from
different vendors. Standardized interoperable solutions will result in mass
volume and bring down costs,
Promote and establish a brand for the technology.
WiMAX offers broadband wireless access at data rates of several tens of Mbit/s (up to
75 Mbit/s per base station) and within a range of several tens of kilometers (up to 50
km). However,
75 Mbit/s is achievable with a 20 MHz channel. Regulators will often allow only
smaller channels (10 MHz or less) reducing the maximum bandwidth,

50 km is achievable only under optimal conditions and with a reduced data rate (a few
Mbit/s). Typical coverage will be around 5 km with indoor CPE (NLOS) and around
15 km with a CPE connected to an external antenna (LOS),
Mobility will target only urban usage, with up to 60 km/h vehicle speed to
maintain optimum throughput performance.
WiMAX product availability
Mass deployment of WiMAX products is planned in two main steps:
mid-2005, availability of the 802.16REVd chipset, allowing the development
of cost optimized CPE operating indoors (NLOS),
in 2006, availability of 802.16e chipsets embedded in laptops and later on in
other mobile devices, enabling mobility (portable Internet).
Current pre-WiMAX products and initial 802.16a WiMAX products available in early
2005, operating similarly to current proprietary equipment (LOS, not cost-optimized
CPE) and at similar cost, will not be widely deployed.
Market for WiMAX
WiMAX will boost today‘s highly fragmented BWA market thanks to standardization
and interoperability, state-of-the-art radio efficiency with NLOS capability, and
strong support from the radio equipment manufacturers and chipset industries.
WiMAX will also target the mobility market with the introduction of low power-
consumption chipsets. The strong support from some of the most important chipsets
manufacturers such as Intel or Fujitsu is a key enabler for the success of WiMAX,
since it will lead to wide availability of affordable WiMAX-enabled terminals (e.g.,
laptops, PDAs, etc.).
WiMAX and its three main markets
WiMAX will open up three main markets – see Figure This will happen in three
waves:
It will bridge the digital divide in low-density areas where technical and
economic factors inhibit cost effective broadband deployments. The prime
markets are in Western Europe, North America, and some Asia-Pacific
countries. This will be the first market to take off - in 2005.
It will offer high-speed Internet and voice access in urban and suburban areas
where access to the copper plant is difficult. It will also support nomadic usage
for operators wishing to stand out from competition (the same subscription
could be used throughout a city). This market will also start in 2005, with
WiMAX progressively replacing current proprietary products.
It will then introduce the portable Internet application by providing broadband
access on the move, extending the currently limited coverage of public
WLANs to city-wide coverage (hotzones). Later expansion will be to
Metropolitan areas, providing high-speed data services under mobility
conditions. This market will first emerge in North America, followed by most
of the developed and developing countries. It will take off with the availability
of WiMAX-enabled laptops in 2006.

WiMAX, a complement to fixed and mobile access

WiMAX integrates perfectly into existing fixed and mobile networks, complementing
them when needed.
This section gives a more detailed analysis of WiMAX integration into fixed and the
mobile markets.
WiMAX for fixed wireless access

Nationwide broadband access has become a priority in many countries. In most
developed countries, the average broadband coverage will reach 90% in the coming
years. Still, in some rural areas of such countries, broadband coverage will not exceed
50%.
The service gap can be categorized by two characteristics: the type of area (rural or
urban) and the level of national development. See Table 1. In developed countries,
DSL service deployment has been massive in urban and sub-urban deployments,
whereas coverage of remote areas -smaller towns and rural areas - is lagging behind.
Hurdles to overcome are the poor line quality of the installed copper base, the large
distances to the central offices or cabinets, or the low population density. In this
context, WiMAX, with its QoS support, longer reach, and data rates similar to DSL, is
naturally positioned as a viable last mile option to offer broadband access to
residential users.
In emerging countries, the main focus of broadband deployment is on urban and sub-
urban areas, and will remain so in the near future. The low POTS penetration and the
low quality of the copper pair prevent mass scale DSL deployment and foster the need
for alternate broadband technologies. In this context, WiMAX is positioned as an
excellent option. Moreover, the possibility of offering broadband services in
combination with voice services will gradually lead to narrowband WLL substitution.

In addition to WiMAX, alternate technologies available to cover urban and rural

markets in developed and developing countries are remote DSL solutions, satellite
combined with Wi-Fi for the last mile, Fiber to the User (FTTU), and possibly Power
Line Communications (PLC).
Parameters such as availability of the copper, distance to the remote unit/central

office, backhauling costs, and teledensity will drive the choice for one or other of
these solutions. For further details, refer to the article ―Providing Always-on
Broadband Access to Under-served Areas‖ in the Alcatel Telecommunication Review
(Q4 2003).
The WiMAX CPE
In most case, a simple plug and play terminal, similar to a DSL modem, provides
connectivity. See Figure. For customers located several kilometers from the WiMAX
base station, a self-install outdoor antenna may be required to improve transmission
quality. To serve isolated customers, a directive antenna pointing to the WiMAX base
station may be required. For customers requesting voice in addition to broadband
services, specific CPE will allow the connection of standard or VoIP phones.
Deployment topologies
Several topology and backhauling options are to be supported on the WiMAX base
stations: wire line backhauling (typically over Ethernet), microwave Point to- Point
connection, as well as WiMAX backhaul. See Figure. With the latter option, the base
station has the capability to backhaul itself. This can be achieved by reserving part of
the bandwidth normally used for the end-user traffic and using it for backhauling
purposes.
Operator’s business case
WiMAX is of interest for incumbent, alternate, and mobile operators. Some possible
business cases:
The incumbent operators can use the wireless technology as a complement to
DSL, allowing them to offer DSL-like services in remote, low-density areas
that cannot be served with DSL.
For alternate operators, the wireless technology is the solution for a
competitive high-speed Internet and voice offering bypassing the landline
facilities, with applicability in urban or sub-urban areas.
In the long term, mobile operators may also take market share from fixed
operators due to substitution of fixed broadband access by wireless broadband
access, giving access to users on the move but also at home.

WiMAX for limited mobility access

WiMAX, the natural complement to Wi-Fi and mobile networks
Mobile networks offer mobility, ubiquitous coverage, and voice support, but at the
expense of limited data rates. WiMAX can be positioned as a complementary solution
by offering high bandwidth when required, in particular in dense urban areas.
Public WLAN, while offering clear benefits, is limited in coverage and mobility
capabilities. WiMAX bypasses these limitations and offers broadband connectivity in
larger areas (hotzones). Wi-Fi and WiMAX solutions are also complementary, with
Wi-Fi being more adapted for short-range, indoor connections (in particular in the
enterprise and at home) and WiMAX for long- range outdoor connections.
From nomadicity to full mobility
While nomadicity offers mobility within the coverage area of a single base station,
limited mobility access implies session continuity throughout the network possibly
with between base stations.

A new generation of networks with multi-access (3G, Wi-Fi, WiMAX, DSL, FTTU,
etc.) enables end-users to enjoy an ―Always Best Connected‖ experience when
accessing their applications via the best available network at home, on the pause, or
on the move. See Figure WiMAX becomes an additional radio access solution in the
global network architecture.
WiMAX, the obvious choice for operators
By integrating WiMAX into their networks, mobile operators can boost their service
with high bandwidth, when necessary, the same applications (messaging, agenda,
location-based services) being offered on both networks with a single billing.
Mobile operators can also reuse existing radio sites and backhauling equipment to
facilitate the deployment of WiMAX.
Fixed operators, incumbent or alternate, will offer nomadic and mobile usage as an
addition to their fixed access offering to complement their DSL and Wi-Fi bundle. For
those having deployed WiMAX for fixed access, this is also a natural evolution of
their offering.
WiMAX Technology Challenge WiMAX, more flexibility and security
Unlike WLAN, WiMAX provides a media access control (MAC) layer that uses a
grant-request mechanism to authorize the exchange of data. This feature allows better
exploitation of the radio resources, in particular with smart antennas, and independent
management of the traffic of every user. This simplifies the support of real-time and
voice applications.
One of the inhibitors to widespread deployment of WLAN was the poor security
feature of the first releases. WiMAX proposes the full range of security features to
ensure secured data exchange:
Terminal authentication by exchanging certificates to prevent rogue devices,
User authentication using the Extensible Authentication Protocol (EAP),

Data encryption using the Data Encryption Standard (DES) or Advanced

Encryption Standard (AES), both much more robust than the Wireless
Equivalent Privacy (WEP) initially used by WLAN. Furthermore, each service
is encrypted with its own security association and private keys.
WiMAX, a very efficient radio solution

WiMAX must be able to provide a reliable service over long distances to customers
using indoor terminals or PC cards (like today‘s WLAN cards). These requirements,
with limited transmit power to comply with health requirements, will limit the link
budget. Subchannelling in uplink and smart antennas at the base station have to
overcome these constraints.
The WiMAX system relies on a new radio physical (PHY) layer and appropriate
MAC layer to support all demands driven by the target applications.
The PHY layer modulation is based on OFDM, in combination with a centralized

MAC layer for optimized resource allocation and support of QoS for different types
of services (VoIP, real-time and non real-time services, best effort). The OFDM PHY
layer is well adapted to the NLOS propagation environment in the 2 – 11 GHz
frequency range. It is inherently robust when it comes to handling the significant
delay spread caused by the typical NLOS reflections. Together with adaptive
modulation, which is applied to each subscriber individually according to the radio
channel capability, OFDM can provide a high spectral efficiency of about 3 – 4
bit/s/Hz.
However, in contrast to single carrier modulation, the OFDM signal has an increased
peak: average ratio and increased frequency accuracy requirements. Therefore,
selection of appropriate power amplifiers and frequency recovery concepts are
crucial.
WiMAX provides flexibility in terms of channelization, carrier frequency, and duplex

mode (TDD and FDD) to meet a variety of requirements for available spectrum
resources and targeted services.
An important and very challenging function of the WiMAX system is the support of
various advanced antenna techniques, which are essential to provide high spectral
efficiency, capacity, system performance, and reliability:
Beam forming using smart antennas provides additional gain to bridge long
distances or to increase indoor coverage; it reduces inter-cell interference and
improves frequency reuse,
Transmit diversity and MIMO techniques using multiple antennas take
advantage of multipath reflections to improve reliability and capacity.

System performance
Table gives typical cell size and throughput at 3.5 GHz in various configuration and environments.
WiMAX Spectrum and Regulation Issues
WiMAX-compliant equipment will be allowed to operate in both licensed and

unlicensed bands. The minimum channel bandwidth for WiMAX usage is 1.75 MHz
per channel, while 10 MHz is considered as an optimum.
Although 2.4 GHz and 5 GHz non-licensed bands are largely available, their usage
could be limited to trials because of the risks of interference preventing QoS
commitments.
The 2.5 and 3.5 GHz licensed bands will be the most common bands for WiMAX
applications. It should be noted that the 5 GHz band is also partially licensed in some
countries.
Most countries have already allocated licensed spectrum, generally to alternate

operators. Nevertheless large quantities of spectrum are still in process of allocation,
and some countries have not even defined any WiMAX licensed bands yet.
WiMAX is designed to accommodate either Frequency Division Duplexing (FDD),

which is more suited to enterprise traffic, or Time Division Duplexing (TDD), which
is more adapted to asymmetrical traffic. Cohabitation of FDD and TDD techniques is
possible within the same bands, provided guard bands are implemented.
Conclusion
The latest developments in the IEEE 802.16 group are driving a broadband wireless
access (r)evolution thanks to a standard with unique technical characteristics. In
parallel, the WiMAX forum, backed by industry leaders, helps the widespread
adoption of broadband wireless access by establishing a brand for the technology.
Initially, WiMAX will bridge the digital divide. Then, thanks to competitive
equipment prices, the scope of WiMAX deployment will broaden to cover markets
where the low POTS penetration, high DSL unbundling costs, or poor copper quality
have acted as a brake on extensive high-speed Internet and voice over broadband.
WiMAX will reach its peak by making portable Internet a reality. When WiMAX

chipsets are integrated into laptops and other portable devices, it will provide high
speed data services on the move, extending today‘s limited coverage of public WLAN
to metropolitan areas. Integrated into new generation networks with seamless roaming
between various accesses, it will enable end users to enjoy an ―Always Best
Connected‖ experience. The combination of these capabilities makes WiMAX
attractive for a wide diversity of people: fixed operators, mobile operators, and
wireless ISPs, but also for many vertical markets and local authorities. Alcatel, the
worldwide broadband market leader with a market share in excess of 37%, is
committed to offer complete support across the entire investment and operational
cycle required for successful deployment of WiMAX services.

VOIP Introduction
Voice communication has traditionally been carried over dedicated Telephone

networks operated by Telecommunication service providers such as the BSNL and
MTNL in India or AT&T in USA. These telephone networks have progressively
evolved from the initial analog circuits to the current digital networks with bandwidth
in excess of 1 Gbps. For reasons of varying bandwidth and networking requirements,
different services were provided on separate networks. For example, Telegraph
networks, Telex networks, Telephone networks, Facsimile networks, Cable networks
and Data networks support different services, as their names would suggest.
These networks possessed characteristics that satisfied the peculiar requirements of

the service they provided. For example, the voice network would support bandwidths
of 64 Kbps for voice communication and would ensure telco-grade voice
communication with little jitter and echo cancellation. Likewise, the cable networks
would provide even higher bandwidth and improved quality of service (QoS) for
video transmission. On the other hand, the data communication network‘s bandwidth
and QoS requirements are highly flexible. This means that the data communication
requirements could be a Telnet application, requiring minimal data pipe, but
reasonably fast network response times. Or it could be a batch transmission
application that required a higher throughput, but can tolerate larger inter packet
deliver delays. For most types of data communication applications, reliability is
critical, which means that the delivery protocols would implement mechanisms for
error checking, acknowledgment, re-transmission and sequencing. On the other hand,
for real-time applications such as voice communications, it would make little sense to
retransmit a lost packet for play back at the receiving end, if it is out of sequence and
is considerably delayed. Essentially, the main point to be nodded is that these
networks have been designed differently in terms of their underlying architecture and
communication protocols.
In the late eighties and early nineties it was realized that integrating these networks
into a single integrated network, such that all services would use common facilities,
would result in efficiency and cost savings. This was the new mantra that made
possible the creation and deployment of ISDN and similar networks, bringing data
and voice communication together. However, nearly all these networks were built and
operated by major telecommunication equipment manufacturers and service
providers. Although, the major international standards bodies such as ITU-T
(formerly CCITT), or the ETSI defined a relevant set of standards for implementation
and to assure inter-operability between products from different telecom equipment
manufacturers, these standards were still inadequate to reduce the proprietary nature
of most implementations. It meant that even if the standards assured inter-operability
among equipment and networks for existing communication services (which number
only in dozens), they fell woefully short, on account of proprietary implementations,
for being able to spawn and envisage even greater types of potential communication
services. Consider what the Internet has done for conceiving and spawning
innumerable types of web-based applications at progressively lower costs.
Subsequently, from the mid-nineties onwards, the Internet has proved to be the major
all-encompassing network that demonstrated its prowess in delivering all types of

media (data, voice and video) at lowest cost. Data communication equipment
manufacturing companies, such as Cisco, have also been instrumental in driving up
the reach of the Internet and Internet protocols. Internet protocols became the
preferred protocol for delivering communication payload for all types of networks,
mainly for their open and widely accepted interface implementations. Contrast this
with ATM, which somehow has been left behind.
However, a major shortcoming in the Internet protocols – TCP, UDP over IP has been
their inability to transfer real-time application data such as voice and video. The major
issues were jitter, network latency, echo cancellation, quality of service and security.
To overcome this shortcoming, newer implementations of IP (e.g. IP version 6) and a
flurry of associated protocol specifications (e.g. H.323 or SIP) were defined to plug
the gap between the Internet protocols and other telecom application-oriented
protocols. These activities of developing and implementing new IP-based protocol
definitions for multimedia communications; their underlying network architecture and
also integration with existing networks are collectively termed as Voice over IP or
VoIP in short.
ISDN
PSTN
TEL
EX
TELEGRA INTERNET
PH
ACCESS
ACCESS TRANSMISI SWITCHIN GATEWAY ROTERS LAN
ON G
TTTTTTTTTTELCOS DATA NETWORKIG COMPNAIES
TELCO EQIPMENT DATA SERVICE DATA EQIPMENT

TELCO MANUFACTURERS PROVIDERS MANUFACTURERS
SERVICE
PROVIDERS
Communication Market Stake Holders
The effort to integrate all communication services over IP is a transition effort on two
major fronts. First, the Telecommunication equipment manufacturers were interested

in integrating the currently deployed services and network protocols to IP. Second, the
Data communication equipment manufacturers, who were already using IP for data
communication services were moving upward to provide voice and multimedia
services over data networks.
The culmination of the above efforts and various standards making bodies is supposed
to achieve the objectives of service portability, network convergence and secured
network access. It is hoped that with the transition of voice (multimedia) over to
Internet protocols would open the doors to the conceptualisation and implementation
of numbers services in thousands from the current dozens.
Issues in voice communication over networks
As the IP network was primarily designed to carry data, it does not provide real-time
guarantees but only provides best effort services, which is inadequate for voice
communication. Upper layer protocols were designed to provide such guarantees.
Further, as there are several vendors in the market implementing these protocols,
conformance to standards and interoperability issues have become important. The
major issues governing transfer of a voice stream over the Internet or using Internet
protocols are listed below.
Bandwidth requirement
In the analog world, the voice transmission frequency spectrum requirement is 0-3.4
KHz in the base band, and is nominally called a 4 KHz voice channel for
convenience. For digital telecommunication, the signal is sampled at twice the rate.
The minimum-sampling rate required is thus 8 KHz. If each sample contains 8 bits,
the digital bandwidth required works out to be 64 Kbps.
Telco quality voice requires sampling at 8 KHz. The bandwidth then depends on the
level of quantization. With linear quantization at 8 bits/sample or at 16 bits/sample,
the bandwidth is either 64 Kbps or 128 Kbps. Further, the quantization (e.g. PCM) is
modified by using an A-law or µ-law companding curve.
In order to communicate telco-grade voice (or similarly, other real-time applications

such as moving video) two different approaches can be attempted. To transmit
information of the highest quality over unrestricted bandwidth or to reduce the
bandwidth required for transmitting information (voice) of a given quality. Stated
differently, decisions are required regarding what information should be transmitted
and how it should be transmitted.
Compression and decompression (CODEC) of digital signals is a means of reducing

the required bandwidth or transmission bit rate. Certain source data are highly
redundant, particularly digitised images such as video and facsimile. If, for example, a
digital signal contains a string of zeroes, it will be economical to transmit a code
indicating that a string of zero follows along with the length of the string. Many
different algorithms for compression and decompression of digital codes have been
constructed.
Pulse code modulation (PCM) and adaptive differential PCM (ADPCM) are examples
of ―waveform‖ CODEC techniques. Waveform CODECs are compression techniques
that exploit the redundant characteristics of the waveform itself. In addition to

waveform CODECs, there are source CODECs that compress speech by sending only
simplified parametric information about voice transmission; these CODECs require
less bandwidth.
Source CODECs include linear predictive coding (LPC), code-excited linear

prediction (CELP) and multipulse-multilevel quantization (MP-MLQ).
Coding techniques for telephony and voice packet are standardized by the ITU-T in
its G-series recommendations.
Some algorithms for voice compression and decompression are given in the table
below.
Table-Coding Algorithms
Input Range Transmission Rate Standard
Liner Predictive Coding algorithm 64 Kbps LPC-10
G.711
Code Excited Liner Prediction (CELP) 8 Kbps G.729
G.729 A
32 Kbps Adaptive Differential Pulse Code 32 Kbps G.721

Modulation (ADPCM)
Mean Opinion Score (MOS)

Each CODEC provides a certain quality of speech. The quality of transmitted speech
is a subjective response of the listener. A common benchmark used to determine the
quality of sound produced by specific CODECs is the mean opinion score (MOS).
With MOS, a wide range of listeners judge the quality of a voice sample
(corresponding to a particular CODEC) on a scale of 1 (bad) to 5 (excellent). The
scores are averaged to provide the MOS for that sample. The table below shows the
below shows the relationship between CODECs and MOS scores.
Table-Compression Methods and MOS Scores
Compression Method Bit Rate (Kbps) Framing Size (ms) MOS Score
G.711 PCM 64 1.25 4.1
G.729 CS-ACELP 8 10 3.92
G.729x2 Encoding 8 10 3.27
G.729x3 Encoding 8 10 2.68
G.729a CS-ACELP 8 10 3.7

Although it might seem logical from a resource usage standpoint to convert all calls to
low bit-rate CODECs to save on infrastructure costs, there are drawbacks to
compressing voice. One of the main drawbacks is signal distortion due to multiple
encodings (called tandem encodings). For example, when a G.729 voice signal is
tandem-encoded three times, the MOS score drops from 3.92 (very good) to 2.68
(unacceptable.
Telco-grade voice refers to MOS scores of 4 or above.
Delay
A very important design consideration in implementing voice communications
networks is minizing one-way, end-to-end delay. Voice traffic is real-time traffic and
if there is too long a delay in voice packet delivery, speech will be unrecognisable. An
acceptable delay is less than 200 milliseconds. Delay is inherent in voice networking
and is caused by a number of different factors.
There are basically two kinds of delay inherent in today‘s telephony networks:
Propagation delay – caused by the characteristics of the speed of light
traveling via a fiber-optic-based or copper-based medium of the underlying
network.
Handling delay (also called serialization delay) – caused by the devices that
handle voice information and have a signicant impact on voice quality in a
packet network. This delay includes the time it takes to generate a voice
packet. DSPs may take 5ms to 20ms to generate a frame and usually one or
more frames are placed in a voice packet. Another component of this delay is
the time taken to move the packet to the output queue. Some devices expedite
this process by determining packet destination and getting the packet to output
queue quickly. The actual delay at the output queue, in terms of time spent in
the queue before being serviced, is yet another component of this handling
delay and is normally around 10ms. A CODEC-induced delay is considered a
handling delay. The table below shows the delay introduced by different
CODECs.
Table CODEC-Induced Delays

CODEC Bit Rate (Kbps) Compression Delay (ms)
G.711 PCM 64 5
G.729 CS-ACELP 8 15
G.729a CS-ACELP 8 15
Serialization delay
Serialization delay is the amount of time a router takes to place a packet on a wire for
transmission. Fragmentation helps to eliminate serialization delay, but fragmentation,
such as FRF.12, doesn‘t help without a queuing mechanism in place. For example, if a
1000-byte packet enters a router‘s queue and is fragmented into ten 100-byte packets,
without a queuing mechanism in place, a router will still send all 1000-bytes before it
starts to send another packet. Conversely, if there is a queuing mechanism in place,
but no fragmentation, voice traffic can still fail. If a router receives a 1000-byte packet

in its queue and begins sending this packet in an instant before it receives a voice
packet, the voice packet will have to wait until all 1000 bytes are sent across the wire,
before entering the queue, because once a router starts sending a packet, it will
continue to do so until the full packet is processed. Therefore, it is essential that there
is a method for a router to break large data packets into smaller ones, and a queuing
strategy in place to help voice packets jump to the front of a queue ahead of data
packets for transmission.
End-to-End delay
End-to-end delay depends on the end-to-end signal paths/data paths, the CODEC, and
the payload size of the packets.
Jitter
Jitter is variation in the delay of arrivals of voice packets at the receiver. This causes a
discontinuity of the voice stream. It is usually compensated for by using a play-out
buffer for playing out the voice smoothly. Play-out control can be exercised both in
adaptive or non-adaptive play-out delay mode.
Echo Cancellation
Echo is hearing your own voice in the telephone receiver while you are talking. When
timed properly, echo is reassuring to the speaker. If the echo exceeds approximately
25ms, it can be distracting and cause breaks in the conversation. In a traditional
telephony network, echo is normally caused by a mismatch in impedance from the
four-wire network switch conversion to the two-wire local loop and is controlled by
echo cancellers.
In voice over packet-based networks or VoIP, echo cancellers are built into the low
bit-rate CODECs and are operated on echo DSP. Echo cancellers are limited by
design by the total amount of time they will wait for the reflected speech to be
received, which is known as an echo trail. The echo trail is normally 32ms.
Reliability
Traditional data communication strives to provide reliable end-to-end communication
between two peers. They use checksum and sequence numbering for error control and
some form of negative acknowledgement with a packet retransmission handshake for
error recovery. The negative acknowledgement with subsequent re-transmission
handshake adds more than a round trip delay to transmission. For time-critical data,
the retransmitted message/packet might therefore be entirely useless. Thus, VoIP
networks should leave the proper error control and error recovery scheme to higher
communication layers. They can thus provide the level of reliability required, taking
into account the impact of the delay characteristics. Therefore, UDP is the transport
level protocol of choice for voice and like communications. Reliability is built into
higher layers.
Audio data is delay-sensitive and requires the transmitted voice packets to reach the
destination with minimum delay and minimum delay jitter. Although TCP/IP provides
reliable connection, it is at the cost of packet delay or higher network latency. On the
other hand, UDP is faster compared to TCP. However, as packet sequencing and some
degree of reliability are required over UDP/IP, RTP over UDP/IP is usually used for
voice and video communication.

Interoperability
In a public network environment, in order for products from different vendors to inter-
operate with each other, they need to conform to standards. These standards are being
devised by the ITU-T and the IETF. H.323 from ITU-T is by far the more popular
standard. However, SIP/MGCP standards from IETF are rapidly gaining more
acceptance as relatively light weight and easily scalable protocols.
Security
On the Internet, since anybody can capture packets meant for someone else, security
of voice communication becomes an important issue. Some measure of security can
be provided by using encryption and tunneling. Usually, the common tunneling
protocol used is Layer 2 Tunneling protocol, and the common encryption mechanism
used is Secure Sockets Layer (SSL).
Integration with PSTN and ISDN
IP Telephony needs to co-exist with traditional PSTN for still some more time. It
means that both PSTN and IP telephony networks should appear as a single network
to users. This is achieved through the use of gateways between the Internet on the one
hand and PSTN or ISDN on the other.
Scalability
As succeeding VoIP products strive to provide Telco-grade voice quality over IP as is
true for PSTN, but at a progressively lower cost, there is a potential for high growth
rates in VoIP systems. in such a scenario, it is essential that these systems be flexible
enough to grow into large user markets.
Typical voice call handling in a VoIP application
It is useful to understand what happens at an application level when a call is placed
using VoIP. The diagram below describes the general flow of a two-party voice call
using VoIP.

IP PSTN
Network
Handset VoIP PBX

Application Gateway
Step 1 Phone
Off Hook
Step 2
Dial Tone Step 4-IP Address
resolution
Step 3 Step 5-PSTN Call

Dialed Digits Step 5-Call signaling to phone
Request
using H.323/SIP
Step 5-Call
signaling to PHX
Ringin
g
Step 5- Off Hook
Step 5-Call
Request
CODEC using H.323/SIP
Talk-
Audio
Step 6-Audio
Transport Step 7
using DTMF
RTP/RTCP
Step 8
Bye
Typical VoIP Call Handling

Table-Typical VoIP Call Handling
Step Action
Step1. The use picks up the handset; this signals an off-hook condition to the
signaling application part of VoIP.
Step2. The session application part of VoIP issues a dial tone and waits of the
user to dial a telephone number.
Step3. The user dials the telephone number; those numbers are accumulated and
stored by the session application.
Step4. After enough digits are accumulated to match a configured destination
pattern, the telephone number is mapped to an IP host via the dial-plan
mapper. The IP host has a direct connection t either the destination
telephone number or a PBX that is responsible for completing the call tot
the configured destination pattern.
Step5. The session application then runs the session protocol (H.323 or
SIP/MGCP) to establish a transmission and a reception channel for each
direction over the IP network. If the call is being handled by a Private
Branch Exchange (PBX), the PBX forwards the call to the destination
telephony. If Resource Reservation Protocol (RSVP) has been
configured, the RSVP reservations are put into effect to achieve the
desired QoS over the IP network.
Step6. The coder-decoder compression schemes (CODECs) are enabled for both
ends of the connection and the conversation proceeds using Real-time
Transport Protocol/User Datagram Protocol/Internet Protocol
(RTP/UDP/IP) as the protocol stack.
Step7. Any call-progress indications (or other signals that can be carried inband)
are cut through the voice path as soon as an end-to-end audio channel is
established. Signaling that can be detected by the voice ports (for
example, inband dual-tone multifrequency (DTMF) digits after the call
setup is complete) is also trapped by the session application at either end
of the connection. It is carried over the IP network, encapsulated in the
Real-time Transport Control Protocol (RTCP) using the RTCP
application-defined (APP) extension mechanism.
Step8. When either end of the call hangs up, the RSVP reservations are torn
down (if RSVP is used) and the session ends. Each end becomes idle,
waiting for the next off-hook condition to trigger another call setup.

An Introduction To World-wide Inter-operability for Microwave

Access (Wi –MAX)
Scope:
The Wi-MAX certification mark is given to product that pass conformity and
interoperability test for the IEEE 802-16 standard which caters for the Air interface
standard for point-to-multipoint broad-band Internet access over a wireless
connection.
General details of Wi-MAX:
Wi-MAX is an acronym that stands for World-wide Interoperability for Microwave

Access. It is an ideal method for ISP to deliver high speed broadband to locations
where wired connections would be difficult or costly. Wi-MAX delivers a point-to-
multipoint architecture. It doesn't require a direct line of sight between the source and
endpoint and it has a service range of 50 Kms. It provides a shared data rate of up to
70 Mbps, which is enough to service up to a thousand homes with high-speed access.
The main advantages of Wi-MAX are:
High speed of broadband service upto 70 Mbps.
Wireless rather than wired access, so that it would be a lot less expensive than cable
or Digital Subscriber Line (DSL) and much easier to extend to suburban and rural
areas.
Broad coverage like the cell phone network instead of small Wi-Fi hotspots , 50 Kms.
There are following, two corresponding Wi-MAX standards:
IEEE 802.16-2004 is for fixed point-to-point and point-to-multipoint wireless access.

It is akin to a faster, airborne version of Digital Subscriber Line (DSL) or cable-
modem services, It is also called first Non Line of Sight (NLOS), Broad-Band
Wireless access (BWA) standard.
IEEE 802.16e is for mobile wireless access from laptops and hand held. It is
analogous to a faster version of third-generation (3G) telecommunications technology.
(Wi-Max proponent Intel Corp. has promised 802.16e-enabled laptops by early 2007)
True roaming cell-like wireless broadband , is IEEE standard 802.20, which is

compatible with Wi-MAX.
Working of Wi-MAX:
Wi-MAX operates similar to Wi-Fi but at higher speeds, over greater distances and
for a greater number of users. It consists of following two parts:

A Wi-MAX tower, similar in concept to a cell-phone tower, and which can provide
coverage to a very large area as big as 3,000 square miles (~8,000 square km).
A Wi-MAX receiver, and antenna could be like a PCMCIA (Personal Computer

Memory Card International Association) card, or they could be built into a laptop
similar to Wi-Fi access.
It can provide two forms of wireless service:
The non-line-of-sight, Wi-Fi sort of service, where a small antenna on your computer
connects to the tower. In this mode, Wi-MAX uses a lower frequency range - 2 GHz
to 11 GHz (similar to Wi-Fi). As lower-wavelength transmissions are not as easily
disrupted by physical obstructions they provided non line of sight coverage.
The line-of-sight service, where a fixed dish antenna points straight at the Wi-MAX
tower from a rooftop or pole. The line-of-sight connection is stronger and more stable,
so it is able to send a lot of data with fewer errors. Line-of-sight transmissions use
higher frequencies, with ranges reaching a possible 66 GHz. At higher frequencies,
there is less interference and lots more bandwidth as shown in Figure.
Wi-MAX operates on the same general principles as Wi-Fi. A typical Wi-MAX

network sends data from one computer to another via radio signals. A computer
(either a desktop or a laptop) equipped with Wi-MAX would receive data from the
Wi-MAX transmitting station, using encrypted data keys to prevent unauthorized
users from stealing access. The fastest Wi-Fi connection can transmit up to 54
megabits per second under optimal conditions. Wi-MAX should be able to handle up
to 70 megabits per second. Even once those 70 megabits is split up between several
dozen businesses or a few hundred home users, it will provide at least the equivalent
of cable-modem transfer rates to each user.

The Wi-MAX protocol is a way of networking computers together Wi-MAX does not
conflict with Wi-Fi. It is designed to interoperate with Wi-Fi and may indeed
complement it. This complementarity to Wi-Fi also extends to all flavors of wired
Ethernet (IEEE 802.3), token ring (IEEE 802.5) and non-IEEE standards that use the
same Logical Link Control (LLC) including Fiber Distribution Data Interface (FDDI)
and cable modem Data Over Cable Service Interface Specification (DOCSIS).
Technical Advantage of Wi-MAX:
IEEE 802.16 networks use the same Logical Link Controller (standardized by IEEE
802.2) as other LANs and WANs. It can be both bridged and routed to them. Wi-
MAX is a wireless Metropolitan Area Network (MAN) technology that can connect
IEEE 802.2 (Wi-Fi) hotspots to the Internet and provide a wireless extension to cable
and DSL for last mile (last km) broadband access. IEEE 802.16 provides up to 50 kms
(31 miles) of linear service area range and allows users connectivity without a direct
line of sight to a base station. Note that this should not be taken to mean that users 50
kms (31 miles) away without line of sight will have connectivity. The technology also
provides shared data rates up to 70 Mbps, which, according to Wi-MAX proponents,
is enough bandwidth to simultaneously support more than 60 businesses with T1-type
connectivity and well over a thousand homes at 1Mbps DSL-level connectivity.
An important aspect of the IEEE 802.16 is that it defines a MAC layer that supports
multiple Physical Layer (PHY) specifications .The MAC is significantly different
from that of Wi-Fi (and Ethernet from which Wi-Fi is derived).
In Wi-Fi, the Ethernet uses contention access: all subscriber stations wishing to pass
data through an access point are competing for the Access Points (AP's), attention on
a random basis. This can cause distant nodes from the Access Point (AP) to be
repeatedly interrupted by less sensitive, closer nodes, greatly reducing their
throughput. By contrast, the 802.16 MAC is a scheduling MAC where the subscriber
station only has to compete once (for initial entry into the network). After that it is
allocated a time slot by the base station. The time slot can enlarge and constrict, but it
remains assigned to the subscriber station meaning that other subscribers are not
supposed to use it but take their turn. This scheduling algorithm is stable under
overload and over subscription (unlike 802.11). It is also much more bandwidth
efficient. The scheduling algorithm also allows the base station to control Quality of
Service (QoS) by balancing the assignments among the needs of the subscriber
stations.
The Wi-MAX outdistances Wi-Fi by miles. Wi-Fi's range is about 100 feet (30
metres). Wi-MAX will blanket a radius of 30 miles (50 kms) with wireless access.
The increased range is due to the frequencies used and the power of the transmitter.
Wi-MAX is both faster and has a longer range than Wi-Fi. However, Wi-MAX does
not necessarily conflict with Wi-Fi but is designed to interoperate with it and may
indeed complement it.
Wi-MAX (IEEE 802.16) Specifications:
Range: 30 miles (50-kms) radius from base station.
Speed: 70 Mbps.
Line-of-sight not needed between user and base station.

Frequency bands: 2 to 11 GHz and 10 to 66 GHz (licensed and unlicensed

bands).
Defines both the MAC and PHY layers and allows multiple PHY-layer
specifications.
Network Scale:
The smallest-scale network is a Personal Area Network (PAN). A PAN allows
devices to communicate with each other over short distances. Bluetooth is the best
example of a PAN.
The next step up is a Local Area Network (LAN). A LAN allows devices to share
information, but is limited to a fairly small central area, such as a company's
headquarters, a coffee shop or your house. E.g. Wi-Fi to connect the network
wirelessly.
Wi-MAX is the wireless solution for the next step up in scale, the Metropolitan Area
Network (MAN). A MAN allows areas the size of cities to be connected. (Figure )
The Network Scale.Standards
The current 802.16 standard is IEEE Std 802.16-2004. It renders the previous (and
1st) version 802.16-2001 obsolete, along with its amendments 802.16a and
802.16c.IEEE Std 802.16-2004 addresses only fixed systems.
802.16-2004: IEEE Standard for Local and Metropolitan Area Networks Part
16 -- Air Interface for Fixed Broadband Wireless Access Systems
802.16.2-2004: IEEE Recommended Practice for Local and Metropolitan Area
Networks -- Coexistence of Fixed Broadband Wireless Access Systems.
802.16-2001 obsolete by 802.16-2004.
802.16a amendment, obsolete by 802.16-2004.
802.16c amendment, obsolete by 802.16-2004.
802.16e in progress, adds mobility to the standard.
An amendment to the standards, 802.16e, and addressing mobility was concluded in

2005. This is some times called ―Mobile Wi-MAX‖, and should not be confused with
802.20, the planned standards for ―Mobile Broadband Wireless Access (MBWA)‖
itself probably some years away.
The Wi-MAX Difference:
Wi-MAX promises to provide high-speed wireless connectivity more simply and cost-
effectively than current cellular technologies, and it offers the scalability to deliver
affordable broadband access across India. Because its wireless infrastructure can be

extended to provide portable and mobile device support in the future, Wi-MAX has
additional advantages for developing economies such as that of India, that don‘t have
widespread broadband infrastructure already in place. By leapfrogging to the latest
technology, they gain not only the best broadband connectivity when in a fixed
environment, but also the potential to easily add fully mobile high-speed data
connectivity in the future.

Because Wi-MAX is standards-based, it can enable economies of scale that will bring down the cost
of broadband access and ensure interoperability while increasing ease of implementation. Without
standards, proprietary equipment manufacturers provide the entire stack of hardware and software
building blocks, and restrictive licensing can drive up costs. For the service provider, standards-based
products with fewer variants and larger volume production will drive the cost of equipment down.
Competition among vendors will also lower equipment costs, because service providers will be able
to buy from many sources and shop for the best price. For consumers, wireless products will be
differentiated by the service, not the technology, and thus the consumer will benefit from a variety of
competitive and cost-effective solutions that match their communication needs. Table 1 depicts the
throughput comparison between other cellular technologies and Wi-MAX. Wi-MAX delivers greater
throughput and greater scalability to meet consumer‘s needs.
Table1. Comparison of cellular technologies and Wi-MAX:
Cellular Wi-MAX
Metric Edge HSPDA 1xEVDO 802.16-2004 802.16e
Technology TDMA GMSK WCDMA (5 CDMA2K QPSK OFDM/OFDMA Scalable
Family and 8-PSK MHz) QPSK & & 16 QAM QPSK, 16 QAM & OFDMA
and Modulation 16 QAM 64 QAM QPSK, 16AM
& 64 QAM
Peak Data Rate 473 Kbps 10.8 Mbps 2.4 Mbps 75 Mbps (20 MHz 75 Mbps (Max)
channel) 18 Mbps (5
MHz channel)
Average User T-put < 130 < 750 kbps < 140 Kbps 1–3 Mbps 80% pfmc
Throughput Kbps initially of fixed usage
model
Range Outdoor 2–10 kms 2–10 kms 2–10 kms 2–10 kms 2–7 kms
(Avg Cell)
Channel BW 200 KHz 5 MHz 1.25 MHz Scalable 1.5–20 Scalable 1.5–20
MHz MHz
Wi-MAX suits India‘s broadband requirement because, there is no comprehensive

wired communications infrastructure in place today. Wired broadband technologies
like Digital Subscriber Line (DSL) connectivity can reach only about 5 Kms (~ 3
miles) from the central office switches, making them an expensive and unrealistic
option to reach the rural and remote areas of India. Planning and expanding the wired
―last-mile‖ solution is a challenge in these areas. In new localities, it is a challenge for
telecommunications operators to estimate physical wiring infrastructure needed for
future growth, and maintenance and upgrading may necessitate excavating the earth to
lay many Kms/miles of extra cables. Both add significant operational costs.
Cable broadband service is another wired last-mile solution. Most cable

broadband services in India offer just 64 Kbps of connectivity. This is not
significantly faster than a dial-up connection and does little to improve the
Internet user experience. There is also no consistent infrastructure quality or
organization and local Internet service providers, so Internet users don‘t
experience consistent Quality of Service.

9.0 Evolution of Wi-MAX:

The first phase of Wi-MAX technology (based on IEEE 802.16-2004) is
providing fixed wireless connections via outdoor antennae from the first half of
2005. In the second half of 2005, Wi-MAX is available for indoor installation,
with smaller antennae similar to a Wi-Fi access point today. In this fixed indoor
model, Wi-MAX is available for use in wide consumer residential broadband
deployments, as these devices become "user installable," lowering installation
costs for carriers. By 2006, the technology will be integrated into mobile
computers to support roaming between Wi-MAX service areas. Figure 3 depicts
the evolution of Wi-MAX.
Figure -3: Evolution of Wi-MAX.
10.0 Advantages of Wi-MAX:

The broad band Internet access has biggest limitation of last mile solution and higher
data rate. The presently available technologies like Wi-Fi does not provides sufficient
band width coverage is very limited roaming , backhaul, interference and security
are also its limitations. Wi-MAX has been evolved takes care all these limitations.
The coverage area of one site is very large the coverage radius is 50Kms as compare
to Wi-Fi which requires 650 access points to cover 10 Sq Km area. The bandwidth of
70 Mbps is good enough to cater hundreds of home users. Roaming and mobility is
available, security features are better that Wi-Fi.
The Wi-MAX standard offers a great deal of design flexibility including support for
licensed and license-exempted frequency bands, channel widths ranging from 1.5
MHz to 20 MHz, per-connection Quality of Service (QoS) and strong security
primitives. 802.16 is optimized to deliver high, bursty data rates to the subscriber but
the sophisticated Medium Access Control (MAC) architecture can simultaneously
support real-time multimedia and isochronous applications such as Voice over IP as

well. This means that Wi-MAX is uniquely positioned to support applications

requiring advanced QOS, such as Internet telephony & streaming video.
11.0 Indian Scenario of Wi-MAX Role out:
In India, WebSky has created a joint venture with World-Wide Wireless India
(WWWI) to design, build and run a network that could address 75m people. WebSky
will provide the funding and will construct the system while WWWI will contribute
its licensed frequencies in 3.5GHz spectrum, which cover nine large cities, including
Mumbai (Bombay), Delhi, Calcutta, Chennai (Madras), Bangalore and Hyderabad.
The first build-out will occur in the city of Ludhiana, in the Punjab.
Also in India, telecom giant Bharat Sanchar Nigam Limited (BSNL) has announced
plans to roll out Wi-MAX and Wi-Fi services in 10 major cities, including
Hyderabad, Pune, Ahemdabad and Bangalore.The installation and commissioning of
Wi-Fi and Wi-MAX certified equipment of BSNL is under progress and will be rolled
out shortly.
It will build 400 to 500 Wi-Fi hotspots, in the first phase, at public locations such as
airports, hotels, universities and hospitals, and will use Wi-MAX for backhaul and for
some last mile services, complementing its existing fixed, mobile and internet
services across India.
On trial basis BSNL has deployed Cambridge Broadband‘s Vectastar Equipment in
Gurgoan near Delhi. Its CPEs are multi frequency and multi sector. Vectastar‘s
technology product is used for both access and transmission with the network
combining IP based access services with the backhaul of traffic from GSM, 3G, Wi-Fi
and Wi-MAX base stations.
French telecom major Alcatel has joined hands in an agreement with the Centre for
Development of Telematics (CDoT) to set up a global research and development
centre in India for broadband wireless products. The joint venture facility, to be
established in Chennai, will employ 1,000 people and initially work on Wi-MAX
technology. Alcatel believes that broadband wireless and particularly Wi-MAX is
appropriate technology for India keeping in mind the requirements of the rural sector.
Tokyo is having the first major deployment of a Wi-MAX Metropolitan Area
Network (MAN) in the world . The Yozan MetroZone will deliver high speed IP
connectivity with support for voice, video and broadband data services. Airspan
Networks and partner Yozan has commenced trials in the second quarter of 2005 and
the commercial rollout has begun from the fourth quarter of the year. The contract is
valued in excess of $12 million. This is a just a sample of how big the market for Wi-
MAX technologies can be in India.
12.0 Abbreviations:
1. LAN: Local Area Network.
2. AP: Access Point.
3. EP: Extension Point .
4. ISM: Industrial Scientific & Medical
5. MAC: Media Access Control.
6. CSMA/CA: Carrier Sense Multiple Access with
Collision Avoidance.
7. DSL: Digital Subscriber Line .
8. IEEE: Institute of Electrical & Electronics Engineers
9. OSI: Open systems Interconnect.
10. PCMCIA: Personal Computer Memory Card International
Association.
11. NLOS: Non Line of Sight .

12. BWA: Broadband Wireless access

13.C-DoT: Centre for Development of Telematics.
14.LLC: Logical Link Control.
15. DOCSIS: Data over Cable Service Interface Specification.
16. PAN: Personel Area Network.
17. WWWI: Worl-Wide Wireless India.
13.0 References:
1. Article in PC Quest Magazine July 2004 issue.
2. Article in Telecommunications Nov-Dec 2005 issue.
3. Technical article at internet site: http://www.Wi-MAXforum.org.
4. Technical article at internet site: www.proxim.com.


MODULE3 - NIB II Project 1 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MODULE3 - NIB II Project 1 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Bharat Sanchar Nigam Limited Hkkjr lapkj fuxe fyfeVsM

JTO Ph-II DATA NETWORK

BHARAT RATNA BHIMRAO AMBEDKAR

PHASE II SPECIALIZATION TRAINING

Week-III NIB-II Project 1

S No Topic Page No.

3. Label Distribution Protocol 148

OVERVIEW OF NATIONAL INTERNET BACKBONE-II (NIB-II)

Project 1: - MPLS based IP Network infrastructure covering 71 cities along

Mangalor STM –16 link

IP MPLS Core Network

Table 1: City-wise categorization of nodes under NIB-II Project 1

Node type No of Cities Name of cities Devices

A1 5 Chennai, Mumbai, Core router - Cisco 12416

A2 3 Hyderabad, Pune and Core router - Cisco 12410

A3 6 Lucknow, Jullundhar, Core router - Cisco 12410

A4 10 Coimbtore, Chandigarh, Core router - Juniper M40

B1 21 -- Edge Router Cisco 7613

B2 26 -- Edge Router Cisco 7613

MPLS based network is a 2-layer centrally managed IP backbone network designed to

The web caching solution needs to be deployed at 8 cities with International

Services planned to be offered under Project 1:

4. Network Address Translation (NAT) Services

NIB-II Universal Access Gateway infrastructure is conceived as an open

The implementation of the Project 2 shall be deployed in two phases.

Type of Number Name of City

A3 5 Jallandhar, Mumbai, New Delhi, Lucknow, Patna,

B1 6 Agra, Noida, Jammu, Amritsar, Ludhiana, Shilong

B2 8 Jamshedpur, Durgapur, Siliguri, Dehradun, Ferozpur, Shimla,

Type of Number Name of City

A2 3 Hyderabad, Ahemedabad, Pune

A3 3 Ernakulam, Indore, Jaipur

A4 7 Coimbatore, Maangalore, Vijaywada (Krishana),

B1 15 Madurai, Trivandrum, Mysore, Vizag, Bhopal, Gwalior,

B2 18 Trichy, Pondicherry, Cannanore, Palghat, Trichur, Belgaum,

Components of Narrow Band Access Network

Components of Broad Band Access Network

SSSS/SSSC (Subscriber Service Selection System/ Centre)

Broadband connectivity Diagram in A cities

Broadband connectivity Diagram in B cities

Components of the Solution:

Network Operation Center (NOC)

Conceptual view of eMS, NMS, EMS OSS/BSS for NIB-II

Fig. 5: Bangalore NOC Connectivity Architecture.

Service Level Agreement (SLA):

WEB SELF CARE PORTAL/IVRS (CTI)

Billing & Wholesale

Provisioning Payment Reporting

MIDDLEWARE-ENTERPRISE APPLICATION INTEGRATION (EAI)

NIB-II Network Infrastructure (NE&NEManagers) All NIB-II Servers (Networking and

Services provided by portal to the customers

Customer Interface Management &Order Entry and Validation:

Work Flow Management:

involves the steps of qualification, reservation, configuration and verification

Subscriber Provisioning Management System (SPMS)

HELP DESK AND TROUBLE TICKETING

Authentication, Authorization and Accounting

OVERVIEW OF MPLS TECHNOLOGY AND QOS

Basic MPLS VPN Overview and Configuration

The following topics will be covered in this chapter:

Provider network— Used by the service provider to offer dedicated point-to-point

Depending on the service provider's participation in customer routing, the VPN

Overlay VPNs were initially implemented by the SP by providing either Layer 1