Вы находитесь на странице: 1из 130

VTN VN2 High Level Design

VTN VN2 High Level Design

May 2009

Final Version

2 of 130

VTN VN2 High Level Design

Document Revision history


Version V0.1 V0.2 V0.3 V.0.4 Date 29/12/08 9/1/09 22/1/09 20/1/09 Author Ronald Lee, Leonard Tan Ronald Lee, Ma Shaowen Ronald Lee Ronald Lee, Leonard Tan, Anh Tuan Chu, Ed Spencer Ronald Lee, Ed Spencer Ed Spencer, Leonard Tan, Anh Tuan Chu Leonard Tan, Ma Shaowen, Anh Tuan Chu Leonard Tan, Ma Shaowen Comment / Changes First draft for comments Second draft for comments Third draft for comments Fourth draft for comments

V.0.5 V0.6

1/3/09 14/03/09

Fifth draft for comments Sixth draft version

V0.7

20/03/09

Seventh draft version

V0.8

04/05/09

Incorporated inputs from the 22Apr meeting

Document Distribution
Name Title Company

3 of 130

VTN VN2 High Level Design

Table of Contents
Document Revision history ............................................................................................................... 1 Document Revision history ............................................................................................................... 2 Document Distribution....................................................................................................................... 2 Table of Contents.............................................................................................................................. 3 1 Scope ....................................................................................................................................... 5 2 Assumptions............................................................................................................................. 5 3 Introduction .............................................................................................................................. 5 4 Network Design Requirements ................................................................................................. 5 5 Physical Network Topology ...................................................................................................... 5 5.1 Network Architecture........................................................................................................ 5 5.2 Existing Network Architecture Caveats ............................................................................ 5 5.3 POP Types and POP design............................................................................................ 5 5.3.1 Type A1 ................................................................................................................... 5 5.3.2 Type A2 ................................................................................................................... 5 5.3.3 Type A3 ................................................................................................................... 5 5.3.4 Type A4 ................................................................................................................... 5 5.3.5 Type A5 ................................................................................................................... 5 5.3.6 Type A6 ................................................................................................................... 5 5.3.7 Type B1 ................................................................................................................... 5 5.3.8 Type B2 ................................................................................................................... 5 5.3.9 Type B3 ................................................................................................................... 5 5.3.10 Type B4 ................................................................................................................... 5 5.3.11 Type B5 ................................................................................................................... 5 5.3.12 Type B6 ................................................................................................................... 5 5.3.13 Type C1................................................................................................................... 5 5.3.14 Type C2................................................................................................................... 5 5.3.15 Type C3................................................................................................................... 5 5.3.16 Type C4................................................................................................................... 5 5.3.17 Type C5................................................................................................................... 5 5.3.18 Type D..................................................................................................................... 5 5.3.19 HNI ASBR ............................................................................................................... 5 5.3.20 HCM ASBR ............................................................................................................. 5 5.3.21 DNG ASBR.............................................................................................................. 5 5.4 Aggregated Core plane facing uplinks ............................................................................. 5 5.5 Network elements types and positioning. ......................................................................... 5 6 Logic al Network Topology ........................................................................................................5 6.1 IP Addressing and naming convention. ............................................................................ 5 6.1.1 IP Addressing .......................................................................................................... 5 6.1.2 Node Naming .......................................................................................................... 5 6.1.3 Port Naming ............................................................................................................ 5 6.1.4 Network Interface Naming ....................................................................................... 5 6.1.5 Service Distribution Point Naming ........................................................................... 5 6.2 IP Routing Recommendations ......................................................................................... 5 6.2.1 Overview ................................................................................................................. 5 6.3 Routing and Control Protocols ......................................................................................... 5

4 of 130

VTN VN2 High Level Design

6.4 End-to-End Logical Topology ........................................................................................... 5 6.4.1 IGP .......................................................................................................................... 5 6.4.2 IGP in Metro Networks ............................................................................................ 5 6.4.3 In-band management to Metro Networks................................................................. 5 6.4.4 BGP......................................................................................................................... 5 6.5 IP Multicast Recommendations........................................................................................ 5 6.5.1 Rendezvous Point (RP) placement.......................................................................... 5 6.5.2 Reverse Path Forwarding (RPF) considerations...................................................... 5 6.6 MPLS Topology and Signalling Overview. ....................................................................... 5 6.6.1 Overview ................................................................................................................. 5 6.6.2 Usage ...................................................................................................................... 5 6.6.3 Backbone MPLS...................................................................................................... 5 6.6.4 RSVP Signalled LSP Topology................................................................................ 5 6.6.5 Traffic Engineering .................................................................................................. 5 6.6.6 Edge MPLS ............................................................................................................. 5 6.7 High Availability................................................................................................................ 5 6.7.1 Border Router related Failure .................................................................................. 5 6.7.2 PE upstream related Failure .................................................................................... 5 6.7.3 P router RSVP Label Switch Path Recovery ........................................................... 5 6.8 Network QoS Design ....................................................................................................... 5 6.8.1 QoS Overview ......................................................................................................... 5 6.8.2 Scheduling............................................................................................................... 5 6.8.3 QoS Design ............................................................................................................. 5 6.8.4 QoS on Juniper router ............................................................................................. 5 6.9 Network Security Recommendation ................................................................................. 5 6.9.1 Generic Node Access.............................................................................................. 5 6.9.2 Authentication, Authorization, and Accounting (AAA) .............................................. 5 6.9.3 User Accounts and Passwords ................................................................................ 5 6.9.4 Packet Filtering Toolset ........................................................................................... 5 6.9.5 Securing Nodes ....................................................................................................... 5 6.9.6 Securing Client Services ......................................................................................... 5 6.9.7 Juniper network management and security ............................................................. 5 7 Service Network Topology........................................................................................................5 7.1 Core and MANs interconnect ........................................................................................... 5 7.2 Service Architecture ......................................................................................................... 5 7.2.1 Ethernet Leased line service using L2 VPN............................................................. 5 7.2.2 Wide Area Switched LAN Service using VPLS ........................................................ 5 7.2.3 Wide area Routed LAN service using VPRN ........................................................... 5 7.2.4 High Speed Internet Service.................................................................................... 5 7.2.5 IPTV Video Core distribution using multicast ........................................................... 5 8 Network Management ..............................................................................................................5 8.1 Alcatel-Lucent 5620 SAM Element Manager (5620 SAM-E) ............................................ 5 8.2 Alcatel-Lucent 5620 SAM-Assurance (SAM-A) ................................................................ 5 8.3 Alcatel-Lucent 5620 SAM Provisioning (SAM-P).............................................................. 5 8.4 Alcatel-Lucent 5620 SAM Open Interface (SAM-O) ......................................................... 5 8.5 Alcatel-Lucent 5620SAM Redundancy............................................................................. 5 8.5.1 Activity switches, failovers, and switchovers............................................................ 5 8.5.2 Server activity switches ........................................................................................... 5

5 of 130

VTN VN2 High Level Design

8.5.3 Database switchovers ............................................................................................. 5 8.5.4 Database failovers................................................................................................... 5 8.5.5 Events associated with an activity switch. ............................................................... 5 8.6 Direct 5620 SAM Client Access ....................................................................................... 5 8.7 IP Addressing and Naming convention ............................................................................ 5 8.8 Bandwidth Requirement................................................................................................... 5 8.8.1 Bandwidth Requirements SAM to Network Elements .............................................. 5 8.8.2 Details on the Bandwidth Requirements .................................................................. 5 8.8.3 Possible consequences of insufficient bandwidth .................................................... 5 8.9 Server Hardware .............................................................................................................. 5 8.10 Security ............................................................................................................................ 5 8.10.1 TACACS+ Configuration.......................................................................................... 5 8.10.2 Communication Port Requirements for 5620-SAM Components ............................. 5 8.11 Network Time Protocol..................................................................................................... 5 9 NMS WANDL IP/MPLSView Solution ...................................................................................... 5 9.1 What Can WANDL Solution Offer .................................................................................... 5 9.1.1 Overview ................................................................................................................. 5 9.1.2 Online Operation Management................................................................................ 5 9.1.3 Offline Planning Simulation ..................................................................................... 5 9.1.4 Provisioning & Service Management ....................................................................... 5 9.2 Design of WANDL NMS Solution for VN2 ........................................................................ 5 9.2.1 Overall Architecture ................................................................................................. 5 9.2.2 Machines ................................................................................................................. 5 9.2.3 User Admin.............................................................................................................. 5 9.2.4 Backup .................................................................................................................... 5 10 Conclusion ............................................................................................................................... 5 References. ...................................................................................................................................... 5 Glossary............................................................................................................................................ 5

6 of 130

VTN VN2 High Level Design

1 Scope (quy m)
The scope of this document is to provide the High-Level Design considerations to ensure a stable and scalable Network implementation using the Alcatel-Lucent 7750 Service Router series. Detail is given regarding architectural high-level design principles, approaches and technology selections, however no attempt is made to detail explicit comman0064-line configuration.

7 of 130

VTN VN2 High Level Design

2 Assumptions
This document assumes that the reader is reasonably familiar with IP/MPLS, Layer-2 and Layer-3 VPNs.

VTN VN2 High Level Design

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

3 Introduction
VNPT will implement a next generation network (NGN) and Alcatel-Lucent has been selected to be the IPCORE Provider Edge (PE) router & Autonomous System Border Router (ASBR) equipment supplier for the VN2 Network. The VN2 network is being envisaged to house all of VNPTs existing networks, inclusive of all Metropolitan Networks, High speed Internet delivery Core and evolve into a new unified next-generation Core network. VN2 is to be built and expanded over time to accommodate all of VNPTs existing service offerings and support the introduction of new services such as IP Television and Videoon-Demand. This document provides high level design (HLD) & recommendations for the VN2 project specific to the PE and ASBR routers. Topics & specifications mentioned in this high level design document will provide the foundation as implementation specifications for the low level design (LLD) phase, which will translate the mentioned implementation specifications into machine specific configurations.

VTN VN2 High Level Design

4 Network Design Requirements


VN2 is poised to be the national NGN backbone network with the capabilities of delivering the following services as depicted by VNPT: High Speed Internet (Broadband access) Voice over IP (VoIP) Multicast Video services (e.g. IPTV, Video Conferencing) Unicast Video services (e.g. Video on Demand) Layer 3 IP-VPN services Layer 2 VPN services (VPLS & Pseudo-wire/VPWS)

VTN VN2 High Level Design

5 Physical Network Topology


This section describes the proposed physical network architecture.

5.1

Network Architecture

The VN2 is based on a dual Core Router plane design with 5 main core regions. These are namely: HNI, HCM, HPG, DNG & CTO. Provider edge routers within these 5 regions will be connected to the 2 Core routers located in the regional Central Office (CO). Core Routers are T-1600 supplied by Juniper Networks. Provider Edge routers and Autonomous system border routers are 7750SR-7 supplied by Alcatel-Lucent. There are a total of 10 Core routers, 79 Provider edge routers and 5 ASBR routers in the VN2 IPCore Network. It is expected that the PE routers will have high speed connectivity to BRAS and Metro Ethernet networks to be realised in separate tenders.

Figure 1: VN2 IP Core Network

Enhancement to the requested VN2 network architecture have been proposed in this high level design document to provide increased service availability and improve the level of optimum route path selection. These enhancements are essentially inter-PE connectivity for PoP with dual PE routers as well as inter- ASBR connectivity for sites with dual ASBR PE routers. For dual PE router POPs, Alcatel-Lucent strongly recommend that a series of Inter- PE link be added so as to provide increased service availability in the event of link failure to the P router.

VTN VN2 High Level Design

5.2

Existing Network Architecture Caveats

Figure 2: Failure Scenario: Inter POP VPLS

In the above failure scenario, a VPLS service is in service between HPG POP and NDH POP. Failure of the STM-64 link of HPG PE1 to HPG P1 will render the VPLS service be split into 2 isolated VPLS islands. As the failure occurred on the MPLS network interface towards HPG P1, the connected MAN-E will not be aware of the failure until the MAC address ages out. This failure scenario can be mitigated by introducing inter PE connection so that VPLS isolation does not occur during a link failure with the P router node. If the inter PE link is unavailable, the failure scenario can alternatively be mitigated by connecting the VPLS instance to an additional VLAN created within the MAN-E Metro Core to support the redundancy, RSTP will have to be configured on the VPLS for the purpose of breaking the layer 2 loop created. This will be the temporary solution until the inter-PE link is made available. The recommended bandwidth for the Inter-PE node shall be at least 3.3Gbps assuming a protection ratio of 1:3. Therefore, this will translate to a 4 x 1GE LAG between the PE nodes.

VTN VN2 High Level Design

5.3

POP Types and POP design

This section describes the various type of Point of Presence. 5.3.1 Type A1

Type A1 POP have 2 units of 7750 SR7 dual homed to MAN using 10GE interfaces as well as dual homed to P routers using STM-64 interfaces. Alcatel- Lucent recommends 4 x 1GE links between the PE router pair for increased availability. Alcatel-Lucent understands that this could only be added in subsequent expansion/variation order. 5.3.2 Type A2

Type A2 P OP have 2 units of 775 0 SR7 dual homed to MAN using 4 x 1GE interfa ces as well as d ual homed to P routers using STM- 64 interfaces.
However, the 1GE modules are not present and it is understood that VTN will be putting up request to acquire these modules for deployment. In addition, 2 x 10GE interfaces are planned for connectivity to BRAS pair. Alcatel-Lucent recommends 4 x 1GE links between the PE router pair for increased availability. It is understood that provisioning the Inter-PE links could only be added in subsequent expansion/variation order.

VTN VN2 High Level Design

5.3.3 Type A3

Type A3 POP have 2 units of 7750 SR7 dual homed to MAN using 5 x 1GE interfaces as well as dual homed to P routers using STM-64 interfaces. However, the 1GE modules are not present and it is understood that VTN will be putting up request to acquire these modules for deployment. In addition, 1 x 10GE interface is planned for connectivity to BRAS pair. Alcatel-Lucent recommends 4 x 1GE links between the PE router pair for increased availability. It is understood that provisioning the Inter-PE links could only be added in subsequent expansion/variation order. 5.3.4 Type A4

Type A4 POP have 2 units of 775 0 SR7 dual homed to M AN u sing 5 x 1GbE interfaces as well as dual homed to P routers using STM-64 interfaces. However, the 1GE modules are not present and it is understood that VTN will be putting up request to acquire these modules for deployment. In addition, 2 x 10GbE interfaces are planned for connectivity to BRAS pair. Alcatel-Lucent recommends 4 x 1GE links between the PE router pair for increased availability. It is understood that provisioning the Inter-PE links could only be added in subsequent expansion/variation order.

VTN VN2 High Level Design

5.3.5 Type A5

Type A5 POP have 2 units of 7750 SR7 dual homed to MAN using 3 x 1GE interfaces as well as dual homed to P routers using STM-64 interfaces. However, the 1GE modules are not present and it is understood that VTN will be putting up request to acquire these modules for deployment. In addition, 2 x 10GE interfaces are planned for connectivity to BRAS pair. Alcatel-Lucent recommends 4 x 1GE links between the PE router pair for increased availability. It is understood that provisioning the Inter-PE links could only be added in subsequent expansion/variation order. 5.3.6 Type A6

Type A6 POP have 2 units of 7750 SR7 dual homed to MAN using 6 x 1GE interfaces as well as dual homed to P routers using STM-64 interfaces. However, the 1GE modules are not present and it is understood that VTN will be putting up request to acquire these modules for deployment. In addition, 3 x 10GE interfaces are planned for connectivity to BRAS pair. Alcatel-Lucent recommends 4 x 1GE links between the PE router pair for increased availability. It is understood that provisioning the Inter-PE links could only be added in subsequent expansion/variation order.

VTN VN2 High Level Design

5.3.7 Type B1

Type B1 POP have 1 unit of 7750 SR7 dual homed to P routers using 2 x STM-16 interfaces. In addition, 1 x 1GE interface to MAN and 1 x 1GE interface to BRAS are planned. 5.3.8 Type B2

Type B2 POP have 1 unit of 7750 SR7 dual homed to P routers using 2 x STM-16 interfaces. In addition, 1 x 1GE interface to MAN and 2 x 1GE interface to BRAS are planned.

VTN VN2 High Level Design

5.3.9 Type B3

Type B3 POP have 1 unit of 7750 SR7 dual homed to P routers using 2 x STM-16 interfaces. In addition, 2 x 1GE interfaces to MAN and 2 x 1GE interfaces to BRAS are planned. 5.3.10 Type B4

Type B4 POP have 1 unit of 7750 SR7 dual homed to P routers using 2 x STM-16 interfaces. In addition, 2 x 1GE interfaces to MAN and 3 x 1GE interfaces to BRAS are planned.

VTN VN2 High Level Design

5.3.11 Type B5

Type B5 POP have 1 unit of 7750 SR7 dual homed to P routers using 2 x STM-16 interfaces. In addition, 3 x 1GE interfaces to MAN and 3 x 1GE interfaces to BRAS are planned. 5.3.12 Type B6

Type B6 POP have 1 unit of 7750 SR7 dual homed to P routers using 2 x STM-16 interfaces. In addition, 3 x 1GE interfaces to MAN and 4 x 1GE interfaces to BRAS are planned.

VTN VN2 High Level Design

5.3.13 Type C1

Type C1 POP have 1 unit of 7750 SR7 dual homed to P routers using 3 x STM-16 interfaces. In addition, 3 x 1GE interfaces to MAN and 1 x 10GE interface to BRAS are planned. 1GE interfaces are absent from the initial order, it is understood that VTN will be putting up additional order in time for deployment. 5.3.14 Type C2

Type C2 POP have 1 unit of 7750 SR7 dual homed to P routers using 3 x STM-16 interfaces. In addition , 3 x 1GE interfaces to MAN and 3 x 1GE interfaces to BRAS are planned.

VTN VN2 High Level Design

5.3.15 Type C3

Type C3 POP have 1 unit of 7750 SR7 dual homed to P routers using 3 x STM-16 interfaces. In addition, 2 x 1GE interfaces to MAN and 4 x 1GE interfaces to BRAS are planned. 5.3.16 Type C4

Type C4 POP have 1 unit of 7750 SR7 dual homed to P routers using 3 x STM-16 interfaces. In addition, 3 x 1GE interfaces to MAN and 4 x 1GE interfaces to BRAS are planned.

VTN VN2 High Level Design

5.3.17 Type C5

Type C5 POP have 1 unit of 7750 SR7 dual homed to P routers using 3 x STM-16 interfaces. In addition, 4 x 1GE interfaces to MAN and 4 x 1GE interfaces to BRAS are planned. 5.3.18 Type D

Type D POP have 1 unit of 7750 SR7 dual homed to P routers using 4 x STM-16 interfaces. Interface requirement for Mobile Access/Core is yet to be determined.

VTN VN2 High Level Design

5.3.19 HNI ASBR

Hanoi ASBR POP will have 2 units of 7750 SR7 dual homed to P routers using 5 x STM64 interfaces as well as 5 x 10GE interfaces to VDC1. Alcatel-Lucent recommends minimum of 1 x 10GE links between the ASBR router pair for increased availability and improved routing convergence. It was understood that Inter-ASBR link could only be added in subsequent expansion/variation order. Therefore, 10GE interfaces originally planned for connectivity to VDC has been reconfigured to allow for interconnectivity between ASBR routers. Alcatel-Lucent would request for VTN to plan for the replenishment of these 10GE interfaces where possible. 5.3.20 HCM ASBR

Ho Chi Minh ASBR POP will have 2 units of 7750 SR7 dual homed to P routers using 5 x STM-64 interfaces as well as 6 x 10GE interfaces to VDC2. Alcatel- Lucent recommends minimum of 1 x 10GE links between the ASBR router pair for increased availability and improved routing convergence. It was understood that Inter-ASBR link could only be added in subsequent expansion/variation order. Therefore, 10GE interfaces originally planned for connectivity to VDC has been reconfigured to allow for interconnectivity between

VTN VN2 High Level Design

ASBR routers. Alcatel-Lucent would request VTN to plan for the replenishment of these 10GE interfaces where possible. 5.3.21 DNG ASBR

Da Nang ASBR POP will have 1 unit of 7750 SR7 dual homed to P routers using 4 x STM64 interfaces as well as 4 x 10GE interfaces to VDC3.

5.4

Aggregated Core plane facing uplinks

For the purpose of supporting P router plane planning, the below table illustrated the aggregated bandwidth from various PE routers.
Plane 1 Plane 2 STM64 STM16 STM64 STM16 4 24 4 20 1 6 1 5 3 13 3 13 1 16 1 12 5 10 5 7 138880 171120 138880 141360 310000 280240

HNI HPG DNG CTO HCM Bandwidth Aggr BW

VTN VN2 High Level Design

5.5

Network elements types and positioning.

The offered Network Provider edge (PE) router and Autonomous System Border Router (ASBR) are both Alcatel-Lucent 7750SR-7 service routers. PE routers are equipped with 2nd generation I/O modules (IOM-2) with 40Gbps/slot capacity giving a total of 200Gbps capacity per system. PE routers can be upgraded in the future with the replacement of IOMs and MDAs to achieve greater performance of up to 100Gbps/slot. ASBR routers are equipped with 3rd generation I/O modules (IOM3XP) and Media dependent Adapters (MDA-XP) with 100Gbps/slot capacity giving a total of 500Gbps capacity per system. The 7750 SR-7 chassis is a fully redundant system and has a total of seven front access slots. Two card slots are dedicated for redundant common equipment, each of which holds one Switch Fabric/Control Processor Module (SF/CPM). Only one SF/CPM is required for full, non- blocking operation at 500 Gbps. A second SF/CPM provides complete redundancy of the fabric and the control processors. When two SR-7 SF/CPMs are installed, the traffic is load shared across the switch fabrics. The remaining five slots are used for Input / Output Module (IOM) baseboards. The 7750 SR-7 chassis supports redundant power and fan trays and is designed to be NEBS Level-3 compliant. Power options for the SR-7 include -48V DC or 120/240V AC power, supporting 1+1 redundancy. All power connection are made in the rear via 2 separate Power Entry Modules (PEMs). In addition to the PEMs, there are also DC line conditions that must be installed in the front of the chassis. System cooling within the SR-7 uses right to back airflow. Two (2) separate fan trays provide 1+1 cooling redundancy. Both fan trays are inserted in the back of the SR-7 chassis. The dimensions for the SR-7 are 14H x 17.5W x 23.5D, meaning five SR-7s will fit in a 7 foot Telco rack with room for a breaker panel.

The Juniper Networks T1600 Core Router is positioned in the VN2 network in the role of the P router. The T1600 is an (8) slot chassis, supporting up to 100Gigabit/sec per slot. Line card options to be used in the VN2 network include the 100Gigabit/sec T1600 Type-4 FPC, supporting two 4-port STM-64 PIC modules, and the 40Gigabit/sec Type-3 FPC, supporting up to four 1-port STM-64 or 4-port STM-16 PIC modules. The T1600 is a fully redundant system. Switch Interface Boards (SIB) redundancy is available as N+N, with a minimum redundancy of 4+1 available at full system capacity, great redundancy available at lower utilization,

VTN VN2 High Level Design

and a capability of graceful capacity degradation in the event of multiple failures. The Routing Engine (RE) used in VN2 is the RE-A-2000, and redundancy is 1+1, with a graceful failover capability available. Power Entry Modules (PEM) are also 1+1 redundant with load sharing capability and with multiple inputs per PEM providing a greater level of protection from individual circuit failure.

VTN VN2 High Level Design

6 Logical Network Topology


6.1 IP Addressing and naming convention.
This section addresses the recommendation for IP addressing and general naming convention to be used on the nodes. 6.1.1 IP Addressing All nodes in VN2 (P, PE, ASBR and RR) will use public IP for loopback and interface addresses. The MAN nodes will use public IP for loopback addresses and private IP for interface addresses. MAN should use separate contiguous IP address blocks for the loopback and interface addresses. 6.1.2 Node Naming Node names will be standardized and have a fixed length. The nodes will be named based on the function that they are performing, the node model and their physical location. The format will be as follows: <location><function><number> <location> <function> Three-letters defining a site location; for example HNI for Hanoi or HPG for Hai Phuong. A three-letter code indicating the function of the node; NPE for Multi Service Network PE router, NPR for Network Core router, ASR for ASBR Router, ACC for Access Router, SAM for 5620SAM Application Server & SDB for 5620SAM Database Server. A two-digit number representing the node number at this location. Where a location has multiple nodes of the same function then there will be a requirement for each node to be uniquely identified.

<number>

For example: HNINPE01 HPGAGG01 First 7750 SR Multi Service router in Hanoi First 7450 ESS Aggregation router in Hai Phuong

All naming should be represented in UPPER CASE. 6.1.3 Port Naming Access/Network port names/descriptions should be standardised in terms of representation. A proposal for the format is as follows: <a-end site>:<b-end site>:<port>

VTN VN2 High Level Design

<a-end site> <b-end site> <port> example:

Node name representing the location of the a- end of the link. Node name representing the location of the b- end of the link. Port number representing the port on the b-end. For

HNINPE01:HPGNPE01:1/1/1 A 7750 SR router in Hanoi connected to the port 1/1/1 on a 7750 SR router in Hai Phong 6.1.4 Network Interface Naming A network interface is a logical IP routing interface that can be associated with either a physical or logical port or an SONET/SDH channel. Note that the interface name can be up to 32 characters, but must start with a letter. For ease of re- configuration it is useful to avoid the logical port being tied in name to the physical. Therefore it is recommended that the network interface name should include the originating node name and the destination node name followed by a link iteration in the event of more that one network interface exists between the same end points. <a-end site>:<b-end site>:<number> <a-end> <b-end site> <number> Node name representing the location of the a- end of the link. Node name representing the name of the b-end of the link. Two-digit number representing the iteration of this a-end and b-end where multiple network interfaces exist between two sites.

For example: HNINPE01:HPGNPE01:01 The first interface connection on a 7750 SR router in Hanoi defined towards another 7750 SR router in Hai Phuong

All naming should be represented in UPPER CASE. 6.1.5 Service Distribution Point Naming Distributed VPN services across PE routers use service distribution points (SDPs) to direct traffic to another PE router through a service tunnel. SDPs are created on each participating PE router, specifying the origination address (the PE router participating in the service communication) and the destination address of another PE router. SDPs are then bound to a specific customer service. Without the binding process, far-end PE router devices are not able to participate in the service (there is no service without associating an SDP with a service).

VTN VN2 High Level Design

In the creation of SDP, the SDP identifier is an integer with a value of between 117407. A proposal for the SDP naming convention is to use the last three digits of the destination system address in decimal. Decimal zeroes must be included. For example, a far-end destination address of 10.220.11.5 would give an SDP name of 005 using the last three digits. Equally, a far-end destination address of 10.220.11.26 would give an SDP name of 026 using the last three digits.

Figure 3: Alcatel-Lucent Service Routing Architecture

Full mesh SDP will be defined to provide 100% reachability to all PE nodes and ASBR nodes.

6.2

IP Routing Recommendations

6.2.1 Overview The logical topology of the VN2 network consists of the device and interface names, the interface, link, and virtual addresses, and the suite of routing and control protocols, including both their individual scopes and interrelations, which are used to organize and bind together the physical components into a working network.

6.3

Routing and Control Protocols

A combination of (4) primary routing and forwarding control protocols have been selected for the VN2 network. The protocols are: Multiprotocol BGP IS-IS LDP RSVP

IS-IS is the baseline routing protocol, running on all devices, and enabled on all core facing physical interfaces, enabling reachability among all devices. IS-IS does not enable any services related traffic to traverse the networks, but each of the other protocols builds on top of it. Details of the use of IS-IS are given in the IGP section.

VTN VN2 High Level Design

RSVP is the next layer, using the information in IS-IS to build MPLS paths among the P routers, across the core WAN portion of the network. LDP is then layered on top of that, by tunneling LDP through the RSVP signaled paths in the core of the network. LDP runs natively between the edge and core to build a full mesh of MPLS paths among all edge routers. This enables some services, and provides the next building block for others. Details of the use of RSVP and LDP are given in the MPLS section. BGP is the top layer. Its operation is abstracted for the forwarding path, making use of centralized route reflector nodes, which are accessed using routing information from the underlying protocols. BGP provides routing information required to enable most services, in the form of a destination route with a next-hop which is reached through the LDP signalled MPLS path. Details of the use of BGP are given in the BGP section.

6.4

End-to-End Logical Topology


BRAS BRAS

Level 1

Level 1

PE P P

PE

ISIS Level 1

ISIS Level 2

ISIS Level 1

ISIS Area ID 3

ISIS Area ID 1

ISIS Area ID 2

MAN MPLS Domain

Dot1q

Backbone MPLS Domain

Dot1q

MAN MPLS Domain

LDP (tunneled) Single hop RSVP RSVP full mesh Single hop RSVP

Figure 4: End-to-End Logical Routing Architecture

An illustration of all network device types and the scope of each protocol running on each device: 6.4.1 IGP The proposed IGP for VN2 IP/MPLS backbone and the connected MANs is Integrated Intermediate System to Intermediate System (IS-IS) and requires that participating network elements support the use of OSI IS-IS for routing in TCP/IP and dual environments (RFC1195), Dynamic Hostname Exchange Mechanism (RFC2763), Support for Intermediate System to Intermediate System Cryptographic Authentication (RFC3567), and Support for Intermediate System to Intermediate System Extensions for Traffic Engineering (RFC3784).

VTN VN2 High Level Design

The following are reasons for the selection of IS-IS over OSPF as the other IGP of choice: 1. Scalability. Far better scaling for the number of router nodes in a single level of more than 1,000 routers vis--vis 250 OSPF router nodes in a single area. This will primarily mean that future expansion for VNPT would be greatly simplified as there is a whole lot more headroom for expansion without having to constantly relooking at creating more areas. 2. Security. IS-IS protocol is non-IP based, it is considered more difficult to spoof or attack from the Internet and therefore is relatively more secure in an ISP environment. 3. Lesser Resource Usage. IS-IS uses single LSP per router. OSPF has different SLA types and has one destination prefix per LSA. 4. Faster Convergence. IS-IS uses less packets to propagate routing information. On top of these, for high availability interworking, Graceful Restart will be enabled. 6.4.2 IGP in Me tro Networks After the meeting held on the 22nd of April 2009, it has been decided by VNPT that the IGP domain of the MANs be part of the IGP domain of VN2. The MANs will be IS-IS level 1 areas. Please refer to figure 4. As some of the existing MANs are already actively serving customers and are running OSPF as the de-facto IGP, we would recommend that planning should begin for those MANs to be migrated to run IS-IS. This would greatly maintain consistency throughout the network, which is very important in maintaining an operational network. 6.4.3 In-band management to Metro Networks As the MANs and VN2 belong to the same IGP domain, in band management of the nodes in the MANs is possible from anywhere within VN2. 6.4.3.1 IS-IS NSAP Addressing Alcatel-Lucent proposes IS-IS as the IGP of choice because of it scalability, hierarchical capabilities, good convergence rate. The IS-IS Network Entity Title (NET) will use the OSI NSAP format. The format of the NET is composed of the following: IS-IS NSAP format has two main components: Initial domain part (IDP) Domain Specific Part (DSP)

VTN VN2 High Level Design

Each of these are broken down as: IDP Authority and format identifier: AFI Initial domain identifier: IDI DSP High order domain specific part (HO-DSP) System Identifier (SysID) NSAP Selector (NSEL) The following parameters shall be set AFI shall be 49 (Private Addressing). IDI shall be set to 00 The High order DSP shall be international country STD code as defined ITU E164, hence 84. The system ID shall be encoded in hex from the routers 32 bit system interface. The NSEL shall be 00.

The system ID is a 6-octet field and defines an intermediate system (IS) within a particular area. Within the IS-IS domain, the system ID is formed from the IPv4 system (loopback) address. For example, the system IP address 172.16.0.101 will take the form 1720.1600.0101. The first part of the NET consists of an Area Address. A variable length field defining the area to which an Intermediate System belongs. 6.4.3.2 ISIS Hierarchy IS-IS support node population in excess of more than 1000 nodes, IS-IS hierarchy is implemented as illustrated in figure 4. The MANs and BRAS will be in IS-IS level 1 areas. The VN2 PE and P nodes will be in a IS-IS level 2 area. The VN2 PE nodes will be configured as IS-IS level 1/2. Each MAN area, together with the backbone area would be in different IS-IS areas.

VTN VN2 High Level Design

6.4.3.3 Convergence In order to utilize IS-IS as a trigger for other fast convergence/High Availability protocols (such as IBGP Multipath/BGP peer tracking) it is necessary to manipulate key timers 1. Shortest Path First (SPF) interval. Each Intermediate System creates a topology map using Dijkstras SPF algorithm. The topology is calculated as a Shortest Path Tree (SPT) with itself as root. Aside from initialisation, an SPF calculation is executed when the Shortest Path Tree (SPT) topology is changed. This may include a link failure, or a change in link metric. 2. IS-IS Link State PDU (LSP) Generation Interval. Is simply the time an Intermediate System should wait before generating and transmitting an LSP. In order to achieve fast re-convergence however, the SPF interval needs to be configurable to a sub-second value. In addition, an exponential back-off is required in order that that Intermediate Systems are not continually computing shortest paths (and consequently using valuable CPU cycles) when subsequent computations are required. All network elements should implement sub-second SPF and exponential back-off and will be configured with an initial SPF delay of 50 milliseconds. This initial wait value is to allow the router to flood the LSP that caused the trigger before actually executing the SPF calculation, and also to ensure that only one SPF calculation is carried out at receiving intermediate systems. The incremental wait between subsequent SPFs will be configured for 100 milliseconds, whilst the maximum SPF interval should be configured for 2 seconds. Note: In the instance of a failed network link, the Intermediate System at each end of the link will generate an LSP. If the initial wait value is too small, then the potential exists that a receiving Intermediate System may execute an SPF after receiving the first LSP, then execute a second SPF after receiving the second LSP. Increasing the initial SPF wait value gives sufficient time to receive both LSPs even if one (or both) LSPs need are routed suboptimally (as in the case of failure).

VTN VN2 High Level Design

Table 1 details the SPF iterations given the defined values.


Time 50 msec 100 msec after completion of first SPF execution 200 msec after completion of second SPF execution 400 msec after completion of third SPF execution 800 msec after completion of fourth SPF execution 2 seconds after completion of fifth SPF execution. Table 1 : SPF Execution with Exponential Back-off Iteration First Second Third Fourth Fifth Sixth

For LSP generation, the initial wait should be configured for 0 seconds. That is, LSPs will be generated immediately following the event. The incremental wait between subsequent LSPs being generated should be configured for 1 second, whilst the maximum LSP interval should be configured for 8 seconds. All network elements should implement sub-second SPF and exponential back-off and will be configured with an initial SPF delay of 50 milliseconds. Actual values used will be decided during the interop testing with Juniper. 6.4.3.4 Traffic Engineering Extension RSVP LSPs will be used within the VN2 network. Therefore, IS-IS TE extension will be enabled on all P and PE nodes. 6.4.3.5 Authentication Within any Service Provider environment, authentication of IGP updates is a desirable attribute. The backbone should be configured to support cryptographic authentication (HMAC-MD5) of IS-IS LSPs. Next to that its worthwhile to use also MD5 authentication for Hello LSPs. The latter provides a mechanism for securely authenticating adjacencies before LSPs can even be exchanged. Separate commands will be used to define first, the authentication type (since 7750 SR also support simple password or plain text authentication) and secondly the authentication key, which will be used to verify the PDUs sent by neighbouring routers on the interface. Configuration of MD5 cryptographic authentication of Hellos is implemented under each interface configured under the IS-IS process. The authentication-key and authentication type must be reconciled for all routers on a link/segment :

VTN VN2 High Level Design

6.4.3.6 Point-to-Point Broadcast Media On point-to-point Ethernet, the election of a Designated Intermediate System (DIS) and regular generation of CSNPs is an unnecessary function. Point-to-point Ethernet links should therefore be configured such that no DIS election takes place and reliable flooding on these links is facilitated through generation of a PSNP to explicitly acknowledge received LSPs. 6.4.3.7 BRAS connection The IS-IS protocol includes both the concept of areas and also makes use of a two level design. IS-IS Level1 routers learn only default routing information from Level1/2 routers in their area. Level1/2 routers pass routes from Level1 up to Level2. It is desirable to support a 2nd tier of edge router downstream of the PE, but without requiring the PE(s) to at each POP to be in separate areas, or to form Level1 adjacencies with each other. To achieve this, the PE should configure links to downstream edge routers as Level1, but in the backbone area. The BRAS router will take advantage of the 2nd tier edge router scheme for IS-IS in order to learn the loopback address of the upstream PE routers, and to provide the upstream PE with a route to its own loopback. This will require the PE to leak its loopback into Level2. The BRAS will then establish iBGP connectivity to the PE router(s). When dual PE routers and/or dual BRAS uplinks are configured, IS-IS will provide the mechanism for rerouting around a single link or PE router failure without requiring the propagation of a change in the BGP route across the entire network. 6.4.3.8 General Parameters (Suggested) 6.4.3.8.1 MaxAge and LSP Refresh Interval IS-IS LSPs have a remaining lifetime, which starts at the value of MaxAge and decrements to zero before they are flushed from a link state database. The LSPs must clearly be refreshed before the remaining lifetime expires. In order to reduce the amount of resource a router must dedicate to generating and processing LSPs, this default configuration should be modified to reflect an LSP MaxAge of 65535 seconds (18 hours) and an LSP refresh interval of 32767 seconds (9 hours). 6.4.3.8.2 Hello Interval and Hello-Multiplier Once an IS-IS adjacency is established, Hellos are exchanged between the Intermediate Systems that act as keepalive messages. The IS-IS Hello interval should be configured as 1 second on all interfaces, whilst the hold time or hello- multiplier should be set to a value of 3. That is, 3 x Hellos must elapse before the adjacency is declared down.

VTN VN2 High Level Design

6.4.3.9 IS-IS Scalability Table 2 details the performance and scaling characteristics for IS-IS on the 7750 SR platform.
Parameter Number of adjacencies Number of adjacencies on a single interface Number of LSP(s) Number of routes Number of routers in a level Time to run SPF on 10K routes Table 2 : IS-IS Scalability 7750 SR 252 84 25K 250K 25K < 1 second

6.4.3.10

IS-IS timing overview (Suggested)


Default Configured 10 sec 100 ms 5 sec 65535 sec 2 sec / 50 ms / 100 ms 8 sec / 0 sec / 1 sec 9 sec 3 1 sec 3 disabled disabled disabled

csnp-interval lsp-pacing-interval retransmit interval lsp-lifetime spf-wait lsp-wait IS-IS L1 hello interval IS-IS L1 hello multiplier IS-IS L2 hello interval IS-IS L2 hello multiplier overload-on-boot P node overload-on-boot PE node overload-on-boot RR node

10 sec 100 ms 5 sec 12000 sec 10 sec / 1 sec / 1 sec 5 sec / 0 sec / 1 sec 9 sec 3 9 sec 3 disabled disabled disabled Table 3 : IS-IS timings

VTN VN2 High Level Design

6.4.4 BGP This section will describe the use of the Multi-protocol Border Gateway Protocol (M-BGP) protocol for the distribution of routing information within the VN2 IP Core. 6.4.4.1 Usage BGP is typically used to distribute routing information pertaining to destination networks. For example: customer networks, application services, or Internet destinations. Intermediate network infrastructure and devices are typically excluded from BGP. Specifically, the following Network Layer Reachability Information (NLRI) types will be used, and the following types of routing information will be distributed by each: IPv4 Unicast NLRI: Upstream and Peer Internet Routes Customer Internet Routes Internal Internet and Application-Service Routes

IPv4 VPN Unicast NLRI: Customer VPN Routes

6.4.4.2 Protocol Features/Parameters Extended Communities Graceful Restart MD5 Authentication Default Timers Settings

6.4.4.3 Autonomous System Number VNPT/VTN has indicated that there would be the requirement to offer inter-service provider VPN services, therefore the Autonomous System number used to deliver BGP/MPLS IPVPN and Internet services shall ideally be a public ASN. VNPT has indicated that a Private ASN will be used initially within VN2. If no BGP router ID is specified, the global router ID will be used. If no BGP router ID and no global router ID is specified, the system interface IP address will be used. Alcatel-Lucent recommends configuring the router-id as the system ip-address. 6.4.4.4 Participants and Topology The network devices that are required to participate in BGP are those forming the border with the above referenced network destinations (customers, services, and

VTN VN2 High Level Design

the Internet). Specifically, all BRAS, PE, ASBR, and RR routers will participate in BGP. The transport core P routers do not require BGP routing information. 6.4.4.5 Route Reflector The key element of the BGP route distribution logical topology is the route reflector function, provided by dedicated RR routers. Route reflectors provide a central point of BGP peering in the network, and eliminate the need for a complex full mesh of BGP sessions. For scalability route reflectors will be organized into two regions, North and South, with a unique cluster-id for each region. A full mesh of normal iBGP sessions will be built among all RR routers.
P PE ASBR

RR

North Central & South

iBGP (NonCluster) iBGP, North Cluster iBGP, South Cluster RR

PE P P

Figure 5: Route Reflector Architecture in day 1

P PE ASBR

RR

North Central & South

iBGP (NonCluster) iBGP, North Cluster iBGP, South Cluster RR

PE P P

Figure 6: Route reflector Architecture in day 2

VTN VN2 High Level Design

On day-one each of two RR routers will establish iBGP sessions to all PE and ASBR routers, and associate these with their regional cluster. In the future both of the two RR routers in each region will establish iBGP sessions with all PE and ASBR router in the same region, and associate them with their regional cluster. 6.4.4.6 ASBR ASBR routers serve the function of learning routes associated with internet peers or transit providers, and relaying them to the RRs. The ASBRs will establish iBGP sessions with the two RR routers. Each ASBR will establish eBGP sessions with peers and transit providers, learning the full internet routing table. Default BGP behaviour is for eBGP routes to be passed on to iBGP neighbours, so these routes will be passed on to the RRs. Next-hop-self should be used to rewrite the next-hop of external routes to the loopback of the ASBR itself. The ASBRs will learn internal/customer routes from the RRs. 6.4.4.7 PE PE routers participate in BGP in order to originate customer routes into the network. All PE routers will establish iBGP sessions with the two RR routers. The PE may also establish eBGP sessions with some transit customer, learning customer routes, and relaying them to the RRs as per default BGP behaviour, but also using a next-hop-self policy. The PE will also be configured to originate customer routes learned via other protocols into BGP, including VPN routes. The PE routers will learn both internet routes and other customer/vpn routes from the RRs Each PE router, or pair of PE routers at a single POP location, will also be configured as BGP route-reflectors, using a unique cluster-id derived from the system address of the PE. The PE routers will establish iBGP sessions with all directly connected BRAS routers, and associate these sessions with the local cluster. In this way customer routes can be learned from the BRAS routers and relayed to the global RRs. Again, a nexthop-self policy will be used toward the RR so that all customer routes including those originated by the BRAS will be reachable via the loopback of the PE itself. 6.4.4.8 BRAS BRAS routers will participate in iBGP in order to originate routes for locally configured customer IP pools into BGP. BRAS routers will establish iBGP sessions with directly connected PE routers only, and will be configured to originate customer IP pool routes. They will learn default routes only from the PE routers

VTN VN2 High Level Design

6.4.4.9 Authentication The TCP MD5 signature option for cryptographic authentication defined in RFC2385 should be adopted for both IBGP and EBGP sessions. The TCP MD5 signature option defines a TCP option for carrying an MD5 digest in a TCP segment, acting like a signature for that segment. As BGP uses TCP as its transport, it is inherently secure if this mechanism is adopted. Keys used for Internal BGP sessions should be different to those used for external peering. Since authentication is performed between neighboring routers, the authentication key is configured on the neighbor level. 6.4.4.10 Policies and Route Selection The logical topology and flow of routing information described above will result in the following route selections and traffic flow: Traffic entering the network through a BRAS router will follow a BGP default route with a next-hop of the directly connected PE router. Normal IP routing will be used to reach that next-hop. Traffic entering the network through a PE or ASBR router will follow a specific BGP route to its destination, with a next-hop of another PE or ASBR. That next-hop will be reachable via MPLS. Each PE/ASBR will learn all routes from two RRs as choose the best path from the two. In most cases these two routes will have the same next-hop. The RRs learn all routes from the PE/ASBR routers, and each RR makes a single best path decision. Only the selected best path is relayed by each RR to its cluster members, so any polices required to influence BGP route selection must be implemented on the RR. The RRs must participate in IS-IS and LDP in order to have visibility to the routing information for the next-hops of all BGP routes, especially MPLS nexthops for VPN routes

6.4.4.11 Routing of Internet Traffic There will be three POPs where connections are made to the VDC network, which acts as an Internet transit provider to VN2. The three POPs correspond to the main points international circuit termination points on the VDC networks. The desired strategy is for VN2 to transport traffic to the POP used as the international exit point for that destination before handing it over to VDC. And conversely for VDC to hand traffic directly back to VN2 at the same POP where it was received, which should result in a symmetrical traffic flow of 'best exit / nearest entry' from the perspective of VN2

VTN VN2 High Level Design

6.4.4.11.1 Outbound For outbound traffic to reach the best exit POP from VN2 to the VDC network each PE must receive the best exit route from the RR. Then the PE will send traffic via MPLS to the ASBR with the next-hop of that route. The BGP route selection to determine the best exit must take place on the RR. The RR receives routes from each of the (5) ASBRs, and must have a means of differentiating them. BGP communities should be applied by the ASBR to indicate the POP in which the route was learned, and BGP communities must be sent from VDC to indicate the POP where the routes come in from the international side. Policies can be used the increase the local-preference of the routes learned at the same POP as the international link preferred of that route on the VDC side. 6.4.4.11.2 Inbound For inbound traffic to take the nearest entry POP from the VDC network toward VN2, the international facing routers in the VDC network should select routes with the next-hop of the VDC ASBR at the same POP. This behavior can be achieved in several ways, depending on the logical topology used by the VDC network. 6.4.4.11.3 Illustration The following is a simplified illustration of the physical links, logical BGP protocol topology, and the flow of traffic through VDC to and from the Internet that will result from the routing policies described above. The traffic flow toward ISP B traverses the VN2 network from North to South to reach the exit point closest to ISP B. The traffic flow from ISP A takes the entry point closes to ISP A and does not traverse the VDC network from North to South.

VTN VN2 High Level Design

VN2
PE P ASBR

VD C
ISP A

North South

RRs

ASB RP

ISP B Best Exit traffic flow BGP Nearest Entry traffic flow

Figure 7: Internet Traffic flow via VDC

6.4.4.12

BGP timing overview (Suggested)

Default min-route-advertisement connect-retry hold-time keepalive min-as-origination 30 sec 120 sec 90 sec 30 sec 15 sec Table 4 : BGP timings

Configured 30 sec 120 sec 90 sec 30 sec 15 sec

6.5

IP Multicast Recommendations

P2MP LSPs is an alternate method of distributing multicast traffic. It provides the 50ms MPLS FRR capability. This feature will need to be tested and verified between the P and PE nodes to ensure a stable rollout of multicast services using this feature. Until this feature operationally tested, PIM will be used for multicast services. Multicast traffic in VN2 is classically routed based on PIM-SM, which is best suited multicast routing protocol for sparsely dispersed sources, and more importantly, has less protocol control overhead compared with other multicast routing protocols.

VTN VN2 High Level Design

It is advised that each interface has PIM-SM correctly configured, to ensure proper operation and correctly forwarding of the multicast traffic across the backbone. PIM will be enabled on all routers in VN2 IP Core and the MANs. The MAN Agg PE routers will for PIM neighbours with the IP Core PE routers.

IP Core

PIM

PIM

IGMP static joins Duplicated MC Traffic stream

MAN

PIM

Figure 8: PIM Topology

For multicast resiliency, the IP Core PE will use IGMP static joins to distribute duplicate copies of desired multicast streams to the two MAN Agg PEs. With PIM, the MAN is able to intelligently manage duplicated multicast streams effectively by ensuring that the end devices only receive a single stream. 6.5.1 Rendezvous Point (RP) placement According to the PIM-SM protocol, all join messages are forwarded to a specific IP address, the rendezvous point (RP). It is recommended to place the RP as close as possible to the source. Considering IPTV as the primary use of multicast in VN2, it is understood that the VHO will be located within the vicinity of the HNI site; therefore, it is recommended that the RP be designated on HNI PE router nodes.

VTN VN2 High Level Design

PE IPTV Source (Primary)

(Anycast RP) North South

MSDP

PE IPTV Source (Backup)

Edge PIMSM

PE P

(Anycast RP)

IGMP

Figure 9: Multicast RP Topology

However, moving forward should the requirement for multicast VPN increases, it would be advisable to relocate the RP to a more centralise node within VN2 so that join latency is optimum throughout the entire network. Redundant RP should be implemented using Any-Cast RP whereby both HNI PE routers will be configured with the same RP address on a loopback interface. Redundant RP in accordance to draft-ietf-pim-anycast-rp-0X should also be configured to ensure that both RP will be capable of synchronising source information. This is to ensure that any failure to either RP, the redundant RP have the most current source states and thus minimises convergence delay. 6.5.2 Reverse Path Forwarding (RPF) considerations Multicast RPF is used in conjunction with PIM-SM to ensure loop-free forwarding of multicast packets. In multicast routing the decision to forward traffic is based upon source address and not on destination address as is the case with Unicast routing. It does this by utilizing either a dedicated multicast routing table or alternatively the router's native Unicast routing table. When a multicast packet enters a router's interface it looks up the list of networks that are reachable via that input interface. If the router finds a matching routing entry for the source IP of the multicast packet, the RPF check passes and the packet is forwarded to all other interfaces that are participating in multicast for this multicast group. If the RPF check fails the packet will be dropped. It is recommended that RPF-check should be enabled based on both Multicast & Unicast RIB.

VTN VN2 High Level Design

6.6

MPLS Topology and Signalling Overview.

6.6.1 Overview This section will describe the use of Multi-Protocol Label Switching (MPLS) for forwarding traffic within the VN2 IP Core network.
P P

ASBR

PE

Single Hop RSVP

RSVP Full Mesh Between P routers

PE
POP A

P
RSVP Signaled LSP

POP B

LDP over RSVP

Figure 10: VN2 MPLS Topology

6.6.2 Usage MPLS will be used in two fundamental ways in the VN2 network. The first is as the baseline forwarding scheme across the WAN portion of the network, providing traffic engineering and fault protection. And second tier of MPLS is used as a unified means of connectivity between edge routers, enabling end-user services like Layer3 VPNs, VPLS, and Pseudowires. Two sets of protocols, participants, and topologies will be used for each, as follows: Backbone MPLS: RSVP and LDP protocols Full mesh RSVP LSPs between P routers LDP will be enabled for full mesh topology to be dynamically created by default Statically configured dual mesh topology (A + B planes) Traffic Engineering (TE) capabilities Enhanced fault protection capabilities

VTN VN2 High Level Design

Edge MPLS: LDP and RSVP protocols Single hop RSVP LSPs between P router and PE or ASBR T-LDP sessions between PEs and ASBRs will be tunnelled over RSVP tunnels (LDPoverRSVP) LDP will be enabled for full mesh topology to be dynamically created by default Follows IGP to determine paths, dependent for re-convergence Graceful restart and Non stop routing enabled for LDP

6.6.3 Backbone MPLS The backbone MPLS scheme based on the Resource Reservation Protocol (RSVP) protocol provides a highly configurable framework for forwarding traffic across the core of the network. As RSVP LSPs must be explicitly configured at the origin for each sourcedestination pair, its use of full mesh is generally confined to the network core, in order to limit the size of the N squared full mesh of LSPs among participating PE routers. In the VN2 network, the full mesh RSVP LSPs will be limited to the P routers. 6.6.4 RSVP Signalled LSP Topology The following grids give a complete list of the unidirectional RSVP signaled LSPs to be configured among the P routers. Check marks indicate an LSP which corresponds to a direct physical link. Check-plus indicates an LSP with an intermediate hop. Plane A
From: To: P1 - HPY P1 - HNI P1 - DNG P1 - HCM P1 - CTO 9 9 9+ 9+ 9 9 9+ 9 9 9 9 9 9 9+ 9 9 9+ 9+ 9 9 P1 - HPY P1 - HNI P1 - DNG P1 - HCM P1 - CTO

VTN VN2 High Level Design

Plane B
From: To: P2 - HPY P2 - HNI P2 - DNG P2 - HCM P2 - CTO 9 9 9+ 9+ 9 9 9+ 9 9 9 9 9 9 9+ 9 9 9+ 9+ 9 9 P2 - HPY P2 - HNI P2 - DNG P2 - HCM P2 - CTO

Interlinks
From: P1 - HPY P1 - HNI P1 - DNG P1 - HCM P1 - CTO To: P2 - HPY P2 - HNI P2 - DNG P2 - HCM P2 - CTO

6.6.5 Traffic Engineering RSVP provides a number of features for fine grained control over the path selection for each LSP, collectively providing the Traffic Engineering (TE) capabilities. Those parameters include a subscribed bandwidth per LSP, admin groups (or colors) per link for inclusion or exclusion, a link metric scheme for TE, and the hop count. Also, RSVP paths can be explicitly defined on a per-hop basis, or allowed to follow the same IGP metric based path selection. As the traffic levels are expected to be low on the VN2 network on day one, but are otherwise unknown, it is proposed to use a course bandwidth allocation scheme, well below the actual available link bandwidth. This scheme may be used for future true bandwidth subscription based TE, or as a means to load share paths across future parallel links. Otherwise, the largely single-hop LSP topology, and the implied primary/backup paths given by the physical circuit topology, largely negate the need for other types of TE configuration. Only the LSP marked with a check-plus in the above grid have any intermediate hop which might be subject to a policy based path decision, and these would be expected to be among the lowest bandwidth consumption

VTN VN2 High Level Design

paths. As such, no other TE configuration is recommended, and the use of the IGP cost scheme to determine LSP paths should be sufficient. 6.6.6 Edge MPLS The edge MPLS scheme leverages the multiprotocol capabilities of MPLS to support converged service offerings. Single hop RSVP LSPs will be used to connect the PE and P routers. The RSVP full mesh is only within the P routers. Source PE routers will use LDP over RSVP tunnels to reach the destination PE routers. With properly placed redundant links between the PE routers, this provides MPLS FRR capability between PE and P routers without the need of a full mesh end to end RSVP tunnels between the PE routers. As a backup to RSVP, LDP can be used to build a full mesh of LSPs among the PE, ASBR and RR routers. LDP must be enabled on all of the following: Links from PE to P routers Links from ASBR to P routers Links from RR to P routers Links connecting two PE routers at the same POP Links connecting two P routers at the same POP Via tunnelling over all RSVP LSPs connecting to P routers

LDP uses the IGP to determine the path used, and also counts on the convergence of the IGP in the event of a failure. In the event of a failure on a PE/ASBR/RR to P router link the recovery of the LSP will be dependent on the IGP convergence around the failure.

6.7

High Availability

This section describes high availability features of the core VN2 topology. For VPN service high availability, please refer to Section 7.2 Service Architecture as the topic of offering VPN high availability is being discussed as an extension. 6.7.1 Border Router related Failure For VN2 ASBR sites with redundant ASBR, single ASBR failure would not constitute to any prolonged failure. Redundant ASBR router will be capable of performing all forwarding should the primary ASBR router fails. In the rare event of a critical failure in VDC or ASBR site, it will render traffic unreachable to and from a particular set of ASBR routers. At this point in time, VN2 BGP will converge and HSI traffic will be automatically re-routed to the next administratively nearer ASBR routers.

VTN VN2 High Level Design

This behaviour covers the following scenarios: 1. Failure of VDC connect BGP routes gets withdrawn on ASBR, the update is populated to both BGP route reflectors and subsequently to other PE routers and BRAS within VN2. PE and BRAS will reconsider other available routes in the Routing Information Base and installs the new route destination in the forwarding table for traffic to be re-routed. 2. Failure of ASBR routers it would be extremely rare for both redundant ASBR routers to fail at the same time, nevertheless, should this occurs, BGP neighbour association with BGP route reflectors would drop and all BGP routes previously learned from the affected ASBR routers will be withdrawn, this update is then populated to PE routers and BRAS within VN2. PE and BRAS will reconsider other available routes in the Routing Information Base and installs the new route destination in the forwarding table for traffic to be re-routed.

Figure 11: F ailure of ASBRs and/or VDC interconnect

In Figure 11, HPG PE routers re-converges upon BGP notification that the preferred traffic egress via HNI ASBR is to be changed to ASBR DNG due to a major failure on either VDC or the HNI ASBRs. 6.7.2 PE upstream related Failure In the event of failure on the upstream of the PE router, POP with single PE router and redundant uplinks will converge and uses the alternate path towards its destination as in the example illustrated by Fig 12 for CTO POP.

VTN VN2 High Level Design

Figu re 12: PE upstream related failure

As for POPs that has dual PE routers, such as the HPG POP illustrated, uplink redundancy will have to be handled via the MAN-E. This is a temporary workaround until inter-PE links are made available. 6.7.3 P router RSVP Label Switch Path Recovery Based on the physical topology of the VN2 network and the proposed dual mesh LSP topology, most RSVP LSPs will correspond to a direct circuit link between two routers, and all POP-to-POP circuit paths are deployed with two parallel physical circuits. As such, most recoverable LSP interruptions will be caused by link failure, and the desired response is for traffic to be shifted from the failed circuit to the parallel circuit.
Physical Links RSVP LSP and Primary Path RSVP LSP Recovery Path POP 1

Figure 13: RSVP LSPs and Recovery Path

LSP A, Pri. Path

LSP A, FRR Path

LSP B, Pri. Path POP 2

VTN VN2 High Level Design

This failure scenario lends itself well to link protection using Fast Reroute. The FRR path used would be via neighbouring P routers in the same POP, and over the parallel circuit, as in the following illustration. This would be expected to be the path of the re-established LSP as well.

6.8

Network QoS Design

6.8.1 QoS Overview The VN2 provides service differentiation using the Differentiated Service Model. It provides a high-level of flexibility to meet different operating environments, which can sometimes appear daunting and/or complex; indeed, there is a faint line between flexibility and complexity. Prior to detailing the recommended QoS configuration for the VN2 Network, this section provides a high-level overview of QoS and traffic management on the 7750 SR. This section is not intended to detail every aspect of traffic management within the 7750 SR, only the parts pertinent to the proposed QoS model. 6.8.1.1 Traffic Classification In order to achieve both scalability and service differentiation, the 7750 SR aggregates microflows in up to eight Forwarding Classes (FC). The behaviour of a FC in terms of ingress marking interpretation, egress marking, and queuing/scheduling is configurable in order to define a different Per-Hop Behaviour (PHB) per FC. By default the Forwarding Classes are classified into three class types; High priority, Assured, and Best Effort (BE). High-priority FCs are serviced before Assured FCs and are intended to be used for real-time delay-sensitive traffic or network control traffic. In turn, Assured FCs are serviced before Best Effort FCs and provide services with a committed rate (Committed Information Rate, or CIR) and peak rate (Peak Information Rate, or PIR). Assured FCs provide the ability to classify ingress traffic as either in-profile or out-ofprofile based upon the traffic arrival rate. A queue is considered in the in-profile state if the rate at which the queue is being serviced is less than its configured CIR. A queue is considered out- of-profile if the rate at which the queue is being serviced is greater than its CIR, but less than its PIR. After the profile state of the packet is determined at service ingress, the profile state of the packet influences the packets queuing priority and drop preference at all subsequent queuing points. It is worth noting that the in- profile/out-ofprofile classification based upon the rate that a queue is being serviced can only be performed on access ingress ports (not network ingress ports). When given some thought this makes sense because at network ingress ports traffic has already been policed (at access ingress).

VTN VN2 High Level Design

Table 5 details the eight Forwarding Classes within the 7750 SR SR together with the type of class and its intended use.
FC NC H1 EF H2 L1 AF L2 BE FC name Network Control High-1 Expedited High-2 Low-1 Assured Low-2 Best Effort Class Type Real Time Real Time Real Time Real Time Assured Assured Best Effort Best Effort Remarks Network Control traffic For a second Network Control traffic or delay/jitter sensitive data For delay/jitter sensitive data For delay/jitter sensitive data Assured traffic Assured traffic For BE traffic For BE traffic

Table 5: Forwarding Classes

In order to understand the 7750 SR QoS architecture, it is important to understand the concept of Forwarding Classes. As a standalone entity FCs do not provide any QoS capability such as classification, metering, marking or policing. FCs are a conduit and require an input (classified traffic) and an output (one or more queues).

FC

Figure 14: Forwarding Class Concept

6.8.1.2 Components of the DiffServ Model Within the 7750 SR DiffServ architecture, there are four constituent components that define the PHB afforded to traffic. These are the Access Ingress, Network Egress, Network Ingress, and the Access Egress.

Ser vice Acce ss Poi nt

Ser vice Acce ss Poi nt

Ser vice (Access) I ng r ess

N etwor k Eg ress

N etwor k I ng ress

Ser vice (Access) Eg r ess

Figure 15: DiffServ PHB Components

Access Ingress

Associated with a Service Access Point and responsible for classification of traffic into an FC based upon Layer-2 (i.e.

VTN VN2 High Level Design

MAC, 802.1p, Ethertype) Layer-3 (i.e. source/destination IP, protocol, DiffServ Codepoint/IP precedence) or Layer-4 (i.e. source/destination port) criteria. Ingress queues are subsequently associated with each FC and resource such as packet buffer; permissible traffic rates for in-profile/out-of- profile traffic, and scheduling priority (towards the fabric) are allocated to each queue. Network Egress Associated with a network interface and responsible for mapping each FC and profile (in/out) into an associated MPLS EXP value. Egress network queues are associated with each FC and again resource such as packet buffer and scheduling priority (towards the line) are allocated to each queue. Associated with a network interface and responsible for classification of traffic into FCs based on MPLS EXP or DSCP bits. Ingress network queues are associated with each FC and resource such as packet buffer and scheduling priority (towards the fabric/other network processors) are allocated to each queue. Associated with a Service Access Point for mapping traffic into egress queues based upon FC or DSCP. Resource such as packet buffer, permissible traffic rates, and scheduling priority (towards the line) are allocated to each queue. Remarking of Layer-2 802.1p bits can also be implemented at the Access Egress (recall that 802.1q bits are not carried over a pseudowire).

Network Ingress

Access Egress

6.8.1.3 Buffer Management Logical default buffer pools exist at the port and media dependent adapter (MDA) levels. Each physical port has three logically associated pools; an ingress access pool, and egress access pool, and an egress network pool. If the mode of a port is configured as access, only ingress access pool and egress access pool are created for the port. Conversely, if the mode of a port were configured as network, only the egress network pool would be created for the port. The size of the buffer pools is automatically determined as a function of the MDA type and the port configuration (i.e. mode and speed of the port).

VTN VN2 High Level Design

Each buffer pool has a reserved and a shared buffer portion. Each Forwarding Class queue with a non-zero CIR is allocated buffers drawn from the reserved portion of the buffer pool. After a queue consumes its reserved buffers, it competes with other queues in the pool for shared buffers drawn from the shared buffer portion of the pool.
M BS CBS

WRED

Shared Buffers

Res erved Res erved buffers buffers

Figure 16: Shared/Reserved Buffer

Reserved buffer is allocated to queues using the Committed Burst Size (CBS) parameter and shared buffer is allocated using the Maximum Burst Size (CBS) parameter. Optionally, Weighted Random Early Detection (WRED) can operate in the shared buffer to provide differing random drop thresholds for in-profile (high- slope) and out-of-profile (low-slope) traffic. The shared buffers are not reserved for any specific queues. Any queue within the buffer pool can use this space when its reserved buffers are full and it has not exceeded its MBS. The number of shared buffers within a buffer pool is the difference between the total number of buffers in the pool and the reserved buffers. 6.8.1.4 Queues Queues are created within buffer pools. For example, a 10 x 1-Gigabit Ethernet MDA has 250MB of buffer, which, when spread across the ports means that each Gigabit Ethernet interface has 25MB of available buffer. This 25MB can be allocated to a single queue (unlikely), or it can be allocated to a number of queues (a more likely scenario). Forwarding types have the intention of providing the capability to control processor intensive tasks such as packet replication at network ingress. A VPLS service supports four forwarding types; unicast, multicast, broadcast, and unknown- unicast. A VPRN will support two forwarding types; unicast and multicast. At service ingress, a queue can be allocated per-Forwarding Class, per-forwarding type. With eight possible FCs, it follows that a VPLS can support up to 32 queues, and a VPRN can support up to 16 queues. At service egress and network egress, there is no concept of forwarding type, hence each of the eight supported Forwarding Classes is allocated a single queue.

VTN VN2 High Level Design

A queue has two main buffer-related parameters; CBS and MBS, and two main scheduling parameters; CIR and PIR. CBS Specifies the number of buffers that can be drawn from the reserved buffer portion of the queues buffer pool. At service ingress and egress, the CBS is defined in Kbytes. At network ingress and egress, CBS is defined as a percentage of the buffer space of the queue buffer pool.

MBS Specifies the maximum queue size of a queue. For packets that enter a queue with a queue size between the CBS and MBS, buffers are drawn from the shared portion of the buffer pool, which may be managed by the WRED function. At service ingress and egress, the MBS for a queue is defined in Kbytes. The MBS for a network queue is defined as a percentage of buffer space of the queue buffer pool. Note that the minimum buffer size granularity is 4 Kbytes, and as partial buffer blocks cannot be allocated, the values allocated to CBS and MBS are automatically rounded up to a number of full buffer blocks. CIR The CIR for a queue performs two functions. The first function is Profile Marking. At service ingress it marks packets as in-profile or out-of-profile based on the CIR of the queue. For each packet that is transmitted from a service ingress queue, the CIR is checked against the current transmission rate of the queue. If the current rate is at or below the CIR threshold, the transmitted packet is internally marked as in-profile. If the current rate is above the threshold, the transmitted packet is internally marked as out-of- profile. The second function performed by the CIR value is Scheduler Queue Priority Metric. The scheduler that serves a group of ingress or egress queues prioritises individual queues based on their CIR and PIR states. Weighted queues that operate below their CIR are always serviced before queues that operate at or above their CIR. The CIR for service ingress and service egress queues is provisioned within a SAP-ingress and SAP-egress QoS policy respectively and is defined in Kb/s. The CIR for network queues is defined within the network QoS policy and is defined as a percentage of the network interface bandwidth. The PIR defines the maximum rate at which packets can be scheduled from a queue. The PIR does not specify the maximum rate at which packets can enter a queue as this is determined by the ability of the queue to absorb bursts and is defined by the MBS. The PIR for service ingress and service egress queues is provisioned within a SAP-ingress and SAP-egress QoS policy respectively and is defined in Kb/s. The PIR for network queues is defined within the network QoS policy and is defined as a percentage of the network interface bandwidth.

PIR

6.8.2 Scheduling The hardware scheduler for a queue determines how it will be scheduled relative to the other queues at the hardware level. When a queue is defined in a SAP-ingress or SAP-egress QoS policy, it is necessary to define the hardware scheduler

VTN VN2 High Level Design

(queue-type) to use for the queue when it is applied to a SAP. The definition of hardware schedulers (queue-types) can be expedited or best-effort. Scheduling ingress/egress scheduling, queues are serviced in the following order High-priority (expedited) queues operating within their CIR Low-priority (best effort) queues operating within their CIR All queues that operate within their PIR but above their CIR

CI R = PI R Q s

In-Profile RR

CI R = PI R Q s

O ut-Profile RR Exped ited Q ue ue s Strict Priority In-Profile RR O ut-Profile RR Best Effort Q ue ues Biased R R

CI R = PI R Q s

CI R = PI R Q s

Figure 17: Scheduling

In the first pass, all the queues that are associated with the high-priority queues and operate within their CIR are serviced in a round-robin manner. The servicing of a queue is stopped after it has transmitted packets up to its operational CIR. Hence, queues get out of first pass one after another and the first pass is repeated until the last queue gets out. In the second pass, all the queues that are associated with the low-priority queues and operate within their CIR are serviced in a round robin manner. The second pass is repeated until the last queue is serviced up to its CIR. In the third pass, all the queues in out-of-profile state (above CIR, but within PIR) are serviced in a biased round robin manner. It is biased round robin because the queues associated with high priority queues obtain at least 50% of third pass bandwidth if there is enough traffic in those queues. Similar to the first and second pass, third pass is repeated until the last queue is serviced up to its PIR. The third pass is basically round robin, however, every time it is interrupted by the two higher priority passes, it always resumes servicing with high priority queues; hence biased round robin.

VTN VN2 High Level Design

6.8.2.1 Virtual Hierarchical Scheduling Single-tier scheduling provides a scalable and flexible solution to share bandwidth. However, certain scenarios require a more flexible scheduling policy at the service ingress and/or service egress. In this instance, the 7750 SR provides Hierarchical Virtual Scheduling (commonly referred to as H-QoS) to provide another level of sophisticated scheduling. Consider the following scenario. The CIR and PIR of the three service ingress queues that correspond to Gold, Silver, and Bronze services are configured as follows Gold Silver Bronze CIR 10 Mb/s, PIR 10 Mb/s CIR 20 Mb/s, PIR 40 Mb/s CIR 0 Mb/s, PIR 100 Mb/s

Using single-tier scheduling, each queue can burst up to its specified PIR, which basically means that up to 150 Mb/s can enter the service through the three queues. Using virtual hierarchical scheduling, a parent scheduler can be created for the Gold, Silver, and Bronze queues, which limits the aggregate rate of all the queues to 100 Mb/s. With virtual hierarchical scheduling, the service can offer any combination of Gold, Silver, and Bronze traffic that conforms to their specified PIR values, but does not exceed 100 Mb/s in total. The 7750 SR hierarchical scheduler structure is very similar to t-ary tree data structure. In a virtual hierarchical scheduler structure, the buffer queues form the leaves of the structure. A parent (intermediate node or root node) is always a virtual scheduler. As in the case of t-ary tree, in a hierarchical scheduler policy a parent scheduler can have any number of children. A virtual scheduler can have queues and other virtual schedulers as its child. Each child scheduler or queue can have only one parent scheduler. The number of levels in a t-ary tree is called its height. In a hierarchical scheduler structure, the number of levels is defined in the context of tiers. The 7750 SR supports up to 3 tiers of virtual schedulers. The root schedulers are defined in Tier 1. Schedulers defined in Tier 2 can have parental associations with schedulers defined in Tier 1. Schedulers defined in Tier 3 can have parental associations with schedulers defined in Tiers 1 or 2. Queues can have parental associations with schedulers at any tier level. In a hierarchical scheduler policy, a virtual scheduler or a queue is provisioned with a CIR and a PIR that effectively dictate how much bandwidth is allocated to that queue/scheduler and the maximum rate at which it can be serviced. In addition, the queue/scheduler is configured with a CIR Level, CIR Weight, Level, and Weight. A parent scheduler distributes its allocated bandwidth to its children (where children can be queues or lower tier schedulers) in two passes. The first pass is

VTN VN2 High Level Design

within CIR pass and the second pass is above CIR pass. The first pass of bandwidth allocation to a child queue/scheduler ends after its servicing rate reaches its configured CIR value. The second pass of bandwidth allocation to a child ends after its servicing rate reaches its configured PIR parameter value. During the first pass, the allocation of bandwidth and the order that a child is serviced relative to other children is based on the childs CIR Level and CIR Weight parameters. During the second pass, the allocation of bandwidth and the order that a child is serviced relative to other children is based on the childs Level and Weight parameters. The range of both CIR Level and Level is 1 to 8. A higher level (8 is the highest priority) is exhaustively serviced before a lower level is serviced. Effectively, CIR Level and Level are used to define the strict priority queuing order. The range of the CIR Weight and Weight parameters is 0 to 100. In both passes, the (CIR) Weight parameter defines the weight of a child within the given (CIR) Level. When multiple children share the same (CIR) Level on a parent scheduler, the ratio of the bandwidth allocated to an individual child depends on the ratio of the weights of the active children within that Level. The ratio is calculated by adding the (CIR) Weights of all the active children, and dividing each childs CIR Weight by the sum. A child with a CIR Weight of zero receives bandwidth only after all the other children of the same Level have received their within-CIR bandwidth.

VTN VN2 High Level Design

Tie r 1
Queue s CI R L= 8
Scheduler C1

Tie r 2

Tie r 3

CI R L= 1 W= 20

CI R L= 1 W= 10 Wit hin CI R p a ss
Scheduler C2 Scheduler A1

Queue s PI R L= 8
Scheduler B1

PI R L= 3 W= 5 0
Scheduler C3

PI R L= 3 W= 2 5 Ab ove CI R p a ss

Figure 18: H-QoS Tiers and Scheduling

Error! Reference source not found.18 illustrates the concept of 3-tier hierarchical scheduling together with the order that a parent scheduler services its children. In Error! Reference source not found. the CIR Level and Weight (within CIR pass) and the Level and Weight (above CIR pass) are illustrated for the queues, however, it is worth re-iterating that the same methodology is applied to a child scheduler when being serviced by its parent scheduler. 6.8.3 QoS Design At the time of writing this document the services supported by the VN2 Network are HSI, Voice, Video & Business VPN. This section details the QoS recommendation to support the above listed services. 6.8.3.1 Service Classes A service class represents a set of traffic that requires common delay, loss and jitter characteristics from the network for which consistent and defined per-hop behaviour applies. Conceptually, a service class pertains to applications with similar characteristics and performance requirements. Table 6 details the service classes that shall be supported within the VN2 Network.

VTN VN2 High Level Design

Application Categories Control Plane Application Control Media-Oriented

Service Classes

Application Examples Network Routing Telephony Signalling IEEE1588v2 Precision Timing Protocol Telephony Bearer Broadcast TV, Video on Demand Business traffic and OAM (SNMP, SSH) Business Traffic HSI-Business/Residential

CONTROL Voice Voice Video Data 1 Data 2 Standard

Business Data

Best-Effort

Table 6: Service Classes

6.8.3.2 Control Service Class The CONTROL service class is used for inter-router signalling protocol traffic. Inter-router signalling protocols are responsible for maintaining the network logical topology and switching; these protocols are the most important protocols crossing the network; even more important than customer real-time traffic itself. If inter- router signalling protocols are affected, then this can affect all client traffic passing through a network node. Applications that may use the CONTROL service class are router control-plane traffic that is originated by the VN2 Network itself (i.e. OSPF, ISIS, RSVP), or router controlplane traffic that passes through at least one network node (Multi- Protocol BGP, Targeted LDP). All flows in the CONTROL service class shall use a Network Control (NC1) PHB and shall be marked with the DiffServ Codepoint Class Selector 48 and IP precendece 6. 6.8.3.3 Voice Service Class The Voice service class is used for applications that require very low delay, very low jitter and very low packet loss for relatively constant rate traffic sources. All traffic in this class originates from internal network controlled equipment. The following applications should use the Voice service class VoIP (G.711, G.729 and other codecs) Voice-band data over IP (modem, fax) T.38 fax over IP

VTN VN2 High Level Design

Circuit emulation Service, CESoPSN & SAToP IEEE1588v2 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Peer-to-peer IP telephony signaling (i.e. SIP, H.323) Peer-to-peer signalling for multimedia applications (i.e. SIP, H.323) Peer-to-peer real-time control function Client-server IP telephony signalling (i.e. H.248, MEGACO) Signalling flows between high-capacity telephony call servers or soft switches using protocol such as SIP-T. Such high-capacity devices may control thousands of telephony (VoIP) calls.

The Voice service class shall use an Expedited Forwarding (EF) PHB and the recommended DiffServ Codepoint is Expedited Forwarding (EF). This service class should be configured to receive guaranteed forwarding resources and all packets should be forwarded without being subject to delay since the inelastic types of RTP payloads in this class do not react to loss or significant delay in any substantive way. 6.8.3.4 Video Service Class The Broadcast Video service class is used for applications that require near-real- time packet forwarding with very low packet loss of constant rate and variable rate inelastic traffic sources. Such applications include broadcast TV, streaming of live audio and video events, some video-on-demand applications, and video surveillance. In general, the Broadcast Video service class assumes that the destination end point has a delay jitter buffer, for video application usually a 2 - 8 video-frame buffer (66 to several hundred of milliseconds), and therefore that it is less sensitive to delay and jitter. The following applications should use the Broadcast Video service class: Video surveillance and security (unicast). TV broadcast including HDTV (multicast). Video on demand (unicast) with control (virtual DVD). Streaming of live audio events (both unicast and multicast). Streaming of live video events (both unicast and multicast).

The Video service class shall use an Assured Forwarding (AF) PHB and shall be marked with the DiffServ Codepoint AF41 and IP predecence 4.

VTN VN2 High Level Design

6.8.3.5 Data 1 Service Class The Data 1 service class is used for applications that require a low packet loss and are relatively sensitive to delay. The service class is also responsible for carrying OAM (Operations, Administration, and Management) using protocols such as Simple Network Management Protocol (SNMP), FTP/SCP, and SSH. The following applications should use the Data 1 service class: Store and forward applications File transfer applications Email VPN service that supports two rates (committed information rate and excess or peak information rate) Provisioning and configuration of network elements Performance monitoring of network elements Any network operational alarms

All flows in the Data 1 service class shall use an Assured Forwarding (AF) PHB and shall be marked with the DiffServ Codepoint AF31 and IP Precedence 3. 6.8.3.6 Data 2 Service Class The Data 2 service class is used for elastic applications that require timely packet forwarding of variable rate traffic sources and, more specifically, is configured to provide good throughput for TCP longer-lived flows. TCP or a transport with a consistent congestion avoidance mechanism will normally drive as high a data rate as it can obtain over a long period of time. The following applications should use the High-Throughput Data service class: Store and forward applications File transfer applications Email VPN service that supports two rates (committed information rate and excess or peak information rate)

The High-Throughput Data service class should use an Assured Forwarding (AF) PHB and the recommended DiffServ Codepoint is AF32 and IP Precedence 2.

VTN VN2 High Level Design

6.8.3.7 Standard Service Class The Standard service class is used for traffic that has not been classified into one of the other supported forwarding service classes in the DiffServ network domain. This service class provides "best-effort" forwarding behavior and typically has minimum bandwidth guarantee. The following applications should use the Standard service class Network services, DNS, DHCP, BootP Any undifferentiated application/packet flow transported through the DiffServ enabled network.

The Standard service class shall use an Assured Forwarding PHB and the recommended DSCP marking is DF (Default Forwarding). 6.8.3.8 Classification Classification of traffic is achieved by the SAP ingress policy assigned at the edge of the network. Multi-field classification is the process of selecting packets based on the content of some arbitrary number of header fields; typically some combination of source/destination address, DiffServ Codepoint, protocol ID, source/destination port. Following multi-field classification and the relevant marking, subsequent classification is based purely on the contents of the DiffServ Codepoint or MPLS EXP bits and is referred to as Behaviour Aggregate (BA) classification. In turn BA classification is linked to a specific PHB group. Within the 7x50 this marking is achieved by mapping ingress traffic to the relevant Forwarding Class, and each Forwarding Class is uniquely identified throughout the remainder of the DiffServ Domain using specific MPLS EXP values. A SAP- ingress QoS policy is provided on the Service Access Point (SAP). Classification of traffic can be based on the physical interface, sub-interface (i.e. VLAN, VPI/VCI, DLCI) or based on any OSI Layer 2, Layer 3, or Layer 4 criteria as defined in Table 7. Note that for the purpose of brevity IPv4 and IPv6 are simply collapsed into IP criteria.
Layer MAC criteria Criteria Frame Type 802.1P Destination SAP Destination MAC Ethertype SNAP-OUI MAC/mask Remarks 802.3, 802.2 LLC, 802.2 SNAP, Ethernet II

VTN VN2 High Level Design

Layer

Criteria SNAP-PID Source MAC Protocol DSCP Destination IP address

Remarks

i.e. GRE, ICMP, IGMP, PIM, OSPF

IP Criteria

Destination port Fragment Source IP address Source port Criteria applies to IP fragments

Default-FC

All traffic received on SAP mapped to specified FC Table 7: Multi-field Classification Criteria

Although the potential exists to employ multi-field classification using the criteria defined in Table 7 at the SAP ingress, the potential also exists to take all traffic received over a particular SAP and map it to a definable FC using the Default-FC capability. For the purpose of simplicity, it is recommended that the Default-FC method of classification be utilised on a single logical/physical interface wherever possible, and that IP/MAC criteria is used only where multiple traffic types are carried over a single logical/physical interface. 6.8.3.9 Service Classes and Traffic Aggregates Once traffic has been classified, it requires marking in order that transit routers can infer the required PHB group. There is a distinct difference between the granularity of PHB on access (customer/client/subscriber) interfaces and the granularity of PHB on network interfaces. On network interfaces where there is a large number of aggregated customer flows the queuing and scheduling is less granular to reduce network complexity. In contrast, on customer/client/subscriber interfaces the potential exists to have much more granular queuing in order to obtain the required forwarding treatment for different traffic classes. In order to achieve this aggregation on network ports, service classes are aggregated into treatment aggregates within the network core. The proposed application to class of service is taken from Table 8: QoS Service Classes and involves mapping of two or more services classes into a single forwarding treatment aggregate.

VTN VN2 High Level Design

The degree of aggregation and hence the number of treatment aggregates depends on a number of factors; most notably these are the speed of the links and whether the scheduler implementing the aggregation can minimize the affects of mixing traffic with different packet sizes/transmit rates on queue depth. Generally however, higher speed links allow for more aggregation and a smaller number of treatment aggregates. This treatment aggregation of service class subsequently needs to be made identifiable within the core network through DiffServ codepoints and MPLS EXP markings as detailed in Table 8. Note that the STANDARD class (ELASTIC treatment aggregate) is assigned two MPLS EXP settings to differentiate in-profile traffic (Business HSI) from out-ofprofile traffic (Residential HSI) with Weighted RED configured to ensure that the latter is dropped before the former.
Application Control Protocol VoIP Voice application signalling Precision Time distribution Video Example RSVP, OSPF, ISIS, BGP Voice SIP, H.248, IGMP IEEE1588v2 Video on Demand, Broadcast TV SNMP, SSH Point-to-Point, Multipoint-toMultipoint service Point-to-Point, Multipoint-toMultipoint service Business HSI Internet Traffic Residential HSI Table 8: QoS Service Classes STANDARD Default ELASTIC Service Class CONTROL TELEPHONY SIGNALLING DiffServ Codepoint CS-6 EF EF Treatment Aggregate Network Control MPLS EXP EXP 6

REALTIMEVOICE

EXP 5

SIGNALLING BROADCAST VIDEO OAM HIGH THROUGHPUT DATA HIGH THROUGHPUT DATA

EF

AF41

REALTIMEVIDEO

EXP4

OAM

AF41

Data 1

AF31

CRITICAL

EXP 3

Data 2

AF32

ASSURED ELASTIC

EXP 2

Inprofile EXP 1 Out-ofprofile EXP 0

VTN VN2 High Level Design

Table 9 details the treatment aggregates, MPLS EXP markings together with the internal Forwarding Class and queue types that are proposed to support the service classes defined in Table 8.

Treatment Aggregate CONTROL REALTIME-VOICE

MPLS EXP

Forwarding Class Network Control Expedited H2 L1 AF

Class Type High Priority High Priority

WRED

EXP 6 EXP 5 EXP 4 EXP 3 EXP 2 EXP 1

No

No

REALTIME-VIDEO ASSURED ELASTIC ASSURED ELASTIC

Assured Assured

No No

Yes in-profile ELASTIC EXP 0 out-ofprofile Table 9: DiffServ QoS Marking BE Effort Yes Best

6.8.3.10 Network QoS Policy On network interfaces where the queuing and scheduling is less granular to reduce network complexity, treatment aggregation is applied to the large number of aggregated client flows. Given the service classes defined in Table 8 and the EXP/FC/Queue mappings defined in Table 9, Figure illustrates the network QoS policy, which can essentially be de-composed into four distinct categories The Ingress Network Policy that defines the EXP and DSCP mapping to the 7x50 internal Forwarding Classes. The Egress Network Policy defining the egress marking to be applied to traffic that has not already been marked (and is therefore applied by the ingress node only as transit traffic has already been marked)

VTN VN2 High Level Design

The Network Queue defines the queuing scheduling characteristics (bandwidth, buffer) for each FC. The Network Queue is applied to all egress network ports. For network ingress traffic a Virtual Output Queue (VOQ) exists on the IOM, which implies some form of buffering on the MDA. However, as over-subscribed MDAs (i.e. >10Gb/s) aggregate <10Gb/s of traffic each MDA has 10Gb/s access to the IOM/Switch Fabric and as such this is not considered a queuing point. This is an important concept as maximum queuing delays are calculated purely on egress port buffering and do not factor ingress MDA queuing/buffering. The WRED Slope Policy that defines when Weighted Random Early Detection is applied to the shared buffer space.
Network Policy (Ingress)
Control -----

Network Queue Policy


NC H1 In Out NC

Network Policy (Egress)


NC

Exp7 Exp6 Exp5 Exp4 Exp3 Exp2

In Out In Out In Out In Out In Out In Out

Q8 Q7 Switching Fabric Q6 Q5 Q4 Q3

Q8 Q7 Q6 Q5 Q4 Q3

In Out In Out In Out In Out In Out In Out

Exp7 Exp6 Exp5 Exp4 Exp3 Exp2

In H1 Out In Out In Out In Out In Out EF EF

H1

Voice

EF EF

EF

Video

H2 H2

H2 H2

H2

Silver

L1

L1

L1

Data 2

AF

AF

AF

-------Best Effort

Exp1 Exp0

L2 In In L2 Ou Out t In BE Out

BE In In BE Ou Out t In BE Out

Q2 Q1

L2 BE

Q2 Q1

In Out In Out

Exp1 Exp0

Figure 19: Network QoS Policy

The queue type and percentage CIR/PIR allocated to each of the network queues is defined in Table 10. CONTROL, REALTIME-VOICE and REALTIME-VIDEO are high-priority (expedited) queues and ASSURED-ELASTIC and ELASTIC queues are low-priority.

VTN VN2 High Level Design

Treatment Aggregate CONTROL REALTIME-VOICE REALTIME-VIDEO ASSURED ELASTIC ASSURED ELASTIC ELASTIC

Network Queue 8 6 5 4 3 1

Priority High High High Low Low Low

CIR 5% 20% 30% 15% 15% 0%

PIR 100% 20% 30% 30% 100% 100%

Table 10: Queue Type and CIR/PIR allocation

Given the parameters defined in Table 10 the following scheduling behaviour will be observed CONTROL, REALTIME-VOICE and REALTIME-VIDEO queues (queue 8, 6, and 5) are high-priority (expedited) queues and are serviced in a strict priority before the round-robin low-priority queues. o The REALTIME-VOICE queue has a CIR of 20% and a PIR of 20%. It is guaranteed 20% of line-rate and is constrained to 20% of linerate (PIR) as its traffic profile dictates. The REALTIME-VIDEO queue has a CIR of 30% and a PIR of 30%. It is guaranteed 30% of line-rate and is constrained to 30% of linerate (PIR) as its traffic profile dictates. The CONTROL queue has a CIR of 5% and is guaranteed 5% of linerate and has a PIR of 100% as we have no desire to constrain network control traffic.

The ASSURED ELASTIC queue (queue 4 and 3) and ELASTIC queue (queue 1) are round-robin (low-priority) queues and are serviced after the CONTROL, REALTIME-VOICE and REALTIME-VIDEO queues up to their respective CIR level. As the ELASTIC queue has 0% CIR, the ASSURED- ELASTIC class will always be serviced first. However, queues 3 can use up to 100% of the available bandwidth in the absence of other traffic.

For control plane (OSPF, RSVP etc) and OAM management traffic marking and queuing (SNMP, SSH, locally-generated ICMP etc) the control plane traffic uses Forwarding Class H1 and DiffServ codepoint CS-6 whilst management traffic uses Forwarding Class H2 and DiffServ codepoint AF41. To ensure that these protocols operate correctly, some resource (in terms of bandwidth/buffer space) is necessary

VTN VN2 High Level Design

and consideration has been given to this requirement for the queue allocations detailed in Table 10. 6.8.3.11 Buffer Management

6.8.3.11.1 Servicing Rate and Buffer Allocation The Committed Burst Size (CBS) defines the guaranteed/committed burst size whilst the Maximum Burst Size (MBS) defines maximum buffer allocation for a given queue. CBS can be considered guaranteed or committed simply because it is taken from reserved pools unlike MBS which is taken from shared pools. The amount of buffer allocated to any queue can be derived from the following formula

The rate at which allocated and configured buffer is emptied is based upon the servicing rate of the queue. For example, a 10 Gigabit Ethernet port has a total buffer pool allocation of ~250MB; hence with a servicing rate of 10,000,000,000 bits per second (equivalent to line-rate) it is possible to buffer for up to 200 milliseconds if the entire buffer space is allocated to a single queue. When multiple individual queues are serviced however, the servicing rate is slower hence the potential time spent in a buffer will increase. On network interfaces, the rate at which the queue is serviced (RATE, CIR) and the buffer allocated to that queue is defined as a percentage of the physical interface and expressed as a non-fractional integer. For example, a buffer allocation of 10% on a 10 Gigabit Ethernet interface would be 25Mbytes (250MB/100*10), which, with a serialisation rate of 10,000,000,000 would represent a maximum of 20 milliseconds of buffer. 6.8.3.11.2 Service-Class Buffer Allocation As defined in Table 10 network interfaces support five queues, and although no explicit delay characteristics have been requested of the network at the time of writing, it is reasonably clear that the traffic aggregates forming those queues have differing buffer allocation requirements. 1. Queue 8 is an expedited queue dedicated to CONTROL traffic with relatively low tolerance to delay and should be configured with a CBS and MBS of 20 milliseconds of the CIR/PIR respectively. 2. Queue 6 is an expedited queue servicing the REALTIME-VOICE treatment aggregate and predominantly contains IP/UDP/RTP traffic with very low tolerance to delay/jitter. As this traffic has no inherent congestion control mechanism it should not take resource from the shared buffer space (hence PIR=CIR) where WRED is configured and shall be configured with an equal CBS/MBS equal to 10 milliseconds.

VTN VN2 High Level Design

3.

Queue 5 is an expedited queue servicing the REALTIME-VIDEO treatment aggregate and predominantly contains IP/UDP/RTP or RTSP traffic. As with REALTIME-VOICE this traffic has no inherent congestion control mechanism so once again should not take resource from the shared buffer space (PIR=CIR) and shall be configured with an equal CBS/MBS of 10 milliseconds.

4. Queue 3 and 4 are weighted queue servicing the ASSURED-ELASTIC treatment aggregate and shall be configured with a CBS and MBS equal to 50 milliseconds of the CIR/PIR respectively. 5. Queue 1 is a weighted queue servicing the ELASTIC treatment aggregate. The service classes contained within this treatment aggregate (Business HSI, Residential HSI) have no stringent latency requirements and are of comparative low priority. In order to ensure that the ASSURED-ELASTIC treatment aggregate is serviced before the ELASTIC treatment aggregate, no CIR value is applied to ELASTIC and all traffic is queued in shared buffer. Therefore a nominal CBS value of 1 to allow a minimum buffer shall be configured with MBS configured for 100 milliseconds. Per-port buffer allocation varies on an MDA basis (number of ports) and the port configuration (i.e. network/access mode; speed), however, the requirement is that the maximum buffer delay is consistent on a network-wide basis in order to yield a deterministic maximum delay/jitter. 6.8.3.11.3 Weighted RED As the ELASTIC treatment aggregate will carry in-profile (Business HSI) and out- ofprofile (Residential HSI) traffic, Weighted Random Early Detection (WRED) will be used to ensure that in the advent of congestion out-of-profile traffic is discarded before in-profile traffic. The ELASTIC treatment aggregate is serviced by queue 1, and there are two separate WRED profiles that can be applied to the shared buffer space of this queue; the low slope, which operates on out-of-profile traffic, and the high slope, which operates on in-profile traffic. Weighted Random Early Detection shall be used within the shared buffer space to ensure that in the advent of congestion low priority traffic (Residential HSI) is discarded before higher priority traffic also consuming shared buffer (Business HSI). WRED monitors the queue depth of a given port and randomly drops traffic with increasing probability as the average queue depth increases. Congestion- aware protocols such as TCP detect congestion after experiencing packet loss; reduce the transmission rate (typically by half), and subsequently implement a slow-start algorithm to detect a sustainable throughput. Using WRED to control the average buffer occupancy allows network queues to reach a more stable utilisation level and generally increases throughput for TCP traffic. The 7x50 has two separate WRED profiles that are applied to the shared buffer space; the low slope operates on out-of-contract/out-of-profile traffic whilst the high slope operates on in-contract/in-profile traffic. Figure shows a typical WRED slope

VTN VN2 High Level Design

plotted in an x-y graph; the x-axis is the percentage of shared buffer average utilisation; the y-axis is the probability of packet discard.

Drop Probability

max-avg

start-avg

Buffer Depth

Figure 20: WRED Parameters

The WRED slopes are specified using the start-avg, max-avg, and max-prob parameters in the associated buffer policy. From zero buffer depth to start-avg the packet discard probability is zero. Between start-avg and max-avg, the packet discard probability is proportional to the average buffer utilisation and ranges from zero to the max-prob. At the max-avg threshold the packet probability instantaneously increases from max-prob to 1. Packets received above max-age have a drop probability of 1 and are immediately discarded. WRED will predominantly operate in queue 1 which is intended to aggregate Residential/Business HSI. Business HSI is set to in-profile and Residential HSI is set to outof-profile; however, the objective of WRED in this queue is not to discard traffic too early (by configuring the WRED parameters aggressively) but to increase throughput in general by maximising the available buffer space and then randomly dropping such that Business HSI has preferable treatment over Residential HSI. Table 11 therefore details the WRED parameters that shall be applied to all network ports regardless of media-type.
Slope Low High Start-Avg 50% 70% Max-Avg 75% 90% Table 11: WRED Parameters Max-Prob 80% 80%

max-prob

VTN VN2 High Level Design

6.8.4 QoS on Juniper router 6.8.4.1 Overview Classification of customer takes place primarily at the PE/ASBR, which is the entry point to the DiffServ domain. The PE/ASBR will tag traffic as belonging to one of a set of predetermined Service Classes, and handle traffic on outbound interfaces accordingly. P routers will receive MPLS encapsulated traffic with the Service Class marked in the EXP bit, and must provide equivalent handling. 6.8.4.2 Juniper Queue and Scheduler Design The (6) Service Classes will correspond to a six queue configuration on the P routers:
MPLS EXP EXP 6 3 Juniper Queue %15 TX Rate %15 Drop Buffer Priority Profile Strict High [90 100] [0 100] (Default) (Default) (Default) (Default) (Default)

EXP 5 EXP 4 EXP 3 EXP 2 EXP 1 / 0

6 5 4 2 0

%20 %30 %15 %15 (balance)

%20 %30 %15 %15 %5

Med-High Med-High Med-High Med-High Low

6.8.4.3 Juniper Traffic Classification P routers will employ input classifiers to map traffic with MPLS EXP and IP Precedence markings into forwarding classes, for handling as per the above parameters. IP Precedence is used to properly handle any traffic not encapsulated in MPLS, including network control and management traffic, and IP Multicast traffic.

6.9

Network Security Recommendation

In designing the VN2 network, it is important to ensure that the infrastructure can be secured to a level acceptable (cost justified) to protect against risk and threats associated with the network itself from both internal and external interfaces. Techniques are available to monitor the overall security posture of the core network and verify its integrity, and it is important to take advantage of these techniques wherever possible. It is important to note that, the recommendations made here are specific to advance security features available for use within the supplied equipment that can be used to implement VNPT/VTNs existing security policy requirements for

VTN VN2 High Level Design

Network related security practices. It does not constitute to a new security policy or does it make any attempt to update VNPT/VTNs security policy. At a high level a secure network implies the following 1. The network continues to forward legitimate customer traffic (availability). 2. Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality). 3. The network elements remain manageable (availability). Only authorized users can manage network elements (authorization) 4. There is a record of all security related events (accountability). 5. The network operator has the necessary tools to detect and respond to illegitimate traffic. 6.9.1 Generic Node Access 6.9.1.1 Node Access and User Security It is essential that only authorised personnel are able to access the core network infrastructure CLI and the related NMS systems. The following shall be adhered to when providing management access to P and PE nodes of the IP/MPLS backbone. a) Access to all devices, including those comprising DMZ infrastructure shall be strictly controlled and an audit trail established. b) Initial access to the DMZ infrastructure shall employ two-factor authentication (i.e. need to know something and need to physically possess something) c) Strong node passwords for the following shall be generated using a method of computer generated random password an be a minimum of 12 characters in length SNMP communities OSPF passwords BGP passwords

d) Individual user accounts (role-based) shall be provided to users of the NMS, to ensure accountability can be tracked. e) All access to the core network from internal networks shall be encrypted to reduce the possibility of username/password sniffing. An example of such a protocol is SSH.

VTN VN2 High Level Design

f) Remote access to the network infrastructure and the NMS made available to local staff and third parties shall be through the remote authorized remote access mechanism. g) Remote access to the NMS infrastructure unencrypted across any public network. shall not be permitted

6.9.1.2 Access to Command Line Interface (CLI) Access to nodal Command Line Interface (CLI) shall be constrained as follows a. Core network infrastructure shall limit access to the CLI from a restricted range of IP addresses. Once logged onto a node it shall not be possible to connect to another node. If the regular access path is not operational then out-of-band management channels shall alternatively be used for each node logon. b. Access to the core network from external networks shall be via the core network NMS DMZ.

6.9.2 Authentication, Authorization, and Accounting (AAA) Network security is based on a multi-step process. The first step, authentication, validates a users name and password. The second step is authorization, which allows the user to access and execute commands at various command levels based on profiles assigned to the user. The third step, accounting, keeps track of the activity of a user who has accessed the network. The type of accounting information recorded can include a history of the commands executed, the amount of time spent in the session, the services accessed, and the data transfer size during the session. 6.9.2.1 Authentication For the purpose of Authentication the 7750 SR can support Remote Authentication Dial In User Service (RADIUS), or Terminal Access Controller Access Control System Plus (TACACS+). TACACS+ is arguably superior to RADIUS because TACACS+ separates the functions of Authentication and Authorization (RADIUS combines them). In addition TACACS+ uses TCP as a transport protocol and is therefore considered more reliable than RADIUS, which uses UDP as a transport protocol. Users accessing the core network infrastructure and the NMS shall be authenticated against a resilient pair of trusted AAA servers. It is recommended that the AAA servers be dedicated solely for the purpose of providing AAA services for operators of the core network. 6.9.2.2 Authorization The 7750 SR supports local, RADIUS, and TACACS+ authorization to control the actions of specific users by applying a profile based on user name and password configurations once authentication is successfully completed. The profiles can be configured locally or passed through RADIUS Vendor Specific Attributes (VSAs).

VTN VN2 High Level Design

Profiles consist of a suite of commands that the user is allowed or not allowed to execute. When a user issues a command, the authorization server looks at the command and the user information and compares it with the commands in the profile. If the user is authorized to issue the command, the command is executed. If the user is not authorized to issue the command, then the command is not executed. Profiles are used to deny or permit access to a hierarchical branch or specific commands. Profiles are referenced in a user configuration. A maximum of sixteen user profiles can be defined. A user can participate in up to sixteen profiles. Depending on the authorization requirements, profiles are configured locally or on a RADIUS server. Table 12 details the supported authorization configurations given the various supported authentication mechanisms.
Authentication Mechanism 7750 SR configured user RADIUS server configured user TACACS+ server configured user 7750 SR Supplied Profile Supported Supported Supported RADIUS Supplied Profile Not Supported Supported Not Supported

Table 12: Supported Authorization Configurations

6.9.2.3 Role-Based Access Using the profile capability, Table 13 details the roles that shall be applied to user accounts in accordance with their role and function.
Role User type Operations manager and technical leads Network operational security engineers Implementation and operation engineers Implementation and operation engineers Number of users Functional access Hierarchical access Has access to his/her role plus all other roles Has access to only his/her role

Super user

Minimal

All functions

Security control

Controlled

Security based packet filters (not route based packet filters) AAA and account management functions Core configuration (MPLS routing protocols, TE, QoS, interfaces, route based packet filters) Perform diagnostic functions and read all configuration on all nodes

Implementatio n and Ops add/moves /changes Diagnostics and read-only

Controlled

Has access to his/her role plus diagnostics Has only access to his role only

Controlled

Table 13: Role-based Access

VTN VN2 High Level Design

6.9.2.4 Accounting The 7750 SR supports accounting records for both RADIUS and TACACS+. When RADIUS accounting is enabled, the server is responsible for receiving accounting requests and returning a response to the client indicating that it has successfully received the request. Each command issued on the 7750 SR generates a record sent to the RADIUS server. The record identifies the user that issued the command and the timestamp. When TACACS+ accounting is enabled, the 7750 SR allows for configuration of the type of accounting record packet that is to be sent to the TACACS+ server when specified events occur on the device. This can be start/stop packets or just stop packets. When a user enters a command for which accounting parameters are configured, or a system event occurs such as a reboot or a configuration file reload, the 7750 SR checks the configuration to see if TACACS+ accounting is required for the specified event. If TACACS+ accounting is required, then, depending on the accounting record type specified, the 7750 SR sends a start packet to the TACACS+ server after which the TACACS+ server will record information about the event. It is this audit trail capability that also makes TACACS+ popular. 6.9.3 User Accounts and Passwords The following guidelines shall be adhered to with regard to the creation and maintenance of user accounts and passwords a. All personnel accessing the core network infrastructure shall have and use their own account. b. Unless there are network/infrastructure failures that require staff to have to use locally defined passwords, staff shall only use their personal account for accessing the network infrastructure. c. Each NMS application accessing the network infrastructure shall have its own individual account (i.e. NMS account). d. Role-based access shall be employed to manage the nodes. e. In the event of a failure of the network infrastructure to contact the AAA system, an account locally defined in the network elements shall be used. f. All accounts shall be created with passwords. g. All accounts shall be authenticated against the AAA system. h. To prevent interception, passwords shall be encrypted in transit between the node and the AAA server. Also the limited set of locally defined passwords shall be encrypted using the strong encryption such as the MD5 hash algorithm.

VTN VN2 High Level Design

i. All accounts shall be assigned the lowest privilege level required j. The operations team shall establish and maintain a standard operating procedure for account management i. Account request, authorization, secure storage, modification, deletion ii. Account/password expiration iii. Account/password compromise iv. Account/password membership distribution including determination of

k. The operations team shall establish and maintain a standard operating procedure for SNMP community string management i. SNMP community string request, storage, modification, deletion ii. SNMP community string expiration iii. SNMP community string compromise iv. SNMP community string distribution including determination of membership 6.9.4 Packet Filtering Toolset The 7750 SR series provide an extensive security toolset in order to address the security requirements. This section defines the application and operation of these tools. 6.9.4.1 Filter Policies Filter policies, also referred to as Access Control Lists (ACLs) are templates applied to services or network ports to control traffic into (ingress) or out of (egress) a Service Access Port (SAP) or Network port based on IP and/or MAC matching criteria. Filters are applied to services to look at packets entering or leaving a SAP or network interface. Filters can be used on several interfaces. The same filter can be applied to ingress traffic, egress traffic, or both. Ingress filters affect only inbound traffic destined for the routing complex, whilst egress filters affect only outbound traffic sent from the routing complex. 6.9.4.2 Filter Policy Entities A filter policy compares the match criteria specified within a filter entry to packets transiting the system in the order that the entries are numbered in the policy. When a packet matches all of the parameters specified in the entry, the system takes the specified action to either drop or forward the packet. If a packet does not match the entry parameters, the packet continues through the filter process and is authorization, secure

VTN VN2 High Level Design

compared to the next filter entry (and so on). If the packet does not match any of the entries, then the packet is subject to the default action specified in the filter policy. Each filter policy is made up of the following 1. Scope (Exclusive policies can be applied to a single SAP/Network port whereas a template policy can be applied to multiple SAPs/Network ports). 2. Default Action (Action to be taken when packets do not match the specified criteria in any of the IP filter entries of the filter). 3. Description 4. At least one filter entry And each filter entry contains 1. Match Criteria 2. An action Filter policies can be associated with the entities defined in Table 14
IP Filter Epipe SAP, spoke SDP Fpipe SAP, spoke SDP IES interface SAP Ipipe SAP, spoke SDP VPLS mesh SDP, spoke SDP, SAP VPRN interface SAP, spoke SDP MAC Filter Epipe SAP, spoke SDP N/A N/A N/A VPLS mesh SDP, spoke SDP, SAP N/A

Table 14: Applying Filter Policies

6.9.4.3 Packet Matching Criteria IP and MAC filter policies specify either a forward or a drop action for packets based on information specified in the match criteria. The 7750 SR supports up to 2000 IP and 2000 MAC filter policies per node, and up to 65535 entries within each filter. Filter entry matching criteria can be as general or specific as required, but all conditions in the entry must be met in order for the packet to be considered a match and the specified entry action performed. The process stops when the first complete match is found and executes the corresponding action specified in the entry; either to drop or forward packets that matches the criteria. IP filter matching criteria includes the following IPv4/IPv6 source IP address/mask.

VTN VN2 High Level Design

Ipv4/Ipv6 destination IP address/mask Protocol Source port/range Destination port/range DiffServ Codepoint ICMP code ICMP type Fragmentation (match occurs if packets have More Fragment (MF) bit set or have a non-zero field in the Fragmentation Offset field. IP options TCP SYN TCP ACK

MAC filter matching criteria includes the following Source MAC address and mask Destination MAC address and mask 802.1p value and mask Ethertype IEEE 802.2 LLC source SAP IEEE 802.2 LLC destination SAP IEEE 802.3 LLC SNAP Protocol ID IEEE 802.3 LLC SNAP Ethernet Frame OUI

6.9.4.4 Event Logging Event logging controls the generation dissemination and recording of system events for monitoring status and troubleshooting faults. Event Logs are the means of recording locally generated system events for real-time of subsequent analysis. The 7750 SR groups events into one of four main categories (or event sources) 1. Security. Events that pertain to attempts to breach system security such as failed login attempts, attempts to access MIB tables to which the user is not granted access, or attempts to enter a branch of the CLI to which access has not been granted.

VTN VN2 High Level Design

2. Change. Events that pertain to the configuration or operation of the node 3. Main. Events that pertain to OS applications that are not assigned to other event categories/sources. Examples of applications within the 7750 SR series include IP, MPLS, ISIS, System, and Security. The command show log applications displays all applications within the context of logging and the following output provides an output of this command.
A:router# show log applications ================================== Log Event Application Names ================================== Application Name ---------------------------------APS ATM BGP CCAG CFLOWD CHASSIS CPMHWFILTER DHCP DEBUG DOT1X FILTER IGMP IGMP_SNOOPING IP ISIS LAG LDP LOGGER MIRROR MPLS NTP OAM OSPF PIM PORT PPP QOS RIP ROUTE_POLICY RSVP SECURITY SNMP STP SUBSCR_MGMT SVCMGR SYSTEM TIP USER VRRP VRTR ==================================

VTN VN2 High Level Design

A number of events are associated with each application. For example, the following output illustrates the events that are associated with the Security application.
A:PPESBAR01# show log event-control security ===================================================================== Log Events ===================================================================== Application ID# Event Name P g/s Logged Dropped --------------------------------------------------------------------L 2001 cli_user_login MI gen 0 L 2002 cli_user_logout MI gen 0 L 2003 cli_user_login_failed MI gen 0 L 2004 cli_user_login_max_attempts MI gen 0 L 2005 ftp_user_login MI gen 0 L 2006 ftp_user_logout MI gen 0 L 2007 ftp_user_login_failed MI gen 0 L 2008 ftp_user_login_max_attempts MI gen 0 L 2009 ssh_user_login MI gen 5 L 2010 ssh_user_logout MI gen 4 L 2011 ssh_user_login_failed MI gen 0 L 2012 ssh_user_login_max_attempts MI gen 0 2013 radiusServerOperStatusChange MI gen 0 2014 radiusOperStatusChange MI gen 0 L 2015 user_disconnect MA gen 0 L 2016 radiusSystemIpAddrNotSet MA gen 0 2017 tacplusServerOperStatusChange MI gen 1 2018 tacplusOperStatusChange MI gen 2 L 2019 mafEntryMatch MA gen 0 L 2020 ftp_transfer_successful MI gen 0 L 2021 ftp_transfer_failed MI gen 0 L 2022 enable_admin WA gen 0 L 2023 host_snmp_attempts WA gen 0 2024 SSH_server_preserve_key_fail MI gen 0 =======================================================================

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

6.9.4.5 Event Control Event control assigns the severity for each application event and whether the event should be suppressed or generated. The severity numbers supported in the 7750 SR confirm to the ITU standards M.3100 X.733 and X.21 and are detailed in Table 15.

Severity Number 1 2 3 4 5 6

Severity Name Cleared Indeterminate (info) Critical Major Minor Warning Table 15: Event Severity Levels

VTN VN2 High Level Design

The following figure illustrates a function block diagram of Event Logging and is followed by some description of each element within the event logging process.

Figure 21: Event logging block diagram

Once an event has been generated, it is passed through Event Control that may pre-process events before passing them to the main event stream. Event Control processes events before they are passed into the main event stream and provides the capability to forward or suppress events from particular applications. Suppressed events will not generate log entries (as the event never reaches the log manager), however, they are recorded within Event Control. Events that are forwarded by Event Control are sent to the Log Manager. The Log Manager is responsible for managing the event logs within the system. Each event log consists of a unique log ID (a numeric identifier), one or more log sources (main, security, change, debug), and a single destination. The destination can be console, session, SNMP Trap Group, memory, or a local file. Finally, each log ID can be assigned an optional event filter policy which again determines whether to forward or drop an event based on defined match criteria. Each generated event has the following characteristics a. A time stamp (in UTC) b. The generating application c. A unique event ID within the application d. A subject identifying the affected object e. A short text description

VTN VN2 High Level Design

6.9.4.6 Log Destinations Only a single log destination can be associated with an event log. An event log can be associated with multiple event sources, but it can only have a single log destination. Table 16 details the log destinations supported by the 7750 SR.
Log Destination Console Session Description Messages sent to all active console sessions. If there are no active console sessions, the event log entries are dropped. A temporary log destination that directs entries to the active console session for the duration of the console session. When the session is terminated, the event log is removed. A memory log is a circular buffer. When the log is full, the oldest entry in the log is replaced with the new entry. When a memory log is created, the specific number of entries it can hold can be specified Log files are stored on the compact flash devices in the file system. A log file is identified with a single log file ID (value 1-99). A log file is configured with a roll-over parameter expressed in minutes that represents the length of time an individual log file should be written to before a new file is created for the relevant log file ID. The rollover time is checked only when an update to the log is being performed. A log file is also configured with a retention time that specifies the amount of time the file should be retained on the file system based on the creation date and time of the file. The retention time is used as a factor to determine which files should be deleted first if the file system nears 100% utlisation. An event log can be configured to send events to SNMP trap receivers by specifying an SNMP trap group destination. An SNMP trap group can have multiple trap-receivers with different trap destinations. Each trap receiver can have different operational parameters such as SNMP version (v1, v2c, or v3), community, or port used to send the trap. An event log can be configured to send events to one Syslog destination. Table 16: Event Log Destinations

Memory Log

Log file

SNMP Trap Group

Syslog

6.9.4.7 CPM Filters The 7750 SR series have embedded traffic management and queuing hardware on the Control Processor Module (CPM) dedicated to protecting the control plane. CPM filters can be created on this hardware. These filters can be used to drop or accept packets, as well as allocate dedicated hardware shaping queues for traffic directed to the control processors. This feature essentially provides dedicated hardware protection for their control planes. It is possible to allocate dedicated CPM hardware queues for certain traffic designated to the CPUs and also set corresponding rate-limits for those queues. The following CPM traffic management features are supported and are recommended for use

VTN VN2 High Level Design

Traffic classification using CPM filters Packets going to the CPM are first classified by the IOM into forwarding classes (FCs) before the CPM hardware sees them. CPM filters can be used to further classify the packets using conventional IP filtering criteria.

Queue allocation Up to 2000 queues are available for allocation to CPM filters. Queue parameters such as PIR, CIR, CBS, and MBS are provisioned on a per- queue basis.

6.9.5 Securing Nodes 6.9.5.1 Control Plane Authentication Authentication of control plane protocols is relatively easy to implement and can serve to protect against numerous security advisories. At a minimum, the following authentication mechanisms shall be implemented within the network: a) Use of the TCP MD5 signature option for cryptographic authentication of both interior and exterior BGP sessions in accordance with RFC2385. The TCP MD5 signature option (RFC2385) defines a TCP option for carrying an MD5 digest in a TCP segment, acting like a signature for that segment. As BGP uses TCP as its transport, it is inherently secure if this mechanism is adopted. Keys for interior BGP sessions (used internally within the network) should be different to those used for external peering. b) HMAC-MD5 cryptographic authentication of IS-IS Hello PDUs and LSP authentication in accordance with RFC3567 and ISO 10589. c) MD5 or SHA-1 cryptographic authentication of RSVP messages using the INTEGRITY object in accordance with RFC2747 (target 7750 SR Release 5.0). d) Use of the TCP MD5 signature option for cryptographic authentication of both Basic Discovery and Extended Discovery LDP sessions. Like BGP, LDP uses TCP as its transport. Hence adoption of the TCP MD5 signature option for LDP in accordance with RFC3036 will provide authenticity.

6.9.5.2 Password/Key Encryption Whilst general user access shall be facilitated through the use of AAA servers, other passwords/keys will be maintained locally on network elements, which may include authentication key passwords for BGP or IS-IS, or last-resort passwords. It is therefore desirable that these passwords/keys are locally maintained in a manner that makes them imperceptible to the human eye (i.e. they are encrypted using a complex key available on the 7750 SR) in order that they are not made available to casual observers.

VTN VN2 High Level Design

6.9.5.3 Last-Resort/Back-door Username/Password In the event that AAA authentication is not available, a locally maintained username/password shall be configured on all network elements facilitating a secondary method of accessing the device. This username/password and/or accompanying username/passwords shall enable a user to enter into an administrator-type privilege level, and shall be a username/password other than any contained in the default configuration. This locally maintained username/password shall be changed with regular periodicity. 6.9.5.4 Virtual Terminal Access Virtual Terminal Access is a generic name given to the logical termination within a network element of an interactive session such as SSH or Telnet. Logging onto network elements using Virtual Terminal Access for support of these interactive sessions will have the following constraints applied; a. Virtual Access Ports shall be constrained to SSHv2 access only; Telnet and other access mechanisms shall be disabled. b. Access to Virtual Access Ports shall be constrained through the use of Ingress IP filters to only those subnets that have legitimate access requirements using hardware-based CPM filters. c. Virtual Access Ports will be configured with a TCP keepalive mechanism of 15 minutes to protect against malicious attacks and/or orphaned sessions. 6.9.5.5 Secure Copy (SCP) Secure Copy (SCP) is similar to the Remote Copy (RCP) protocol; however, unlike RCP data is encrypted during transfer to avoid potential attackers from extracting usable information from data packets. Integrity and confidentiality is not provided through the SCP protocol itself, but by SSH. For security reasons the use of SCP is recommended for file transfers. 6.9.5.6 Console and Management Ports In addition to securing virtual terminal access, it is equally important to secure access to the local console and/or Management ports. To this effect, AAA authentication shall also be applied to these ports. 6.9.5.7 Directed Broadcasts Directed Broadcasts cause an undesirable amount of traffic and may be used in denial of service attacks. VPRN interfaces shall be configured to drop directed broadcasts.

VTN VN2 High Level Design

6.9.5.8 Source-routing IPv4 datagrams support strict/loose source-routing options. This allows the originator of an IP datagram to dictate the path that the datagram will take towards its destination. Source routed packets typically bypass the forwarding table and can be used to route malicious packets to their ultimate destination. They are also forwarded in software and can therefore consume resources on the Control Processor Module (CPM). IP source-routing shall therefore be disabled. 6.9.5.9 ICMP Rate-Limiting The amount of time that the CPM of any network element spends responding to ICMP echo requests and generating ICMP messages such as unreachables or TTL-expired shall be constrained by rate-limiting ICMP. This rate-limiting shall be implemented in hardware (the only option on the 7750 SR series). 6.9.5.10 ICMP Redirect Messages Routers generate ICMP redirect messages when it is identified that a host or another router is using a sub-optimal route. The source host or router will thereafter amend its routing table. Redirect messages are limited to interactions between a router and a host/router on a directly connected subnet; however, potential attackers may violate these rules. ICMP redirect messages shall therefore be filtered out on VPRN PE-CE links. 6.9.5.11 Warning Banner All network devices should be configured with a warning banner upon access to the node. The warning banner shall contain the following information a. Warn unauthorized users that unless they are authorized they should not proceed. b. Be common across all core network nodes. 6.9.6 Securing Client Services 6.9.6.1 BGP/MPLS IP-VPN Security Maintaining security and isolation between numerous Layer 3 IP-VPNs supported on a common network infrastructure requires adherence to the multiplexing technology that is used to implement them. The purpose of this section is to detail the generic security mechanisms defined in RFC4364 and how they will be implemented.

VTN VN2 High Level Design

6.9.6.2 VPN address separation A key element in the use of any VPN is the ability of subscribers to use and maintain their own address space. This may be registered address space, or more frequently, private address space as defined in RFC1918. BGP Multi-protocol Extensions allow BGP to carry routes from multiple address families. In BGP/MPLS-VPNs, the address family used is the VPN-IPv4 address family. A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address prefix. PE routers learn IPv4 address prefixes from CE routers and translate these into unique VPNIPv4 address prefixes before advertising them to other PE routers through Multi- Protocol iBGP. The Route-Distinguisher ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN. It is important to understand however that the Route-Distinguisher does not influence how VRF route tables are populated; its purpose is purely to allow common IPv4 address prefixes to be made unique. The Route-Distinguisher is an 8-byte field, comprising of a 2-byte type field, and a 6-byte value field. The IP-VPN QoS uses the type 0x00. The value field consists of two sub-fields Global Administrator sub-field: 2 octets This sub-field contains an Autonomous System number assigned by IANA. This value will be a registered Autonomous System owned by the OpCo. Local Administrator sub-field: 4 octets The organisation identified by Autonomous System number in the Global Administrator sub-field, can encode any information in this sub-field. Decimal integers are assigned to the VRF of a particular customer. 6.9.6.3 VPN Address Propagation The mechanism that is used to control the distribution of VPN routes between PE routers is achieved through the use of the BGP Extended Community Route- Target. When a route learned from a CE is injected into Multi-Protocol iBGP, it is associated with a Route-Target Extended Community through use of an export list. When a remote PE router receives the Multi-Protocol-iBGP update, it checks the BGP Extended Community Route Target value. If the PE router has an import statement matching the Route Target value, it accepts the update. If the PE router does not have an import statement matching the Route Target value, it discards the update. This functionality improves the scalability of PE routers by ensuring that routes are held only for VPNs that are directly connected to that PE router. The BGP Extended Community Route-Target value follows the same format as the Route-Distinguisher previously described.

VTN VN2 High Level Design

6.9.6.4 PE to CE Dynamic Routing Protocols For the purpose of resilience and reduction of manual configuration, it is highly desirable to run a dynamic routing protocol for route advertisement between CE and PE routers. To meet this requirement, BGP is the preferred dynamic routing protocol, however, the PE router is potentially open to Denial-of-Service attacks through injection of a large number of BGP prefixes from the CE router consuming both memory and CPU cycles. This is controlled using the following: Service separation between core and CE BGP instances such that a customer BGP process can never impact the core BGP process. In addition, customer BGP instances are serviced in a round-robin manner such that a runaway BGP peer can never consume all CPU cycles. Imposing a limit on the number of BGP prefixes that will be imported into a given VRF.

6.9.7 Juniper network management and security 6.9.7.1 Overview Both the security of network devices and their proper management are key elements in the availability and performance of the network as a whole. This section will describe the JunOS features recommended to protect routers from unauthorized access, to protect the protocols from either unintentional or malicious interference, and enable management of the devices in order to maintain their proper function, and also to get visibility for into the operating parameters of the network as a whole. 6.9.7.2 Protocol Security Many of the network control and device management protocols require routers to accept traffic destined to the router itself. Each of the following protocols which will require the router to accept inbound traffic should make use of the indicated security features in order to prevent external interference. IS-IS RSVP LDP BGP PIM Not addressable externally. Authentication of neighbors. Filtered to known peers. Authentication of peers. Authentication of neighbors. Filtered to known peers. Authentication of peers. Filtered by known address ranges. Authentication of neighbors. SNMP Filtered to known management hosts. Community string. SSH SYSLOG RADIUS Filtered to known management hosts. Authentication by user. Initiation outbound only. Filtered to known management hosts. Initiation outbound only. Filtered to known servers.

VTN VN2 High Level Design

NTP

Initiation outbound only. Filtered to known servers. File

transfer Initiation outbound only. Filtered to known servers. 6.9.7.3 Device Access 6.9.7.3.1 SSH When operations staff requires direct CLI access to Juniper P routers, then the primary means of access should be to connect via SSH, inband over the network, to the loopback IP address of the device. The SSH protocol provides privacy to the CLI session. 6.9.7.3.2 AAA An Authentication, Authorization, and Accounting (AAA) service will be used, and each router should be configured with the a primary and secondary Radius server. User logins via SSH will be authenticated using Radius, and subsequent CLI activity will be authorized and accounted using Radius. 6.9.7.3.3 OOB In the event of a failure, or for use during certain operational tasks, an Out-of-Band (OOB) network connection should be available to each Routing Engine (RE) console and management ethernet ports. Providing access to the management ethernet port allows for network based protocols like authentication, logging, and snmp to function when in-band connectivity is down. Providing access to the serial console allows for remote configuration of new or replacement equipment, and provides access to the lowest level interface to the router hardware for troubleshooting. Equipment and links used to provide the OOB network should be diverse of the VN2 network at all levels between the NOC and each network device. 6.9.7.4 Device Management The primary role of the Network Management System (NMS) to be used to manage Juniper routers in the VN2 network is to manage the health of the devices and network links, and to gather information about link utilization, queue utilization, and other operating parameters of the network. As there are no customer service/instances being configured on the P routers there are no provisioning tasks, so the use of a provisioning system is not specifically recommended. However, a provisioning system, if available, could aid in managing aspects of the base configuration which might change form time to time, such as a change in the location of network management systems, etc. The primary means available to the NMS for managing JunOS routers are Syslog and SNMP.

VTN VN2 High Level Design

6.9.7.4.1 SNMP A primary and secondary syslog server should be configured on each router. Syslog servers can provide a consolidated view of log messages coming from all routers across the network, as well as correlate events around multiple log messages from multiple sources, and alert based on the configured severity of these events. 6.9.7.4.2 SNMP Primary and secondary SNMP trap receiver servers should be configured on each router. SNMP traps complement syslog messages and can likewise be used by the NSM to correlate events and raise alerts. 6.9.7.4.3 NTP The Network Time Protocol (NTP) is an important component in network management as it ensures that all router clocks are synchronized, which is important in correlating and sequencing events across multiple devices.

VTN VN2 High Level Design

7 Service Network Topology.


7.1 Core and MANs interconnect
There are a few options available to interconnect the new IP Core to the existing and new MANs. The 2 main options are either : Layer 2 VLAN Layer 3 MPLS

When choosing an option, the choice has to address the following : Ease of OAM Security Scalability

The following table describes the main differences between the 2 options. MANs and IP Core are categorised as different administrative domains.
Layer 2 (VLAN) Demarcation between IP Core and MAN Demarcation is clear as IP Core PE and MAN PE are under different administrative domains Operational functions such as provisioning and troubleshooting are strictly contained to nodes within each administrative domain. Layer 3 (MPLS) Demarcation is not clear as IP Core PE is part of MANs IGP/MPLS domain Operational functions in the MAN are more complicated as it involves the IP Core PE node which is accessible to different administrative domains. During provisioning, a different vendors NMS in the MAN will not be able to provision and manage the IP Core PE node. This would mean that provisioning in the MANs would likely to be done via CLI or scripts.

OAM

Security

Provides a more secure connection between the MAN and IP Core. Provisioning and management of nodes do not cross administrative domains. IP Core PE nodes are not visible within the MANs.

Not as secure as IP Core PE nodes will be reachable within the MAN. This makes the IP Core PE node more vulnerable to attacks from users in the MAN.

Same multi segment Scalability

VTN VN2 High Level Design

Layer 2 (VLAN) Same multi segment provisioning for services and LSPs as Layer 3 option TLDP sessions are confined to individual MAN and within the IPCore.

Layer 3 (MPLS) provisioning for services and LSPs as Layer 2 option. TLDP sessions are confined to individual MAN and the corresponding IPCore PE nodes.

Network stability

Issues such as routing instability within the MANs are totally isolated and will not affect the IP Core. MANs choice of IGP and types of L2 and L3 redundancy features are independent of the IP Core nodes. Configuration of IP Core PE nodes is simple to standardise with VLANs.

Network stability may be affected as the IP Core nodes are required to participate in the MANs IGP/MPLS domain. Configuration of IP Core PE nodes may be different for different MANs as these IP Core PE nodes may need to support different features and routing protocols used in the different MANs.

Table 17 : Comparison between L2 and L3 interconnect

Alcatel-Lucent recommends that layer 2 VLAN interconnect be used between the IP Core PE and MAN PE nodes as it offers high level of stability, scalability as well as technology neutral to MAN vendors. However, after the meeting on 22nd Apr 2009, VNPT has decided that the MANs and VN2 IP Core will be in the same IGP domain. Kindly refer to figure 4.

7.2

Service Architecture

Applications such as VPN-high speed internet (HSI), voice, IPTV and business VPN are transported using MPLS services such as virtual leased lines (VLL), virtual private LAN service (VPLS) and virtual private routed networks (VPRN). These MPLS services use MPLS LSPs to correctly direct traffic from source to destination. The Alcatel-Lucent 7750 service routers are purpose built for rendering thousands of VPN services. Each PE router is capable of supporting the following concurrent VPN service counts:

Dedicated

Concurrent#

VTN VN2 High Level Design

Virtual Leased Line Virtual Private LAN Service Virtual Private Routed Network
#

32,000 8,000 2,000

16,000 8,000 2,000

Actual service scaling will be limited by other factors such as FIB size, queues and MAC address space

Provisioning of LSPs for these MPLS services require multi segment provisioning. Each administrative domain (MAN or IP Core) will provision the part of the LSP in its domain. The following diagram illustrates an example of how multi segment LSP provisioning is done. In this particular example, we have a service that originates in MAN A and terminates in MAN B.
MAN PE LSP LSP MAN A MAN B IP Core PE IP Core IP Core PE MAN PE LSP

Figure 22: 3 segment MPLS Service Provisioning

This will be a three segment LSP provisioning. One segment in MAN A, one segment in the IP Core and one segment in MAN B. As each segment lies in a different administrative domain, the provisioning and management of each segment lies solely with the corresponding domains administrative body. 7.2.1 Ethernet Leased line service using L2 VPN For the purpose of providing Ethernet based leased line service, VLL is a layer 2 point to point pseudowire service that is designed for this purpose. The following diagram illustrates how a VLL service is provisioned from MAN A to MAN B, across the IP Core.

MA N PE VLL 1

IP Core PE

IP Core VLL 2

IP Core PE

MAN PE VLL 3

MAN A

MAN B

Figure 23: Virtual Leased Line Service

VTN VN2 High Level Design

Provisioning scope of VN2 is to facilitate the backbone VLL service across VN2 Network so as to stitch the adjacent MAN-A and MAN-B VLL service. For MANs with two PE connecting to two IP Core PE, redundancy options are available. One possible redundancy option assumes that the MAN runs MPLS and supports the pseudowire redundancy feature. This feature enables a pseudowire to have a single headend but 2 different tailends. Each tailend corresponds to a primary and a standby pseudowire. When a failure is detected at the tailend of the primary pseudowire, the headend will be notified of the failure and will then redirect traffic onto the standby pseudowire. The following failures at the tailend of the primary pseudowire would trigger the standby pseudowire : Link failure between MAN PE and IP Core PE Node failure of either the MAN PE or IP Core PE

In the following two diagrams, MAN A and MAN B provision a VLL with the redundant pseudowire feature. To support this redundancy feature, the IP Core must provision a VPLS service to connect both MANs together. A potential problem could arise if the customer site sends multiple MAC addresses. As more and more customers subscribe to the VLL service, care must be taken to limit the number of MAC addresses allowed per customer.

MA N A MA N PE Primary

IP Core IP Core PE IP Core PE VPLS MAN PE

MAN B

Primary

Standby Standby

MAN A MAN PE Primary

IP Core IP Core PE

IP Core PE

MAN B MAN PE Prim ary

VPLS Standby Standby

Figure 24: VLLs in MAN, VPLS in Core

VTN VN2 High Level Design

The VPLS in the core will learn the MAC addresses of the traffic on the primary pseudowires. When the link between the MAN PE and IP Core PE fails, traffic within the MAN will be redirected onto the standby pseudowire. On the IP Core PE node which is connected to the failed link, the MAC addresses will be withdrawn from that failed VPLS port and relearned again on the other VPLS port (single IP Core PE) or the other IP Core PE node (dual IP Core PEs) when it receives traffic from the standby pseudowire. This redundancy solution works for all MANs connecting to either one or two IP Core PE nodes.

7.2.2 Wide Area Switched LAN Service using VPLS VPLS is a layer 2 multipoint Ethernet service. It enables a MPLS network to provide virtual LAN services like a traditional layer 2 switch. It is useful for providing layer 2 connectivity to multiple sites located across multiple MANs for use by Enterprise customers to extend their local area network & aggregate islands of routed WAN without the need to invest in Wide area interface cards or equipment. This would be an attractive service for Enterprise customers who wants to control their IP address allocation.

7.2.2.1 Deployment Option A Single exit point This section deals with scenarios where the MANs have a single exit point to the VPLS service in the core network. In the following diagram, there are 2 customer sites in MANs A and B connected over a VPLS service in the IP Core. The VPLS end points will learn the MAC addresses and forward the traffic the same way the ports on an Ethernet layer 2 switch does.
MAN PE VLL VPLS MAN A IP Core PE IP Core PE IP Core VLL Standby MAN B Primary

Figure 25: VLLs in MAN, VPLS in Core

Redundant pseudowires in MAN B provides network resiliency in the event of failure to the IP Core PE or MAN Agg PE.

VTN VN2 High Level Design

7.2.2.2 Deployment Option B Dual exit points This section deals with scenarios where the MANs have dual exit points to the VPLS service in the core network. Such a scenario would create a Layer 2 loop between the MAN and the IP Core network. The following diagram shows 2 MANs running VPLS connecting to 2 PE routers in the IP Core, also running VPLS. The layer 2 loop is created between the 2 green and 2 yellow nodes. Such a loop is capable of causing broadcast storms which will severely affect services in the MAN and IP core networks.
Metro1 ro1
- PE U E P NE P N

S L P V ) h e s M (
-

Nm V PLS

-E W G P

GW P

Cor e-M esh


C-PE C-PE C-PE C-PE

VPLS (Mesh) (Mesh) VPLS


C -P C -E CPE C-PE C-PE

G W PE P E

V P L

M e s

G N W P E

N -P E

)
N P

-P E

M Met et ro2

Figure 26: mVPLS between MAN and IP Core with dual links

To break the layer 2 loop, MSTP can be used. MSTP will be configured on the four nodes (IP Core PEs and MAN Agg PEs). Together with proper values used for root priority and link cost, it is possible to selectively disable the desired links between the MAN and IP Core networks. On the 7750SR nodes, a management VPLS (mVPLS) is configured to maintain loop free topologies for multiple VPLS instances. If there are two IP Core PE routers, then load balancing can be achieved by separating the VPLS instances being forwarded by them. For example, PE1 can be made to forward traffic for VPLS 1 1000 and PE2 can be made to forward traffic for VPLS 1001 2000. For redundancy, PE1 will forward traffic from VPLS 1001 2000 when PE2 fails and vice versa. In such a scenario, there will be two mVPLS configured. One to handle VPLS traffic forwarded by PE1 and the other handles VPLS traffic forwarded by PE2.

VTN VN2 High Level Design

7.2.2.3 Scaling VPLS Implementing VPLS in the core to interconnect VPLS in the MANs provide scaling issues related to MAC addresses and broadcast (eg. ARP). It is not recommended to have the IP Core PEs maintain the MAC FIB of end devices, such as setup boxes and SIP clients. However, if VPLS is required in VN2, the following features are available on the IP Core PE routers to help control and secure it. QoS control on the Alcatel-Lucent 7750 allows classification based on parameters such as MAC address, 802.1p, IP address and DSCP Dedicated queues for broadcast, multicast and unknown traffic types MAC FIB size limit to specify the max number of MAC FIB entries MAC move to protect the network against L2 loops MAC learning protection to allow a set of protected SAPs, SDPs and MAC addresses to be defined Implementing PBB VPLS in the MANs to protect VN2 from maintaining MAC FIB entries of customer end devices (eg. STB and SIP clients)

VTN VN2 High Level Design

7.2.3 Wide area Routed LAN service using VPRN VPRN is a widely deployed service by Enterprise customers to operate Managed Wide area network service. VPRN is a layer 3 VPN service (RFC4364 IP VPNs). Each VPRN consists of a set of customer sites connected to a PE router. Each associated PE router maintains a separate IP forwarding table for each VPRN. The PE routers exchange the routing information configured or learned from all customer sites via MP-BGP peering. Each route exchanged via the MP-BGP protocol includes a Route Distinguisher (RD), which identifies the VRPN association. 7.2.3.1 Locations with dual IP Core PE In the following diagram, the layer 3 VPRN end points are on the IP core PE nodes. The MAN provides MPLS L2 (VPLS or VLL) transport between the customer CPE (router) and the IP core PE nodes. The hand off between the MAN PE and IP Core PE nodes is layer 2 (VLAN).

IP Core MAN AGG PE MAN A VPLS VPRN IP Core PE IP Core PE

VRF

Standby VLL Primary MAN B

Figure 27: VPRN with dual IP Core PE

For locations with two IP Core PE nodes, redundancy can be provided with VRRP. 7.2.3.2 Locations with single IP Core PE It is highly recommended to deploy a second IP Core PE at those MANs with only a single IP Core PE. MANs with single IP Core PEs exhibit a single point of failure for the entire MAN. It is also highly desirable to maintain a standardised design for the entire network as the MANs with dual IP Core PEs. For locations with a single IP Core PE, there are a few deployment options available for providing redundancy.

VTN VN2 High Level Design

7.2.3.2.1 Option 1 CPE runs IGP with IP Core PE


IP GW(B) IP Core IP Core PE IP Core PE MAN AGG PE CPE running IGP with Core PE

VPRN

IP GW(A)

Figure 28: Single IP Core PE with routed CPE

CPEs that are capable of running routing protocols (IGP) can select a primary and secondary IP gateway on the IP Core PE. When the primary IP gateway on the IP Core PE fails, the CPE will detect it via IGP and redirect traffic towards the secondary IP gateway. 7.2.3.2.2 Option 2 CPE with floating static routes
IP GW(B) IP Core IP Core PE IP Core PE MAN AGG PE Primary GW VPRN Secondary GW CPE running IGP with floating static routes

IP GW(A)

Figure 29: Single IP Core PE with CPE running floating static routes

CPEs can also be configured with floating static routes towards the two IP gateways on the IP Core PE. Some CPEs have the capability to track the status of the IP gateway. When the primary IP gateway is unreachable, the CPE will redirect traffic towards the secondary IP gateway.

VTN VN2 High Level Design

7.2.3.2.3 Option 3 End devices with static IP gateway


IP Core IP Core PE IP Core PE IP GW(B) MAN AGG PE Clients connecting these MAN PEs use IP GW (B)

VPRN Clients connecting these MAN PEs use IP GW (A)

IP GW(A)

Figure 30: Single IP Core PE with static GW configuration on end devices

For end devices with static IP gateway configuration (eg. SIP clients, STB), each IP gateway on the IP Core PE can serve half of the devices in the MAN. The main disadvantage in this scenario is that there is no IP gateway redundancy for the end devices. When IP gateway (A) fails, all the end devices will be disconnected from the service and will need to reconnect to the service again. There are two alternatives to provide IP gateway redundancy for such end devices. The first alternative would be to deploy another IP Core PE for the MAN.
MAN AGG PE IP Core PE

VPLS/VLL

VRF

Figure 31: Dual IP Core PE No single point of failure

This would be the ideal solution as it addresses the single point of failure for the MAN. With dual IP Core PE, the MAN will no longer have a single point for failure. For MANs with dual MAN Agg PEs layer and dual IP Core PEs layer, L3 termination can be on either layer. However, for end devices such as SIP clients or STBs, it is highly recommended that the L3 termination be on the MAN Agg PE layer. This would free the IP Core PE from maintaining ARP entries of such end devices.
IP Core PE MAN AGG PE IP GW

Figure 32: IP gateway on MAN Agg PE

VTN VN2 High Level Design

7.2.4 High Speed Internet Service High Speed Internet (HSI) service for residential and business customers will be served by VTNs newly acquired BRAS.
Route Reflectors

iBGP

iBGP

iBGP BRAS RR Client NPE RR & RR Client MPLS Core


1

eBGP ASBR RR Client VDC

Figure 33: High Speed Internet Service

BRAS will be participating in the BGP AS together with VN2 PE & ASBR routers. BRAS will route Internet bound traffic base on full Internet routes updated by iBGP. Therefore, during normal circumstances, BRAS within the same region e.g. HNI will egress the HNI ASBR routers to VDC centre 1. Should there be a failure in VDC centre 1, the Internet routes advertised by HNI ASBR will be withdrawn and the affected BRAS will re-evaluate its routing table to install the next best default route base on the next best preference.

VTN VN2 High Level Design

7.2.5 IPTV Video Core distribution using multicast Distribution of broadcast (live) video content is done using multicast routing. Until the MPLS P2MP LSP feature is tested and verified, VN2 will distribute IPTV multicast streams using PIM-SM and/or PIM-SSM from the Video Super head-end office or content service providers. Therefore, both P and PE routers will have to run PIM with the RP recommended to be at the HNI PE where it is connected to the video head-end.

IP Core

PIM

PIM

IGMP Static Joins MC traffic streams

MC traffic streams

MAN

PIM

Figure 34: Multicast routing between VN2 and MAN

As requested by VNPT, the MANs and VN2 will form a single multicast PIM domain. To aid the recovery time of the multicast streams, IGMP static joins will be configured on the IP Core PE links to the MAN. Regardless of locations with dual IP Core PEs or single IP Core PE, this would mean that every MAN would receive duplicate copies of the multicast stream. The PIM protocol running in the MANs will select a multicast stream and uses the other duplicate stream for failure recovery.

VTN VN2 High Level Design

8 Network Management
The proposed Network Management system for the administration and management of the PE and ASBR node is the Alcatel-Lucent 5620 Service Aware Manager (SAM). In the VN2 Network Management deployment, a redundant installation of 5620SAM has been planned. The primary set of 5620SAM servers will reside in Hanoi city and the redundant set of 5620SAM servers will reside in Ho Chi Minh city. The 5620 SAM (Service Aware Manager) provides a central management of the Alcatel Services routers.

The 5620 SAM provides full FCAPS functionality across four modules:

Alcatel-Lucent 5620 SAM Element Manager (5620 SAM-E) base module for equipment management, basic fault management using alarms, statistics collection, security, the GUI, and equipment management and monitoring Alcatel-Lucent 5620 SAM Provisioning (5620 SAM-P) optional module for provisioning services, creating and managing service policies such as QoS, correlating alarms to services, and configuring networking protocols Alcatel-Lucent 5620 SAM Assurance (5620 SAM-A) optional module for service assurance using OAM tools, service topology maps, service location, and performance monitoring Alcatel-Lucent 5620 SAM Open Interfaces (5620 SAM-O) optional module for XML-based open interfaces management, including provisioning, monitoring, configuration, and service assurance

VTN VN2 High Level Design

8.1

Alcatel-Lucent 5620 SAM Element Manager (5620 SAM-E)


Node mediation Equipment Management Inventory and Reporting Security Management CLI session (Telnet/SSHv1/SSHv2) Access to NE Secure File Transfer and Backup and Restore of NE configuration Equipment Navigation Equipment Statistics Alarm Policy Management

The Alcatel-Lucent 5620 SAM-E module provides the following functions:

8.2

Alcatel-Lucent 5620 SAM-Assurance (SAM-A)

The Alcatel-Lucent 5620 SAM-A module of the 5620 SAM Suite provides the following functions:

Physical Topology LSP Topology SDP Topology LSP Path and LSP cross connect Topology Service Topology Composite Service Topology Service Mirroring Service Assurance for IES, VLL, VPLS, VPRN Fault management including correlation of element, network, and service Service Assurance System (SAS) Test Manager for Service OAM test, suites and test policies including scheduling. Statistics Policies and historical data Accounting Policies and data Generic NE assurance support

8.3

Alcatel-Lucent 5620 SAM Provisioning (SAM-P)

The Alcatel-Lucent 5620 SAM-P module of the 5620 SAM Suite provides the following functions:

Service IES, VLL, VPLS, VPRN management Composite Service Provisioning Provisioning Wizards Provisioning Service Templates Network Tunnel (SDP), MPLS Path and LSP management Subscriber Management Policy Management (QoS, Filters, Routing, Accounting, File) Service Navigation Generic NE provisioning support Script Manager provisioning Dynamic Subscriber Management with Profiles and Policies

VTN VN2 High Level Design

8.4

Alcatel-Lucent 5620 SAM Open Interface (SAM-O)

The Alcatel-Lucent 5620 SAM-O is an open interface on the 5620 SAM through which an OSS client application can perform the following tasks:

Configure or access network management information in the 5620 SAM database Send requests and receive responses between the 5620 SAM-O server and the OSS client Receive information about managed objects Manipulate managed objects Receive event information from the 5620-SAM server using a persistent or nonpersistent JMS connection

Enabling the SAM-O module requires all three other based modules to be activated, and as it is proposed that the full 5620 SAM Suite be deployed within the VN2 architecture.

8.5

Alcatel-Lucent 5620SAM Redundancy

A 5620 SAM server and database pair installed on Solaris can be deployed in a redundant configuration to provide greater fault tolerance. 5620-SAM redundancy uses extra server and database components to ensure that there is no single point of software failure within the 5620-SAM system. A redundant configuration that uses redundant physical links to the managed network ensures that the network remains visible to the 5620 SAM during a single network or hardware failure. The state of a server or database defines the current role of the component, whether primary or standby. The primary server actively manages the network while the primary database is open in read/write mode. When a standby component detects a primary component failure, it automatically assumes the primary role. A server role change, whether automatically or manually performed, is called an activity switch.

An automatic database role change is called a failover, while a manually performed database role change is called a switchover. The 5620 SAM supports collocated and distributed redundancy configurations (for VN2 a Distributed System has be recommended). In a distributed configuration, the 5620-SAM server and the 5620 SAM database are installed on separate stations. The servers and databases are four independent entities, regardless of the physical or geographical deployment. The 5620 SAM servers ping each other periodically to verify redundancy. If the standby server fails to reach the primary server over a 60-s period, the standby server activates and becomes the primary server. The 5620 SAM databases achieve redundancy through Oracle functionality.

VTN VN2 High Level Design

The 5620 SAM client GUIs always connect to the current primary server. After a server activity switch, the 5620 SAM client GUIs connect to the new primary server, which is the former standby server. Activity switches are transparent to a 5620 SAM client. OSS clients also connect to the primary server, but after an activity switch, the connection is lost. OSS clients must know which server is the new primary server before they can again interact with the 5620 SAM. Both the primary and standby servers have visibility of the redundant databases. You can use the 5620 SAM GUI to do the following related to redundancy: Check the status of redundant 5620 SAM servers and databases Perform a switchover from the primary to the standby 5620 SAM database You can use scripts on the server to perform a server activity switch. Redundancy is configured during a 5620-SAM server or database component installation. 8.5.1 Activity switches, failovers, and switchovers The figure below shows the three types of redundancy activities: Server activity switches Database switchovers Database failovers.

Figure 35: Server activity switch, and database switchover and failover

8.5.2 Server activity switches A 5620 SAM server activity switch can be performed to:

VTN VN2 High Level Design

Recover from subnet failures or errors Test redundancy in case of a catastrophic failure Prepare a station for a software upgrade

There are two types of activity switches for servers: Automatic Manual

During a server activity switch transition period, a main server does not process SNMP traps from the network, and no regularly scheduled resynchronizations occur. For example, when an on-demand statistics request occurs during an activity switch, the 5620 SAM collects no statistics for the current collection period. An auxiliary server continues to process outstanding requests during an activity switch but does not communicate with a main server during this time. The figures below show the relationship of the servers and databases before and after a server activity switch.

Figure 36: Before activity switch

Figure 37: After activity switch

During the activity switch shown in the figures above: Alarms are raised. Client GUIs receive a message about the redundancy change to indicate that the server is not available and they must connect after the activity switch completes.

VTN VN2 High Level Design

After an activity switch: GUI clients communicate with the new primary server and are aware of the current redundancy status. OSS clients must reconnect to the primary server, as described in the 5620 SAM-O OSS Interface Developer Guide [4] The new primary server establishes communication and synchronizes information with the known auxiliary servers in the 5620-SAM domain. Auxiliary servers no longer exchange information with the former primary server. The Preferred or Reserved state of an auxiliary server may change, depending on the new primary main server configuration settings.

If the primary server does not complete a deployment request from a client before the activity switch, the new primary server attempts to redeploy the request. 8.5.3 Database switchovers The figures show the relationship of the servers and databases before and after a successful database switchover.

Figure 38: Before Switchover

VTN VN2 High Level Design

Figure 39: After Switchover

Before a database switchover, the primary server requests that each auxiliary server in the cluster release all connections to the current primary database. When a switchover is successful: The primary and standby database roles are reversed. The primary server can establish connections to the new primary database. Archive logging begins on the new primary database. The primary server directs each auxiliary server to connect to the new primary database. When a switchover is not successful, the databases remain in the original primary and standby roles.

8.5.4 Database failovers A failover is an automatic transition of a standby database to the primary database role, for example, when there is a catastrophic primary database failure. After a failover, database redundancy is inactive. A database failover is a disaster-recovery mechanism. A failover occurs only when the primary server and the standby database lose visibility of the primary database. When this happens, the primary server initiates a database switchover on the standby database. Failover functionality is enabled by default during 5620-SAM database installations. A database failover occurs after one of the following events: The primary database station loses power. The primary database station becomes unreachable over the network. The primary database crashes or otherwise ceases to communicate with the primary server. The following conditions must be present before a database failover occurs: The standby database is configured, operational, and reachable. The primary database is unavailable.

VTN VN2 High Level Design

All auxiliary server connections to the primary database are closed. Before it initiates a failover, the primary server requests that each auxiliary server in the cluster release all connections to the current primary database. After a successful failover, the primary server directs each auxiliary server to connect to the new primary database. The figures below show the relationship of the server and the databases before and after a successful failover

Figure 40: Before failover

Figure 41: After failover

When a failover is not successful, the primary server retries its connection to the former primary database. If the former primary database remains unavailable, the primary server again attempts to initiate a failover. Communication between the primary server and the primary database must fail for a minimum of five minutes before an automatic failover occurs. If the failure also triggers a server activity switch, the time increases to a minimum of 15 min. The table below lists the minimum failure periods for specific scenarios before a database failover occurs.

VTN VN2 High Level Design

Scenario Primary database crashes, or otherwise ceases to communicate Primary database station loses power Primary database station becomes unreachable

Minimum length of communication failure 5 min 5 min 5 min

Table 18: Failover minimum timings

8.5.5 Events associated with an activity switch.

Type Database switchover

Description A switchover is a manual operation that reverses the primary and standby database roles, for example, during primary database maintenance, or to realign database roles with specific database stations after a server activity switch.

Notes When the primary 5620 SAM server detects a communication failure between itself and the primary 5620 SAM database, the client GUIs are informed that the primary 5620 SAM database is not reachable.

For a switchover to occur both the primary and When the primary 5620-SAM server standby databases must be functioning detects a communication failure correctly and communicating with each other. between itself and the standby 5620 SAM database, the

VTN VN2 High Level Design

Type Database failover

Description A failover is the automatic transition of a standby database to the primary database role, for example, after a catastrophic primary database failure. A failover involves the following sequence of events. The primary server fails to establish communication with the primary database for a certain time period. The primary server asks each auxiliary server in the cluster to release all database connections. If all database connections are not released within 15 min, the switchover fails. After all database connections are released, the primary server initiates a switchover to the standby database. The switchover completes; the former standby database is the new primary database. The primary server restarts to ensure proper synchronization of information with the new primary database. Depending on the duration of the primary server restart, the standby server may interpret peer unresponsiveness as a failure and attempt an activity switch to primary. The primary server directs each auxiliary server to connect to the new primary database. After a failover, the former primary database can be restored to the 5620- SAM system as the new standby database. Database redundancy is not available until reinstantiation is complete. A failover results in minimal data loss.

Notes client GUIs are notified that the standby 5620 SAM database is not reachable. After the problem that caused the communication failure is resolved, the clients GUIs are notified that database redundancy is operational.

VTN VN2 High Level Design

Type Re-establishing database redundancy

Description Re-establishing database redundancy is a user action that restores the primary database to the redundant 5620-SAM system as the new standby database. After a failover, the former primary database does not participate in database redundancy until a 5620 SAM operator with the appropriate scope of command role reinstantiates it as the new standby database.

Notes The following conditions must be met before database redundancy can be re-established. The failover completes successfully. The station that contains the primary database is operational. The former primary proxy port is configured and in service.

8.6

Direct 5620 SAM Client Access

The 5620-SAM Client application utilizes Java technology. The 5620 SAM Client installation package contains a Java Virtual Machine that is installed with the software. This Java Virtual Machine is dedicated to the 5620 SAM Client and does not conflict with other Java Virtual Machines, which may already be installed on the 5620-SAM Client workstation. The 5620-SAM Client application can be run on the following platforms: Solaris o Solaris 9 and the Solaris 10 releases o Solaris 10 x86 for AMD based platforms Windows (32-bit version only) o Windows 2000 /2003/XP Professional/Vista Business/Enterprise and Ultimate Red Hat Linux o Linux Red Hat Enterprise WS 3.0. The recommended bandwidth to be made available between each 5620 SAM Client and the 5620 SAM Server Application is 512Kbps.

8.7

IP Addressing and Naming convention

IP addressing and naming convention shall be as defined in 6.1 IP Addressing and naming convention.

VTN VN2 High Level Design

8.8

Bandwidth Requirement

The following table summarizes the bandwidth requirements between the 5620 SAM components.
Available Bandwidth Requirements From a 5620 SAM Server to a 5620 SAM Database From a 5620 SAM Server to a 5620 SAM Client From a 5620 SAM Server to a 5620 SAM- O Client (OSS) Between a primary and a standby 5620 SAM Server Between a primary and a secondary 5620 SAM Database Min Bandwidth 3 Mbps Recommended Bandwidth 15 Mbps

512 Kbps

512 Kbps

1Mbps

1Mbps

1Mbps

1Mbps

3 Mbps

15 Mbps

Table 19: 5620 SAM Bandwidth Requirements

8.8.1 Bandwidth Requirements SAM to Network Elements In order to effectively manage the network, 5620 SAM must have access to sufficient bandwidth between the 5620 SAM Server(s) and the network elements. It is recommended that 100 kbps of bandwidth in the network be available from 5620 SAM to each of the MDAs in the network. This bandwidth will be used to carry the management traffic between 5620 SAM and the network element. The following table describes, as an example, the bandwidth requirements for a particular network element
Number of MDAs 5 10 Network Element Example 7750 SR-7 (Partially Loaded) 7750 SR-7 (Fully Loaded) Recommended Bandwidth 500Kbps 1 Mbps

Table 20: Example 5620 SAM to Network Element Bandwidth Requirements

VTN VN2 High Level Design

Figure 42: Example b/w calculation

The diagram above shows how a calculation can be reached to determine the amount of management traffic bandwidth that will be required on each link in the network. 100Kbps is allowed for each MDA fitted into the switch/router device, and the summed bandwidth is added to every subsequent link in the chain back to the active 5620-SAM server (note similar calculation must be made to the standby site as all management traffic will switch over automatically in the event of fail-over or forced activity switch). In cases where the management traffic is carried over a shared infrastructure, which services more than 20 network elements, the 5620 SAM will only perform bandwidth-intensive operations on 20 network elements simultaneously. In this case, the reserved bandwidth required on this shared infrastructure will be the sum of the bandwidth requirement for the twenty largest nodes on the shared infrastructure. 8.8.2 Details on the Bandwidth Requirements The recommended bandwidth described above is a conservative figure that is meant to ensure that the performance of 5620 SAM and its ability to manage successfully each network element will not be affected by unusual network conditions. Specifically, the bandwidth recommendation ensures that 5620 SAM can fully discover (or resynchronize) all of the objects contained in the network element, within a reasonable amount of time, usually no more than a few minutes for a densely populated network element.

VTN VN2 High Level Design

The following are the main operations that result in significant amounts of information being exchanged between 5620 SAM and the network elements. These factors are therefore the principal contributors to the bandwidth requirements. Network Element Discovery: Upon first discovery of the network element, a significant amount of data is exchanged between 5620 SAM and the network element. SNMP traps: SNMP traps do not result directly in significant data being sent from the network element to the 5620 SAM. Several of the SNMP traps however do not contain all of the information required for 5620 SAM to completely represent the new status of the network element. As a result the 5620 SAM will subsequently perform a poll of a certain number of the SNMP MIBs to obtain the required information from the network element. Consequently, SNMP traps do result in a certain quantity of data and therefore cause bandwidth utilization. The exact quantity of bandwidth utilized will vary based on the number and the type of trap that is sent from the network element. In the worst case however, this bandwidth utilization will be less than that utilized during a network element discovery. SNMP polling: It is possible to configure 5620 SAM to poll the SNMP MIBs on the network elements at various intervals. By default, 5620 SAM will perform a complete poll of the SNMP MIBs every 24 hours for 7750 SR and 7450 ESS network elements. It is possible to configure individual MIBs to have a different polling rate. During the polling cycle, the amount of data transferred between 5620 SAM and the network element is equivalent to the amount of data transferred during the network element discovery. Statistics collection: It is possible to configure 5620 SAM to poll the SNMP MIBs on the network elements that contain performance statistics information. During the polling cycle, the amount of data transferred between 5620 SAM and the network element is less than the amount of data transferred during the network element discovery. Network element backup: It is possible to configure 5620 SAM to request a backup of the network element at specified interval. During the polling cycle, the amount of data transferred between 5620 SAM and the network element is less than half of the amount of data transferred during the network element discovery. The frequency of network element back-ups will be governed by internal VTN/VNPT NOC procedural policy, best practice would be for at a minimum to back-up the nodal configurations every 24 hours, however during periods of intense provisioning/configuration activity it maybe prudent to decrease the back-up period interval time to make sure the nodal backups reflect the truest state of the network if a disaster recovery plan has to be implemented. Provisioning of services and deployment of configuration changes: When network elements are configured or when services are provisioned via the 5620 SAM GUI or via application using the 5620 SAM-O interface, a small quantity of network bandwidth is utilized. The amount of data transferred is significantly less than during the network element discovery.

VTN VN2 High Level Design

8.8.3 Possible consequences of insufficient bandwidth In situations where there is less than the recommended bandwidth between the 5620 SAM and the network element, the following are possible consequences: The length of time required to perform a network element discovery will increase The length of time required to perform a SNMP poll of the network element will increase The length of time required to retrieve statistics from the network element will increase The proportion of SNMP traps that will not reach 5620 SAM because of congestion will increase. This is significant since 5620 SAM will detect it has missed traps from the network element and will result in 5620 SAM performing additional SNMP polling to retrieve the missing information. This will result in additional data being transferred, which will increase the bandwidth requirements, possibly exacerbating the situation.

8.9

Server Hardware

The proposed server hardware for the VN2 5620SAM deployment will be 2 units of Sun Fire X4200 with 16GB of DRAM and 2 x 146GB HDD. One unit will be designated as the 5620SAM Application server and the other as the 5620SAM database server. A duplicate set of the server hardware will be located in the Ho Chi Minh City VTN facility for the purpose of providing geographic redundancy.

8.10 Security
8.10.1 TACACS+ Configuration The 5620 SAM uses a JAAS security framework to provide authentication and authorization services. When a user logs in to the 5620 SAM, the authentication method that is used depends on the configuration of login modules. The 5620 SAM supports two remote authentication login modules: 1. RadiusJaasLoginModule 2. TacacsPlusJaasLoginModule The JAAS security framework integrates the login modules into the 5620 SAM. On startup, the 5620 SAM locates the SamJaasLogin.config file, which defines the login modules. Depending on the samvsa flag setting in the SamJaasLogin.config file, two remote authentication and authorization scenarios are available for remote users that do not have a 5620 SAM client user account. The remote server authenticates the user and the 5620 SAM provides the user group to which the user belongs.

VTN VN2 High Level Design

The remote server authenticates the user and provides the user group to which the user belongs to the 5620 SAM. This method will be implemented on the VN2 network.

Upon a successful authentication by the remote TACACS server, the login module will return the user group name to be used by the user. The user group returned should match the required permissions allocated to the requesting user. In order to return a user group, the following VSA (Vendor Specific Attribute) needs to be configured on the TACACS+ authentication servers:
Name sam-security-group Description Indicates the name of the group the authenticated user belongs to String One or more octets containing printable ASCII characters

The following is an example of the TACACS+ user group VSA: service=sam-app{sam-security group="VTN_SamOGroup"} Note. The user group must be a valid user group in the 5620 SAM. 8.10.1.1 5620 SAM Authorization Rules To make sure that a user can login, the following rules apply: A successful TACACS+ authentication should return the following mandatory attribute: o User group the user belongs to The user group name returned by the external server should match an existing User Group defined in SAM. If not, authorization will fail. A temporary User will be created in SAM if the user name does not match an existing User defined in SAM. Temporary Users cannot be modified, and they are removed from SAM when the login session is terminated

8.10.1.2 5620 User Accounts/Roles The admin account must exist on the 5620 SAM for administrative purposes and cannot be deleted. However, the administrator can, and should, set up other accounts for users of the 5620 SAM based on what roles VNPT & VTN deem necessary for the OAM of the system. User permissions are based on scope of command roles that are assigned to user groups (the indicator sent back from the TACACS+ server) using scope of command profiles. The user inherits the scope of command access rights from the user group that they belong to.

VTN VN2 High Level Design

A scope of command role defines the read, create, update, and delete access permissions on a 5620 SAM Server object type, or package. You can create scope of command roles to suit specific functions in your operations by assigning specific access permissions to different functional areas of the 5620 SAM. These functional areas are organized into packages, methods, and classes. Default scope of command roles have been pre-defined within the SAM, however tailored roles can also be created by the system administrator. The default roles cannot be deleted. Full details on configuring user accounts and roles can be found in 5620-SAM User Guide Section 10.1 8.10.2 Communication Port Requirements for 5620-SAM Components It is recommended that Network management systems and their associated databases be housed behind VNPT/VTNs Firewall for security purposes. The following are network port TCP/UDP requirement for SAM to function:
Default Port 1098 Type TCP Description org.jboss.naming.NamingService This port is required to ensure successful communication between the SAM Server and the SAM GUI clients. SAM GUI clients use this port to look up items provided by the SAM Server. The items looked up are functions that the clients use to get or send information to and from the server 1099 TCP org.jboss.naming.NamingService This port is required to ensure the SAM GUI clients properly initialize with the SAM Server. When initially logging into the SAM Server, SAM GUI clients use this port to find the various services that are available. This port is also used by the SAM GUI clients to register with the SAM Server to receive notification of network changes. SAM- Server to GUI Clients Usage SAM- Server to GUI Clients

1100

TCP

Jboss High Availability JNDI service This port is required to ensure the 5620 SAM GUI clients properly initialize with the 5620 SAM Server when there are redundant servers. This port is used when 5620 SAM is installed in a redundant configuration. When initially logging into the 5620 SAM Server, 5620 SAM GUI clients use this port to find the various

SAM- Server to GUI Clients

VTN VN2 High Level Design

Default Port

Type

Description services that are available. The 5620 SAM GUI clients to register with the 5620 SAM Server to receive notification of network changes also use this port.

Usage

11800 Ports from 3276865536 12800

TCP

Jboss High Availability JNDI service This port is required to ensure the 5620 SAM Server can monitor the peer servers availability when there are redundant servers.

Active Server to Standby Server

TCP

(Jboss clustering) During run-time operations, the 5620 SAM Auxiliary use this port to end and receive information to and from the 5620 SAM Server. The number of required ports depends on the umber of 5620 SAM auxiliary workstations that are installed.

Note: Only required when Aux servers deployed

4444 4450

TCP

Jboss Messaging During run-time operations, the SAM GUI clients use this port to send and receive information to and from the SAM Server. For example, GUI user operations, such as clicking "apply" on a configuration form, will result in information being transmitted to the server using this port.

SAM- Server to GUI Clients

8080

TCP

HTTP This port provides an HTTP interface for 5620-SAM-O clients to access the 5620-SAM Server

OSS Applications to SAM Servers GUI Client to SAM Server

8085

TCP

HTTP This port provides an HTTP interface for 5620-SAM client. The 5620 SAM Client uses this port to verify the existence of the server.

8443

TCP

HTTPS This port provides an HTTPS (Secure HTTP) interface for 5620-SAM-O clients to access the 5620-SAM Server

OSS Applications to SAM Servers (if secure HTTPS connection

VTN VN2 High Level Design

Default Port

Type

Description

Usage enabled)

8444

TCP

HTTPS This port provides an HTTPS (Secure HTTP) interface for 5620-SAM clients. This is a secure version of port 8085. Used only if 5620 SAM Client is connecting via SSL.

5620 SAM Server to SAM Clients

8093 8094

TCP

JMS (Java Message Service) This port is used by the SAM server to send real-time notifications of changes that have happened in the network such as alarms or newly created configurations to the SAM GUI clients and registered SAM-O OSS applications. The messages are sent using the JMS protocol (over tcp).

SAM- Server to GUI Clients and to any OSS applications that utilize JMS connections

162

UDP

SNMP Traps By default, SNMP traps from the nodes are received by the SAM server at this port. This item is specified during the installation of the server and can be changed.

Network Elements to SAM- Server

161

UDP

SNMP By default, this port is used by the SAM server to send SNMP messages, such as configuration requests and service deployments to managed routers. This item is specified during the installation of the server and can be changed.

SAMServer to Network Elements

21 Ports from 1023 65536 22

TCP

FTP (Passive) This port is used to enable ftp communication between the SAM Server and the managed routers. ftp occurs to transfer information from the routers to the SAM Server such as accounting statistics.

SAMServer to Network Elements

TCP

SSH This port used by clients to request a SSH session to a managed router.

SAMServer to Network Elements SAMServer to

23

TCP

Telnet

VTN VN2 High Level Design

Default Port

Type

Description This port used by clients to request a telnet session to a managed router.

Usage Network Elements Only for 7250 and Telco devices

69

UDP

TFTP This port is used to do ftp when managing 7250-SAS or Telco T5C equipment. If there are no 7250 SAS or Telco T5C nodes in the network, this port is not required

9002 Ports from 3276865536

TCP

5620 SAM Database Proxy This port is used by the 5620 SAM Server to monitor disk usage on a remote 5620 SAM Database. When there are redundant databases, it is also allows the 5620 SAM Server to initiate database switchovers and failovers .

SAMServer to both active and standby database platforms

9003 Ports from: 3276865536

Database file transfer Port This port is used by the 5620 SAM Database workstations in a redundant workstation configuration. This port allows Database transfers between the primary and standby databases. For example: when the standby database is re- instantiated, or when the standby database is installed for the first time. Ports are allocated dynamically and temporarily in the range to satisfy the initial requests that arrive on port 9003 (the listener port).

SAM Active and SAM Standby Database Servers

1523

TCP

Oracle SQL*Net Listener This port is used by the 5620 SAM Server to connect to and communicate with the 5620 SAM Database. When there are redundant databases, this port is also used by Oracle DataGuard to keep the databases in sync.

SAMServer to both active and standby database platforms

1094 1095 4448 4449 1096 1097

TCP

(Jboss messaging) These ports are used by commands on the 5620-SAM Auxiliary workstation to adjust the 5620-SAM Auxiliary behavior. (Example: adjusting log levels, shutting down the auxiliary server, etc)

Note: Only required if Aux Servers deployed.

TCP

(JMS messaging service) Used by the 5620 SAM Client (GUI and OSSI) and 5620 SAM Server and 5620 SAM Auxiliary applications to

SAMServer to SAM Clients,

VTN VN2 High Level Design

Default Port 4446 4447

Type

Description register for JMS notifications and messages. This is used to ensure that the Client, Server, and Auxiliary are aware of system events (i.e.: database changes or alarm notifications, etc)

Usage OSS applications and Aux Servers if deployed

8.11 Network Time Protocol


Network Time Protocol is a protocol designed to synchronize the clocks of computers over a network. NTP has a client/server relationship in which time stamping is achieved from one or more servers to a number of clients configured for NTP. The synchronization of time-stamps allows events from multiple routers to be correlated when system logs are created. Optimally, one or more dedicated NTP servers with a Stratum 1 clock source would be deployed for this purpose however this is not a stringent requirement. All VN2 routers should be synchronized to at least two NTP servers, including the 5620 SAM Management Servers.

VTN VN2 High Level Design

9 NMS WANDL IP/MPLSView Solution


9.1 What Can WANDL Solution Offer

9.1.1 Overview IP/MPLSView is WANDL's multi-vendor, multi-protocol, multi-layer and end-to-end topology both online and offline NMS total solution for IP and/or MPLS networks. IP/MPLSView differs from other solutions in the OSS space in that it is the first integrated traffic engineering and network management solution to address all aspects of the FCAPS ITU Model: Fault Management Configuration Management Accounting Management Performance Management Security Management

Built on a highly-scalable multi-vendor platform, IP/MPLSView provides unprecedented visibility into both the physical and logical layers of the IP network. With both online and offline capabilities, IP/MPLSView can be leveraged by various groups within the organization from Operations to Engineering to Planning. Each stage of the network lifecycle can be managed by using an accurate and consistent data model through IP/MPLSView's intuitive graphical interface. The system provides concise and in-depth views of IP or IP/MPLS routers, tunnels, routing protocol configurations, and traffic through an intuitive graphical display and through flexible and comprehensive reports. *WANDL System also supports Juniper logical router (JUNOS), logical system (JUNOS) and virtual router (JUNOSe). LR/LS/VR will be seen on network topology as independent node according to the network configuration. All the CM/PM/FM features support LR/LS/VR, such as correlation of traps, traffic, and LSP, VPN, protocols. Correct correlation will be applied to exact LR/LS/VR in the network instead of physical routers. 9.1.2 Online Operation Management IP/MPLSView offers a variety of configuration, data and traffic management capabilities to help you monitor, manage and troubleshoot your IP network. Schedule a variety of management tasks, perform automatic collection of near real-time views of the network (router and tunnel configurations, operational network state), and have your entire network topology automatically displayed in a powerful and easy-to-use graphical interface. View the Layer 3 traffic data collected from the network, as well as the Layer 2 LSP tunnel load distribution (for MPLS-enabled networks), to facilitate the monitoring of LSP routes and traffic flow pattern changes. Perform network diagnostics with ease.

VTN VN2 High Level Design

<Reference document: IPMPLSView_Management.pdf> 9.1.3 Offline Planning Simulation IP/MPLSView is the ideal platform for performing network engineering tasks as well as short-term and strategic long-term network planning. Whether your network project involves network architecture design or redesign, troubleshooting, network migration, new technology deployment, network optimization or tuning, count on IP/MPLSView to deliver fast, accurate and reliable results. <Reference document: IPMPLSView_Planning.pdf> 9.1.4 Provisioning & Service Management WANDLs IP/MPLSView product has been established for many years as a marketleading software package for collection monitoring and offline planning in carrier and largeenterprise networks. One of the key uses of IP/MPLSView is for offline network planning. There is a clear requirement for the planner to use our software for design and analysis of changes to the network and then to take the output from the software model in a form that can be directly sent back to the routers for configuration. Some of the output from the planners design and analysis can require substantial engineering or financial input to deploy and the associated changes to the router configs are minimal. However many of the tasks that a planner will use IP/MPLSView software to help with their network design role requires only configuration changes on the routers. A close connection between the network design output from the planner and the actual changes to the routers will shrink the time for the planning cycle and cut-down the chances of errors creeping into the process. WANDL can offer profession service for provisioning template design. <Reference document: IPMPLSView_Provisioning.pdf>

9.2

Design of WANDL NMS Solution for VN2

9.2.1 Overall Architecture 9.2.1.1 NOC Centers There are three NOC in three regions Hanoi, Danang, and HCM. Primary servers are in Hanoi and backup servers are in HCM. Data collectors are in every region. The historical data will be back up daily between primary and backup servers.

VTN VN2 High Level Design

9.2.1.2 WANDL System

Figure 43: WANDL System

9.2.2 Machines Application Server Database Data Collectors Report Server Web Server Task Server Provisioning Server User Clients 9.2.3 User Admin 9.2.3.1 User Administration by Function Via the User Administration window, users can be assigned different group and user access privileges by the administrator, restricting access to a specific set of functionalities and data. 9.2.3.2 Regional Administration The user administration system also supports both ROC and NOC operation needs. IP/MPLSView has built-in user grouping capability to allow the administrative user to create different profiles for other users with different access

VTN VN2 High Level Design

level and different preferred views. Regions can be defined, and users restricted to only viewing detailed information for the regions that they are assigned to. Users with restricted regional access can see the entire network topology, but will be restricted from viewing/running various data/functions on nodes not in their region(s), including: events/alarms, tunnel events/tunnel path revisions, configuration file, telnet to device, run CLI commands, ping/traceroute, equipment/chassis view, live cpu utilization, interface/tunnel traffic, etc. 9.2.4 Backup 9.2.4.1 Disaster Redundancy WANDL provide disaster redundancy through Solaris Rsync and MySQL Replication features. Users can manually startup the backup server when primary fails.

Figure 44: Disaster Redundancy

9.2.4.2 High Availability Through Jboss HA feature and Sun Clusters, WANDL system automatically startup the backup server to minimize the operation downtime. <Reference document: WANDL_HASolution.pdf>

can

even

VTN VN2 High Level Design

10 Conclusion
This section presents any conclusions arising from the proposed network design, as applicable.

VTN VN2 High Level Design

References.
Input Documents. [1] . .. - .

Output Documents [1] . .. - .

Other Documents [1] . .. - .

VTN VN2 High Level Design

Glossary
AAA AAL AAL1 AAL2 AAL3/4 AAL5 ACL AS ATM BCP BFD BGP CBR CE CES CIR COS CPM DHCP diff-serv DLCI DNS DSCP E-BGP FE FIB FR FRR FTP GE H-QOS I-BGP ICMP IGMP IGP IGRP ILMI IMA IOM IP IPCP IPSec IPv4 IPv6 Authorization Authentication and Accounting ATM Adaptation Layer ATM Adaptation Layer Type 1 ATM Adaptation Layer type 2 ATM Adaptation Layer Type 3/4 ATM Adaptation Layer type 5 Access Control List Autonomous System Asynchronous Transfer Mode Bridge Control Protocol Bi-directional Forwarding Detection Border Gateway Protocol Committed Bit Rate Customer Edge Circuit Emulation Service Committed Information Rate Class Of Service Control Process Module Dynamic Host Control Protocol Differentiated services Data Link Connection Identifier Domain Name Service DiffServ Code Point Exterior BGP Fast Ethernet Forwarding Information Base frame relay Fast Reroute File Transfer Protocol Gigabit Ethernet Hierarchical QOS Interior BGP Internet Control Message Protocol Internet Group Management Protocol Interior Gateway Protocol Interior Gateway Routing Protocol Interim Link Management Inverse Multiplexing on ATM Input/Output Module Internet Protocol Internet Protocol Control Protocol IP security IP version 4 IP version 6

VTN VN2 High Level Design

ISIS ISP IWF LACP LAN LDP LSP LSR MAC MP-EBGP MP-IBGP MPLS NNI NRT-VRB NSAP NTP OAM OOB OSPF PDU PE-node PIM PIM-SM PIM-SSM P-node POP POS PPP PVC QoS RADIUS RD RED RFC RIB RR RSTP RSVP RSVP-TE RT RTCP RTP RT-VBR SAP SDH SDP

Intermediate System to Intermediate System Internet Service Provider InterWorking Function Link Aggregation Control Protocol Local Area Network Label Distribution Protocol Link State PDU Label Switched Router Media Access Control Multi Protocol EBGP Multi Protocol IBGP Multiprotocol Label Switching Network to Network Interface Non Real Time Variable Bit Rate Network Service Access Point Network Time Protocol Operations Administration and Maintenance Out Of Band Open Shortest Path First Protocol Data Unit provider edge Protocol Independent Multicast PIM Sparse Mode PIM Source Specific Multicast provider Point Of Presence Packet Over Sonet Point-to-Point Protocol Permanent Virtual Circuit Quality of Service Remote Authentication Dial-In User Service Route Distinguisher Random Early Drop Request For Comments Routing Information Base Route Reflector Rapid STP Resource ReserVation Protocol RSVP Traffic Engineering Route Target Real Time Control Protocol Real Time Protocol Real Time Variable Bit Rate Service Access Point Synchronous Digital Hierarchy Service Distribution Point

VTN VN2 High Level Design

SF SIP SNMP SPF SSH STP TCP TLV UBR UDP UNI VC VCC VCI VLAN VLL VP VPC VPI VPLS VPN VPRN VRRP WRED

Switch Fabric Session Initiation Protocol Simple Network Management Protocol Shortest Path First Secure Shell Spanning Tree Protocol Transmission Control Protocol Type Length Value Unspecified Bit Rate User Datagram Protocol User to Network Interface Virtual Channel VC connection VC identifier Virtual Local Area Network Virtual Leased Line Virtual Path VP connection VP identifier virtual private LAN service virtual private network virtual private routed network Virtual Router Redundancy Protocol Weighted RED