Idea - IPRAN - HLD 2.2

Idea IP RAN
High Level Design Document

This document covers the broad level design and schemas useful for network
planners and implementation team to create Low Level Design and
Configuration Scripts.
INDEX OF TABLES
TABLE 1: CIRCLE CODES ...................................................................................................................................................... 9
TABLE 2: CITY CODES .......................................................................................................................................................... 9
TABLE 3: LINK CODES ......................................................................................................................................................... 10
TABLE 4: BANDWIDTH CODE .............................................................................................................................................. 10
TABLE 5 : RR PARAMETERS ..................................................................................................................................................... 53
TABLE 6 : BGP PROTOCOL VALUES ..................................................................................................................................... 57
TABLE 7: OSPF PROTOCOL VALUES .................................................................................................................................... 60
TABLE 8: LDP PROTOCOL PARAMETERS ............................................................................................................................. 63
TABLE 9: RSVP PROTOCOL PARAMETERS ........................................................................................................................... 64
TABLE 10: CNMS STRINGS .................................................................................................................................................. 73
TABLE 11: IPRAN AND NLD NNI LOCATIONS ....................................................................................................................... 74
TABLE 12: TRAFFIC TYPES TO BE MIGRATED ...................................................................................................................... 76
TABLE 13: QUALITY OF SERVICE PARAMETERS .................................................................................................................. 81
TABLE 14: O&M SERVICES OVERVIEW ............................................................................................................................... 89
TABLE 15: SNMP VERSIONS................................................................................................................................................ 89
TABLE 16: SNMP COMMUNITY STRING (CIRCLE) ............................................................................................................... 90
TABLE 17: GENERAL IPRAN CONFIG GUIDELINES ............................................................................................................ 102
TABLE 18: VRRP PROTOCOL VALUES .............................................................................................................................. .109
TABLE 19: SECURITY GUIDELINE ...................................................................................................................................... 110
TABLE 20 : RECOMMENDED PROTOCOL TIMER VALUES ................................................................................................. 114
TABLE 21: ASR 9010 BILL OF MATERIAL ........................................................................................................................... 119
TABLE 22: ASR 9006 BILL OF MATERIAL ........................................................................................................................... 120
TABLE 23: LOCATION WISE DISTRIBUTION OF IP RAN ROUTERS ...................................................................................... 121
Copyright 2016 Nokia Solutions & Networks. IP RAN High Level Design – version 2.2 2
All rights reserved.
1. Document Information
1.1 Document Author

Avdhesh avdhesh.goyal@Nokia.com
Goyal
Abhishek abhishek.mittal@Nokia.com
Mittal
Mahesh mahesh.modak@Nokia.com
Authors Modak
Senthil senthil.1.kumar_b@Nokia.com
Kumar B
Santosh santosh.r.gupta29@Nokia.com
Gupta
Mangesh Mangesh.mehta@nokia.com
Mehta
Mitrabh Shukla mitrabh.shukla@Nokia.com

Reviewers
Gavin Rego garego@cisco.com
1.2 Document Approver

Bhaskar Patel bhaskar.patel@idea.adityabirla.com
Approvers
Vishal Verma vishal.verma1@idea.adityabirla.com
Milin Shah milin.shah@idea.adityabirla.com
Neelesh Balani neelesh.balani@idea.adityabirla.com
1.3 Version Control
Version Change Date Change description
no. requested by
1.0 16th Aug 2013 Draft Document created
1.1 Idea 26th Aug 2013 Changes as per the meeting with Idea
team
1.2 Idea 27th Aug 2013 Changes in diagrams and addition of

few additional items like LBS, RAS etc.
1.3 Idea 2nd Sep 2013 Changes in write-ups and explanation of

exception locations.
1.4 Idea 5th Sep 2013 Changes in diagrams
1.5 Idea 30th Jun 2014 Added Delhi circle in HLD
1.6 Idea 8th July 2014 Added EPFT & Enterprise ILL features
1.7 Idea 9th July 2014 Added Bihar Circle
1.8 Idea 8th Aug 2014 Added KOL, RoB, NE, Assam &
Chennai Circles
1.9 Idea 28th Aug 2014 Added Pune – Sharda Centre
2.0 Idea 15th July 2015 Pre-Agg layer addition and updation of
Nokia circles.
2.1 Idea 27th Nov 2015 New RR Architecture
2.2 Idea 24th Aug 2016 Removed Non-Nokia Circle,QOS update
1.4 Icons Used
LEGEND
BSC PaCo
SGSN
Routers ASR 9010
RNC
GGSN
MPBN ASR 9006
Router
NodeB
MSS
Gb NLD Routers
Mux MGW Router
BSC MPBN Gb Switch National

Switch Switch RR
OSS L3 Switch
10 Gbps P2P bandwidth on EoSDH Mux (Protected)
10 Gbps P2P bandwidth on DWDM (ASON Protected)
10 Gbps LAN
1 Gbps P2P bandwidth on EoSDH Mux (Protected)
1 Gbps P2P bandwidth on DWDM (ASON Protected)
Figure 1: Network icons used in the document
2. Introduction
This document will focus primarily on proposed IP based RAN network solution and it will cover all key
components of the network design which will help all the key stakeholders to understand the key activity of the
projects.
The document will also help network planners to create Low level Design (LLD) and Network Implementation
plan (NIP) which typically covers micro level details of the planning.
The key highlights of the project as per RFP are as per following
 Adequate amount of routing / switching capacity to fulfill future 3G RAN requirements

 Ample of port-density in the router chassis
 Compliance to 10 Gbps interface
 Offloading of IuB, IuPS, IuCS, Gb & Gn interfaces on IP RAN Router to create logical
separation between MPBN and RAN from Security point-of-view
 To accommodate any Future Mobility and/ Or Enterprise services
Nokia Solutions & Networks’ proposal will enable IDEA to take full benefits of its field proven, high capacity
solution based on market leader ‘Cisco’. This solution is aligned to take into account all these factors and
comprises of
 Cisco ASR 9010 supports a switching capacity of 1.76 Tbps and ASR 9006 supports
upto 880 Gbps Full Duplex
 Cisco ASR 9K can scale upto 220 Gbps per slot
 SUP / RSP will be configured in active / standby mode
 Support XFP based 10 GE / 100 GE interfaces
 Support BNG
 Proven experienced local services capability for multi vendor integration in 2G & 3G
 Robust platform with standard interfaces to rollout new services like 2G, 3G, Mobile
backhaul, multicast, BNG
Nokia Solutions & Networks, acting as a solution integrator, leverages its considerable IP and mobile skills, as
well as the assets of Cisco to deliver a remarkably affordable solution. Cost-effective and scalable, the MPBN
is an IP/MPLS-based backbone that puts CSPs in the driver’s seat for mobile broadband. It provides the
transport power and performance capability CSPs need to satisfy skyrocketing demand for data services, grow
as they go, and sustain their business for the long haul.
2.1 Scope
The Scope of this document is to provide all the proposed changes and their overview in all 10 circles of Idea’s
IP RAN network. This includes proposed physical topology, routing protocol (IGP), BGP peering, QoS
Schema, MPLS VPN, TE, Redundancy mechanism etc.
Each circle has single / multiple MPBN Locations called sites based on their size. As per the proposed
solution, each site is either categorised as “Type-1” or “Type-2” location. Type-1 Location will have a new pair
of Cisco ASR9010 router and Type-2 locations will have a pair of Cisco ASR9006 router:
3. Network Architecture
As per IDEA’s requirement, Nokia Solutions & Networks has proposed architectural changes in the existing IP
network for providing 2G, 3G and 4G backhaul for its 6 circles. The new IP RAN Router will be used as Multi-
Services Edge Router to backhaul all kinds of layer 2 access traffic for services like GSM, UMTS, Wi-Fi and
LTE.
The existing circles have MPBN network running on IP/MPLS with single / multiple MPBN Locations based on
the size of the circle.Currently RNC, BSC and NodeB are connected on MPBN. All 25 IP RAN Locations will
be part of common AS number. The IP RAN router will have ebgp peering with MPBN, PaCo routers and iBGP
peering with NLD routers.
Following interfaces will be in focus throughout this document:

 GboIP interface (BSC-SGSN)
 IuPS CP/UP interface (RNC-SGSN/GGSN)
 IuCS interface (RNC-MSS/MGW)
 IuB interface (NodeB-RNC)
 Iur interface (RNC-RNC)
 LI, Gn, Ga, Gx, Gy & Gz (SGSN-GGSN)
 OSS/O&M (RNC and NodeB)
 eNodeB
 S1C,S1U,MME,S6a,S11,SGs,S10,
Following ip address pool will be used for all loopbacks, WAN and LAN interfaces on IP RAN routers.
IP POOL 10.220.0.0/18
Router Naming Convention:

As per the existing policy of Idea, all the routers deployed in IDEA’s RAN Network will have a hostname 13
characters long which is based on the below logic to make them unique in the network.
<Circle Name><City Name><Location code><Service Type><NE type><Instance No.>
<XX> <XXX> <XXX> <XX> <X> <XX>
<Circle Code> is 2 alphabets representing circle name.

<City Code> is 3 alphabets representing city name.
<Location Code> is 3 alphabets indicating one of the multiple facilities in a city.
<Service Type> is 2 alphabets indicating Service Type (Mobile Backhaul is represented as MB).
<NE type> is 1 alphabet indicating NE type (Router is represented as R).
<Instance No.> is 2 digits indicating one of the multiple NE in that location (01-99).
Please refer the tables below for Circle Code, City Code and Location Code.
Sr. No. Circle Name Circle Code

1 Maharashtra MH
2 Uttar Pradesh (East) UE
3 Uttar Pradesh (West) UW
4 Kerala KL
5 Delhi DL
6 Bihar BH
Table 1: Circle Codes
City
Circle City City Code Circle City Code
Pune – Vega Centre PUN Meerut MRT
Pune – Sharda
Centre PUN UP(West) Moradabad MRD
Aurangabad-2 ARB Agra AGR
Maharashtra &
Panjim PNJ Dehradun DHN
Goa
Nagpur – 2 NGP Lucknow-1 LKO
Nashik – 2 NSK Lucknow-2 LKO2
Kolhapur – 2 KLP Gorakhpur GKP
UP(East)
Pune – VC 5th Floor PUN Varanasi VNS
Bihar Patna-2 PAT Kanpur KNP
Ernakulam ERN Azamgarh AZM
Kerala Calicut CLT
Trivandrum TVP
Noida E5 NDA
Delhi Vikaspuri VKP
MCIE MCI
Table 2: City Codes
Interface Naming Conventions:
Below standard Interface Nomenclature is proposed where first 68 characters are fixed & 69th to further
characters are variables. We have illustrated one example to explain in detail.
<A-Location-B-Location>;<A-NE hostname>; <B-NE hostname>;<link type & no>;<BW in Mbps>;<
Transmission circuit ID>;< A-NE interface>;< B-NE interface>;
Device name: as configured on the remote device

Interface Name/Number: Short name of remote Interface along with its interface ID (Example:
Gigabitethernet0/0/1 should be written as “Gig0/0/1”)
Circuit_ID: as provided by circuit provider.
Sr. No. Link Type Description Code

1 WAN Router to Router WAN link & Router W
to Router local L3 connectivity
2 LAN Router to Switch & Switch to switch L
3 NNI Inter domain connectivity i.e. MPBN N
to NLD, MPBN to PACO, MPBN to IN,
NLD to PACO, IPRAN to MPBN,
IPRAN to NLD etc.
4 Customer External customer links i.e. Enterprise C
VPN, Internet VPN etc.
5 Access Link For NodeB, BTS, BSC etc. A
Table 3: Link Codes
Bandwidth Code
E1 000002M
DS3 000045M
STM-1 000155M
STM-4 000620M
1G 001000M
10G 010000M
100G 100000M
Table 4: Bandwidth Codes
3.1 IP RAN Network Architecture for NOKIA circles
Vikaspuri
Nagpur-2
MCIE
Kolhapur-2
Nasik-2
Aurangabad-2
Goa Noide-E5
Pune-SC
Pune-VC 2 PUNE R2 Delhi
R1
Agra
Maharashtra
Pune
Dehradun
ME
R1
Noida TX
ER
Moradabad
UT
NLD CORE
BGP FREE Lucknow-2 R2
Kakanad Logical Fully Meshed UP-W

Patna-2 UP-W
R2
R1 UP-E
Ernakulam R1 Varanasi
R1 R2
Trivanduram
Gorakhpur
Calicut Patna-2 R2
LUCKNOW-2
Azamgarh
BIHAR Lucknow-1 Kanpur

Kerala BIHAR
Figure 2: IP RAN Network Architecture of Nokia Circle
Below is the diagram for Proposed Architecture
eNodeB
eNodeB
VPNv4 Services
NodeB
Pre-Agg Network IPRAN Network
NLD-MPLS NodeB
National IPRAN Network Pre-Agg Network
RR
BTS
BTS
BGP – LU
BSC iBGP (AS 55644) with Hierarchical LSP BSC
BGP – LU BGP – LU BGP – LU BGP – LU BGP – LU BGP – LU
IS-IS L2 OSPF (Leaf Area) OSPF (Backbone Area) OSPF (Leaf Area) IS-IS L2
LDP LDP LSP LDP LDP LSP LDP LDP LSP LDP
RSVP RSVP RSVP
Figure 3: IP RAN Network Architecture (Proposed)
3.2 Circle Level Network Architecture & Traffic Flow
The current and proposed network architecture with the flow of different types of traffic are illustrated in this
section.
Figure 4: Circle Level IP RAN Network Architecture (Proposed)
PAN India Pre-Agg Network will have multiple circles and each circle will have multiple sites where Cisco ASR
903 will be deployed. Each Pre-agg will have its nearest IP RAN router as aggregator which in turn will have
RR-based BGP peering with all other IP RAN routers of the circle. LDP will be used in Pre-Agg network with IP
FRR (LFA). Different IGP domains would be used in IPRAN & Pre-agg layer. There will be re-distribution
between OSPF & IS-IS in IP RAN routers only for loopback IP address.BGP-LU would be used between
IPRAN & Pre-agg to exchange the Label information for Loopbacks. All the Pre-Agg & IP RAN routers would
be in single AS & IP RAN would act as RR for access layer routers.
DELHI CIRCLE:
Current Architecture
NLD-MPLS
Noida-E5 NLD
GGSN
P routers
SGSN
Noida-E5
PaCo Routers
RNC
BSC
GGSN
SGSN Noida-E5
PACO Vikaspuri RNC
Network IPRAN Network

MCIE
BSC
MCIE PaCo
RNC
Routers
BSC
Delhi MCIE
Noida-E5
Noida-A68
MPBN Network
CS-Core / STP / OSS / IN Vikaspuri
Figure 5: Delhi Circle Transmission Topology
o Above diagram shows the proposed connectivity of the Delhi circle.

o IPRAN routers is deployed at 3 locations which are Noida-E5, Vikaspuri & MCIE.
o MSS and MGw remains on MPBN routers.
o Only BSCs to be migrated on IPRAN routers.
o For R- BSCs:
o Provisioned on L2-EoSDH on IPRAN router pair.
Aggregation point is MUX. The gateway IP is IPRAN router pair and VRRP heartbeat for
BSCs is passed from mux.
o The current gateway IP in all BSCs is the VRRP IP in IPRAN routers and two additional IP addresses
from the same subnet is used as the interface IPs on IPRAN routers.
o UNI service integration is on 1G interface.
o NNI service integration on 10G interface (subject to availability of 10G interface).
o Gb traffic of Delhi circle will be switched from Delhi MCIE PACO routers to individual IPRAN location.
o The Gb traffic from all IPRAN locations traverse till Noida-E5 IPRAN location.
o After reaching at Noida-E5 IPRAN, Gb traffic will go to Noida-E5 PACO router to reach SGSN node.
o Both the Gb & the Gn traffic will be locally switched at Noida-E5 PACO routers as both SGSN and
GGSN are connected to same router pair.
o Below diagram shows the IPRAN transmission topology.
SGSN GGSN
Noida-E5 PACO
routers
NLD-MPLS BSC
SGSN GGSN
RNC
Noida-E5 PACO
NLD P Gn and Network
routers IuPS
3 X MCIE PACO
Noida- 1G routers
3 X R1 E5 R2
1G R1
R1 IPRAN Network
MCIE
Vikaspuri
3 X
R2 1G R2
RNC BSC
BSC RNC
Noida-A68
Noida-E5 Vikaspuri
MPBN Network
MCIE
CS-Core / STP / OSS / IN
Figure 6: Delhi Circle Transmission Topology (Transmission)
Proposed Architecture
NLD-MPLS
Noida-E5 NLD
GGSN
P routers
SGSN
Noida-E5
PaCo Routers
RNC
BSC
GGSN
SGSN Noida-E5
PACO Vikaspuri RNC

MCIE
BSC
MCIE PaCo RNC BSC

Routers
RNC BSC
Noida-A68
Delhi MCIE
Noida-E5
Delhi circle MPBN Network

Pre-Agg Network
CS-Core / STP / OSS / IN Vikaspuri
Figure 7: Delhi Circle Proposed Architecture
o There will be 1+1 deployment of PRE-AGG router in Delhi circle.

o Each PRE-AGG router is RR-client with its respective IPRAN location.
o In future if there comes another sub-PRE-AGG layer router then that router will be RR client of its
respective PRE-AGG layer router. That PRE-AGG router will run ISIS Level-1-2 & sub-PRE-AGG
layer router will run ISIS Level-1.
o We will use different IGP for logical separation of the layers. ISIS Level-2 will be used as an IGP
between IPRAN & PRE-AGG routers.
o We will run LDP & Seamless MPLS feature on PRE-AGG & on IPRAN routers.
o For carrying different traffic type we will enable iBGP & MP-BGP feature between IPRAN & PRE-AGG
routers.
o Node-Bs, BTSs and BSCs will be migrated to the PRE-AGG routers.
o From each TCU card 6 sub-interfaces would be configured towards Pre-agg location. Out of these 6
sub-interfaces, 3 sub-interfaces (IuB, Abis & OAM) would be terminated on Router-1 & 3 would be
terminated on Router-2 to achieve the complete redundancy of IuB, Abis & OAM.
o For standalone 3G sites where we don’t have TCU card, VRRP would be configured on Pre-agg
routers for IuB & OAM traffic.
o We will run static + BFD sessions between PRE-AGG routers & TCU for primary & secondary links for
faster link failure detection.
o There will be 3 interfaces between each PRE-AGG router & EVO-BSC. Following is the traffic
distribution on each interface:
1. Gb.
2. OAM.
3. LBS, SYNC, PABIS, AoIP & 2G_SIGNALING.
o We will also run static + BFD sessions between PRE-AGG routers & E/// EVO BSC for primary &
secondary links for faster link failure detection.
o We will also put static route with higher metric between PRE-AGG routers for reaching EVO BSC.
o There will be 6 traffic types that will be traversing between IPRAN & PRE-AGG routers. They are Gb,
AoIP, OAM, LBS, SYNC & 2G_SIGNALING.
o After reaching at IPRAN router following is the segregation of traffic:
1. OAM, LBS, AoIP & 2G_SIGNALING will be forwarding towards MPBN.
2. Gb traffic will be forwarding towards PACO.
3. SYNC will be locally switched with TOP server.
o The Gn traffic of Delhi will be locally switched as SGSN and GGSN are connected to same PACO
routers.
MAHARASHTRA CIRCLE:
BSC RNC
RNC
BSC RNC
BSC
RNC
Pune VC2
Kolhapur-2 Aurangabad-2
BSC Goa RNC
Pune
IPRAN Network Nashik-2
RNC Sharda BSC

Center
BSC Pune-Vega Nagpur-2

BSC Centre RNC
RNC
GboIP & IuPS BSC
PaCo
IuCS
Routers
GGSN
Nagpur-2
Pune-
Pune-Vega Sharda
Pune s
cle Centre Nagpur-1
SGSN Cir
er
th
fo
co
affi
tr Nashik-2 Aurangabad-1
Gn
MPBN Network
Nashik-1
NLD P Aurangabad-2
Routers Goa
NLD-MPLS
Solapur
CS Core / STP / OSS
Kolhapur-2
Kolhapur-1
Figure 8: Maharashtra Circle Transmission (Current)
o Above diagram shows the proposed connectivity of the Maharashtra circle.

o IPRAN routers deployed at eight locations in Maharashtra circle.
o Pune – VC is the hub location for the circle IPRAN traffic.
o IPRAN spoke locations are Pune - Sharda Center, Nagpur-2, Nashik-2, Aurangabad-2, Kolhapur-2,
Pune VC2 and Goa.
o MSS and MGW is on MPBN routers.
o RNCs, NodeB and BSCs would be migrated on IPRAN routers.
o The co-located NWI and non-NWI BSCs of IPRAN location terminates on the IPRAN routers via
MPBN switches bypassing the MPBN routers. The gateway IP configured on IPRAN router and VRRP
heartbeat for non-NWI BSC will be passed from BSC switch.
o The co-located NWI and non-NWI BSCs of non-IPRAN location connected to mux from MPBN
switches and then carried to the IPRAN location via transmission Mux bypassing the MPBN routers.
The gateway IP configured on the nearest IPRAN router pair and VRRP heartbeat for non-NWI BSC
passed from BSC switch.
o The remote NWI and non-NWI BSCs of IPRAN as well as non-IPRAN locations aggregated on mux at
nearest IPRAN location and then terminate on the IPRAN routers from mux bypassing the MPBN
routers and switches. The gateway IP configured on IPRAN router pair from the existing MPBN router
pair and VRRP heartbeat for non-NWI BSC passed from BSC switch.
o During IPRAN optimization phase, all co-located NWI & non-NWI BSCs at IPRAN and non IPRAN
location directly terminated on nearest IPRAN router pair location, bypassing the MPBN switches.
o For remote non-NWI BSCs, HA provided by IPSLA solution. By default, IPRAN R1 is the VRRP
master and R2 the standby. IPRAN routers send the IPSLA probes towards the BSC to track the
interface status. In case of transmission failures in the path, IPSLA decrements the priority of IPRAN
R1 and IRPAN R2 becomes the VRRP master and R1 as standby. This way, the Gb traffic switchover
is achieved.
o For NWI BSCs, static routes towards IPRAN with BFD feature are used.
o UNI service integration on 1G interface.
o VRRP running for IuPS-UP, IuCS-UP, IuR-UP, IuB, RNC-OAM, Node-B services and VRRP heartbeat
for the respective service passed by the IPRAN router pair for each location.
o For Node-Bs, VRRP heartbeat passed by the Mux.
o IuCS traffic from RNC switched from respective IPRAN routers to MPBN routers through IPRAN-
MPBN NNI as Core Nodes are connected to MPBN router pair.
o Gb and IuPS traffic of Maharashtra circle switched from IPRAN hub location to PACO routers through
IPRAN-PACO NNI as PACO nodes are connected to PACO router pair.
o PACO routers and NLD P routers are connected to Pune – VC IPRAN hub location.
o The Gn traffic of Maharashtra is locally switched as SGSN and GGSN are connected to same PACO
routers.
o The Gn traffic of other circles are sent via NLD to Pune PACO routers via hub IPRAN routers within
Gn vrf.
o SC IPRAN connected to VC IPRAN routers in Hub-spoke fashion. Connectivity to SC IP RAN via VC.
o WAN connectivity between SC IPRAN and VC IPRAN on 1x10G in R1 – R1 & 10G in R2 – R2.
o R1 – R1 & R2 – R2 WAN connectivity on two separate Tx trails.
o LSPs from SC IPRAN routers designed as per established guidelines.
o All existing co-BSCs of SC migrated to IPRAN-SC.
o All BSCs would be directly terminated on SC IPRAN routers.
o EVORNC integrated on IPRAN-SC on 10G port in Active-Standby manner.
o New evoBSC also integrated on IPRAN-SC.
o Port and traffic mapping of evoBSC as confirmed by IDEA circle & E/// team.
o All BSC and RNC prefix at VC and SC advertised on IP RAN Router. The physical port of evoBSC
carrying Gb traffic terminated on IPRAN-SC only while rest of the physical interfaces carrying PAbis,
AoIP, SS7 & OAM traffic terminated directly on MPBN.
o All NodeB would be connected to VC IPRAN only. No NodeBs migrated to IPRAN SC. However, the
corresponding RNC connected to IPRAN-SC.
o WAN bandwidth utilization between SC IPRAN and VC IPRAN is carefully dimensioned due to
complexity of traffic flows. Few scenarios are mentioned below.
o Node-B @ VC, RNC @ SC, SGSN @ SC, GGSN @ VC
o BSC @ VC, SGSN @ SC, GGSN @ VC
o Node-B @ VC, RNC @ SC, SGSN @ VC
o BSC @ SC, SGSN @ VC, GGSN @ VC
o BSC @ SC, SGSN @ SC, GGSN @ VC
o Few nodes pumps 2G + 3G data traffic to SC PaCo while others pumps traffic to VC PaCo. This
implies that both PaCo NNIs carrys live traffic at a time and not be used as complete Active-Standby.
However, both PaCo NNIs act as backup to each other in case of outage scenarios.
o No new NTP connectivity established with SC IPRAN. SC IPRAN receives the Sync source from VC
IPRAN over MP-iBGP peering.
RNC
BSC
RNC RNC
RNC Aurangabad-2
BSC BSC
Kolhapur-2
BSC Goa
Pune-Vega Nashik-2 RNC

Centre 2
BSC
BSC
RNC Pune-Vega
Centre
Pune-Sharda Center
RNC
BSC
Nagpur-2
GboIP & IuPS BSC
RNC
PaCo
IuCS
Routers
GGSN
Nagpur-2
Pune-
Pune-Vega Sharda
Pune s
cle Centre Nagpur-1
SGSN r Cir
he
ot
of
f f ic
tra Nashik-2 Aurangabad-1
Gn
MPBN Network
Nashik-1
NLD P Aurangabad-2
Routers Goa
NLD-MPLS
Solapur
CS Core / STP / OSS
Kolhapur-2
Kolhapur-1
BS RN BS RN
C C C C
10Gbps RN RN
Interface C C
BS
BS
C
C
Goa Kolhapur-2
Aurangabad-2 RN RN
Pune SC BS
RN C C C
C Nashik-2
IPRAN Network BS
BS
C
C Pune VC2
BS
C Pune- Nagpur-
Vega 2
RN Centre
C
GboIP &
PaCo IuPS RN
Iu BS
Router
CS C
C Pre-Agg Layer
s
GG
SN
Pune Nagpur-
s Pune- - 2
Pun cle
e r Cir Vega Shar Nagpur-
he Centre da 1
SGS ot
c of
N ff i
tra Nashik- Aurangabad
Gn 2 -1
MPBN Network
Nashik-
NLD 1 BS RN
Aurangabad C C
PE Go -2
Router a
NLD-MPLS s
Solap
CS-Core / STP / OSS / IN ur
Kolhap
Kolhap
ur-2
ur-1
Figure 9: Maharashtra Circle Transmission (Proposed)
o There will be 1+0 deployment of PRE-AGG router in MH&G circle.

between IPRAN & PRE-AGG router.
router.
o Node-Bs and BSCs will be migrated to the PRE-AGG router.
o As of now BTS & SIU/TCU are not planned to be migrated on PRE-AGG router.
o From each TCU/SIU card 3 sub-interfaces (IuB, Abis & OAM) would be terminated on Pre-agg
location.
o For standalone 3G sites where we don’t have TCU/SIU, termination will be on PRE-AGG router for
IuB & OAM traffic.
o We will run static + BFD sessions / dynamic routing between PRE-AGG router & TCU/SIU for faster
link failure detection.
1. Gb.
2. OAM.
o We will also run static + BFD sessions between PRE-AGG router & E/// EVO BSC for faster link failure
detection.
o There will be multiple traffic types that will be traversing between IPRAN & PRE-AGG router. They are
Gb, AoIP, IuB, OAM, LBS, SYNC & 2G_SIGNALING.
o The Gn traffic of Maharashtra & Goa will be either locally switched or be carried on IPRAN between
Pune-VC & Pune-SC as SGSN and GGSN are connected at these two PACO locations.
KERALA CIRCLE:
SGSN
RNC
Paco BSC
Kakanad-RAN
Kerala-IP RAN Network

RNC
KER Data PE
TVM
(MX 480)
NLD-MPLS
RNC
Calicut
B’lore Data
PE (MX 480)
MPBN Network
Kakkanad
GGSN
KAR-Paco Choice
CS Core / STP / OSS
Figure 10: Kerala Circle Transmission Topology
o Above diagram shows the current connectivity of the Kerala circle.

o IPRAN routers deployed at 3 locations in Kerala circle.
o Ernakulum-Kakanad is the hub location for the circle IPRAN traffic.
o IPRAN spoke locations are Calicut and Trivandrum.
o MSS and MGw connected on MPBN routers.
o RNCs, NodeB and BSCs migrated on IPRAN routers.
o Migrate all Co-BSCs from PACO router to hub IPRAN routers. For Co-BSC’s gateway redundancy is
not possible at this stage. For achieving load balancing 50% Co-BSCs would be on IPRAN R1 and
50% would be on IPRAN R2. Cable needs to be shifted from IPRAN R1 to R2 or vice versa in case of
any outage. The gateway IP will be migrated to IPRAN router pair from the existing PACO routers.
o For R- BSCs:
o Provisioned on L2-EoSDH connected directly on IPRAN router pair.
Aggregation point is MUX. The gateway IP configured on IPRAN router pair and VRRP
heartbeat for BSCs passed from mux bypassing the Gb router.
o The current gateway IP configured in all BSCs remains unchanged. This IP will become the VRRP IP
in IPRAN routers and two IP addresses from the same subnet used as the interface IPs on IPRAN
routers.
o For Node-Bs, VRRP heartbeat passed by the Mux. In Kerala, most of the NodeBs are standalone. So
there is no redundancy.
o Gb and IuPS traffic of Kerala circle switched from IPRAN hub location to PACO routers through
o The Gn and IuPS traffic of Kerala switched from Kakanad SGSN to Bengalore GGSN via
transmission.
SGSN
RNC
Paco BSC
Kakanad-
RAN
RNC
KER Data PE
TVM
(MX 480)
NLD-MPLS
RNC
Calicut
B’lore Data
PE (MX 480)
MPBN Network
Kakkanad
GGSN
KAR-Paco Choice
CS Core / STP / OSS
Figure 11: Kerala Circle Transmission Topology (Transmission)
SGSN
RNC
Paco BSC
Kakanad-RAN
NLD-MPLS Kerala-IP RAN Network

RNC
KER Data PE
B’lore Data TVM
(MX 480)
PE (MX 480) Calicut
RNC
MPBN Network
GGSN
KAR-Paco Pre-Agg Network
Kakkanad
CS Core / STP / OSS
Figure 12: Kerala Circle Proposed Architecture
o There will be 1+0 deployment of PRE-AGG router in Kerala circle.

router.
location.
IuB & OAM traffic.
1. Gb.
2. OAM.
detection.
o The Gb traffic of Kerala will be carried on IPRAN Kakanad as SGSN is connected at this PACO
location.
o The GN traffic will be carried from Kakanad IP RAN to Bangalore location.
UP EAST CIRCLE:
Noida NLD
P routers
NLD-MPLS
Gb and
IuPS
LKO-2 NLD Gb and

P routers IuPS
Gn
RNC
Meerut
BSC
RNC BSC
SGS
Noida E-5
N
Lucknow-2
Gn
Kanpur
IPRAN Network Gorakhpur BSC
Varanasi
Azamgarh RNC
PaCo
Routers Lucknow-1
RNC BSC
BSC
MCIE GGSN RNC
DELHI
Lucknow-1
Varanasi
MPBN Network Kanpur
RNC
Lucknow-2
CS Core / STP / OSS
Figure 13: UP-East Circle Transmission Topology
o Above diagram shows the current connectivity of the UP East circle.

o IPRAN routers deployed at six locations in UP East circle.
o Lucknow-2 is the hub location for the circle IPRAN traffic.
o IPRAN spoke locations are Varanasi, Gorakhpur, Lucknow1, Kanpur & Azamgarh.
o MSS and MGw remains on MPBN routers.
o RNCs, NodeB and BSCs configured on IPRAN routers.
o For Co-BSCs aggregation point are Gb Switches. Gb switch exchanges VRRP messages between
IPRAN routers R1 and R2. The gateway IP migrated to IPRAN router pair from the existing Gb.
o For R-BSCs:
o Aggregation point for R-BSCs coming on L1 EoSDH is Gb switch. The gateway IP configured
on IPRAN router bypassing the Gb router. Gb switch exchanges VRRP messages between
IPRAN routers R1 and R2.
o Aggregation point for R-BSCs coming on L2 EoSDH is mux. The gateway IP configured on
IPRAN router bypassing the Gb router and switches. Mux exchanges VRRP messages
between IPRAN routers R1 and R2.
o The current gateway IP of Gb router configured in all BSCs would be unchanged. This IP becomes the
VRRP IP in IPRAN routers and two IP addresses from the same subnet are used as the interface IPs
on IPRAN routers.
o During IPRAN optimization phase, we have eliminated Gb switches from the network and all the Gb
traffic from:
o Co-BSCs directly terminate on the IPRAN routers for which there is no redundancy as it is a
single arm BSC. For achieving load balancing 50% Co-BSCs configured on IPRAN R1 and
50% on IPRAN R2.
o R-BSCs directly terminate on the IPRAN routers via mux and VRRP heartbeat passes from
mux. Also individual R-BSCs connected to the nearest IPRAN location instead of coming onto
hub IPRAN location.
o Gb and IuPS traffic of UP East circle reachs at UP West Meerut SGSN via NLD network.
o Gn and IuPS then go towards Delhi MCIE GGSN from UP West Meerut SGSN via NLD network.
Noida NLD
P routers
NLD-MPLS
LKO-2 NLD SGSN

Gb and RNC RNC
IuPS P routers
Gb and BSC
IuPS
BSC
Gn
Kanpur
Meerut
Gorakhpur
SGSN Lucknow-1 Lucknow-2

Noida E-5
Gn BSC
Varanasi
RNC
PaCo
Routers
Azamgarh
MCIE RNC BSC

DELHI
GGSN
Lucknow-1 Varanasi RNC BSC
MPBN Network Kanpur
CS Core / STP / OSS Lucknow-2
Figure 14: UP-East Circle Transmission Topology (Transmission)
Noida NLD
P routers
NLD-MPLS
Gb and RNC
IuPS
BSC
LKO-2 NLD SGSN
Gn
Noida E-5 P routers
Meerut
SGS Gn Gb and
N IuPS
Lucknow-2
PaCo
Routers Lucknow-1
IPRAN Network Gorakhpur BSC

MCIE GGSN Kanpur
DELHI Varanasi
RNC
RNC BSC
Azamgarh
BSC
RNC
RNC BSC
Lucknow-1
Varanasi
Pre-Agg Network MPBN Network

Kanpur
CS Core / STP / OSS Lucknow-2
Figure 15: UP-E Proposed Architecture
o There will be 1+0 deployment of PRE-AGG router in UPE circle.

router.
location.
IuB & OAM traffic.
1. Gb.
2. OAM.
detection.
o The Gb traffic of UPE will be carried on IPRAN Lucknow-2 as SGSN will connected at this IPRAN
Lucknow2 location. Right now the Gb traffic is carried to Delhi PACO as Delhi SGSN is serving the
UPE circle.
o The GN traffic will be carried from Lucknow IP RAN to Delhi PACO.
UP WEST CIRCLE:
SGSN
NLD-MPLS
Noida NLD
P routers
Gn and
IuPS
Noida E-5 RNC
BSC
BSC
GGSN Meerut
RNC
Dehradun
MCIE IPRAN Network Moradabad

DELHI
Agra
PaCo
Routers
BSC
RNC
RNC
BSC
Meerut
Agra
Moradabad
MPBN Network
Dehradun
Figure 16: UP-West Circle Transmission Topology (Current)
o Above diagram shows the current connectivity of the UP West circle.

o IPRAN routers deployed at 4 locations in UP East circle.
o Meerut is the hub location for the circle IPRAN traffic.
o IPRAN spoke locations are Moradabad, Agra and Dehradun.
o MSS and MGw will remain on MPBN routers.
o RNCs, NodeB and BSCs migrated on IPRAN routers.
o Migrate all Co-BSCs from PACO router to hub IPRAN routers. For Co-BSC’s gateway redundancy is
not possible at this stage. For achieving load balancing 50% Co-BSCs on IPRAN R1 and 50% on
IPRAN R2. Cable needs to be shifted from IPRAN R1 to R2 or vice versa in case of any outage. The
gateway IP migrated to IPRAN router pair from the existing PACO routers.
o For R- BSCs:
o Provisioned on L2-EoSDH shifted directly on IPRAN router pair.
Aggregation point is MUX. The gateway IP migrated to IPRAN router pair from the existing
PACO router and VRRP heartbeat for BSCs will be passed from mux bypassing the Gb
router.
o The current gateway IP in all BSCs remains unchanged. This IP becomes the VRRP IP in IPRAN
routers and two IP addresses from the same subnet would be used as the interface IPs on IPRAN
routers.
o During IPRAN optimization phase, individual BSCs shifted to the nearest IPRAN location instead of
coming onto hub IPRAN location.
o Gb and IuPS traffic of UP West circle switched from IPRAN hub location to PACO routers through
o PACO routers and NLD P routers at Noida-E5 are connected to Meerut IPRAN hub location.
o The Gn and IuPS traffic of UP West switched from Meerut SGSN to Delhi MCIE GGSN via IPRAN and
NLD network.
SGSN
NLD-MPLS
Noida NLD
P routers
Gn and
IuPS
Noida E-5 RNC

BSC
BSC
Meerut Dehradun
GGSN
RNC
MCIE
DELHI
Agra
PaCo
Routers
Moradabad
BSC
RNC
RNC
BSC
Meerut
Agra
Moradabad
MPBN Network
Dehradun
Figure 17: UP-West Circle Transmission Topology (Transmission)
SGSN
NLD-MPLS
Noida NLD
P routers
Gn and
IuPS
Noida E-5 RNC
BSC
BSC
GGSN Meerut
RNC
Dehradun
MCIE IPRAN Network Moradabad

DELHI
Agra
PaCo RNC
Routers
BSC
BSC
RNC
Moradabad
Meerut
Agra
MPBN Network
Pre-Agg Network
CS-Core / STP / OSS / IN Dehradun
Figure 18: UP-W Proposed Architecture
o There will be 1+0 deployment of PRE-AGG router in UPW circle.

router.
o From each TCU/SIU card 3 sub-interfaces (IuB, Abis & OAM) would be terminated on Pre-Agg
location.
IuB & OAM traffic.
1. Gb.
2. OAM.
detection.
o The Gb traffic of UPW is carried on IPRAN Meerut as SGSN is connected at this IPRAN Meerut
location
o The GN traffic will be carried from Meerut IP RAN to Delhi PACO.
BIHAR CIRCLE:
SGSN
Delhi MCIE GGSN
BSC
PaCo Routers
Co-located BSC
Remote BSCs
BSC MUX Gb router
BSC
Gb switches
BSC
MUX
Patna-1 Patna-2
MGW
MGW
MSS
MSS
MSS
MSS
MGW Muzaffarpur Ranchi MGW
Figure 19: Bihar Circle Transmission Topology (Existing)
o Above diagram shows the current connectivity of the Bihar circle.

o There are no 3G services in the circle.
o There are 4 MPBN locations in Bihar circle. Patna-1 is the hub location.
o MSS and MGW are parented to the respective MPBN locations.
o All remote BSCs are aggregated at Patna-1 via mux. The aggregated Gb traffic then terminates on the
Gb switches from the transmission mux and then goes towards Gb router which carries the Gb traffic
further to PACO network at DELHI MCIE location.
o Co-located BSC at hub location is terminated on the Gb switches directly and then goes towards Gb
router which carries the Gb traffic further to PACO network at DELHI MCIE location.
o There is no redundancy with Gb router. Gb router is working as a standalone.
o Gb router is connected to MPBN routers only for OAM purposes of BSC.
o All UNI & NNI service integration is on 1G interface.
R-
R- BSC
Noida E5 NLD BSC
Co-
P routers
NLD-MPLS BSC
SDH Ring
R-
Patna-2 NLD R-
BSC
GGSN P routers BSC
SGSN
Noida-E5
PaCo Routers
GGSN PACO Patna-2

Noida-E5
SGSN IPRAN Routers
Delhi MCIE
PaCo Routers
Patna-1
Patna-2
Ranchi
MPBN Network
CS-Core / STP / OSS / IN Muzaffarpur
Figure 20: Bihar Circle Transmission Topology (Proposed)
o Above diagram shows the proposed connectivity of the Bihar circle.

o IPRAN router - 9006 would be deployed at only one location which is Patna-2.
o MSS and MGw will remain on MPBN routers.
o All BSCs would be migrated on IPRAN routers.
o For Co-BSC aggregation point would be Gb Switches. Gb switch will exchange VRRP messages
between IPRAN routers R1 and R2. The gateway IP will be migrated to IPRAN router pair from the
existing Gb.
o For R-BSCs:
o Aggregation point for R-BSCs coming on L1 EoSDH will be Gb switch. The gateway IP will be
migrated to IPRAN router pair from the existing Gb router bypassing the Gb router. Gb switch
will exchange VRRP messages between IPRAN routers R1 and R2.
o Aggregation point for R-BSCs coming on L2 EoSDH will be mux. The gateway IP will be
migrated to IPRAN router pair from the existing Gb router bypassing the Gb router and
switches. Mux will exchange VRRP messages between IPRAN routers R1 and R2.
o The current gateway IP of Gb router configured in all BSCs would be unchanged. This IP will become
the VRRP IP in IPRAN routers and two IP addresses from the same subnet would be used as the
interface IPs on IPRAN routers.
o During IPRAN optimization phase, we will eliminate Gb switches from the network and all the Gb
traffic from:
o Co-BSC would directly terminate on the IPRAN
o R-BSCs would directly terminate on the IPRAN routers via mux and VRRP heartbeat will be
passed from mux. Also we will shift individual R-BSCs to the nearest IPRAN location instead
of coming onto hub IPRAN location.
o UNI service integration will be on 1G interface.
o NNI service integration will be on 10G interface (subject to availability of 10G interface).
o Gb traffic of Bihar circle would reach at DELHI MCIE SGSN via NLD network.
3.3 Site Level IP RAN Network Architecture

The diagram shows the proposed site connectivity for a single location & its connectivity with circle gateway
router, MPBN Router and PaCO routers. The diagrams also explain the traffic flow for various traffic types like
IuPS, IuB, IuCS, Gb & GN traffic between CS/PS Core to BSC, RNC and NodeB.
During IP RAN deployment, RNC, BSC and NodeB connectivity will shift to ASR9010/AS9006 routers as per
existing structure where Primary interface of one type of traffic is connected to R1 and Secondary interface of
that traffic is connected to R2. In some cases, one interface can also carry multiple type of traffic using VLANs
or sub-interfaces.
Based on the RNC/BSC type the site connectivity is divided into 2 categories which are E\\\ specific and
NOKIA specific. Following diagrams show the existing and proposed connectivity for both categories.
BSC Switch
Non-
NWI R- VRRP
VRRP
BSC MUX Node B
Remote BSC
BSC Switch
For Location-A
MUX
NWI
R-
BSC Static route
with BFD
NWI MPBN
Router
Co-BSC MPBN Location-A IPRAN MUX
Switch Route
r
BSC
Switch VRRP
MPBN
P
ST
Switch
R
MPBN MUX
P
Router
ST
IPRAN
MPBN
R
Non-NWI Router
Co-BSC Router VRRP
MUX
MUX
VRRP RNC
Location-D
(non-IPRAN)
Static
route with
VRRP BSC BSC BFD
BSC Switch Switc
Switch h
MUX
NWI
Non-NWI Co-BSC
Co-BSC
Remote BSC
For Location-D R-BSC
Figure 21: E/// specific site topology
o In Ericsson proposed scenario Gb routers and switches are directly terminating the Gb traffic on to the
IPRAN routers.
o For NWI BSC: Two VLANs each for Gb and OAM between BSC and MPBN router pair. One
OAM VLAN between BSC and MPBN R1 and one OAM VLAN between BSC and MPBN R2.
Each of these VLANs are assigned a “/30” IP subnet, making it a point2point connectivity. To
achieve switchover we are using static route with BFD feature. As soon as link goes down,
BFD detects the link failure, and traffic is shifted to secondary link.
o For non-NWI BSC: Single VLAN each for Gb and OAM between BSC and IPRAN router pair.
A “/29” IP subnet is being used for each VLAN in order to provide VRRP based gateway
redundancy both at IPRAN router pair and BSC. Static routes for destinations are configured
with NH as VRRP IP. For exchange of VRRP hellos generated from IPRAN routers for remote
BSCs, vlan is passed through BSC switch pair. To achieve switchover we will be using IP SLA
tracking feature. IPRAN router R1 will configure IP SLA probe for physical IP of BSC switch 1.
As soon as the link goes down, IP SLA tracking feature will decrement the VRRP priority in
such a manner so that IPRAN router R2 will become master. This way we will achieve the
switchover of Gb traffic.
IPRANRouter
BSC Switch
VRRP
VRRP
Non-NWI Co-BSC
BSC Switch
Figure 42: E/// Co-Lo BSC with LAN Switch
IPRANRouter
BSC Switch
VRRP
NWI Co-BSC
BSC Switch
Figure 23: E/// Co-Lo NWIE BSC
o Remote NWI BSC: Remote BSC will be terminated on Pre-Agg router ASR 903. Two VLANs
each for Gb and OAM between BSC and Pre-Agg router pair. One Gb VLAN between BSC
and Pre-Agg R1 and one Gb VLAN between BSC and Pre-Agg R2. If there is only one Pre-
Agg router then both the link will be terminated on one Pre-Agg router.
Each of these VLANs are assigned a “/30” IP subnet, making it a point2point connectivity. To
achieve switchover we are using static route with BFD feature. As soon as link goes down,
BFD detects the link failure, and traffic is shifted to secondary link.
Co-located BSC
Vlan-A (Gb)
Vlan-B (OAM)
NWIE
Pre-Agg R1 BSC
Static towards Gb subnet with NH as BSC Gb IP + BFD

Static towards OAM subnet with NH as BSC OAM IP + BFD
Layer-3 Connectivity
Figure 24: E/// Remote NWIE BSC with single Pre-Agg
Co-located BSC
Pre-Agg R1 Vlan-A (Gb)
Vlan-B (OAM)
NWIE
BSC
Pre-Agg R2
Figure 25: E/// Remote NWIE BSC with pair of Pre-Agg
o Remote non-NWI BSC: Single VLAN each for Gb and OAM between BSC and Pre-Agg router
pair. A “/29” IP subnet is being used for each VLAN in order to provide VRRP based gateway
redundancy both at Pre-Agg router pair and BSC. Static routes for destinations are configured
with NH as VRRP IP. For exchange of VRRP hellos generated from IPRAN routers for remote
BSCs, vlan is passed through BSC switch pair. To achieve switchover we will be using IP SLA
tracking feature. PRE-AGG router R1 will configure IP SLA probe for physical IP of BSC
switch 1. As soon as the link goes down, IP SLA tracking feature will decrement the VRRP
priority in such a manner so that PRE-AGG router R2 will become master. This way we will
achieve the switchover of Gb traffic. If there is only one Pre-Agg router then both the link will
be terminated on same Pre-Agg.
BSC Switch
Pre Agg Router
VRRP
VRRP
Non-NWI Co-BSC
BSC Switch
Figure 26: E/// Remote non-NWIE BSC
o For Remote Evo BSC:

Evo BSC connect to either a pair of Pre-Agg router(Delhi) or a single router. Evo BSC connects
to Pre-Agg with 3 physical cable and the services running between BSC and Pre-Agg are AoIP,
ABIS, O&M, SS& and GB.
Co-located BSC
Pre-Agg R1 Vlan-A (Gb)
Vlan-B (OAM)
Vlan-C (Misc)
EVO BSC
Misc = AoIP, LBS,

Pre-Agg R2 Pabis, Sync

Static towards MISC subnet with NH as BSC MISC IP + BFD
Figure 27: Connectivity between pair of PRE-AGG & EVOBSC
Co-located BSC Vlan-A (Gb)
Vlan-B (OAM)
Vlan-C (Misc)
EVO BSC
Pre-Agg R1 Misc = AoIP, LBS,
Pabis, Sync
Figure 28: Connectivity between single PRE-AGG & EVOBSC
o Co-Located 10Gig Evo BSC

Evo Bsc is connected to IPRAN on 10Gig interface and services run between BSC and IPRAN on
sub-interface.
Co-located BSC
IP RAN R1 Vlan-A (Gb)
Vlan-B (OAM)
1* 10Gig Vlan-C (Misc)
1* 10Gig EVO BSC
Misc = AoIP, LBS,

IP RAN R2 Pabis, Sync

Figure 29: Connectivity of 10G EVOBSC
Nokia Specific BSC:

SGSN
Remote BSC IPRAN

MUX
BSC
PaCo
routers
Remote BSC
(non-IPRAN) MUX Site A
MUX
BSC
Co-BSC
NLD-MPLS
MUX
IPRAN
MUX
MUX VRRP
Node B
VRRP
RNC
Figure 30: NOKIA specific site topology (Current)
o In NOKIA proposed scenario following is the setup of BSCs:

o For Co-BSCs there would not be any redundancy. Co-BSCs will be terminated on directly on IPRAN
routers. For achieving load balancing 50% Co-BSCs would be on IPRAN R1 and 50% would be on
IPRAN R2. Cable needs to be shifted from IPRAN R1 to R2 or vice versa in case of any outage. The
gateway IP will be migrated to IPRAN router pair from the existing PACO routers.
o For R- BSCs all the BSC would be aggregated on IPRAN hub location. Aggregation point will be MUX.
The gateway IP will be migrated to IPRAN router pair from the existing PACO router and VRRP
heartbeat for BSCs will be passed from mux.
Figure 31: Connectivity of Remote Nokia BSC(current)
o For R- BSCs all the BSC would be terminated on Pre-Agg. The gateway IP will be migrated to Pre-Agg router
pair from the existing IPRAN router.
R-BSC
E
Static towards Gb subnet with NH as ESB0 Gb IP
S Static towards OAM subnet with NH as ESB0 OAM IP
B Sub-
interfaces
0
Pre-Agg R1
NOK
BSC
Vlan-A (Gb)
E
Vlan-B (OAM)
S
B
Static towards Gb subnet with NH as ESB1 Gb IP with higher metric
1 Static towards OAM subnet with NH as ESB1 OAM IP with higher metric
Figure 32: Connectivity of Remote Nokia BSC with single Pre-Agg (proposed)
o For R-mcBSC, all the BSC would be terminated on Pre-Agg. The gateway IP will be migrated to Pre-Agg
router pair from the existing IPRAN router. Services will be mapped from mcBSC to Pre-Agg router.
Sync
SYNC PTUM
LBS
LBS M
Pabis, TRX_SIG, OMU_SIG
PABIS O
OAM D
Pre-Agg OAM U
ROUTER-1
GboIP L
GboIP
AoIP-UP
E
AoIP
Sigtran-1 & 2 0
SIGTRAN
4 x 1G Bundle towards mcBSC
mcBSC
OSPF
Sync
SYNC PTUM
LBS
LBS M
Pabis, TRX_SIG, OMU_SIG
PABIS
O
OAM D
Pre-Agg OAM U
ROUTER-2 GboIP L
GboIP
E
AoIP-UP
AoIP
Sigtran-1 & 2 1
SIGTRAN
4 x 1G Bundle towards mcBSC
Figure 33: Huawei Specific Site Topology (Current)
o There is only one type of BSC in Huawei circles.

o BSC sends untagged traffic. One VLAN each for Gb and OAM is tagged by BSC switch between BSC
and Gb switch. Each of these VLANs are assigned a “/28” IP subnet.
o BSC is connected to LAN switch by two cables, one for Gb and one for OAM.
o BSC points a static route towards Gb IP of Gb router which acts as the gateway for Gb traffic.
o In BSC, there is only one LAN (L2) switch and hence it is a single point of failure.
o The PCU card in BSC has one active (Primary) and one standby (secondary) port. The BSC behaves
in Active-Standby mode.
o There is no VRRP running between BSC and the LAN switch.
o The router points two static routes towards BSC’s PCU IPs with next-hop tracking to sense the active
port of PCU.
o Gb traffic comes towards MPBN routers and goes further to PaCo network.
o OAM traffic follows a separate path via AR48 Juniper routers and terminates on M2000.
Figure 34: Huawei Specific Site Topology
o There is only one type of BSC in Huawei circles.

o BSC sends untagged traffic. One VLAN each for Gb and OAM is tagged by BSC switch between BSC
and Gb switch. Each of these VLANs are assigned a “/28” IP subnet.
o In BSC, there is only one LAN (L2) switch and hence it is a single point of failure.
o BSC will be connected to LAN switch by two cables, both for Gb.
o OAM connectivity will be unchanged and OAM traffic will flow to M2000 as it is currently. This traffic
WILL NOT be migrated on IPRAN routers.
o BSC will point a static route towards VRRP IP of IPRAN router which acts as the gateway for Gb
traffic.
o The PCU card in BSC has one active (Primary) and one standby (secondary) port. The BSC behaves
in Active-Standby mode.
o There is no VRRP running between BSC and the LAN switch.
o IPRAN router will point two static routes per BSC towards BSC’s PCU IPs.
o To achieve switchover static route with IPSLA next-hop tracking mechanism would be used to sense
the reachability of next-hop i.e. PCU IP. As soon as link goes down, IPSLA detects the link failure, the
static route is dissolved and traffic is shifted to secondary link.
o Gb traffic comes towards MPBN routers and goes further to PaCo network.
3.4 IPRAN-Pre-Agg Connectivity
Scenerio-1 : Pre-Agg –IPRAN connectivity with Y connectivity at both ends
IPRANRouter
Pre-Agg
Y
connectivity Ring TX
Y
connectivity
o Pre-Agg connected to mux using Y connectivity by 2 physical paths. Only one path will be active at a
time.
o Mux to Mux will have the protection for the path.
o At the other end, the link is terminated on IPRAN using Y connectivity with 2 physical paths.
Scenerio-2 : Pre-Agg –IPRAN connectivity with Y connectivity at IP RAN end parenting to
different IP RAN location
IPRANRouter
Pre-Agg Y
Ring TX connectivit
2 sun-interfaces y
2 sun-interfaces
IPRANRouter
Ring TX
Y
connectivit
y
o Pre-Agg connected to mux by 2 physical paths. Both the paths will be active simultaneously.
o Pre-Agg will be parented to different IP RAN location.
o The other end termination point will be 2 different IP RAN location.
o At the other end, the link is terminated on IPRAN using Y connectivity with 2 physical paths.
Scenerio-3 : Pre-Agg –IPRAN connectivity parenting to different IPRAN location
IPRANRouter
Pre-Agg
Ring TX
Y
connectivity
Pre-Agg
Pre-Agg
IPRANRouter
Pre-Agg
Ring TX
Y
connectivity
o Pre-Agg connected to mux by 1 physical path at one end and will be connected to other Pre-Agg at
other end. Both the paths will be active simultaneously.
o Pre-Agg to Pre-Agg will be connected in Ring fashion with the end Pre-Agg connected to IPRAN via
Mux.
o Pre-Agg will be parented to different IP RAN location.
o The remote end termination point will be 2 different IP RAN location.
o At the other end, the link is terminated on IPRAN using Y connectivity with 2 physical paths with one
path active at a time.
3.5 Route Reflector Architecture
Route reflectors have the special BGP ability to re-advertise routes learned from an internal peer to other
internal peers. So rather than requiring all internal peers to be fully meshed with each other, route reflection
requires only the route reflector to be logical fully meshed with all internal peers. The route reflector and all its
internal peers form a cluster.
Without route reflectors, whenever a new PE is introduced, each existing PE in the Service Provider network
will need to have an extra BGP neighbour command added pointing to the new PE. Requirement in BGP is
that updates received by a peer in the same autonomous system (AS) are not allowed to be forwarded on
within the AS. Therefore a BGP network must be fully meshed, with all peers seen as directly adjacent to one
another, as far as BGP routing updates are concerned.
With Route Reflectors, the PE’s would only require neighbours defined for each route reflector. Any updates,
including VRF information, would be sent to the Route reflectors only. The Route Reflectors are then
responsible for propagating any information received from PE’s to all other PE’s. Each time a new PE is
added, only the Route Reflectors would need to be updated with neighbour statements.
Route Reflectors are also useful for a customer that has connections to several PE’s (dual homing). In the
situation where a route change occurs in the customer network, the PE that terminates that part of the
customer network would have to update every PE peer participating in that VPN. Route Reflectors would
remove the burden of BGP updates from the PE.
Based on the above, Idea’s IP RAN Network will have hierarchical design of route reflectors where two pairs of
M120 router will be dedicated for national level RR functionality. One pair is located at Pune and other pair is
at Noida. RR pair of Pune is using different cluster-id and RR pair of Noida is using different cluster-id. All
these RRs are non-client of each other. Each circle will also have a pair of router which will also play Regional
RR role and this RR will be RR client for National RR. All other sites in the circle will peer to Regional RR and
function as RR client.
Redundancy will be achieved by using R2 of hub location as Primary RR and R2 of non-hub location as
Secondary RR. Mumbai, Delhi & Rajasthan IPRAN routers will connect directly to National RR.
National
Level RR
Pune Delhi
IBGP
National Level RR Client

Circle Level- RR
ASR9K ASR9K
ASR9K ASR9K ASR9K
ASR9K
CIRCLE A CIRCLE B CIRCLE C

Circle Level- RR Client ASR9K ASR9K ASR9K
ASR9K ASR9K ASR9K
iBGP
Peering ASR9K IBGP ASR9K IBGP ASR9K IBGP
ASR9K ASR9K ASR9K
Figure 35: Route Reflector Architecture (Current)
New Architecture for RR.
Currently RR services for IPRAN are provided by NLD RR.As per the new RR architecture, RR services will
be provided by IPRAN RR in addition to NLD RR. Four sites are identified for IP RAN RR i.e. Delhi, Lucknow,
Pune and Kakkanada. RR architecture will in 1+0 in each site. RR will physically connect to nearby IPRAN
sites.
The New IPRAN RR will become the primary RR for all the IPRAN location and NLD PEs. NLD RR will be
secondary RR which will be ceased out eventually after some time.
Details of the RR architecture are mentioned below:
 IP RAN RR planned at four locations in 1+0 fashion.

 Clustering is planned with 2 locations in 1 cluster. Delhi & Lucknow will be in one cluster and Pune &
Kakkanada will be in another cluster.
 Ip & Cluster ID details for RR Routers at these 4 locations is as follows,
Loopbacks
Router ID Cluster ID
Hostname IGP loopback IPs (/32)
10.111.255.249/32 10.111.255.249 1.0.0.1
DLNDAE05NRR01
10.111.255.250/32 10.111.255.250 1.0.0.2

MHPUNVGANRR02
10.111.255.251/32 10.111.255.251 1.0.0.2

KLERNKKDNRR03
10.111.255.252/32 10.111.255.252 1.0.0.1

UELKOTITNRR04
Table 5: RR Parameters
There are 2 points behind the planning of 2 clusters. One point stress on geographic redundancy and
other point is about saving the RIB table.
 Hub IP RAN router from every IP RAN circle will peer with all the four IP RAN RRs. The RIB table will
be populated from both the clusters. Only one router’s route from each cluster will be added in RIB
table. In this way there will be 2 routes for the same destination in the RIB table, one from each
cluster of IP RAN RR. In addition to this, one more route for same destination will be added in RIB
table from NLD RR till NLD RR exists in the network.
 Routes selected for the forwarding table will be decided on IP address of the RR. Route selection
depends on the lowest router-id of the RR. Router ID of these new RR will be lower than that of NLD
RR, so NRR will be preferred.
 There would not be peering between IPRAN RR and NLD RR.
 Following address families will be enabled on this NRR,
o ipv4 unicast
o vpnv4 unicast
o vpnv6 unicast
o ipv4 multicast
o ipv4 mdt
o l2vpn vpls-vpws
o ipv4 labeled-unicast
 BGP-LU would be enabled on all IPRAN RR.

 Redundancy planned at 2 levels wrt to clustering. One level of redundancy is between the clusters
and other within cluster. Apart from this redundancy, NLD RR will provide another layer of
redundancy till it exist in the network. All IPRAN routers will select route from IPRAN RR as primary
and secondary whereas tertiary path via NLD RR.
 Each RR will have one OAM loopback attached to OAM vrf for accessibility purpose.
 Access will be done by connecting the RR with local IT LAN.
 All the RR will be integrated with Syslog, CNMS and RAS before making live in the IPRAN network.
 Route filtering to be applied on circle RR & no policy will be applied on NRR.
 Same Policy which is applied towards NLD on IPRAN, will be applied towards NRR as well.
 RR changes will be governed/approved by IDEA Corporate IP planning team only.
 Upgradation IOS of RR to be governed/approved by IDEA Corporate IP planning team only.
Physical Connectivity of RR:
 New IP RAN RR will be connected to local IPRAN location.

 RR will be connected to IPRAN in 1+0 fashion.
 One router will be placed at each identified RR location.
 RR will connect to both R1 and R2 of local IP RAN routers (electrical port).
 RR will have following BOQ at all RR locations.
o BOQ : 20*1G card MOD-80 (electrical)
 ASR router 9000 series planned for RR.
BOQ of RR
Sr.No Model Description Quantity
A9K- ASR 9000 Mod80 Modular Line Card, Service Edge Optimized, requires
1 1
MOD80 modular port adapters.
ASR 9000 20-port 1-Gigabit Ethernet Modular Port Adapter, requires

A9K-MPA- SFP optics
2 1
20x1GE
NLD RR
IPRAN RR IPRAN RR
Pune Delhi Delhi Pune Kakinada

Lucknow
National Level
ASR9K ASR9K RR
ASR9K ASR9K IBGP
IBGP IBGP IBGP
National Level RR Client
Circle Level- RR
ASR9K
ASR9K ASR9K ASR9K
ASR9K ASR9K
Other IPRAN/
CIRCLE A CIRCLE B CIRCLE C
NLD Routers
Circle Level- RR Client ASR9K ASR9K ASR9K
ASR9K ASR9K ASR9K

iBGP
Peering
ASR9K IBGP ASR9K IBGP ASR9K IBGP
ASR9K ASR9K ASR9K
3.6 Multiprotocol BGP Architecture
BGP is necessary to provide VPN services to Service Provider VPN customers. BGP is used to propagate
VPN routing information.
In the MPLS network each Service Provider defined VPN consists of VPN Routing and forwarding tables
(VRF’s) which are associated with each customer interface. The VRF tables consist of unique VPN-IPv4
addresses, (they are unique as each is prefixed with the Route Distinguisher). Since these are not IPv4
addresses, BGP provides multiprotocol extensions that allow the distribution of these VPN-IPv4 routes.
BGP propagates VPN-IPv4 information using the BGP multiprotocol extensions for handling these extended
addresses. (See RFC 2283, Multiprotocol Extensions for BGP-4.) It propagates reachability information,
expressed as VPN-IPv4 addresses, among the PE routers only. The reachability information for a given VPN
is propagated only to other members of that VPN. The BGP multiprotocol extensions identify the valid
recipients for VPN routing information. All the members of the VPN learn routes to other members.
In Idea network, we propose to deploy following BGP parameters
Protocol characteristics Description
Local AS 65050
Route reflectors Yes
Peer Groups Yes
Confederations No
BGP Attributes
Communities Yes (new format)
Local preference Yes (High on primary, Low on secondary)
MED TBD
Keepalive 30 s (default 60s)
Hold-Down 90 s (default 180s)
Features
Cluster-id Yes ( at Hub location only & different for
R1 and R2)
Graceful-restart Yes ( restart-time=120s stalepath-
time=360s)
Source address Yes (for iBGP); No (for eBGP)

EBGP Multihop No
Authentication Yes (MD5) for eBGP only
Dampening Yes
BFD Yes (min-interval 300ms, multiplier 3)
Next-Hop Tracking Yes (wherever required)
NSR Yes
Table 6: BGP Protocol Values
As shown in the diagram below, In Idea IP RAN network, a single AS will be used for all IP RAN routers. Each
router in circle will have iBGP peering with Regional RR and Regional RR will have iBGP peering with National
RR.
Figure 36: BGP Architecture (Proposed)
3.7 IGP (OSPF) Architecture
OSPF provides a lot of flexibility and hierarchical area structure apart from the following benefit and that is the
reason to choose OSPF for Idea IP RAN Network
 The intelligent use of VLSM is very useful in IP address allocation.
 OSPF uses IP multicast to send link-state updates. This ensures less processing on routers that are
not listening to OSPF packets. Also, updates are only sent in case routing changes occur instead of
periodically. This ensures a better use of bandwidth.
 OSPF allows for better load balancing.
 OSPF allows for a logical definition of networks where routers can be divided into areas. This limits
the explosion of link state updates over the whole network. This also provides a mechanism for
aggregating routes and cutting down on the unnecessary propagation of subnet information.
 OSPF allows for routing authentication by using different methods of password authentication.
 OSPF allows for the transfer and tagging of external routes injected into an Autonomous System. This
keeps track of external routes injected by exterior protocols such as BGP.
Figure 37: OSPF Architecture (Proposed)
As per the above diagram, proposed IP RAN network will have one area for each circle and will be connected
to backbone area 0 that comprises all the NLD routers and connected interfaces toward IP RAN routers. In
Idea IPRAN network following parameters will be used in OSPF deployment. For Mumbai, Delhi and
Rajasthan circles, loopback to be created on IPRAN routers and to be made a part of leaf area.
By using OSPF hierarchy and different areas for different circles, Idea network will get advantage as below:
 Network Scalability
 Reduced frequency of SPF calculations
 Smaller routing tables
 Reduced LSU overhead
Areas One for Each Circle (except DL, RAJ & MUM)
Reference Bandwidth 10 G
Features
Point-to-point links Yes
LDP synchronization Yes
Authentication No
BFD Yes (min-interval 300ms, multiplier 3)
Traffic Engineering extensions Yes
NSF Yes ( IETF)
NSR Yes
Table 7: OSPF Protocol Values
3.8 MPLS VPN Design
The MPLS VPN architecture utilises the services of the Border Gateway Protocol (BGP) to distribute VPN
routing information. BGP was essentially invented to solve a route distribution problem in a very scalable
manner and to provide a mechanism to achieve a loop-free routing topology. Due to its distance vector like
behaviour, and the features implemented to provide stability, BGP by its very nature, does not converge as
quickly as a link-state Interior Gateway protocol. For this reason, additional implementation timers have been
added to speed-up the default convergence times (which are high when compared to an IGP convergence),
and these timers may be adjusted to provide an optimal deployment of the MPLS VPN architecture.
Convergence Points for a VPNv4 routing update
To help understand the components that make up the overall VPN site-to-site convergence time, analysis of
how a routing update is sent from one VPN site to another must be done. With this information, the separate
points of convergence which make up the total end-to-end convergence time can be defined.
There are several different steps that take place when a routing update is flooded from one VPN site to
another. To illustrate each of these steps, the typical backbone design presented in figure below will be used.
Within the figure, multiple convergence points (8 in total) have been shown, as highlighted by T(1-8).
RR #1 RR #2
T3 T5
T6
T1 T4 T7 T8
BGP BGP
VPN A VRF VRF VPN A

VPN A VPN A
Site #1 Site #2
Site #1 Site #2
T2 PE Router PE Router
P Router
Figure 38: VPN convergence points
These convergence points can be defined as follows:
 T1 : PE router receipt of a routing update from a CE router

 T2 : import of local routing information into the corresponding ingress VRF
 T3 : receipt of local routes into BGP on the PE router
 T4 : advertisement of routes to MP-BGP peers
 T5 : receipt of advertised routes into BGP on the PE router
 T6 : import of newly received routes into local VRFs
 T7 : advertisement of routes to CE routers
 T8 : processing of incoming updates by the CE router
VRF forwarding points
VPNv4 Peering
IuPS-CP VRF IuPS-UP VRF
IuPS-UP VRF IuPS-CP VRF
Other Sig VRF Other Sig VRF
er
iB
G
Pe
P
PaCO/RAN VPNv4 RR
Pe
Gn Gn
er
iB
IuB IuB
CDR CDR
LI LI
IuPS/UP IuCS/UP
IuPS/CP IuCS/CP
OAM OAM
IuB OAM
Gn LI
MPBN IuCS-UP VRF IuCS-UP VRF
Gb CDR
Network Other Sig
IuCS-CP VRF IuCS-CP VRF
IP RAN Router (PE) IP RAN Router (PE)
IP Interfaces
Figure 39: MPLS/MPLS-VPN Architecture
The above diagram refers to the separation of routing tables for various type of traffic in Idea’s IP RAN
network using Virtual Route Forwarding (vrf) tables and propagation of vpnv4 routes to other PE using
regional level or national level RR. For any requirement of forwarding between different vrf, route leaking
method should be used. The RD (Route Distinguisher) values will be used in IP:NN format, where IP is
loopback IP of the device and RT (Route Target) will be used in AS:NN format where AS is autonomous
system number used.
3.9 Proposed MPLS-TE: LDP Tunnelling and RSVP Tunnels
Label Distribution Protocol (LDP):
MPLS LDP provides the means for LSRs to request, distribute, and release label prefix binding information to
peer routers in a network. LDP enables LSRs to discover potential peers and to establish LDP sessions with
those peers for the purpose of exchanging label binding information.
MPLS LDP enables one LSR to inform another LSR of the label bindings it has made. Once a pair of routers
communicates the LDP parameters, they establish a label-switched path (LSP). MPLS LDP enables LSRs to
distribute labels along normally routed paths to support MPLS forwarding. This method of label distribution is
also called hop-by-hop forwarding. With IP forwarding, when a packet arrives at a router the router looks at the
destination address in the IP header, performs a route lookup, and forwards the packet to the next hop. With
MPLS forwarding, when a packet arrives at a router the router looks at the incoming label, looks up the label in
a table, and then forwards the packet to the next hop. MPLS LDP is useful for applications that require hop-by-
hop forwarding, such as MPLS VPNs.
LDP provides a standard methodology for hop-by-hop, or dynamic label, distribution in an MPLS network by
assigning labels to routes that have been chosen by the underlying Interior Gateway Protocol (IGP) routing
protocols. The resulting labeled paths, called label switch paths (LSPs), forward label traffic across an MPLS
backbone to particular destinations. These capabilities enable service providers to implement MPLS-based IP
VPNs and IP+ATM services across multivendor MPLS networks.
LDP Protocol characteristics Description

LDP Yes (only with NLD Routers)
Authentication No
Tunnel Characteristics
LDP tunneling Yes
Secondary Paths Yes
Administrative Groups No
Traffic Protection - Fast Reroute No
Bidirectional Forwarding Detection (BFD) No
NSF Yes (IETF)
QoS marking and honoring Yes
Table 8: LDP Protocol Parameters
Resource Reservation Protocol (RSVP):
RSVP is a signaling protocol that reserves resources, such as for IP unicast and multicast flows, and requests
quality-of-service (QoS) parameters for applications. The protocol was extended in MPLS RSVP TE to enable
RSVP to set up label switched paths (LSPs) that can be used for TE in MPLS networks.
RSVP interacts with TE to support the MPLS TE functionality.
The TE process contains the following functionalities:
 End-point control, which is associated with establishing and managing TE tunnels at the headend and
tailend.
 Link-management, which manages link resources to do resource-aware routing of TE LSPs and to
program MPLS labels.
 Fast Reroute (FRR), which manages the LSPs that need protection and to assign backup tunnel
information to these LSPs.
When a router's link or neighboring node fails, the router often detects this failure by receiving an interface-
down notification. When a router notices that an interface has gone down, it switches LSPs going out that
interface onto their respective backup tunnels (if any).
RSVP establishes backup LSP-based tunnels for the local repair of TE LSPs. RSVP uses the facility backup
method in which a PLR creates one or more bypass tunnels that can be used to protect multiple LSPs.
RSVP Protocol characteristics Description

RSVP Yes
Authentication No
Tunnel Characteristics
Secondary Paths Yes with Path Option and pre-signaled
Administrative Groups No
Traffic Protection - Fast Reroute Yes
Bidirectional Forwarding Detection (BFD) No
Explicit Path Yes with Path Option
QoS marking and honoring Yes
Table 9: RSVP Protocol Parameters
The diagram shown below depict the Idea’s high level MPLS architecture with respect to MPLS protocol and
boundaries of LDP and RSVP along with concept of Traffic engineering tunnels between PE’s.
In Idea IPRAN Network we proposed to have RSVP explicit path option tunnels within circle. For inter circle, it
will peer with NLD routers using LDP hence LDP tunnelling (LDP over RSVP TE) will be required for
Gn,Gb,IuPS/CP & IuPS/UP traffic wherever inter-circle LSP are required. Following section explains the
concept of LDP tunnelling.
LDP Tunnelling (LDP over RSVP Tunnels):
The following steps describe how this topology is established and how packets are sent from CE Router CE2
to CE Router CE1:
1. The P routers P1 and P3 establish RSVP LSPs between each other and install their loopback
addresses in their routing tables.
2. PE Router PE1 establishes an LDP session with Router P1 over its directly connected interface
3. Router P1 establishes an LDP session with Router P3’s loopback address, which is reachable using
the RSVP LSP.
4. Router P1 sends its label bindings, which include a label to reach Router PE1, to Router P3. These
label bindings allow Router P3 to direct LDP packets to Router PE1.
5. Router P3 establishes an LDP session with Router PE2 over its directly connected interface and
establishes an LDP session with Router P1’s loopback address.
6. Router P3 sends its label bindings, which include a label to reach Router PE2, to Router P1. These
label bindings allow Router P1 to direct LDP packets to Router PE2’s loopback address.
7. Routers PE1 and PE2 establish IBGP sessions with each other.
When Router PE2 wants to forward a packet to any CE Router, it pushes two labels onto the packet’s label
stack: first the VPN label that is bound to the interface between Router PE1 and CE Router, then the LDP
label used to reach Router PE1. Then it forwards the packets to Router P3 over directly connected interface.
1. When Router P3 receives the packets from Router PE2, it swaps the LDP label that is on top of the
stack (according to its LDP database) and also pushes an RSVP label onto the top of the stack so that
the packet can now be switched by the RSVP LSP. At this point, there are three labels on the stack:
the inner (bottom) label is the VPN label, the middle is the LDP label, and the outer (top) is the RSVP
label.
2. Router P2 receives the packet and switches it to Router P1 by swapping the RSVP label. In this
topology, because Router P2 is the penultimate-hop router in the LSP, it pops the RSVP label and
forwards the packet over it directly connected interface to Router P1. At this point, there are two labels
on the stack: The inner label is the VPN label, and the outer one is the LDP label.
3. When Router P1 receives the packet, it pops the outer label (the LDP label) and forwards the packet
to Router PE1 using its directly connected interface. In this topology, Router PE1 is the egress LDP
router, so Router P1 pops the LDP label instead of swapping it with another label. At this point, there
is only one label on the stack, the VPN label.
4. When Router PE1 receives the packet, it pops the VPN label and forwards the packet as an IPv4
packet to CE router over its directly connected interface.
Figure 40: MPLS-TE (RSVP and LDP Tunnels) Overview
Following diagram shows the structure of MPLS-TE tunnels within a circle. All the spoke location will have 2
primary tunnels (unidirectional) and 2 secondary tunnels (unidirectional). Hub location will have 4 tunnels for
each spoke location connected to it.
LSP Naming Conventions:
Idea should used the existing guidelines (if any), in absence of the same, following can be used:
<Local Device Name>_<Remote Device Name>_<LSP type>_<Seq No.>
Local Device name: as configured on the local device

Remote Device name: as configured on the remote device
LSP_Type: P for Primary; B for backup
Sequence_No : A two digit number starting with 01 upto 99.
Location-1
R1 R2
Primary LSP from Location-1 R1 to Location-2 R1

Secondary LSP from Location-1 R1 to Location-2 R1
R1 Secondary LSP from Location-1 R2 to Location-2 R1

Location-2 Primary LSP from Location-1 R1 to Location-3 R2
R2
Location-3
R1 R2
Figure 41: LSP detailed View
All the traffic will flow via single router (R1 or R2) and there will not be any load sharing.
3.10 Proposed NNI Architecture for Inter AS VPN
The MPLS VPN Inter-AS feature provides a method of interconnecting VPNs between different MPLS VPN
service providers. This allows sites of a customer to exist on several carrier networks (Autonomous Systems)
and have seamless VPN connectivity between these sites.
Section 10 of RFC4364 (obsoletes RFC 2547bis) defines three options defined to provide MPLS VPN
connectivity between different carrier networks as follows:
 Option A - Back to Back VRF connections
 Option B - VPNv4 route distribution between ASBRs
 Option C - VPNv4 route distribution between Route Reflectors in each AS
As per Idea network design, there would be few services running between IPRAN and PaCo network as well
as IPRAN and MPBN network. These services are not expected to increase in future hence it has been
decided that NNI Option A will be used between IP RAN & MPBN routers and between IP RAN and PaCo
Routers.
Figure 42: Sample Inter AS VPN Option-A Schema
In this option, a PE router in one AS attaches directly to a PE router in another. The two PE routers will be
attached by multiple sub-interfaces, at least one for each of the VPNs whose routes need to be passed from
AS to AS. Each PE will treat the other as if it were a CE router. That is, the PE routers associates each such
sub-interface with a VRF, and use a dynamic routing protocol to distribute unlabeled IPv4 addresses to each
other (eBGP would be preferred).
This is a very simple procedure that does not require any exchange of labels between the AS. However, it is
the least scalable of the solutions, as a VRF and sub-interface must be provisioned on ASBR for every
customer that requires an Inter-AS service.
3.10.1 IP RAN & PaCO (NNI Option – A)
IuPS-CP vrf OAM vrf
IuPS-UP vrf CDR vrf

Gb vrf Gn vrf
Primary Traffic path
Secondary Traffic path
eBGP NNI (Option-A)

PaCo AS IPRAN AS
BVI
PaCo routers
IP RAN routers
Figure 43: NNI between IPRAN and PaCo Routers
IPRAN routers would be connected with PaCo routers with single or multiple 10G ports based on the traffic
requirements. The services between PaCo and IPRAN networks can be classified as given below
 3G data traffic
 2G data traffic
 O&M traffic
 Billing and regulatory requirements’ traffic
Based on the above services, the traffic can be segregated in individual VRF as shown below. Traffic
description for each vrf is also given.
VRF Description
IuPS/CP: This vrf will carry the control plane traffic of 3G packet data from the RNCs to SGSN.
IuPS/UP: This vrf will carry the user plane traffic of 3G packet data from the RNCs to GGSN /
SGSN
Gb: This vrf will carry the control & user plane traffic of 2G packet data from the
BSCs to SGSN.
Gn: This vrf will carry the traffic of packet data from the SGSN to GGSN.
OAM: This vrf will carry the O&M traffic of packet core nodes and routers.
Other PaCo This vrf will carry the billing traffic, lawful intercept, the provisioning service data
based on the on-line policy rules and on-line & off-line charging data from packet
signaling traffic (LI, core nodes.
Ga, Gx, Gy & Gz)
To realize the NNI Option A connectivity, relevant VRFs and BDIs would be configured on both primary and
secondary IPRAN routers. High availability is taken care of using router level redundancy and Traffic
switchover will take place though dynamic routing protocol. To achieve this, service-wise BDIs would be
created on the inter-IPRAN router BVI.
3.10.2 IP RAN & MPBN (NNI Option – A)
eBGP NNI (Option-A)

MPBN AS IPRAN AS
IuCS-CP vrf
IuCS-UP vrf
OAM vrf
MPBN Routers BVI Primary Traffic path
Secondary Traffic path
IP RAN routers
Figure 44: NNI between IPRAN and MPBN Routers
IPRAN routers would be connected with MPBN routers with 2x1G or 1x10G port. The services between
IPRAN and MPBN networks can be classified as given below
 3G voice traffic
 O&M traffic
Based on the above services, the traffic can be segregated in individual VRFs. Traffic description for each vrf
is given below.
IuCS/CP This vrf will carry the control plane traffic of 3G voice data from the RNCs to MSS.
IuCS/UP This vrf will carry the user plane traffic of 3G voice data from the RNCs to MGW
OAM This vrf will carry OAM traffic of BSC, RNC & NodeB towards OSS.
This VRF will also carry traffic of IPRAN routers, NTP, SNMP, IT LAN, RAS, Syslog &
TOP traffic.
To realize the Option-A' connectivity, relevant VRFs and BDIs would be configured on both primary and
secondary IPRAN routers. High availability is taken care by router level redundancy and traffic switchover will
take place with the help of dynamic routing protocol. To achieve this, service-wise BDIs would be created on
the inter-IPRAN router BVI.
For NTP a direct cable would be extended to hub IP RAN Router from SSU LAN Switch.
3.10.3 IP RAN & NLD (NNI)
Integration of IPRAN with NLD will involve two different organizations. So for seamless and smooth integration
both the sides must agree on protocols & timers to be used. We are configuring following set of features on
IPRAN side same is expected from NLD side as well. Following parameters should be used between IPRAN
and NLD
 All Hostnames, LSP Description and Interface Description should be standard across all IP RAN
Routers.
 All static routes should have relevant description as per the Services.
 MTU-size should be 1600 bytes for NNI Interface.
 MTU-size should be 1500 bytes for NNI Interface.
 Loopbacks IPs should be /32 mask.
 WAN IPs should be /30 mask.
 All interfaces in OSPF should be passive-interface by default.
 OSPF network type for WAN links should be ‘point-to-point’.
 ‘ip ospf mtu-ignore’ should be enabled.
 Default OSPF timers should be used.
 We should use OSPF area 0 for connectivity between IPRAN & NLD.
 OSPF cost should not be used as NLD has configured the strict RSVP TE tunnel at core.
 LSA Throttling & iSPF features should be use at later stage.
 Graceful Restart must be enabled for all Layer-3 protocols.
 Non-Stop Routing, Non-Stop Forwarding (NSF) and ISSU (In Service Software Update) should be
enabled so that no or minimum packet-drop transpires during chassis or card-level switchover.
 BGP timers should be as 30s keepalive and 90s holddown.
 IPRAN will be doing iBGP peering with National RRs which are NLD RRs deployed at Pune and Delhi.
 BGP communities should be of new format.
 MTU path discovery and BGP Next-hop tracking should be enabled.
 BFD should be mandatory for directly connected links like connectivity with NLD Core Routers.
 BFD should be enabled; For LAN, 300ms X 3 & for WAN, 300 ms X 3.
 One-hop RSVP tunnel should be enabled between IPRAN and NLD routers (with auto-backup or
explicit-path as mutually agreed between NOKIA and IDEA NLD team).
 Following community string should be configured for each circle:
Sr. No. Name of the Circle Community String
1 Maharashtra CNMS-MH
2 UP (West) CNMS-UW
3 Delhi CNMS-DL
4 Kerala CNMS-KL
5 Bihar CNMS-BH
6 UP (East) CNMS-UE
Table 10: CNMS Strings
 ‘mpls ldp igp sync’ should be enabled.

 RD value should be as IP:NN format, where IP is loopback IP of the device.
 RT value should be as AS:NN format where AS is autonomous system no. of the device.
 Following security banner should be used across all IP RAN Routers:
“You are about to log on to a proprietary system where access is provided, by the Owner of
the system, only to authorized users. If you are not authorized to use this system, please
refrain from doing so. All activities on this system are being monitored. Unauthorized access
to this system may be subjected to legal action and/or prosecution”.
 TE-Tunnels between P routers across NLD using RSVP should be provisioned, designed and
configured by IDEA NLD team.
 For inter-circle traffic, NLD team should enable ‘LDP Tunnelling over RSVP’ feature on all NLD P-
routers.
 QoS markings as sent by IP-RAN would be honoured by NLD routers.
 NLD should reserve adequate bandwidth, which would be proposed by IPRAN Team.
 “Minimum link” configuration should be mandatory for Layer-2 and Layer-3 port-bundles or multi-links.
 2 x 10GE ports should be used for inter-router links across all IP RAN Routers.
 ICMP traffic should be rate-limited and rate-limit should be confirmed with right justification from
NOKIA.
 Any well known application ports to be kept open / blocked must be validated with Idea Team before
its implementation on the IP RAN Routers.
 Size of the syslog file should be fine tuned for minimum 48 hours to maximum 4 days window.
 Value for MAC aging timer should be standardized across all IP RAN Routers as per the
recommendation from NOKIA.
 BPDU filters and Guard to be applied on all 802.1q port.
 No SVI interfaces should be configured on IP RAN Routers.
 Multicast and Broadcast Strom control should be applied on router ports connecting to Switch & MuX
and it should be rate-limited as per the recommended value from NOKIA which is 10% of the traffic.
 UDLD – Unidirectional link detection to be enabled with port activation timer (300 seconds).
 Port fast to be enabled on all the Layer-2 switch port.
 SNMP v2c should be configured across all IP RAN Routers.
 Route prefix limit (by mutual consent) should be configured on router-pair of NNI networks, to avoid
any outage in case of route flooding from either side.
 For eBGP failover detection, protocol BFD (Bidirectional Forwarding Detection) will be used.
 BFD Hello Timer : 300 msec.
 BFD Hold Timer : (Hello Timer) x (Multiplier value) = (300 x 3) msec = 900 msec.
 Authentication should be used between e-BGP sessions only.
 NOKIA should identify and notify all CPU impacting security features.
 MTU path discovery should be configured all NNI interfaces.
 First Secondary LSP path for every RSVP Tunnel should be configured to be pre-signaled.
 Ideal Timeout for each router should be 10 minutes for each user.
 Concurrent user login on each router should be restricted to 5.
 Configuration backup on Syslog Server should be automated to trigger once in 24 hours. The time of
the day should be configured between 4:00 am to 5:00 am.
Following is the list of local & remote NNI locations where NLD core is integrated.
NLD Core Local NNI Remote NNI

Kakanad – Cochin Kakanad - Cochin -
Lucknow-2 - Lucknow-1
Patna-2 Patna-2 -
Noida-E5 Noida-E5 -
- Meerut
Pune-Vega Pune-Vega
-
Pune-Sharda Center Pune-Vega
Table 11: IPRAN and NLD NNI Locations
Key point of integration between IP RAN and NLD as shown below:

 Hub Location IPRAN Router will work as a gateway for its circle.
 At most of the locations, interface between IPRAN & NLD is 10 Gig. In some locations it is 1Gig
subject to availability of 10Gig.
 IDEA NLD team will extend its IGP from NLD routers to IPRAN routers, so that interface between
ASR9010 routers & NLD routers will be part of single IGP with area 0.
 All the NLD routers & the IPRAN routers will be part of single BGP AS number, which will be of NLD
AS. So IPRAN router will work as a PE router & NLD router will work as a P router. There will be 2
dedicated nationalized Route-reflectors (RR) placed in Pune & Delhi.
 Within 7 core locations IDEA is running full-mesh RSVP-TE with FRR feature.
 For data plane traffic, among the circles, NLD team will enable “LDP Tunnelling over RSVP” on
MX960 routers.
 LDP would be implemented between NLD & IPRAN.
3.11 Traffic Migration and Flow
During the deployment of IP RAN routers, we should be migrating following type of traffic from existing routers
to new IP RAN routers.
Nodes Traffic Type

RNC IuB, IuR (CP/UP), IuPS(CP/UP), IuCS(CP/UP), OAM
BSC Gb(CP/UP), O&M(E///)
NodeB IuB, OAM
PACO IuPS(CP/UP), Gn, Gb , Ga, Gx, Gy, Gz, OAM, LI, CDR
MPBN IuCS(CP/UP), OAM, IT LAN, TOP, CNMS, NTP, RAS, Syslog
Table 12: Traffic types to be migrated
The diagrams below demonstrate the exact flow of different type of traffic within circle and between the circles.
(Intra and Inter circle)
The First Diagram explains, IuPS Traffic between SGSN & RNC via IPRAN Routers.
GGSN
PaCo
routers
IPRAN
routers
SGSN
MGW
MSS
` `
NLD
NLD
routers ` `
R1 R2 R1 R2
MPBN PACO
IP RAN Routers R1 R2
Primary IuPS-CP path
Secondary IuPS-CP path

VRRP
Primary IuPS-UP path
Secondary IuPS-UP path
RNC
Node B
This diagram is valid for RNCs where DT is enabled
Figure 45: IuPS Traffic Flow Path
IuPS Traffic Flow:
 IuPS traffic from RNC will be routed to PaCo via IPRAN router on eBGP Option A NNI connectivity.
 For IuPS-CP traffic, SCTP is used for redundancy purposes. In case of primary SCTP path failure, entire
traffic will switch over to the secondary SCTP path.
 For all RNCs where DT is enabled, the IuPS-UP traffic will go directly to GGSN and in all non-DT
scenario, the IuPS-UP traffic will go towards SGSN and then to GGSN.
 For IuPS-UP traffic, VRRP is used for redundancy purpose at the UNI end and heartbeat messages will
be exchanged by IPRAN router. Primary IPRAN router will be the VRRP master while secondary router
will be in VRRP standby mode. In case of node outage or physical connectivity outage, secondary IPRAN
router will become the VRRP master and the IuPS-UP traffic will flow via secondary IPRAN router.
 In the IPRAN router, the incoming IuPS-CP traffic will be mapped into appropriate vrf, BDI and will be
routed to the appropriate outgoing interface towards SGSN within the same vrf.
 In the IPRAN router, the incoming IuPS-UP traffic will be mapped into appropriate vrf, BDI and will be
routed to the appropriate outgoing interface towards SGSN / GGSN within the same vrf.
GGSN
PaCo
routers
IPRAN
routers
SGSN
MGW
MSS
` `
NLD
NLD
` `
routers
R1 R2
R1 R2
MPBN PACO
R2
IP RAN Routers R1
Primary IuCS-CP path
Secondary IuCS-CP path

VRRP
Primary IuCS-UP path
Secondary IuCS-UP path
RNC Node B
Figure 46: IuCS Traffic Flow Path
IuCS Traffic Flow:

 IuCS traffic from RNC will be routed to MPBN via IPRAN router on eBGP Option A NNI connectivity.
 For IuCS-CP traffic, SCTP is used for redundancy purposes. In case of primary SCTP path failure, entire
traffic will switch over to the secondary SCTP path.
 For IuCS-UP traffic, VRRP is used for redundancy purpose at the UNI end and heartbeat messages will
be exchanged by IPRAN router. Primary IPRAN router will be the VRRP master while secondary router
will be in VRRP standby mode. In case of node outage or physical connectivity outage, secondary IPRAN
router will become the VRRP master and the IuCS-UP traffic will flow via secondary IPRAN router.
 In the IPRAN router, the incoming IuCS-CP traffic will be mapped into appropriate vrf, BDI and will be
routed to the appropriate outgoing interface towards MSS within the same vrf.
 In the IPRAN router, the incoming IuCS-UP traffic will be mapped into appropriate vrf, BDI and will be
routed to the appropriate outgoing interface towards MGW within the same vrf.
GGSN
PaCo
routers
IPRAN
routers
SGSN
MGW
MSS
` `
NLD
NLD
` `
routers
R1 R2 R1 R2
MPBN PACO
R1 R2
IP RAN Routers Active Backup
VRRP
VRRP
Primary IuB
(CP/UP) path
Secondary IuB
(CP/UP) path
RNC NodeB
Figure 47: IuB Traffic Flow Path
IuB Traffic Flow:
 IuB traffic from NodeB clusters will be aggregated on the mux and then carried forward to IPRAN router.
 VRRP is used for ensuring the high availability of the nodes and heartbeat messages will be exchanged
by mux.
 Primary IPRAN router will be the VRRP master for the IuB traffic while secondary router will be in VRRP
standby mode.
 In the IPRAN router, the incoming IuB traffic will be mapped into an appropriate vrf, BDI and will be routed
to the appropriate outgoing interface towards RNC within the same vrf.
 In case of node outage or physical connectivity outage, secondary IPRAN router will become the VRRP
master and the IuB traffic will flow in the same manner via secondary IPRAN router.
GGSN
PaCo
routers
IPRAN
routers
SGSN
MGW
MSS ` `
NLD
NLD
` `
routers
R1 R2
MPBN PACO
R1
R2
R1 R2
Active Backup
IPRAN
VRRP
Primary Gb path
Secondary Gb path
Primary Gn path
Secondary Gn path
BSC
Mux
Switch
BSC Co-BSC
Figure 48: Gb & Gn Traffic Flow Path
Gb Traffic Flow:
 Gb traffic from multiple BSCs will be aggregated on the mux and then carried forward to IPRAN router.
 VRRP is used for ensuring the high availability of the nodes and heartbeat messages will be exchanged
by mux.
 Primary IPRAN router will be the VRRP master for the Gb traffic while secondary router will be in VRRP
standby mode.
 In the IPRAN router, the incoming traffic will be mapped into an appropriate vrf, BDI and will be routed to
the appropriate outgoing interface towards PaCo network (SGSN node) within the same vrf.
 In case of node outage or physical connectivity outage, secondary IPRAN router will become the VRRP
master and the Gb traffic will flow in the same manner via secondary IPRAN router.
Gn Traffic Flow:
 Gn traffic from SGSN will be carried to IPRAN router on eBGP Option A NNI.
 Router level redundancy is built to ensure the high availability for Gn traffic.
the appropriate outgoing interface towards PaCo network (GGSN node) within the same vrf.
OAM Traffic Flow:

 OAM traffic from core nodes will be carried to MPBN router on eBGP Option A NNI.
 Router level redundancy is built to ensure the high availability for OAM traffic.
the appropriate outgoing interface towards MPBN network within the same vrf.
Figure 49: OAM Traffic Flow Path
Above diagram shows the traffic flow for various other traffic which will be migrated to IP RAN.
3.12 Quality of Service Schema
QoS technologies refer to the set of tools and techniques to manage network resources and are considered
the key enabling technology for network convergence. The objective of QoS technologies is to make voice,
video and data convergence appear transparent to end users. QoS technologies allow different types of traffic
to contend inequitably for network resources. Voice, video, and critical data applications may be granted
priority or preferential services from network devices so that the quality of these strategic applications does not
degrade to the point of being unusable. Therefore, QoS is a critical, intrinsic element for successful network
convergence.
QoS tools are not only useful in protecting desirable traffic, but also in providing deferential services to
undesirable traffic such as the exponential propagation of worms. You can use QoS to monitor flows and
provide first and second order reactions to abnormal flows indicative of such attacks, as will be discussed in
additional detail later in this document.
In Idea’s IP RAN Network we will use classification and marking techniques to prioritise critical traffic.
Following table demonstrate which QoS methodology will be used and what type of traffic will be classified to
which DSCP value.
Police Bandwidth
Traffic Type DSCP QOS Group Priority Bandwidth % Renaining % MPLS EXP Bit P-Bit
SYNC 51 54 56 63 1 1 10 NA 7 7
Signalling 40 48 2 1 10 NA 6 6
Voice/OAM 16 24 30 32 34 36 38 42 3 1 10 NA 5 5
3G Data / 2G Data 0 8 12 14 18 22 26 28 4 NA NA 30 4 4
4G Data 10 20 5 NA NA 65 3 3
Default NA NA NA NA 5 NA 2
Table 13: Quality of Service parameters
3.13 BGP Dampening:
3.13.1 Route Dampening

Route dampening is a BGP feature that minimizes the propagation of flapping routes across an internetwork.
A route is considered to be flapping when it is repeatedly available, then unavailable, then available, then
unavailable, and so on.
For example, consider a network with three BGP autonomous systems: autonomous system 1, autonomous
system 2, and autonomous system 3. Suppose the route to network A in autonomous system 1 flaps (it
becomes unavailable). Under circumstances without route dampening, the eBGP neighbor of autonomous
system 1 to autonomous system 2 sends a withdraw message to autonomous system 2. The border router in
autonomous system 2, in turn, propagates the withdrawal message to autonomous system 3. When the route
to network A reappears, autonomous system 1 sends an advertisement message to autonomous system 2,
which sends it to autonomous system 3. If the route to network A repeatedly becomes unavailable, then
available, many withdrawal and advertisement messages are sent. Route flapping is a problem in an
internetwork connected to the Internet, because a route flap in the Internet backbone usually involves many
routes.
3.13.2 Minimizing Flapping
The route dampening feature minimizes the flapping problem as follows. Suppose again that the route to
network A flaps. The router in autonomous system 2 (in which route dampening is enabled) assigns network A
a penalty of 1000 and moves it to history state. The router in autonomous system 2 continues to advertise the
status of the route to neighbors. The penalties are cumulative. When the route flaps so often that the penalty
exceeds a configurable suppression limit, the router stops advertising the route to network A, regardless of
how many times it flaps. Thus, the route is dampened.
The penalty placed on network A is decayed until the reuse limit is reached, upon which the route is once
again advertised. At half of the reuse limit, the dampening information for the route to network A is removed.
3.13.3 Defaults
Route dampening is disabled.
half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: four times half-life value
3.13.4 Recommended:
Route dampening – Enabled
half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: four times half-life value
3.14 Control Plane Policing (CoPP):
Control Plane Policing is a network security feature which increases device resiliency by protecting the Route
Processor from excess unnecessary and sometimes malicious traffic which can affect the normal operation of
the Network.
A router can be logically divided into three functional components or planes:
 Data Plane,
 Management Plane,
 Control Plane.
The vast majority of traffic generally travels through the router via the data plane; however, the Route
Processor must handle certain packets, such as routing updates, keepalives, and network management. This
traffic is often referred to as control and management plane traffic.
The Route Processor is critical to network operation. Any service disruption to the route processor, and hence
the control and management planes, can lead to business-impacting network outages. A Denial of Service
(DoS) attack targeting the route processor, which can be perpetrated either inadvertently or maliciously,
typically involves high rates of traffic destined to the Route Processor itself that result in excessive CPU
utilization. Such an attack can be devastating to network stability and availability and may include the following
symptoms:
 High Route Processor CPU utilization (near 100%).
 Loss of line protocol keepalives and routing protocol updates, leading to route flaps and major
network transitions.
 Interactive sessions via the Command Line Interface (CLI) are slow or completely unresponsive
due to high CPU utilization.
 Route processor resource exhaustion: resources such as memory and buffers are unavailable for
legitimate IP data packets.
 Packet queues back up, leading to indiscriminate drops (or drops due to lack of buffer resources)
of other incoming packets.
CoPP addresses the need to protect the control and management planes, ultimately ensuring routing stability,
reachability, and packet delivery. It uses a dedicated control-plane configuration via the IOS Modular Quality of
Service CLI (MQC) to provide filtering and rate limiting capabilities for control plane packets. Prior to
developing the actual CoPP policy, required traffic must be identified and separated into different classes. One
recommended methodology involves stratifying traffic into distinct groups based on relative importance as
shown below:
Critical: BGP, LDP & OSPF; Important: SSH, SNMP, NTP etc; Normal: Ping, Trace etc.
Undesirable: Unwanted or malicious traffic like (DoS Attacks, Spoofing Attacks, Smurf Attacks). This can be
achieved by implementing appropriate ACLs at the perimeter of network.
3.15 Operation & Management
For operation and management of IPRAN routers, in-band or out-band access of routers should be provided
with secure password and login banner.
 SNMP protocol should be enabled and secured for authorised usage only via ACLs and SNMP
authentication.
 NTP protocol services should be enabled and used for time synchronisation among all devices and
should again be secured for authorised usage via NTP authentication and ACLs.
 DNS service should be used on routers only when it’s required to resolve device name using internal
DNS. If internal DNS server is not feasible, services should be disabled.
Following diagram show the concept of carrying O&M traffic like SNMP, NTP, DNS, BRAS, CNMS etc which
will flow from IP RAN router -> MPBN router -> NLD.
NTP: NTP will be directly connected to hub IPRAN router. Non-hub IPRAN routers will sync –up with hub
IPRAN router.
CNMS: CNMS network will be reachable via NLD PE router. NLD PE router will import RT values from all
the circles.
RAS: RAS users will login through Terminal service of RAS, then RAS will contact with syslog & from
there they will be able to login to remote device.
IT Network RAS
OSS
NLD PE
CNMS NLD
NTP
P
Syslog
IP RAN Router
Syslog server will act as a terminal server for RAS logins
Figure 50: O&M Traffic flow
For best practises for all of the above services please refer Best Practices section in this document. The list
below refers to what parameters will be used by Idea for its IP RAN Network.
Management Traffic
Transport mode for the management traffic in the network.
Transport Mode Description Notes

Management traffic transport In-band
If Out-of-band, specify separation type
Dedicated infrastructure for serial consoles No
Router Access
Router access parameters to be deployed in the network.
Router access characteristics Description Scope

Circle (2 char)+ City (3 char)+Location (3 char)+ Service
Device name All Routers
Type (2 Char) + Device type (1 char)+ ID (2 No.)
User access levels Yes All Routers
Local users Yes All Routers
External authentication No
RADIUS No
TACACS+ No
Authentication order Local Only All Routers
Remote access protocols enabled
SSH Yes All Routers
SFTP No
Telnet No All Routers
FTP No
HTTP No
HTTPS No
Other (add details in Notes) No
Router Security
Specify the router security parameters to be deployed in the network.
Router security characteristics Description Scope
Password encryption in configuration file No
Login banner Yes All Routers

Control plane protection filter Yes All Routers
Disable Out-of-band interfaces No All Routers
Other (add details in Notes)
Network Services
Specify the network services to be deployed in the network.
Network services Description Scope

SNMP Yes (Version 2c) All Routers
Gather statistics Yes All Routers

Send traps Yes All Routers
NTP Yes All Routers
DNS No
Syslog Yes All Routers
Yes (Maximum Buffer Size to be Configured on
Local storage All Routers
Router.)
Remote storage Yes All Routers
Other (add details in Notes)
Table 14: O&M Services Overview
Simple Network Management Protocol (SNMP)
The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message
format for communication between SNMP managers and agents. SNMP provides a standardized framework
and a common language used for the monitoring and management of devices in a network.
The SNMP framework consists of three parts:
 An SNMP manager—The system used to control and monitor the activities of network devices using
SNMP.
 An SNMP agent—The software component within the managed device that maintains the data for the
device and reports these data, as needed, to managing systems. To enable the SNMP agent, you
must define the relationship between the manager and the agent.
 A managed information base (MIB)—The collection of managed objects on the SNMP agent.
There are primarily three types of SNMP versions, SNMPv3 is latest and most secured one because it
supports MD5 authentication.
Model Level Authentication Encryption What Happens

v1 noAuthNoPriv Community No Uses a community string match for authentication.
string
v2c noAuthNoPriv Community No Uses a community string match for authentication.
string
v3 noAuthNoPriv Username No Uses a username match for authentication.
v3 authNoPriv HMAC-MD5 or No Provides authentication based on the Hash-Based
HMAC-SHA Message Authentication Code (HMAC) Message
Digest 5 (MD5) algorithm or the HMAC Secure
Hash Algorithm (SHA).
v3 authPriv HMAC-MD5 or DES Provides authentication based on the HMAC-MD5
HMAC-SHA or HMAC-SHA algorithms. Provides Data
Encryption Standard (DES) 56-bit encryption in
addition to authentication based on the Cipher
Block Chaining (CBC) DES (DES-56) standard.
Table 15: SNMP Versions
It has been decided that Idea will use SNMPv2C for IPRAN Network. A list below depicts the community
strings which will be used in RAN network for each circle:
Sr. No. Name of the Circle Community String

1 UP-West CNMS-UW
2 Delhi CNMS-DL
3 Maharashtra CNMS-MH
4 UP-East CNMS-UE
5 Kerala CNMS-KL
6 Bihar CNMS-BH
Table 16: SNMP Community String (Circle)
Network Time Protocol (NTP)
NTP is designed to synchronize the time on a network of machines. NTP runs over the User Datagram
Protocol (UDP), using port 123 as both the source and destination, which in turn runs over IP. NTP Version 3
is used to synchronize timekeeping among a set of distributed time servers and clients.
Each client in the synchronization subnet, which may also be a server for higher stratum clients, chooses one
of the available servers to synchronize to. This is usually from among the lowest stratum servers it has access
to.
Below is the list of association modes used by NTP servers to associate with each other.
 Client/Server
 Symmetric Active/Passive
 Broadcast
As per discussion with Idea, following NTP architecture will be used for IP RAN network:
 Hub IPRAN would learn NTP SSU /26 prefix from HUB MPBN NNI in OAM VRF
 Hub IPRAN would announce it’s management loopbacks to MPBN
 Hub IPRAN routers will sync directly with NTP SSU IP.
 Remaining circle Spoke IPRAN routers to sync NTP clock from Hub IPRAN routers.
 Stand alone NodeB’s would continue to take clock from TOP server
 RNC’s would continue to take the clock from present NTP source (MPBN router / NTP SSU IP) & at
later stage all RNCs would be synced with hub IPRAN.
Logging Management (Syslog)

Syslog is a method to collect messages from devices to a server running a syslog daemon. Logging to a
central syslog server helps in aggregation of logs and alerts. Cisco devices can send their log messages to a
Unix-style SYSLOG service. A SYSLOG service simply accepts messages, and stores them in files or prints
them according to a simple configuration file. This form of logging is the best available for Cisco devices
because it can provide protected long-term storage for logs. This is useful both in routine troubleshooting and
in incident handling.
For Idea’s IP RAN Network, we propose a centralised syslog server in addition to local buffer. The max buffer
for file should be set for 48 hours (max).
In addition of IOS-XR own configuration backup management, Syslog server should also be used for
configuration backup management which should happen every day between 4 AM to 5 AM.
MPS (Mobile Positioning System) or LBS (Location Based Services)
Location in GSM & UMTS is an innovative technology that provides information based on the geographical
location of the user. The concept behind any Location Based Application is to find the location of the
requesting subscriber and then, process this location according to the requirement of the requesting
Subscriber.
Traffic flow of LBS service will be as follows:
 GMLC & SMLC will make IP association with STP via MPBN router.
 STP then in turn makes IP association with MSS via MPBN router.
 For BSC, MSS will make association with BSC on TDM interface.
 For RNC, MSS will make IP association with RNC via MPBN & IPRAN routers.
STP
IP associations
IP associations
SMLC
MSS
TDM
GMLC IP associations BSC
RNC
Figure 51: LBS Traffic flow
Idea has finalized Ericsson’s MPS solution that finds the Location of Subscriber in the network and provides
this location to the Middleware/Applications.
For providing the location services, the RNCs will communicate to the SMLC, GMLC and STP via MPBN
network for the Lg and IuPC traffic. MPBN routers would advertise the networks of SMLC, GMLC and STP
towards IPRAN routers to establish the reachability. Lg traffic is the control plane traffic and will be carried on
the IuCS-CP vrf between MPBN – IPRAN NNI and IuPC traffic is the control plane traffic and will be carried on
the IuCS-CP vrf between MPBN – IPRAN NNI.
RNC will communicate with the OAM of SMLC and GMLC. Reachability of these routes will be provided by
MPBN routers in the OAM vrf. RNC does not communicate with the OAM of STP.
Lb traffic towards the BSCs will flow on TDM connectivity and hence is not covered under IPRAN scope.
RAS (Remote Access System)
The Service Node (SN) solution enhances the current remote access functionalities by bundling the RAS
potential with a unique designed system – the SN - which will be part of the NOKIA RAS platform connected to
the customers VPN endpoint.
The SN solution provides following features.
1. User Access Management – Totally controlled and administered by customer
2. Online real-time session Monitoring
3. Video Recording and Streaming
4. Reporting functionalities
5. Fast file transfer
6. Hosting of special applications
The RAS solution description is given below.
1. Standard PC in NOKIA intranet
2. User connects to RAS Tool inside DMZ Segment (1. Authentication). User Selects customer and
connects
3. RAS Tool redirects user access to Citrix Terminal Server (WAH) (2. Authentication)
4. WAH Terminal Service hosts a selected set of user applications
5. User connects to WAH server, WAH establishes a connection to customer network (RAS Service
Node) over a secure VPN connection
6. RAS Service Node hosts special applications and enables extended RAS features for access control,
large file transfer, session recording, reporting etc.
Router Access Control
As per best practices, in-band access control should be provided as per below:
1. Secure level 7 user password
2. Secure enable level 7 password
3. Terminal access list control (ACL)
4. Login Banner Message
5. SSH enabled access (Preferred)
6. Exec timeout of 10 minutes
7. Concurrent access to 5 users only.
8. Profile based AAA authentication using TACACS+ (Preferred)
3.16 MISCELLANEOUS FEATURES
Cisco ASR 9000 Series Aggregation Services Routers offer number of features. We will enable some of them
in IPRAN project. Following are the features that we will use:
3.16.1 EPFT (Excessive Punt Flow Trap)
The Excessive Punt Flow Trap feature attempts to identify and mitigate control packet traffic from remote
devices that send more than their allocated share of control packet traffic. A remote device can be a
subscriber device, a device on a VLAN interface, or a device identified by its source MAC address.
When remote devices send control packet traffic to the router, the control packets are punted and policed by a
local packet transport service (LPTS) queue to protect the router's CPU. If one device sends an excessive rate
of control packet traffic, the policer queue fills up, causing many packets to be dropped. If the rate from one
"bad actor" device greatly exceeds that of other devices, most of the other devices do not get any of their
control packets through to the router. The Excessive Punt Flow Trap feature addresses this situation.
The Excessive Punt Flow Trap feature is supported on both subscriber interfaces, and non-subscriber
interfaces such as L2 and L3 VLAN sub-interfaces and bundle virtual interfaces (BVIs). If the source that
floods the punt queue with packets is a device with an interface handle, then all punts from that bad actor
interface are penalty policed. The default penalty rate, for each protocol, is 10 protocols per second (pps).
Otherwise, if the source is a device that does not have an interface handle, then all packets from this bad actor
are dropped.
IPRAN
Network
Enable EPFT
feature on all
MUX
Access nodes
NodeB MUX
NodeB
Cluster NodeB RNC
NodeB
NodeB BSC BSC
Figure 52: EPFT Feature
Functioning of Excessive Punt Flow Trap Feature

The Excessive Punt Flow Trap feature monitors control packet traffic arriving from physical interfaces, sub-
interfaces, BVI, and subscriber interfaces. It divides interfaces into two categories:
• "Parent" interfaces, which can have other interfaces under them.
• "Non-parent" interfaces, which have no interfaces under them.
A physical interface is always a parent interface because it has VLAN sub-interfaces. A BVI is always a parent
interface because it is the "parent" of L2 interfaces. An L3 VLAN sub-interface can either be a parent or a non-
parent interface. If the VLAN sub-interface is enabled for subscribers, then it is a parent interface, otherwise it
is a non-parent interface. A subscriber interface (IPoE or PPPoE) is always a non-parent interface.
When a flow is trapped, the Excessive Punt Flow Trap feature tries to identify the source of the flow. The first
thing it determines is from which interface the flow came. If this interface is not a "parent" interface, then the
feature assumes that it is the end-point source of the flow and penalty policing is applied. If the trapped
interface is a "parent" interface, then instead of penalizing the entire interface (which would penalize all the
interfaces under it), this feature takes the source MAC address of the bad flow and drops all packets from the
MAC address under the parent. Due to platform limitation, the penalty policer cannot be applied on a MAC
address; therefore all packets are dropped.
The protocols that are supported by the Excessive Punt Flow Trap feature are Broadcast, Multicast, ARP,
DHCP, PPP, PPPoE, ICMP, IGMP, L2TP and IP (covers many types of L3 based punts, both IPv4 and IPv6).
Each protocol has a static punt rate and a penalty rate. For example, the sum total of all ICMP punts from
remote devices is policed at 1500 packets per second (pps) to the router's CPU. If one remote device sends
an excessive rate of ICMP traffic and is trapped, then ICMP traffic from that bad actor is policed at 10 pps. The
remaining (non-bad) remote devices continue to use the static 1500 pps queue for ICMP.
Once a bad actor is trapped, it is penalty policed on all its punted protocols (ARP, DHCP, PPP, etc.),
irrespective of the protocol that caused it to be identified as a bad actor. A penalty rate of 10 pps is sufficient to
allow the other protocols to function normally. However, if the bad actor is trapped by source MAC address,
then all its packets are dropped.
When an interface is trapped, it is placed in a "penalty box" for a period of time (a default of 15 minutes). At
the end of the penalty timeout, it is removed from penalty policing (or dropping). If there is still an excessive
rate of control packet traffic coming from the remote device, then the interface is trapped again.
Restrictions
These restrictions apply to implementing Excessive Punt Flow Trap feature:
• This feature does not support interfaces on SIP-700 line cards and ASR 9000 Ethernet Line Card.
• This feature is non-deterministic. In some cases, the Excessive Punt Flow Trap feature can give a false
positive, i.e. it could trap an interface that is sending legitimate punt traffic.
• The Excessive Punt Flow Trap feature traps flows based on the relative rate of different flows; thus, the
behavior depends on the ambient punt rates. A flow that is significantly higher than other flows could be
trapped as a bad actor. Thus the feature is less sensitive when there are many flows, and more sensitive
when there are fewer flows present.
• Sometimes control packet traffic can occur in bursts. The Excessive Punt Flow Trap has safeguards against
triggering on short bursts, but longer bursts could trigger a false positive trap.
Enabling Excessive Punt Flow Trap Processing

Perform this task to enable the Excessive Punt Flow Trap feature for both subscriber and non-subscriber
interfaces. The task also enables you to set the penalty policing rate and penalty timeout for a protocol.
SUMMARY STEPS
1. configure
2. lpts punt excessive-flow-trap subscriber-interfaces
3. lpts punt excessive-flow-trap non-subscriber-interfaces
4. lpts punt excessive-flow-trap penalty-rate protocol penalty_policer_rate
5. lpts punt excessive-flow-trap penalty-timeout protocol time
6. Use the commit or end command.
3.16.2 Enterprise ILL (Internet Leased Line)
With the implementation of IPRAN network, IDEA wants to Implement Enterprise ILL (Internet Leased Line)
services using L2VPN in a given circle.
A Layer 2 MPLS VPN is a term in computer networking. It is a method that Internet service providers use to
segregate their network for their customers, to allow them to transmit data over an IP network. This is often
sold as a service to businesses.
Layer 2 VPNs are a type of Virtual Private Network (VPN) that uses MPLS labels to transport data. The
communication occurs between routers that are known as Provider Edge routers (PEs), as they sit on the
edge of the provider's network, next to the customer's network. There is no one IETF standard for Layer 2
MPLS VPNs. Instead, two methodologies may be used. Both methods use a standard MPLS header to
encapsulate data. However, they differ in their signaling protocols.
Types of Layer 2 MPLS VPNs
1. BGP-based: The BGP-based type is based on a draft specification by Kireeti Kompella, from Juniper
Networks. It uses the Border Gateway Protocol (BGP) as the mechanism for PE routers to
communicate with each other about their customer connections. Each router connects to a central
cloud, using BGP. This means that when new customers are added (usually to new routers), the
existing routers will communicate with each other, via BGP, and automatically add the new customers
to the service.
2. LDP-based: The second type is based on a draft specification by Luca Martini from Cisco Systems.
This method is also known as a Layer 2 circuit. It uses the Label Distribution Protocol (LDP) to
communicate between PE routers. In this case, every LDP-speaking router will exchange FECs
(forwarding equivalence classes) and establish LSPs with every other LDP-speaking router on the
network (or just the other PE router, in the case when LDP is tunnelled over RSVP-TE), which differs
from the BGP-based methodology. The LDP-based style of layer 2 VPN defines new TLVs and
parameters for LDP to aid in the signaling of the VPNs.
The L2VPN feature provides the ability to provide point-to-point and multipoint services.
1. Point-to-Point service: Point-to-point service basically emulates a transport circuit between two end
nodes so the end nodes appear to be directly connected over a point-to-point link. This can be used to
connect two sites. In reality, there can be multiple routers between the two end nodes. Virtual Psuedo
Wire Services (VPWS) lets you connect two sites using MPLS PWs.
2. Multipoint service: Multipoint service emulates a broadcast domain so that all hosts connected in that
bridge-domain appear to be logically connected to the same Ethernet segment. All hosts can be
connected to the same router/switch. Spanning tree must be used in order to break loops. Virtual
Private LAN Services (VPLS) lets you extend the broadcast domain between multiple sites using
MPLS PWs.
Here IDEA will use only VPWS based services. To chose Martini or Compella depends on Circle
requirements.
ILL Customer 1
MUX L2VPN Tunnel

port
rnet
Ethe
IPRAN Network
ISP Router
ILL Customer 2 ILL Customer 3
Figure 53: Enterprise L2VPN
Here is the sample config based on Martini based L2VPN.
interface tunnel-te101
bandwidth 100000
ipv4 unnumbered Loopback10
autoroute announce
destination 10.220.10.1
path-protection
path-option 1 explicit name A protected-by 2
path-option 2 explicit name B protected-by 1
!
interface GigabitEthernet0/1/0/2
negotiation auto
l2transport
!
!
l2vpn
pw-class ILL-VLAN
encapsulation mpls
transport-mode ethernet
preferred-path interface tunnel-te 101 fallback disable
!
!
xconnect group ILL
p2p ILL-POC
neighbor ipv4 10.220.10.1 pw-id 10001
pw-class ILL-VLAN
!
!
!
mpls traffic-eng
!
!
mpls ldp
!
!
Here is the sample config based on the Compella based L2VPN
negotiation auto
l2transport
!
!
l2vpn
xconnect group ILL
p2p ILL-POC
vpn-id 101
l2-encapsulation ethernet
autodiscovery bgp
rd auto
route-target x.x.x.x:100
signalling-protocol bgp
ce-id 1
interface Gig0/0/0/2 remote ce-id 2
!
!
!
!
3.16.3 General Guidelines for IPRAN

Following recommended guidelines will be configured in all IPRAN /Pre-AGG routers
SrNo Description
Jumbo MTU 9600 on all WAN links starting from Pre-aggregation towards IPRAN and within IPRAN network
1 across. Make sure Jumbo MTU is enabled in TX also.
2 MTU 1600 on access interfaces/sub-interfaces ( towards NodeB, eNodeB, BTS, BSC)
3 Reference BW for OSPF 100Gbps.
4 Arp-timeout ( mac-aging) 290 sec towards access ports
5 Hold-down timer (carrier-delay) 300 msec on WAN interfaces
6 Difference ISIS instances in different rings as per earlier guideline shared.
7 Community tagging for IGP loopbacks as per earlier guideline.
IGP loopback redistribution between ISIS and OSPF within a circle. Only circle IPRAN loopback to be
8 redistributed towards Pre-aggregation.
While redistribution from ISIS into OSPF, it should be type-1 redistribution, so that IGP cost be added by
9 default while traversing the prefixes within IPRAN network.
10 Prefix limit to be added in each VRF as per LLD.
11 Broadcast/ARP suppression to be Configured on all access ports with 50pps on all IPRAN/Pre-agg routers.
12 No NH-Self on circle RR on all remote IPRAN peering for IPV4 prefixes.
13 No NH-Self for VPNV4 prefixes across IPRAN and pre-agg network.

14 NH-Self only on In-line RR for IPV4 prefixes.
15 Active standby LAG on access ports towards NodeB at Pre-aggregation router.
16 MC-LAG on access ports at IPRAN routers.
17 BFD to be enabled on all WAN links.
In case of port-bundling on WAN links, make sure both the WAN links are from common media ( SDH or DWDM)
18 with same physical paths. Protection should be on different path.
19 All the secondary LSPs should be pre-signalled.
20 Import-export policy on all NNI as per LLD
21 Integration with NTP, SAM, U2000 and CNMS
22 Integration with RAS & syslog.
Table 17: Recommended Guidelines for IPRAN/Pre-Agg

3.17 ASR 9000 Architecture
Cisco ASR 9000 Series Aggregation Services Routers offer one of the industry's highest-capacity Carrier
Ethernet platforms. These routers are optimized for aggregation of dense 10 Gigabit Ethernet and 100 Gigabit
Ethernet connections.
In addition to a higher capacity and scale, the Cisco ASR 9000 Series offers:
 Distributed forwarding and control planes for higher performance
 Modularized system components in both hardware and software, isolating failure and faults to
subsystem and component
 Hardware-based signalling for the fabric: support for zero packet loss on switchover
 Built-in redundancy in hardware components such as the route switch processor, switch fabric,
control-plane chassis control bus, and power supplies, thereby avoiding a single point of failure
The Cisco ASR 9000 Series operates in a fully distributed fashion, meaning that all packet-forwarding
decisions and actions take place on each individual line card. The Cisco ASR 9000 Series Line Cards provide
flexible programming infrastructure with high-density hierarchical quality-of-service (HQoS) services, security,
and integrated Synchronous Ethernet (SyncE). The distributed nature of the Cisco ASR 9000 Series also
presents itself in the control plane. The distributed control plane facilitates scale in features such as
Bidirectional Forwarding Detection (BFD) and Ethernet operations, administration, and management (EOAM),
which improve resilience and provide comprehensive instrumentation.
Cisco ASR 9000 Series routers bring the time-tested and comprehensive carrier-class capabilities of Cisco
IOS® XR Software to the Carrier Ethernet edge. The operating system supports true software process
modularity. The capabilities of Cisco IOS XR Software allow each process to run in separate protected
memory, including each routing protocol along with multiple instances of control, data, and management
planes supported. The software also supports distributed route processing.
Figure 54: ASR9000 Scalable System Architecture
Figure 55: ASR9000 Fully Distributed Control Plane
The Cisco ASR 9000 Series operates in a fully distributed fashion, meaning that all packet-forwarding
decisions and actions take place on each individual line card.
Figure 56: ASR9000 Layer3 Control Panel Overview
Figure 57: IOS-XR Two Stage Forwarding Overview
Hardware Redundancy
The Cisco ASR 9000 provides a carrier-class solution to Carrier Ethernet service delivery by taking advantage
of Cisco experience in core routing and extending that design to the network edge. Newer routing design
should support distributed architectures with distributed asynchronous forwarding engines and distributed
asynchronous route-processing capabilities to remove single points of failure. As a next-generation routing
platform, the Cisco ASR 9000 offers several additional redundancy features, including route switch processor
(RSP), switch fabric, power supply, fan tray, line card, and operating-system redundancy:
• Route switch processors (RSPs): RSPs are deployed in "active" or "standby" configurations. The Cisco ASR
9000 Route Switch Processor is designed with load-shared redundancy to support software upgrades and
software patches.
Note: Idea’s IP RAN Network will have Active-Standby configuration.
• Switch fabric: Using an active/active configuration model allows for distribution of the traffic load across both
switch fabrics, taking advantage of the processing capacity of both switch fabrics. If a failure occurs, the single
active switch fabric continues to forward traffic in the system, with hardware support for zero packet loss on
fabric online insertion and removal (OIR). Because both switch fabrics are active and forwarding traffic, they
are both ready to assume the full traffic load.
• Power supplies: Redundant power supplies are deployed in load-balanced configurations to share the load
across all power supplies. You can also configure the power supplies in 1:1 and 1:N modes to provide power-
supply redundancy.
Note: Idea’s IP RAN Network will have 1:N mode configuration.
• Fan trays: Redundancy is offered on a single fan tray (that is, through multiple fans) and between fan trays. If
a fan tray fails, fan-tray redundancy allows for the protection of the fan tray, giving service providers an alarm
and time window over which they can replace the failed fan tray.
• Line cards: The Cisco ASR 9000 Series can handle faults by bundling and protecting ports together on
multiple line cards by supporting IEEE 802.3ad Link Aggregation. Cisco ASR 9000 linecard redundancy is
supported through the bundling of up to eight interfaces across line cards into a single, logical Layer 2 or Layer
3 connection. Fast failover between ports within a bundle occurs if any port fails, providing more flexibility than
simple linecard redundancy. This allows service providers to support stringent customer SLAs.
• Operating system: System infrastructure components are distributed to all cards in the system, and relevant
data is replicated on different cards based on usage. This setup avoids single points of failure and allows
distribution of applications based on resource availability.
Configuration Features in Cisco IOS XR

The following are some of the similarities between IOS and IOS XR configurations a user can come across:
■ Configurations can be viewed in ASCII form
■ Configuration entries can be copied and pasted into the console command prompt
■ Configurations can be loaded and saved to media devices
■ Command syntax is similar to that used in IOS (with some exceptions)
Cisco IOS XR has other unique features, including the following:

■ Command return <CR> does not cause the actual configuration change to take place in Cisco IOS XR, as it
does in IOS. Users can check and save a configuration without actually committing the configuration to the
router (target configuration).
■ Cisco IOS XR allows you to lock and unlock a configuration session. It is not used as a security feature but
serialization to prevent data/config corruption.
■ Configuration tagging (checkpoint) for management and operations
■ Rollback feature for security, recovery, and troubleshooting.
■ Configuration verifier to check for user errors
Configuration Rollback
In IOS XR the target configuration built by the user is committed to form the new running config. For every
successful commit operation, a unique ID or label is generated. This ID or commit point can be used as a
rollback point. Rollback is simply undoing some of the configuration changes that were done by the user.
Configuration rollback is an atomic operation that rolls the active configuration back to a previous known
state. IOS XR has the capacity to roll back up to 100 commits. If an error is encountered in the rollback
operation, active configuration is not changed. The show rollback points command can be used to list all the
rollbacks. Each rollback commit is logged with the user information that made the commit along with a
timestamp. You can make the rollback point more user friendly by providing a comment using CLI. Because
these are different commit files or refpoints, you can view the configuration changes that went in for every
commit using show configuration rollback changes <commit id>. The command show configuration commit
list can be used to list all the commit IDs that can be used for rollback with the user and timestamp
information of every commit.
4. Appendices
4.1 Cisco Network Design Best Practices

4.1.1 High Availability
HA Feature Components:
Non Stop Forwarding (NSF):

This will be deployed for all the Routing Protocols. All IP RAN routers will be configured NSF – Capable
routers as they have Dual RP engines. The peering routers will be configured as NSF aware routers to
understand and respond to NSF capable Hello messages and synchronize to maintain pre-switchover FIB
states. This will be deployed for OSPF and LDP. The NSF Mode used will be “IETF”
Graceful Restart (GR)
This will be deployed for BGP GR and existing parameters of GR from MPBN routers will be maintained
for BGP GR configuration: BGP GR: Re-start timer & Stale-path timer will maintained from existing MPBN
Routers. Recommended values: Re-start timer (reconnect-timeout) : 120, Stale-path timer (forwarding-
state-holdtime): 360
Non Stop Routing (NSR)
Non-Stop Routing (NSR) is the latest evolution of HA features and is a self-contained solution to
maintain the routing service during: · RP fail-over , · Process restart , · In Service Software Upgrade
(ISSU). The aim of NSR is to avoid any kind of disruption of the routing protocol interaction with other
routers. This will be deployed for BGP, OSPF and LDP. Each routing plane protocol will be configured
with “NSR”
ISSU (In Service Software Upgrade)
BFD (Bidirectional Fault Detection)
 Bidirectional Forwarding (BFD) is a lightweight protocol and designed to provide a single mechanism
to detect failures in the path between two adjacent forwarding engines .
 It provides a low-overhead, short-duration method of detecting failures in the forwarding path,
including the interfaces, data links, and forwarding planes.
 BFD operates in a unicast, point-to-point mode on top of any data protocol being forwarded between
two systems. To guarantee timely transmission of BFD control packets, BFD control packets are sent
using CEF interrupt path. BFD packet reception processing is not punted to process level and is done
in the CEF switching path in interrupt level.
 When routing protocol discovers a neighbor, it can call BFD to start BFD session with that neighbor.
When BFD detects the neighbor is down, BFD will notify to the registered routing protocol(s). Beyond
this point, it‘s all up to the routing protocol to do the route convergence around the failed link, and
goes through the normal neighbor discovery cycle and re-establishes neighbor relationship to achieve
a fast link down reaction, and a normal link up detection. BFD uses UDP as the encapsulating protocol
(destination port 3784 and source port between 49252 to 65535).
 BFD is independent of the upper-layer protocol. Several upper-layer protocols may use the same BFD
session to track the status of a neighbor by registering as clients with the BFD process. BFD then
propagates neighbor state-change events to the registered clients.
 BFD provides optimum performance and the timer granularity required for fast convergence. BFD
hello times on the order of hundreds or even tens of milliseconds are supported.
 BFD is optimized for forwarding-plane fault detection. Where possible, BFD functions are implemented
locally on the line card rather than on the Route Processor, and in such a way as to provide maximum
validation of the actual forwarding infrastructure.
 BFD has two main parameters minimum-interval and bfd-multiplier which will be set to 300ms and 3
respectively in Idea IPRAN network.
Redundancy Protocol: VRRP
The Virtual Router Redundancy Protocol (VRRP) is an election protocol that dynamically assigns
responsibility for one or more virtual routers to the VRRP routers on a LAN, allowing several routers on a
multiaccess link to utilize the same virtual IP address. A VRRP router is configured to run the VRRP protocol
in conjunction with one or more other routers attached to a LAN. In a VRRP configuration, one router is
elected as the virtual router master, with the other routers acting as backups in case the virtual router master
fails.
We propose to have VRRP configured across all the IP RAN Routers with the parameters as per below table:
VRRP Groups Yes
Features
Advertise-Interval 300 ms
Hold-Interval 1s
Preempt Yes (360 ms)
Object Tracking Yes (Wherever required)
Priority 120 (Master), 90 (Backup)
Other
Table 18: VRRP Protocol Values
4.1.2 Security
Network & Device Security:

Following services are potential hole for network & device security which could be used by attackers for
service interruption hence it should be enabled/disabled as recommended.
Security Service Default Behaviour Command

Disable Finger Service Disable no ip finger
Disable PAD Service Disable NA
Verifying that TCP Small Servers Service is Disabled Disable no service {ipv4|ipv6} tcp-small-servers
Verifying that UDP Small Servers Service is Disabled Disable no service {ipv4|ipv6} udp-small-servers
Disable CDP Disable no cdp
Disable IP Source Route Disable no ipv4 source−route
Disable Bootp Disable ipv4 helper-address
exec-timeout 5 0
Enable TCP Keepalives for Inbound Telnet/SSH Sessions 30 secs session-timeout 5
exec-timeout 5 0
Enable TCP Keepalives for Outbound Telnet/SSH Sessions 30 secs session-timeout 5
service timestamps debug datetime
Enable Sequence Numbers and Time Stamps on Debugs Enable [localtime] [msec] [show-timezone]
Set TCP Synwait Time Default value is 30 sec tcp synwait-time 5
Disable IP Redirects Disable ipv4redirects (Interface level)
Disable IP Proxy ARP Disable proxy-arp (Inetrface level)
Disable IP Directed Broadcast , Disable IP Unreachables Disable ipv4 directed-broadcast (Interface level)
Disable MOP Disable no mop for non-ethernet based interface
Disable IP HTTP server Disable no http server
Disable DHCP Disable no dhcp {ipv4|ipv6}
Table 19: Security Guideline
Operational Security:
Following services need to be enabled for operational and monitoring purposes but should be restricted to
authorised uses only, using access-lists and password.
 SNMP and SNMP communities: SNMP v2c should be configured across all IP RAN Router
 Device Trap Logging
 SNMP Polling
 Router Access Control: Ideal Timeout for each router should be 10 minutes for each user; Concurrent
user login on each router should be restricted to 5.
 Access Class on VTY Lines
 Enable SSH for Access to the Router
 Source interface for network operations
 Banners : Following banner should be used across all devices
“You are about to log on to a proprietary system where access is provided, by the Owner of the system,
only to authorized users. If you are not authorized to use this system, please refrain from doing so. All
activities on this system are being monitored. Unauthorized access to this system may be subjected to
legal action and/or prosecution”
Service Provider Security:

In addition to the services above, Service Providers also need to have additional Security in agreement with
their peers or customers. Following list suggests the possible security mechanisms.
 Label Distribution Protocol (LDP) Security: MD5 Authentication
 Controlling the number of VRF routes : Optional
 PE-CE Routing Protocol Security
o eBGP MD5 authentication
o eBGP Prefix Limits (optional)
 Service provider data plane security
o Securing the Data Plane
o Infrastructure ACLs
4.1.3 Prevention from Attacks
ICMP Traffic Rate Limiter : This is not deployed yet on IPRAN
 ICMP supports IP traffic by relaying information about paths, routes, and network conditions.
ICMP host unreachable messages are sent out if a router receives a non-broadcast packet
that uses an unknown protocol, or if the router receives a packet that it is unable to deliver to
the ultimate destination because it knows of no route to the destination address. These
messages can be used by an attacker to gain network mapping information.
 The command to disable ICMP host unreachable messages is as follows:
interface <Type Number>
no ip unreachables
 To limit number of ICMP unreachable messages from the routers and not to disable them on
interfaces use global command "icmp ipv4 rate-limit unreachable".
Control Plane Policing (CoPP)/ LPTS (Local Packet Transport Services)
 LPTS Characteristics
 LPTS has Hardware policers on line cards to limit traffic sent to local or remote
nodes
 LPTS entries in TCAM classifies packets to select a policer to apply
 The policer value can be tuned to 0 (to drop all packet matching classification
criteria)
 Polices on protocol (BGP, OSPF, SSH) and flow state (BGP established, BGP
configured, and BGP listen)
 Policing done on the LC Hardware ASIC before packets hit RP/LC CPU
 Filters are automatically and dynamically installed by the IOS XR infrastructure
Note: We will be using default LPTS values which are inbuilt in the ASR – 9K Platform (IOS-XR: 4.3.1), we
will be monitoring and tracking LPTS counters for the behavior.
4.1.4 MPLS Core Convergence
There are many features and procedures available to improve convergence times in an MPLS network. Three
procedures that may be applicable to the IP RAN core as follows:
FRR (Fast Re Route)

BGP Next Hop Tracking
FRR (Fast Re Route)
A feature of MPLS traffic engineering is a procedure known as fast reroute (FRR). FRR can protect an
individual link such that in the event of a failure of the link, traffic can be rerouted.
This means that each link along the TE LSP can be protected and a backup path instigated from the point of
the link failure, independent of the head-router. This differs from path protection, where the backup path is
instigated from the head-end router.
With FRR, the head-end router does not need to be immediately aware of the failure and from its perspective
the established TE tunnel will operate as normally. It will eventually be informed of a failure after the reroute
phase, and can make a decision on whether to calculate a new path in a different direction.
FRR will be used in Idea’s IP RAN Network for switchover between Primary & Second TE tunnels.
BGP Next Hop tracking
In Cisco IOS-XR, the BGP process has a procedure call the scanner which runs every 60 seconds. The
scanner’s task is to do general house-keeping work and walk the BGP table to validate the next hops currently
used for BGP routes. BGP next hops are mostly IGP routes and the IGP metric is accounted in BGP best path
algorithm. Therefore, if the next hop changes due to an IGP event, BGP must run the best path algorithm, as
the currently chosen best path may have become invalid due to non-reachability. This scanner process is run
at 60 second intervals so that a churn in IGP will not result in a churn in BGP.
However, in the case where the IGP is not churning and due to some event the next hop is no longer available
or a better next hop has become available, it may be desirable for BGP to react much faster than 60 seconds.
BGP next hop tracking is a new feature that will help BGP to react faster than the default 60 seconds in the
case there is no churn in the IGP. However, in case of there is considerable IGP churn then there are
mechanisms in the feature to avoid propagating the churn into BGP
4.1.5 Recommended Protocol Timers
Based on the implementation in various service providers and best practises, NOKIA recommends following
timer values for IP RAN deployment
Protocol Timer Network Type Default Recommended

Value Value
OSPF Hello-interval Point-to-point & 10 s 10 s

Broadcast
NBMA, P2MP, P2MP 30 s 30 s
(NB)
Dead-interval Point-to-point & 40 s 40 s
Broadcast
NBMA, P2MP, P2MP 120 s 120 s
(NB)
Retransmission- - 5s 5s
interval
BGP Keepalive - 60 s 30 s
Hold-down - 180 s 90 s
Advertisement-interval iBGP 0s 0s
eBGP 30 s 30 s
Scan-timer - 60 s 60 s
BGP NHT Delay-timer - 5s 5s
Graceful-restart restart-time 120 s 120 s
stalepath-time 360 s 360 s
VRRP Advertisement-interval - 1s 300 ms
Minimum-interval LAN/WAN None 300 ms
BFD
Detect Multiplier - 3 3
Table 20 : Recommended Protocol Timer Values
4.2 References
Introduction to IOS-XR- Cisco's Next Generation Operating System
https://www.ciscolive365.com/connect/sessionDetail.ww?SESSION_ID=5339&tclass=popup
The Cisco ASR 9000 Architecture
https://www.ciscolive365.com/connect/sessionDetail.ww?SESSION_ID=5321&backBtn=true
Cisco ASR9000 Configuration Guides
http://www.cisco.com/en/US/products/ps5845/products_installation_and_configuration_guides_list.html
Cisco IOS XR Software Release 4.3.1 for Cisco ASR 9000 Series Aggregation Service
Router
http://www.cisco.com/en/US/customer/docs/routers/asr9000/software/asr9k_r4.3/general/release/notes/reln_431a9
k.html#d25e2294a1635
Converting Cisco IOS Configurations to Cisco IOS-XR Configurations
http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.5/xr12000_conversion/reference/guide/cnv_r35.pdf
New and Changed Features in Cisco IOS XR Software, Release 4.3.x for Cisco ASR 9000
Series Aggregation Services Router
http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/new_changed_info/b_new_and_changed
_info_r43xasr9k.pdf
OSPF Design Guide
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml
Cisco Guide to Harden Cisco IOS Devices
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml
Network Time Protocol Best Practices
http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml#ntpoverview
4.3 IOS-XR Rel 4.3.1 Feature Summary
4.3.1 Feature Summary List
Software Features Introduced in Cisco IOS XR Software Release 4.3.1 for Cisco ASR 9000 Series
Aggregation Service Router is as listed below for more details about each feature please refer link in
references appendix.
 BFD over MPLS Traffic Engineering LSPs
 BFD over Pseudowire Headend
 BFD over Satellite Interfaces
 BGP VRF Dynamic Route Leaking
 Flexible L3VPN Label Allocation Mode
 IS-IS IP/LDP Remote Loop Free Alternate Fast Re-route
 IS-IS IPv6 Loop Free Alternate Fast Re-route
 IS-IS Link-group
 LISP Virtualization
 LISP xTR Support
 LISP Common Control Plane
 OSPF IP/LDP Remote Loop Free Alternate Fast Re-route
 OSPFv2 Autoroute Exclude
 OSPFv2 Unequal Cost Load Balancing
 OSPFv3 Loop Free Alternate Fast Re-route
 Match tag Support for OSPF distribute-list in
 Selective VRF Download Disable
 VPN Route Limit
 VRF Import Policy Enhancement
 Auto-IP Configuration for nV Satellite System
 CFM Scale Enhancements
 ICCP Based Service Multihoming
 Small Frame Padding
 Y.1731 Loss Measurement Mechanism
 PPPoE Smart Server Selection
 NAS-Port-Type on Interface or VLAN Sub-interface
 L2TP Reassembly on LAC
 IETF Tagged Attributes on LAC
 PPPoE Session Limit and Throttle
 PPPoE Session Limit
 PPPoE Session Throttle
 VLAN Policy on Access Interface
 Service Accounting
 Merging QoS Policy-maps
 L2TP Access Concentrator Stateful Switchover
 Option 82 Relay Information Encapsulation
 GPRS Tunneling Protocol Load Balancing
 L2TPv3 over IPv6
 PWHEv6 Support
 Virtual Connection Type 4 Support with BGP Auto-discovery
 IPv6 Rapid Deployment
 SNMP Phase 1 Enhancements
 SyncE and PTP MIB
 Mapping of Address and Port-Encapsulation Mode
 Point-to-Point Tunneling Protocol-Application Level Gateway
 Real-Time Streaming Protocol-Application Level Gateway
 ACL-Chaining
 ACL Scale Enhancements
 ATMoMPLS Cell Relay Virtual Path Mode
 Bandwidth Reservation Percentage
 IP-Less MPLS-TP Ping and MPLS-TP Traceroute
 Label Security for BGP Inter-AS Option-B
 MPLS OAM Support for BGP 3107
 MPLS-TP LSP Wrapping
 Policy-Based Tunnel Selection
 Weighted-SRLG Auto-backup Path Computation
 DHCPv6 Proxy Binding Table Reload Persistency
 Service Guarantee Architecture (SGA)
 VRF-aware MSDP
 Netflow over BVI
 ISSU Support
 Flexible CLI Configuration Groups
 SSHv2 Client Keyboard-Interactive Authentication
 Configuring FIPS Mode
 Software Feature Enhancements
4.3.2 Software Maintenance Updates
Allows for software package installation/removal leveraging on Modularity and process restart
Redundant processors are not mandatory (unlike ISSU) and in many cases are non service impacting and
may not require reload.
 Mechanism for delivery of software features (e.g. Multicast, MPLS)
 Delivery of critical bug fixes without the need to wait for next maintenance release
Here is the list of recommended SMU for IOS-XR Release 4.3.1
http://www.cisco.com/web/Cisco_IOS_XR_Software/pdf/ASR9000_431_Release_SMU_Recommendation.pdf
4.4 Bill of Material
Unit
Sr. Remarks (Elucidation in plain and Quantity
Model Number Hardware / Software Description
No. simple language) (Per Router
Chassis)
Requirement for BoQ - 1 (Single Chassis Specific)
ASR 9010 DC Chassis with PEM
1 ASR-9010-DC-V2 Version 2 Base ASR 9010 DC Chassis 1
2 ASR-9010-FAN ASR-9010 Fan Tray Fan Tray's 2 numbers in each boxes 2
3 modules of 2000 KW DC power
supply has been included in 9010
3 PWR-2KW-DC-V2 2KW DC Power Module Version 2 chassis 5
ASR9K Route Switch Processor with RSP enabling 440 Gig with support
4 A9K-RSP440-SE 440G/slot Fabric and 12GB of different clocking options 2
Cisco IOS XR IP/MPLS Core
5 XR-A9K-PXK9-04.02 Software 3DES for RSP440 IOS image 1
6 A9K-LC-FILR A9K Line Card Slot Filler Line Card Slot Filler 6
ASR9K Power Entry Module Version Power Entry Module Version 2
7 A9K-PEM-V2-FILR 2 Filler Filler 5
8 ASR-9010-4P-KIT ASR-9010 4 Post Mounting Kit Chassis Mounting Kit 1
80G Modular Linecard Service Edge
9 A9K-MOD80-SE Optimized MOD 80 SE Card 1
ASR 9000 20-port 1GE Modular 20 x 1 Port GE MPA Card with 256
10 A9K-MPA-20X1GE Port Adapter K queues 1
11 SFP-GE-L 1000BASE-LX/LH SFP (DOM) SFP for Fiber ports Single Mode 5
12 SFP-GE-T 1000BASE-T SFP (NEBS 3 ESD) Electrical SFP 15
ASR 9000 4-port 10GE Modular
13 A9K-MPA-4X10GE Port Adapter Modular Port Adapter - 4x10GE 1
Multirate XFP module for
14 XFP-10GLR-OC192SR 10GBASE-LR and OC192 SR-1 Optical 10GE XFP Single Mode 4
L3 VPN License for MOD80 Service Edge L3VPN with higher
15 A9K-MOD80-AIP-SE Linecard Service Edge Optimized Scale 1
ASR 9000 20-port 1GE Modular 20 x 1 Port GE MPA Card with 256
17 A9K-MPA-20X1GE Port Adapter K queues 1
ASR 9000 4-port 10GE Modular
19 A9K-MPA-4X10GE Port Adapter Modular Port Adapter - 4x10GE 1
Multirate XFP module for
20 XFP-10GLR-OC192SR 10GBASE-LR and OC192 SR-1 Optical 10GE XFP Single Mode 4
L3 VPN License for MOD80 Service Edge L3VPN with higher
21 A9K-MOD80-AIP-SE Linecard Service Edge Optimized Scale 1
Table 21: ASR 9010 Bill of Material
Unit
Quantity
Sr. Remarks (Elucidation in plain and
Model Number Hardware / Software Description (Per
No. simple language)
Router
Chassis)
Requirement for BoQ - 2 (Single Chassis Specific)
ASR 9006 DC Chassis with PEM Version
1 ASR-9006-DC-V2 2 ASR 9006 DC Chassis 1
2 ASR-9006-FAN ASR-9006 Fan Tray ASR 9006 Fan tray 2
3 PWR-2KW-DC-V2 2KW DC Power Module Version 2 2KW DC power supply 4
ASR9K Route Switch Processor with RSP enabling 440 Gig with support of
4 A9K-RSP440-SE 440G/slot Fabric and 12GB different clocking options 2
Cisco IOS XR IP/MPLS Core Software
5 XR-A9K-PXK9-04.02 3DES for RSP440 IOS image 1
6 A9K-LC-FILR A9K Line Card Slot Filler Line Card Slot Filler 3
ASR9K Power Entry Module Version 2
7 A9K-PEM-V2-FILR Filler Power Entry Module Version 2 Filler 2
ASR 9000 20-port 1GE Modular Port 20 x 1 Port GE MPA Card with 256 K
9 A9K-MPA-20X1GE Adapter queues 1
10 SFP-GE-L 1000BASE-LX/LH SFP (DOM) SFP for Fiber ports Single Mode 2
ASR 9000 4-port 10GE Modular Port
12 A9K-MPA-4X10GE Adapter Modular Port Adapter - 4x10GE 1
Multirate XFP module for 10GBASE-LR
13 XFP-10GLR-OC192SR and OC192 SR-1 Optical 10GE XFP Single Mode 4
L3 VPN License for MOD80 Linecard Service Edge L3VPN with higher
14 A9K-MOD80-AIP-SE Service Edge Optimized Scale 1
Table 22: ASR 9006 Bill of Material
Circle Location BoQ-1-Product BoQ-2-Product

MH Pune– Vega Centre 2
Aurangabad-2 2
Kolhapur–2 2
Panjim (Goa) 2
Nagpur–2 2
Nashik–2 2
Pune-Sharda Center 2
Pune– Vega Centre 2 2
Total Qty 4 12
KER Calicut 2
Ernakulum (KKD) 2
Trivandrum 2
Total Qty 2 4
UPW Agra 2
Moradabad 2
Meerut 2
Dehradun 2
Total Qty 2 6
UPE Varanasi 2
Lucknow-1 2
Lucknow-2 2
Kanpur 2
Azamgarh 2
Gorakhpur 2
Total Qty 4 8
DL Noida E5 2
Vikaspuri 2
MCIE 2
Total Qty 2 4
BH Patna-2 2
Total Qty 0 2
Table 23: Location wise Distribution of IP RAN Routers
4.5 Glossary
AS—An autonomous system is a collection of networks under a common administration sharing a common
routing strategy.
BGP— Border Gateway Protocol is an exterior routing protocol that exchanges network reachability
information with other BGP systems (which may be within the same autonomous system or between multiple
autonomous systems).
eBGP—External Border Gateway Protocol used for BGP peering between routers located within different
autonomous systems
iBGP—Internal Border Gateway Protocol used for BGP peering between routers within the same autonomous
system
IGP—Interior Gateway Protocol is interior routing protocol used to exchange routing information within a single
autonomous system. Examples of common Internet IGP protocols include IGRP, OSPF, IS-IS, and RIP.
MP-BGP—Multiprotocol BGP
MPLS—Multiprotocol Label Switching
LSP---Label Switched Path
RSVP----Resource Reservation Protocol
MPLS-TE----MPLS Traffic Engineering
BFD: Bidirectional Forwarding Detection
NSF—Nonstop forwarding enables routers to continuously forward IP packets following a Route Processor
takeover or switchover to another Route Processor. NSF maintains and updates Layer 3 routing and
forwarding information in the backup Route Processor to ensure that IP packets and routing protocol
information are forwarded continuously during the switchover and route convergence process.
PE router—Provider edge router is part of a service provider's network. It is connected to a customer edge
(CE) router. All MPLS VPN processing occurs in the PE router.
P router—Provider router is part of a service provider's core network and used to connect provider routers at
different locations.
QoS—Quality of service is measure of performance for a transmission system that indicates its transmission
quality and service availability.
RD—Route distinguisher is an 8-byte value that is concatenated with an IPv4 prefix to create a unique VPN-
IPv4 prefix.
VPN—Virtual Private Network is secure MPLS-based network that shares resources on one or more physical
networks (typically implemented by one or more service providers). A VPN contains geographically dispersed
sites that can communicate securely over a shared backbone network.
VRF—VPN routing and forwarding instance is Routing information that defines a VPN site that is attached to a
PE router. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the
forwarding table and a set of rules and routing protocols that determine what goes into the forwarding table.
DSCP---Differentiated Services Code Point is an integer value encoded in the DS field of an IP header. The
DSCP is an example of traffic marking because its value corresponds with a preferred QoS as the packet
traverses the network. The DSCP value corresponds to a specific QoS.
DWDM---Dense Wavelength Division Multiplexing is a fiber-optic transmission technique that employs light
wavelengths. Multiple incoming optical signals are combined into a group for transmission over a single fiber.
DWDM can be used as a means of extending the lifespan of existing fibers
FEC---Forwarding Equivalence Class is a group of IP packets that are forwarded over the same path and with
the same traffic handling treatment. An FEC can be a destination IP subnet or a traffic class that the LER
considers significant
LSP---Label Switched Paths are often also referred to as tunnels. LSPs are used to transport data, such as IP
packets, across an MPLS network. An LSP is a set of hops across a number of MPLS nodes. At the edge of
the MPLS network, the incoming traffic is encapsulated in an MPLS frame and the latter is then routed, using
the embedded label for addressing. The path traversed by an LSP can be specifically engineered for traffic so
that different incoming traffic streams receive different service levels
PNNI---Private Network-To-Network Interface is an ATM Forum protocol that supports QoS and hierarchical
operation in ATM networks. It supports routing and signaling in multivendor ATM networks. PNNI hierarchy is
provided via peer groups--any nodes that share a given peer group ID elect a peer group leader, which then
represents the peer group in the next level of hierarchy. Each PNNI node has a topology database that
represents its view of the network. Signaling is used to create connections (e.g., SPVCCs) across the network
RAS---A Remote Access Server is a combination of a computer and specific software that exists to provide
remote network access to users. A RAS is often associated with a firewall to ensure security and may operate
in conjunction with a router for forwarding the remote access requests to some other part of the network. A
RAS may also be used as part of a virtual private network or a wireless network
TOS-- Type of Service (RFC 1349) is a single-byte field in an IP packet header that specifies the service level
required for the packet. It is now called the DS field and can have the following values:
 Bits 0-2: Precedence

 Bit 3: 0 = Normal Delay, 1 = Low Delay
 Bit 4: 0 = Normal Throughput, 1 = High Throughput
 Bit 5: 0 = Normal Reliability, 1 = High Reliability
 Bits 6-7: Reserved for Future UseUML
WAN-- A Wide Area Network is a geographically distributed telecommunications network. Often, a WAN is
employed to interconnect LANs across a corporation. A WAN may be privately owned, leased, or rented, but
normally includes some element of public networks
- - - - End of Document- - - - -

Idea - IPRAN - HLD 2.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Idea - IPRAN - HLD 2.2

Uploaded by

Copyright:

Available Formats

Idea IP RAN

High Level Design Document

1.1 Document Author

Mitrabh Shukla mitrabh.shukla@Nokia.com

1.2 Document Approver

Milin Shah milin.shah@idea.adityabirla.com

Neelesh Balani neelesh.balani@idea.adityabirla.com

1.2 Idea 27th Aug 2013 Changes in diagrams and addition of

1.3 Idea 2nd Sep 2013 Changes in write-ups and explanation of

1.4 Idea 5th Sep 2013 Changes in diagrams

1.5 Idea 30th Jun 2014 Added Delhi circle in HLD

1.7 Idea 9th July 2014 Added Bihar Circle

1.9 Idea 28th Aug 2014 Added Pune – Sharda Centre

2.1 Idea 27th Nov 2015 New RR Architecture

2.2 Idea 24th Aug 2016 Removed Non-Nokia Circle,QOS update

BSC MPBN Gb Switch National

10 Gbps P2P bandwidth on DWDM (ASON Protected)

1 Gbps P2P bandwidth on EoSDH Mux (Protected)

1 Gbps P2P bandwidth on DWDM (ASON Protected)

Figure 1: Network icons used in the document

 Adequate amount of routing / switching capacity to fulfill future 3G RAN requirements

Following interfaces will be in focus throughout this document:

Router Naming Convention:

<Circle Name><City Name><Location code><Service Type><NE type><Instance No.>

<XX> <XXX> <XXX> <XX> <X> <XX>

<Circle Code> is 2 alphabets representing circle name.

Sr. No. Circle Name Circle Code

Table 1: Circle Codes

Table 2: City Codes

Interface Naming Conventions:

Device name: as configured on the remote device

Sr. No. Link Type Description Code

Table 4: Bandwidth Codes

Kakanad Logical Fully Meshed UP-W

BIHAR Lucknow-1 Kanpur

Figure 2: IP RAN Network Architecture of Nokia Circle

BSC iBGP (AS 55644) with Hierarchical LSP BSC

BGP – LU BGP – LU BGP – LU BGP – LU BGP – LU BGP – LU

RSVP RSVP RSVP

Figure 3: IP RAN Network Architecture (Proposed)

Figure 4: Circle Level IP RAN Network Architecture (Proposed)

Network IPRAN Network

CS-Core / STP / OSS / IN Vikaspuri

Figure 5: Delhi Circle Transmission Topology

o Above diagram shows the proposed connectivity of the Delhi circle.

CS-Core / STP / OSS / IN

Figure 6: Delhi Circle Transmission Topology (Transmission)

Network IPRAN Network

MCIE PaCo RNC BSC

Delhi circle MPBN Network

CS-Core / STP / OSS / IN Vikaspuri

Figure 7: Delhi Circle Proposed Architecture

o There will be 1+1 deployment of PRE-AGG router in Delhi circle.

RNC Sharda BSC

BSC Pune-Vega Nagpur-2

Figure 8: Maharashtra Circle Transmission (Current)

o Above diagram shows the proposed connectivity of the Maharashtra circle.

Pune-Vega Nashik-2 RNC

Figure 9: Maharashtra Circle Transmission (Proposed)

o There will be 1+0 deployment of PRE-AGG router in MH&G circle.

Kerala-IP RAN Network

CS Core / STP / OSS

Figure 10: Kerala Circle Transmission Topology