UMMT 3.0 Implementation Guide - Large Network Multi-Area IGP Design With IPMPLS Access Design and...

7/18/2019 UMMT 3.0 Implementation Guide - Large Network Multi-Area IGP Design With IPMPLS Access Design and Implementation Guide

1/114

C I S C O C O N F I D E N T I A L

UMMT 3.0 Implementation Guide - LargeNetwork, Multi-Area IGP Design with IP/MPLS

Access

Design and Implementation Guide

SDU-6516

Version 1

Sept. 11, 2012

Americas Headquarters

Cisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 527-0883


2/114


Cisco Validated Design

The Cisco Validated Design Program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and

more predictable customer deployments. For more information visi t www.cisco.com/go/validateddesigns.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE

WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BEACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL

RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE

INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU

ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR

A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as

part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE

PROVIDED "AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED

OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL

DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE

OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH

DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of

Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners.

The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any

examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes

only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

UMMT 3.0 Implementation Guide - Large Network, Multi-Area IGP Design with IP/MPLS Access Design and Implementation Guide

1992-2012 Cisco Systems, Inc. All rights reserved.
http://www.cisco.com/go/validateddesigns


3/114

UMMT 3.0 Implementation Guide - Large Network, Multi-Area IGP Design with IP/MPLS Access DIG, v.1

SDU-6516 iii


C O N T E N T S

Preface ix

Document Version and System Release ix

Document Organization x

Obtaining Documentation, Obtaining Support, and Security Guidelines x

C H A P T E R 1 Introduction 1 - 1

C H A P T E R 2 Reference Topology 2 - 1

C H A P T E R 3 Unified MPLS Transport 3 - 1

3.1 Multi-Area IGP Design with Labeled BGP Access 3 - 1

3.1.1 Core Route Reflector Configuration 3 - 2

3.1.2 Mobile Transport Gateway Configuration 3 - 5

3.1.3 Core Area Border Router Configuration 3 - 8

3.1.4 Pre-Aggregation Node Configuration 3 - 12

3.1.5 Cell Site Gateway Configuration 3 - 16

3.2 Multi-Area IGP Design with IGP/LDP Access 3 - 18

3.2.1 Pre-Aggregation Node Configuration 3 - 20

3.2.2 Cell Site Gateway Configuration 3 - 25

C H A P T E R 4 Services 4 - 1

4.1 L3 MPLS VPN Service Model for LTE 4 - 1

4.1.1 MPLS VPN Transport for LTE S1 and X2 Interfaces 4 - 1

4.1.2 MPLS VPN Control Plane 4 - 5

4.2 L2 MPLS VPN Service Model for 2G and 3G 4 - 9

4.2.1 CESoPSN VPWS Service from CSG to MTG 4 - 9

4.2.2 SAToP VPWS Service from PAN to MTG 4 - 12

4.2.3 ATM Clear-channel VPWS Service from PAN to MTG 4 - 15

4.2.4 ATM IMA VPWS Service from PAN to MTG 4 - 18

4.3 Fixed-Mobile Convergence Use Case 4 - 20


4/114

Contents



iv SDU-6516

C H A P T E R 5 Synchronization Distribution 5 - 1

5.1 Hybrid Model Configuration 5 - 1

C H A P T E R 6 High Availability 6 - 1

6.1 Transport Network High Availability 6 - 1

6.1.1 Loop-Free Alternate Fast Reroute with BFD 6 - 1

6.1.2 BGP Fast Reroute 6 - 5

6.1.3 Multihop BFD for BGP 6 - 6

6.2 Service High Availability 6 - 8

6.2.1 MPLS VPN- BGP FRR Edge Protection and VRRP 6 - 8

6.2.2 Pseudowire Redundancy for ATM and TDM services 6 - 10

C H A P T E R 7 Quality of Service 7 - 1

C H A P T E R 8 Operations, Administration, and Maintenance 8 - 1

8.1 IP SLA Implementation 8 - 3

C H A P T E R 9 Related Documents 9 - 1


5/114


SDU-6516 v


F I G U R E S

Figure 1-1 UMMT Transport Models 1 - 1

Figure 2-1 Reference Topology - Large Network, Multi-Area IGP-based Design 2 - 1

Figure 3-1 Unified MPLS Transport for Multi-Area IGP Design with Labeled BGP Access 3 - 1

Figure 3-2 Centralized Core Route Reflector (CN-RR) 3 - 3

Figure 3-3 Mobile Transport Gateway (MTG) 3 - 6

Figure 3-4 Core Area Border Router (CN-ABR) 3 - 9

Figure 3-5 Pre-Aggregation Node (PAN) 3 - 12

Figure 3-6 Cell Site Gateway (CSG) 3 - 16

Figure 3-7 Unified MPLS Transport for Multi-Area IGP Design with IGP/LDP Access 3 - 19

Figure 3-8 Pre-Aggregation Node (PAN) 3 - 20

Figure 3-9 Cell Site Gateway (CSG) 3 - 25

Figure 4-1 MPLS VPN Service Implementation for LTE Backhaul 4 - 1

Figure 4-2 BGP Control Plane for MPLS VPN Service 4 - 5

Figure 4-3 CESoPSN Service Implementation for 2G and 3G Backhaul 4 - 9

Figure 4-4 SAToP VPWS Service Implementation for 2G Backhaul 4 - 12

Figure 4-5 ATM VPWS Service Implementation for 3G Backhaul 4 - 15


Figure 5-1 Test Topology 5 - 2Figure 6-1 Multihop BFD Topology 6 - 7

Figure 6-2 CESoPSN/SAToP Service Implementation for 2G and 3G Backhaul 6 - 11


Figure 7-1 QoS Enforcement Points 7 - 1

Figure 8-1 OAM implementation for Mobile RAN Service Transport 8 - 1


6/114



vi SDU-6516


7/114


SDU-6516 vii


T A B L E S

Table i-1 Document Version i - ix

Table i-2 Document Organization i - x

Table 1-1 Approaches for Extending the Unified MPLS LSP 1 - 2

Table 5-1 Connectivity Table 5 - 2


8/114



viii SDU-6516


9/114


SDU-6516 ix


Preface

This implementation guide is for Large Network, Multi-Area IGP Design with IP/MPLS Access for

UMMT 3.0.

The huge growth in mobile data trafficis challenging legacy network infrastructure capabilities and

forcing transformation of mobile transport networks. Until now, mobile backhaul networks have been

composed of a mixture of many legacy technologies that are operationally complex and have reached

the end of their useful life. The market inflection point for mobile backhaul is introduction of 4G/

LTE. The majority of deployments require concurrent legacy (2G/3G radio) backhaul support whilegracefully introducing long term evolution (LTE) to the service mix, along with virtualization of the

packet transport to deliver multiple services.

The Unified MPLS Mobile Transport (UMMT) System is a comprehensive RAN backhaul solution

that forms the foundation for LTE backhaul,while integrating components necessary for continued

support of legacy 2G GSM and existing 3G UMTS transport services. The UMMT System enables a

comprehensive and flexible framework that integrates key technologies from Cisco's Unified MPLS

suite of technologies to deliver a highly scalable and simple-to-operate MPLS-basedRAN backhaul

network.

This preface includes the following major topics:

Document Version and System Release

Document Organization

Obtaining Documentation, Obtaining Support, and Security Guidelines

Document Version and System ReleaseThis is the UMMT System Release 3.0 Large Network, Multi-Area IGP Design with IP/MPLS Access

Implementation Guide.

Document Version

Table i-1lists document version information.

Table i-1. Document Version

Document Version Date Notes

1 9/11/2012 Initial release.

System Release


10/114

Preface

Document Organization



x SDU-6516

UMMT System Release 3.0 covers Unified MPLS for Mobile Transport supporting LTE and the

introduction of ASR 901.

Document OrganizationThe chapters in this document are described in Table i-2.

Table i-2. Document Organization

Chapter Major Topics

Chapter 1, Introduction Introduction to Large Network, Multi-Area IGP Design with IP/

MPLS Access in the UMMT System.

Chapter 2, Reference

Topology

Describes the UMMT 3.0 reference topology for the Large Network,

Multi-Area IGP Design with IP/MPLS Access transport model.

Chapter 3, Unified MPLS

Transport

Includes Multi-Area IGP Design with Labeled BGP Access and

Multi-Area IGP Design with IGP-LDP Access configurations for the

UMMT System.

Chapter 4, Services Describes the services associated with the Large Network, Multi-

Area IGP Design with IP/MPLS Access transport model.

Chapter 5, Synchronization

Distribution

Includes configurations for the hybrid model (SyncE and IEEE

1588v2) in the UMMT System.

Chapter 6, High

Availability

Describes high availability for this transport model at the transport

network level and the service level.

Chapter 7, Quality of

Service

Includes QoS configurations for the UMMT System.

Chapter 8, Operations,

Administration, and

Maintenance

Describes the IP SLA implementation in the UMMT System.

Chapter 9, Related

Documents

Describes and provides links for all UMMT 3.0-related collateral.

Obtaining Documentation, Obtaining Support, and SecurityGuidelines

Specific information about UMMT can be obtained at the following locations:

Cisco ASR 901 Series Aggregation Services Routers: http://www.cisco.com/en/US/products/

ps12077/index.html


ps11610/index.html

Cisco ME 3800X Series Carrier Ethernet Switch Routers: http://www.cisco.com/en/US/products/

ps10965/index.html


ps9853/index.html

Cisco Carrier Routing System: http://www.cisco.com/en/US/products/ps5763/index.html
http://www.cisco.com/en/US/products/ps5763/index.htmlhttp://www.cisco.com/en/US/products/ps9853/index.htmlhttp://www.cisco.com/en/US/products/ps9853/index.htmlhttp://www.cisco.com/en/US/products/ps10965/index.htmlhttp://www.cisco.com/en/US/products/ps10965/index.htmlhttp://www.cisco.com/en/US/products/ps11610/index.htmlhttp://www.cisco.com/en/US/products/ps11610/index.htmlhttp://www.cisco.com/en/US/products/ps12077/index.htmlhttp://www.cisco.com/en/US/products/ps12077/index.html


11/114

Preface



SDU-6516 xi

For information on obtaining documentation, submitting a service request, and gathering additional

information, see the monthly What's New in Cisco Product Documentation, which also lists all new

and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS)

feed and set content to be delivered directly to your desktop using a reader application. The RSS feedsare a free service and Cisco currently supports RSS version 2.0.
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html


12/114

Preface



xii SDU-6516


13/114


SDU-6516 1-1


C H A P T E R 1Introduction

The UMMT System provides the architectural baseline for creating a scalable, resilient, and

manageable mobile backhaul infrastructure that is optimized to seamlessly interwork with the MPC.

The system is designed to concurrently support multiple generations (2G/3G/4G) of mobile services

on a single converged network infrastructure. The system supports graceful introduction of LTE with

existing 2G/3G services with support for pseudowire emulation (PWE) for 2G GSM and 3G UMTS/ATM transport, L2VPNs for 3G UMTS/IP, and L3VPNs for 3G UMTS/IP and 4G LTE transport. It

supports essential features like network synchronization (physical layer and packet based), H-QoS,

OAM, performance management, and fast convergence. It is optimized to cater to:

Advanced 4G requirements like IPSec and authentication.

Direct eNodeB communication through the X2 interface.

Multicast for optimized video transport.

Virtualization for RAN sharing.

Capability of distributing the EPC gateways.

Traffic offload.

Figure 1-1. UMMT Transport Models

As described in the UMMT 3.0 Design Guide, the transport architecture structuring based on access

type and network size leads to five architecture models that fit various customer deployments and

operator preferences. This implementation guide of the UMMT System covers the transport model for

a Large Network, Multi-Area IGP-based design with an IP/MPLS Access Network, and presents

two approaches for extending the unified MPLS LSP into the mobile RAN access domain.
http://spsu-nsite.cisco.com/publications/viewdoc.php?docid=6432


14/114

Chapter 1 Introduction



1-2 SDU-6516

Table 1-1. Approaches for Extending the Unified MPLS LSP

Option Description

Option-1: Multi-Area IGP

Design with Labeled BGP

Access

Utilizes a separate IGP area or level for the access domain, and

extends the labeled BGP control plane to the Cell Site Gateway

(CSG). This model is developed for operators that wish to employ asingle control plane end-to-end for mobile service transport.

Option-2: Multi-Area IGP

Design with IGP/LDP

Access

Utilizes a separate IGP process for the access domain, and

redistributes selected prefixes between this IGP and BGP at the pre-

aggregation node (PAN). The labeled BGP control plane extends

only to the PAN. This model is developed for operators that, due to

operational factors, wish to deploy a transport network in this fashion

for mobile service transport.


15/114


SDU-6516 2-1


C H A P T E R 2Reference Topology

The network design follows a Unified MPLS Transport implementation where the organization

between the core and aggregation domains is based on a single autonomous system, multi-area IGP

design.

Figure 2-1shows a detailed view of Metro-1 with access and aggregation domains interfacing with the

core network.

Figure 2-1. Reference Topology - Large Network, Multi-Area IGP-based Design

In the core network, the mobile transport gateways (MTG) are provider edge (PE) devices terminating

MPLS VPNs and/or AToM pseudowires to provide connectivity to the EPC gateways (SGW, PGW,

MME) in the MPC. At each core PoP, the core nodes (CN-ABR) are area border routers (ABR)


16/114


17/114


SDU-6516 3-1


C H A P T E R 3Unified MPLS Transport

This chapter includes the following major topics:

Section 3.1 Multi-Area IGP Design with Labeled BGP Access

Section 3.2 Multi-Area IGP Design with IGP/LDP Access

3.1 Multi-Area IGP Design with Labeled BGP AccessThis option assumes an end-to-end labeled BGP transport where the access, aggregation, and core

networks are integrated with unified MPLS LSPs by extending labeled BGP from the core all the

way to the CSGs in the RAN access. Any node in the network that requires inter-domain LSPs to

reach nodes in remote domain acts as a labeled BGP PE and runs iBGP IPv4 unicast+label with its

corresponding local route reflectors (RR).

Figure 3-1. Unified MPLS Transport for Multi-Area IGP Design with Labeled BGP Access

The CN-ABRs are labeled BGP ABRs between the core and aggregation domains. They peer

with iBGP labeled-unicast sessions with the centralized core route reflector (CN-RR) in the core

network, and act as inline-RRs for their local aggregation network PAN clients. The CN-ABRs insert

themselves into the data path to enable inter-domain LSPs by setting next-hop-self (NHS) on all

iBGP updates towards the CN-ABR in core network and their local aggregation network PAN clients.

The MTGs residing in the core network are labeled BGP PEs. They peer with iBGP labeled-unicast


18/114

Chapter 3 Unified MPLS Transport

3.1.1 Core Route Reflector Configuration



3-2 SDU-6516

sessions with the CN-RR, and advertise their loopbacks into iBGP labeled-unicast with a common

BGP community (MPC BGP community) representing the MPC.

The PANs are labeled BGP ABRs between the aggregation and RAN access domains. They peer with

iBGP labeled-unicast sessions with the higher level CN-ABR inline-RRs in the aggregation network,

and act as inline-RRs for their local RAN access network CSG clients. All the PANs in the aggregation

network that require inter-domain LSPs to reach remote PANs in another aggregation network, or

the core network (to reach the MTGs, for example), also act as labeled BGP PEs and advertise theirloopbacks into BGP labeled-unicast with a common BGP community that represents the aggregation

community. The PANs learn labeled BGP prefixes marked with the aggregation BGP community and

the MPC BGP community. The PANs insert themselves into the data path to enable inter-domain LSPs

by setting NHS on all iBGP updates towards the higher level CN-ABR inline-RRs and their local RAN

access CSG clients.

The CSGs in the RAN access networks are labeled BGP PEs. They peer with iBGP-labeled unicast

sessions with their local PAN inline-RRs. The CSGs advertise their loopbacks into BGP-labeled

unicast with a common BGP community that represents the RAN access community. They learn

labeled BGP prefixes marked with the MPC BGP community for reachability to the MPC, and the

adjacent RAN access BGP community if inter-access X2 connectivity is desired.

The MTGs in the core network are capable of handling large scale and will learn all BGP-labeledunicast prefixes since they need connectivity to all the CGSs in the entire network. As described

above, since all prefixes are colored withBGP Communities, prefix filtering is performed on the

CN-RRs for constraining IPv4+label routes from remote RAN access regions from proliferating into

neighboring aggregation domains where they are not needed. The PANs only learn labeled BGP

prefixes marked with the aggregation BGP community and the MPC BGP community. This allows the

PANs to enable inter-metro wireline services across the core, and also reflect the MPC prefix to their

local access networks. Isolating the aggregation and RAN access domain by preventing the default

redistribution enables the mobile access network to have limited route scale, since the CSGs only learn

local IGP routes and labeled BGP prefixes marked with the MPC BGP community.

This section includes the following topics:

Section 3.1.1 Core Route Reflector Configuration Section 3.1.2 Mobile Transport Gateway Configuration

Section 3.1.3 Core Area Border Router Configuration

Section 3.1.4 Pre-Aggregation Node Configuration

Section 3.1.5 Cell Site Gateway Configuration

3.1.1 Core Route Reflector Configuration

This section shows the IGP/LDP configuration required to build intra-domain LSPs and the BGP

configuration required to build the inter-domain LSPs on the centralized CN-RR.


19/114




SDU-6516 3-3

Figure 3-2. Centralized Core Route Reflector (CN-RR)

Interface Configuration

interface Loopback0

description Global Loopback

ipv4 address 100.111.4.3 255.255.255.255!

interface GigabitEthernet0/1/0/0


20/114




3-4 SDU-6516

ispf

spf-interval maximum-wait 5000 initial-wait 50 secondary-wait 200

!

interface Loopback0

passive

address-family ipv4 unicast

!

!

interface GigabitEthernet0/1/0/0


21/114


3.1.2 Mobile Transport Gateway Configuration



SDU-6516 3-5

address-family vpnv4 unicast

!

!

neighbor-group cn-abr


22/114




3-6 SDU-6516

Figure 3-3. Mobile Transport Gateway (MTG)


interface Loopback0


ipv4 address 100.111.15.1 255.255.255.255

!

interface TenGigE0/0/0/0

description To CN-K0201 Ten0/0/0/0


23/114




SDU-6516 3-7

ispf

spf-interval maximum-wait 5000 initial-wait 50 secondary-wait 200

!

interface Loopback0

passive

point-to-point


!

!


circuit-type level-2-only

bfd minimum-interval 15

bfd multiplier 3

bfd fast-detect ipv4

point-to-point


fast-reroute per-prefix

mpls ldp sync

!

!


circuit-type level-2-only

bfd minimum-interval 15

bfd multiplier 3

bfd fast-detect ipv4

point-to-point


mpls ldp sync

!

!

mpls ldp

router-id 100.111.15.1

discovery targeted-hello accept

nsr

graceful-restart

session protection

log

neighbor

graceful-restart session-protection

nsr

!


!


!

!

BGP Configuration

router bgp 100

nsr

bgp router-id 100.111.15.1

bgp redistribute-internal

bgp graceful-restart

ibgp policy out enforce-modifications


additional-paths receive


24/114


3.1.3 Core Area Border Router Configuration



3-8 SDU-6516

session-group infra

remote-as 100

password encrypted 011F0706

update-source Loopback0

!

neighbor-group cn-rr

use session-group infra

address-family ipv4 labeled-unicast

maximum-prefix 150000 85 warning-only

next-hop-self

!


!

!

neighbor 100.111.4.3


25/114




SDU-6516 3-9

Figure 3-4. Core Area Border Router (CN-ABR)


!

interface Loopback0

ipv4 address 100.111.10.1 255.255.255.255

!



26/114




3-10 SDU-6516

propagate level 1 into level 2 route-policy drop-all


27/114




SDU-6516 3-11

router bgp 100

nsr


bgp cluster-id 1001


28/114


3.1.4 Pre-Aggregation Node Configuration



3-12 SDU-6516

!

!

route-policy CN_ABR_Community

set community CN_ABR_Community

end-policy

!

community-set CN_ABR_Community 1000:1000

end-set

!


This section shows the IGP/LDP configuration required to build the intra-domain LSPs, and the

BGP configuration required to build the inter-domain LSPs in the aggregation network. The PANs

are ABRs between the aggregation and RAN access domains. The segmentation between the two

domains is achieved by enabling two different IGP processes on the PANs. The first process is the

core/aggregation IGP process, and the second process is another independent RAN IGP process. All

CSGs subtending from the same pair of PANs are part of this RAN IGP process.

Figure 3-5. Pre-Aggregation Node (PAN)


!

interface Loopback0


29/114




SDU-6516 3-13

ip router isis core-agg

mpls ip

synchronous mode

bfd interval 50 min_rx 50 multiplier 3

isis network point-to-point

!

interface TenGigabitEthernet0/2


30/114




3-14 SDU-6516

net 49.0100.1001.1100.9007.00

is-type level-1


31/114




SDU-6516 3-15

!

router bgp 100


bgp cluster-id 907

bgp log-neighbor-changes

bgp graceful-restart restart-time 120

bgp graceful-restart stalepath-time 360

bgp graceful-restart

no bgp default ipv4-unicast

neighbor csg peer-group


32/114


3.1.5 Cell Site Gateway Configuration



3-16 SDU-6516

set community 100:100 100:101


33/114




SDU-6516 3-17

bridge-domain 10

!

interface GigabitEthernet0/11


34/114


3.2 Multi-Area IGP Design with IGP/LDP Access



3-18 SDU-6516




neighbor pan peer-group

neighbor pan remote-as 100

neighbor pan password lab

neighbor pan update-source Loopback0

neighbor 100.111.9.7 peer-group pan


!

address-family ipv4

network 100.111.13.18 mask 255.255.255.255 route-map CSG_Community


35/114




SDU-6516 3-19

Figure 3-7. Unified MPLS Transport for Multi-Area IGP Design with IGP/LDP Access

The CN-ABRs are labeled BGP ABRs between the core and aggregation domains. They peer withiBGP labeled-unicast sessions with the CN-RR in the core network, and act as inline-RRs for their

local aggregation network PAN clients. The CN-ABRs insert themselves into the data path to enable

inter-domain LSPs by setting next-hop-self on all iBGP updates towards the CN-ABR in core

network and their local aggregation network PAN clients. The MTGs residing in the core network

are labeled BGP PEs. They peer with iBGP labeled-unicast sessions with the CN-RR, and advertise

their loopbacks into iBGP labeled-unicast with a common BGP community (MPC BGP community)

representing the mobile packet core.

All the PANs in the aggregation network that require inter-domain LSPs to reach remote PANs in

another aggregation network, or the core network (to reach the MTGs, for example), act as labeled

BGP PEs and peer with iBGP labeled-unicast sessions with the higher level CN-ABR inline-RRs.

The PANs advertise their loopbacks into BGP labeled-unicast with a common BGP community that

represents the aggregation community. They learn labeled BGP prefixes marked with the aggregationBGP community and the MPC BGP community.

The inter-domain LSPs are extended to the MPLS/IP RAN access with a controlled redistribution

based on IGP tags and BGP communities. Each mobile access network subtending from a pair of

PANs is based on a different IGP process. At the PANs, the inter-domain core and aggregation LSPs

are extended to the RAN access by redistributing between iBGP and RAN IGP. In one direction,

the RAN access node loopbacks (filtered based on IGP tags) are redistributed into iBGP labeled-

unicast and tagged with RAN access BGP community that is unique to that RAN access region. In the

other direction, the MPC prefixes filtered based on MPC-marked BGP communities, and optionally,

adjacent RAN access prefixes filtered based on RAN-region-marked BGP communities (if inter-access

X2 connectivity is desired), are redistributed into the RAN access IGP process.

The MTGs in the core network are capable of handling large scale and will learn all BGP-labeledunicast prefixes since they need connectivity to all the CGSs in the entire network. Simple prefix

filtering based on BGP communities is performed on the CN-RRs for constraining IPv4+label routes

from remote RAN access regions from proliferating into neighboring aggregation domains, where

they are not needed. The PANs only learn labeled BGP prefixes marked with the aggregation BGP

community and the MPC BGP community. This allows the PANs to enable inter metro Wireline

services across the core, and also redistribute the mobile packet core prefix to their local access

networks. Using a separate IGP process for the RAN access enables the mobile access network to

have limited control plane scale, since the CSGs only learn local IGP routes and labeled BGP prefixes

marked with the MPC BGP community.


36/114





3-20 SDU-6516

Note The network infrastructure organization of this model at the top layers of network (namely, the core

and aggregation domains) is identical to that defined in Section 3.1 Multi-Area IGP Design with

Labeled BGP Access. The difference here is that labeled BGP spans only the core and aggregation

networks and does not extend to the RAN access. Instead, the end-to-end unified MPLS LSP is

extended into the RAN access with selective redistribution between labeled BGP and the RAN access

domain IGP at the PAN. Please refer to the Multi-Area IGP Design with Labeled BGP Access section

for configuration details on the Core Route Reflector, Mobile Transport Gateway, and Core Area

Border Routersince the same configuration is also applied to this model.

This section includes the following major topics:

Section 3.2.1 Pre-Aggregation Node Configuration

Section 3.2.2 Cell Site Gateway Configuration


This section shows the IGP/LDP configuration required to build the intra-domain LSPs, and the BGP

configuration required to build the inter-domain LSPs in the aggregation network. The segmentation

between the aggregation and RAN access domains is achieved by enabling two different IGP processes

on the PANs. The first process is the core/aggregation IGP process, and the second process is another

independent RAN IGP process. All CSGs subtending from the same pair of PANs are part of this RAN

IGP process.

Figure 3-8. Pre-Aggregation Node (PAN)


!

interface Loopback0


37/114




SDU-6516 3-21

mpls ldp router-id Loopback0 force

!

interface TenGigabitEthernet0/1


38/114




3-22 SDU-6516

Note PAN K0907's LDP ID Loopback0 is in the core-aggregation IS-IS process and not in the RAN IS-IS

IGP process. The command mpls ldp discovery transport-address 100.111.99.7, changes the transport

address to Loopback100 for LDP discovery out of the RAN access ring-facing interface G0/1.

Core-Aggregation LDP/IGP Process Configuration

router isis core-agg

net 49.0100.1001.1100.9007.00

is-type level-1


39/114




SDU-6516 3-23

ip community-list standard EPC_Community permit 1001:1001


40/114




3-24 SDU-6516

deny 100.111.13.0 0.0.0.255

deny 10.0.0.0 0.255.255.255

permit any

Note Since we are dealing with a ring access network, we have a dual redistribution scenario between the

aggregation network iBGP and the RAN IGP. In such a situation, even though the MPC prefixes arelearned via iBGP on the PANs, the lower admin distance leads to the IGP routes being preferred over

iBGP routes. Unlike OSPF, IS-IS does not support inbound filtering using route maps with a distribute

list. The solution is to bump up the IGP admin distance based on the IGP originator address for the

IBGP to RAN IGP-redistributed prefixes.

BGP Configuration

!

router bgp 100


bgp cluster-id 907


bgp graceful-restart restart-time 120

bgp graceful-restart stalepath-time 360bgp graceful-restart


neighbor csg peer-group


41/114


3.2.2 Cell Site Gateway Configuration



SDU-6516 3-25

!

route-map AGG_Community permit 10


42/114




3-26 SDU-6516

!

interface Loopback0

ip address 100.111.13.18 255.255.255.255

isis tag 10


43/114




SDU-6516 3-27

no hello padding

log-adjacency-changes

passive-interface Loopback0

bfd all-interfaces


44/114




3-28 SDU-6516


45/114


SDU-6516 4-1


C H A P T E R 4Services

This chapter includes the following major topics:

Section 4.1 L3 MPLS VPN Service Model for LTE

Section 4.2 L2 MPLS VPN Service Model for 2G and 3G

Section 4.3 Fixed-Mobile Convergence Use Case

4.1 L3 MPLS VPN Service Model for LTEThis section includes the following topics:

Section 4.1.1 MPLS VPN Transport for LTE S1 and X2 Interfaces

Section 4.1.2 MPLS VPN Control Plane

4.1.1 MPLS VPN Transport for LTE S1 and X2 Interfaces

This section describes the L3VPN configuration aspects on the CSGs in the RAN access, and the

MTGs in the core network required for implementing the LTE backhaul service for X2 and S1

interfaces.

Figure 4-1. MPLS VPN Service Implementation for LTE Backhaul

CSG MPLS VPN Configuration


46/114

Chapter 4 Services



4-2 SDU-6516

The MPLS VPN configuration on the CSGs, which is minimal, is the same on all CSGs in a given

RAN region. The configuration shown includes the required commands to enable BGP PIC protection

support for MPLS VPNs.

eNodeB UNI Interface



47/114

Chapter 4 Services



SDU-6516 4-3

Note The above route target 10:101 implies that this is a CSG in metro-1, RAN access region-1. Similarly,

the route target 10:103 implies that this is a CSG in metro-1, RAN access region-3. Please refer

to the "L3 MPLS VPN Service Model for LTE" section in the UMMT 3.0 Design Guidefor a

detailed explanation of how inter-access X2 communication is enabled with labeled BGP using BGP

communities.

PAN BGP Configuration

The following BGP configuration is required on the PANs to facilitate BGP PIC resiliency for MPLS

VPNs.

router bgp 1000

!

address-family ipv4

bgp additional-paths receive

bgp additional-paths install

bgp nexthop trigger delay 0

!

address-family vpnv4

bgp additional-paths install bgp nexthop trigger delay 1

(Optional) PAN MPLS VPN Configuration

The following MPLS VPN configuration on the PANs is optional, and is only required in deployments

where there are cell sites close to the pre-aggregation network with eNBs directly connected to the

PANs at the CO.

eNodeB UNI Interface

interface GigabitEthernet0/3/6

vrf forwarding LTE2

ip address 114.1.23.1 255.255.255.0

load-interval 30negotiation auto

ipv6 address 2001:114:1:23::1/64

end

VRF Definition

vrf definition LTE2

rd 1111:1111

!

address-family ipv4

export map ADDITIVE

route-target export 10:101

route-target import 10:101


exit-address-family!

address-family ipv6

export map ADDITIVE

route-target export 10:101



exit-address-family

Route map to export common RT 1111:1111 in addition to Local RAN RT 10:101

!


48/114

Chapter 4 Services



4-4 SDU-6516

route-map ADDITIVE permit 10

set extcommunity rt 1111:1111 additive

!

VPNv4/v6 BGP Configuration

!

router bgp 100bgp router-id 100.111.14.1

!

address-family ipv4 vrf LTE2

redistribute connected

exit-address-family

!

address-family ipv6 vrf LTE2


exit-address-family

Mobile Transport Gateway MPLS VPN Configuration

This is a one-time MPLS VPN configuration done on the MTGs. No modifications are made when

additional CSGs in any RAN access or other MTGs are added to the network.

SAE GW UNI Interface

interface TenGigE0/0/0/2.1100

description Connected to SAE Gateway.

vrf LTE2

ipv4 address 115.1.23.3 255.255.255.0

ipv6 nd dad attempts 0

ipv6 address 2001:115:1:23::3/64

encapsulation dot1q 1100

VRF Definition

vrf LTE2address-family ipv4 unicast

import route-target

1111:1111


49/114

Chapter 4 Services

4.1.2 MPLS VPN Control Plane



SDU-6516 4-5

vrf LTE2



!



!

MTG 2 VPNv4/v6 BGP Configuration

router bgp 100


!

vrf LTE2



!



!

Note This version of the UMMT System release supports v6 MPLS VPNs using 6VPE functionality as

defined in RFC 4659 only on the ASR 903 PAN and ASR 9000 MTG. 6VPE will be supported on the

ASR 901, ME3800X and ME3600X-24CX platforms in the next system release.

4.1.2 MPLS VPN Control Plane

This section describes the BGP control plane aspects for the VPNv4 LTE backhaul service.

Figure 4-2. BGP Control Plane for MPLS VPN Service

CSG LTE VPNv4 PE Configuration

router bgp 100




50/114

Chapter 4 Services



4-6 SDU-6516

neighbor pan send-community extended

neighbor 100.111.14.1 activate


exit-address-family

!

address-family rtfilter unicast


51/114

Chapter 4 Services



SDU-6516 4-7

router bgp 100


!



52/114

Chapter 4 Services



4-8 SDU-6516

...

!


route-reflector-client

route-policy BGP_Egress_RAN_Filter out

!


route-reflector-client

route-policy BGP_Egress_RAN_Filter out

!

!


use neighbor-group cn-abr

!



!

neighbor 100.111.10.1


!

neighbor 100.111.10.2


!

neighbor 100.111.15.1

use neighbor-group mtg

!

neighbor 100.111.15.2

use neighbor-group mtg

route-policy BGP_Egress_RAN_Filter

if extcommunity rt matches-any Deny_RAN_Community then

drop

else

pass

endif

end-policy

extcommunity-set rt Deny_RAN_Community

1111:1111

end-set

Note Please refer to the "Prefix Filtering" section in the UMMT 3.0 Design Guidefor a detailed explanation

of how egress filtering is done at the CN-RR for constraining VPN routes from remote RAN access

regions.

MTG LTE VPNv4/v6 PE Configuration

router bgp 100


!


use session-group intra-as

...

!


!


!

!


use neighbor-group cn-rr


53/114

Chapter 4 Services

4.2 L2 MPLS VPN Service Model for 2G and 3G



SDU-6516 4-9

!

Note This version of the UMMT System release supports v6 MPLS VPNs using 6VPE functionality, as

defined in RFC 4659 only on the ASR 903 PAN and ASR 9000 MTG. 6VPE will be supported on the

ASR 901, ME3800X and ME3600X-24CX platforms in the next system release.

4.2 L2 MPLS VPN Service Model for 2G and 3GLayer 2 MPLS VPN service models provide TDM Circuit Emulation Services (CES) for 2G backhaul

and ATM CES for 3G backhaul. The following services were validated as part of UMMT 3.0:

TDM backhaul from the CSG to the MTG, utilizing the structured CESoPSN mechanism

TDM backhaul from the PAN to the MTG, utilizing the unstructured SAToP mechanism

ATM backhaul from the PAN to the MTG, supporting both ATM clear-channel and ATM IMA

circuits.

This section includes the following topics:

Section 4.2.1 CESoPSN VPWS Service from CSG to MTG

Section 4.2.2 SAToP VPWS Service from PAN to MTG

Section 4.2.3 ATM Clear-channel VPWS Service from PAN to MTG

Section 4.2.4 ATM IMA VPWS Service from PAN to MTG

4.2.1 CESoPSN VPWS Service from CSG to MTG

Circuit Emulation Services over Packet Switched Network (CESoPSN) provides structured

transport of TDM circuits down to the DS0 level across an MPLS-based backhaul architecture. The

configurations for the CSG and MTGs are outlined in this section, including an illustration of basic

backup pseudowire configuration on the CSG to enable transport to redundant MTGs. Complete highavailability configurations are available in the Service High Availabilitysection.

Figure 4-3. CESoPSN Service Implementation for 2G and 3G Backhaul


54/114

Chapter 4 Services



4-10 SDU-6516

Note Regarding the example shown:

ASR 901 Motherboard with built-in 12GE, 1FE, 16T1E1 (A901-12C-FT-D) is used to create

CEM interface for TDM pseudowire.

Both ASR 9000 MTGs utilize 1-port channelized OC3/STM-1 ATM and circuit emulation SPA

(SPA-1CHOC3-CE-ATM) in a SIP-700 card for the TDM interfaces.

CESoPSN encapsulates T1/E1 structured (channelized) services. Structured mode (CESoPSN)

identifies framing and sends only payload, which can be channelized T1s within DS3 and DS0s

within T1. DS0s can be bundled to the same packet. This mode is based on IETF RFC 5086.

"MPLS LDP discovery targeted-hello accept" is required because of its LDP session via PW

tunnel between PEs are not directly connected and targeted-hello response is not configured so

both sessions will be showing as passive, which is normal.

ASR 901 Cell Site Gateway Configuration

card type t1 0 0

!

controller T1 0/0

framing esf

linecode b8zs

cablelength short 133

cem-group 0 timeslots 1-24

!

pseudowire-class CESoPSN

encapsulation mpls

control-word

!

!

interface CEM0/0

no ip address

load-interval 30

cem 0

xconnect 100.111.15.1 13261501 encapsulation mpls pw-class CESoPSN

backup peer 100.111.15.2 13261502 pw-class CESoPSN

!

hold-queue 4096 in

hold-queue 4096 out

!

interface Loopback0

ip address 100.111.13.26 255.255.255.255

isis tag 10

!

router isis agg-acc


!

!

mpls ldp discovery targeted-hello accept

!#

!# ISIS and BGP related configuration needed to ensure MPLS LDP binding with remote PE

so as to establish AToM PW

!#

ASR 9000 Mobile Transport Gateway Configuration

The other MTG configuration is identical, except with a Loopback 0 IP address of 100.111.15.2, and

an pw-id of 13261502.

hw-module subslot 0/2/1 cardtype sonet

!


55/114

Chapter 4 Services



SDU-6516 4-11

controller SONET0/2/1/0

description To ONS15454-K1410 OC3 port 4/1

ais-shut

report lais

report lrdi

sts 1

mode vt15-t1

delay trigger 250

!

clock source line

!

controller T1 0/2/1/0/1/1/3

cem-group framed 0 timeslots 1-24

forward-alarm AIS

forward-alarm RAI

clock source line

!

interface CEM0/2/1/0/1/1/3:0

load-interval 30

l2transport

!

!

interface Loopback0


ipv4 address 100.111.15.1 255.255.255.255

!

l2vpn

!

pw-class CESoPSN

encapsulation mpls

control-word

!

!

xconnect group TDM-K1326

p2p T1-CESoPSN-01

interface CEM0/2/1/0/1/1/3:0

neighbor 100.111.13.26 pw-id 13261501

pw-class CESoPSN

!

!!

!

router isis core

!

interface Loopback0

passive

point-to-point


!

!

router bgp 1000



network 100.111.15.1/32 route-policy MTG_Community

!

mpls ldprouter-id 100.111.15.1


!

!#



!#


56/114

Chapter 4 Services

4.2.2 SAToP VPWS Service from PAN to MTG



4-12 SDU-6516

4.2.2 SAToP VPWS Service from PAN to MTG

Structure-Agnostic Time Division Multiplexing over Packet (SAToP) provides unstructured transport

of TDM circuits across an MPLS-based backhaul architecture. The configurations for the PAN and

MTGs are outlined in this section, including an illustration of backup pseudowire configuration on the

PAN to enable transport to redundant MTGs.

Figure 4-4. SAToP VPWS Service Implementation for 2G Backhaul

Note Regarding the example shown:

ASR 903 utilizes a 16 port T1/E1 Interface Module (A900-IMA16D) for TDM interfaces.

ME 3600X 24CX utilizes on-board T1/E1 interfaces.

Both ASR 9000 MTGs utilize 1-port channelized OC3/STM-1 ATM and circuit emulation SPA

(SPA-1CHOC3-CE-ATM) in a SIP-700 card for the TDM interfaces.

SAToP encapsulates T1/E1 services, disregarding any structure that may be imposed on these

streams, in particular the structure imposed by the standard TDM framing. This mode is based on

IETF RFC 4553.


tunnel between PEs are not directly connected and targeted-hello response is not configured, so


ASR 903 Pre-Aggregation Node Configuration

card type t1 0 5

!

controller T1 0/5/0

framing unframed

clock source internal

linecode b8zs


cem-group 0 unframed

!

pseudowire-class SAToP

encapsulation mpls

control-word

!

!

interface CEM0/5/0

no ip address

load-interval 30

cem 0

xconnect 100.111.15.1 14011501 encapsulation mpls pw-class SAToP

backup peer 100.111.15.2 14011502 pw-class SAToP

!

hold-queue 4096 in

hold-queue 4096 out

!


57/114

Chapter 4 Services



SDU-6516 4-13

interface Loopback0

ip address 100.111.14.1 255.255.255.255

!

!

router isis agg-acc


!

!


!#



!#

ME 3600X 24CX Pre-Aggregation Node Configuration

card type t1 0 1

!

controller T1 0/1

framing unframed


linecode b8zs


cem-group 0 unframed!

pseudowire-class SAToP

encapsulation mpls

control-word

!

!

interface CEM0/1

no ip address

load-interval 30

cem 0

xconnect 100.111.15.1 9171501 encapsulation mpls pw-class SAToP

backup peer 100.111.15.2 9171502 pw-class SAToP

!

!

interface Loopback0

ip address 100.111.9.17 255.255.255.255

!

!

router isis agg-acc


!

!


!#



!#



pw-ids ending in 1502 instead of 1501.

hw-module subslot 0/2/1 cardtype sonet

!

controller SONET0/2/1/0

description To ONS15454-K1410 OC3 port 4/1

ais-shut

report lais

report lrdi

sts 1

mode vt15-t1


58/114

Chapter 4 Services



4-14 SDU-6516

delay trigger 250

!

clock source line

!


cem-group unframed

forward-alarm AIS

forward-alarm RAI

clock source line

!


cem-group unframed

forward-alarm AIS

forward-alarm RAI

clock source line

!

interface CEM0/2/1/0/1/1/1

load-interval 30

l2transport

!

!


load-interval 30

l2transport

!

!

!

interface Loopback0


ipv4 address 100.111.15.1 255.255.255.255

!

l2vpn

pw-class SAToP

encapsulation mpls

control-word

!

!


p2p T1-SAToP-01

interface CEM0/2/1/0/1/5/1 neighbor 100.111.9.17 pw-id 9171501

pw-class SAToP

!

!

!


p2p T1-SAToP-01


neighbor 100.111.14.1 pw-id 14011501

pw-class SAToP

!

!

!

router isis core

interface Loopback0

passive point-to-point


!

!

!

router bgp 1000




!

mpls ldp

router-id 100.111.15.1



59/114

Chapter 4 Services

4.2.3 ATM Clear-channel VPWS Service from PAN to MTG



SDU-6516 4-15

!

!#



!#

4.2.3 ATM Clear-channel VPWS Service from PAN to MTG

Any Transport over MPLS (AToM) pseudowire circuits are utilized to provide ATM circuit transport

across an MPLS-based backhaul architecture. The ATM interface is configured for AAL0 to allow for

transparent transport of the entire PVC across the transport network. The configurations for the PAN

and MTGs are outlined in this section. QoS implementation for ATM circuits is covered in the Quality

of Servicesection, and resiliency via pseudowire redundancy and MR-APS is covered in the High

Availabilitysection.

Figure 4-5. ATM VPWS Service Implementation for 3G Backhaul

Regarding the example shown:

Note ASR 903 utilizes a 16 port T1/E1 Interface Module (A900-IMA16D) for ATM interfaces.

Both ASR 9000 MTGs utilize 1-port OC3/STM-1 ATM SPA (SPA-1XOC3-ATM-V2) in a

SIP-700 card for the TDM interfaces.

ATM transport via Pseudowire over an MPLS infrastructure is detailed in IETF RFC 4447.

The PE side of the ATM interface uses aal0 encapsulation, and the CE side uses aal5snap

encapsulation


tunnel between PEs are not directly connected and targeted-hello response is not configured, so


CE node connected to PAN

!

card type t1 0 0

!

controller T1 0/3framing esf

clock source line

linecode b8zs

cablelength long 0db

mode atm

!

interface ATM0/3

ip address 100.14.15.26 255.255.255.252

load-interval 30

no scrambling-payload

no atm enable-ilmi-trap

pvc 100/4011


60/114

Chapter 4 Services



4-16 SDU-6516

protocol ip 100.14.15.25 broadcast

encapsulation aal5snap

!

!

interface Vlan201

ip address 214.14.6.17 255.255.255.252

load-interval 30

no ptp enable

!


description Traffic Generator with IP 214.14.6.18

switchport access vlan 201

switchport mode access

load-interval 30

!

ip route 214.15.3.16 255.255.255.252 100.14.15.25

!


card type t1 0 5

license feature atm

controller T1 0/5/2framing esf


linecode b8zs

cablelength long 0db

atm

!

interface ATM0/5/2

no ip address


!

interface ATM0/5/2.100 point-to-point


pvc 100/4011 l2transport

encapsulation aal0

xconnect 100.111.15.1 1401150115 encapsulation mpls

!

!

interface Loopback0

ip address 100.111.14.1 255.255.255.255

!

!

router isis agg-acc


!

!


!#



!#




interface ATM0/2/3/0

load-interval 30

!

interface ATM0/2/3/0.100 l2transport

pvc 100/4011

encapsulation aal0


61/114

Chapter 4 Services



SDU-6516 4-17

shape vbr-rt 20000 14000 7000

!

!

!

interface Loopback0


ipv4 address 100.111.15.1 255.255.255.255

!

l2vpn

pw-class ATM

encapsulation mpls

!

!

xconnect group ATM-K1401

p2p T1-ATM-01

interface ATM0/2/3/0.100

neighbor 100.111.14.1 pw-id 1401150115

pw-class ATM

!

!

!

router isis core

interface Loopback0

passive

point-to-point


!

!

!

router bgp 1000




!

mpls ldp

router-id 100.111.15.1


!

!#

!# ISIS and BGP related configuration needed to ensure MPLS LDP binding with remote PEso as to establish AToM PW

!#

CE device connected to MTGs

interface ATM3/1/0

no ip address

no atm ilmi-keepalive


!

interface ATM3/1/0.100 point-to-point

ip address 100.14.15.25 255.255.255.252


pvc 100/4011



!

!

interface GigabitEthernet2/3/0

description Traffic Generator with IP 214.15.3.18

ip address 214.15.3.17 255.255.255.252

load-interval 30

speed 1000

no negotiation auto

cdp enable

!

ip route 214.14.6.16 255.255.255.252 ATM3/1/0.100


62/114

Chapter 4 Services

4.2.4 ATM IMA VPWS Service from PAN to MTG



4-18 SDU-6516

!

4.2.4 ATM IMA VPWS Service from PAN to MTG

Any Transport over MPLS (AToM) pseudowire circuits are utilized to provide ATM circuit transport

across an MPLS-based backhaul architecture. The ATM interface in this example is configured for

IMA. The configurations for the PAN and MTGs are outlined in this section. QoS implementation forATM circuits is covered in the Quality of Servicesection, and resiliency via pseudowire redundancy

and MR-APS is covered in the High Availabilitysection.

Figure 4-6. ATM VPWS Service Implementation for 3G Backhaul

Regarding the example shown:

Note ASR 903 utilizes a 16 port T1/E1 Interface Module (A900-IMA16D) for ATM interfaces.

Both ASR 9000 MTGs utilize 1-port OC3/STM-1 ATM SPA (SPA-1XOC3-ATM-V2) in a

SIP-700 card for the TDM interfaces.

ATM transport via Pseudowire over an MPLS infrastructure is detailed in IETF RFC 4447.

The PE side of the ATM interface uses aal0 encapsulation, and the CE side uses aal5snap

encapsulation

"MPLS LDP discovery targeted-hello accept" is required because of its LDP session via PWtunnel between PEs are not directly connected and targeted-hello response is not configured, so


CE node connected to PAN

!

card type t1 0 0

!

controller T1 0/3

framing esf


linecode b8zs


ima-group 0 no-scrambling-payload

!

!

interface ATM0/IMA0

ip address 100.14.15.30 255.255.255.252

ima group-id 0



pvc 200/4021



!

!


63/114

Chapter 4 Services



SDU-6516 4-19

interface Vlan201

ip address 214.7.1.1 255.255.255.0

no ptp enable

!


switchport access vlan 201

switchport mode access

!

ip route 215.3.1.0 255.255.255.0 100.14.15.29

!


card type t1 0 5

license feature atm

controller T1 0/5/3

framing esf


linecode b8zs


ima-group 1

!

interface ATM0/5/ima0no ip address

atm bandwidth dynamic



pvc 200/4021 l2transport

encapsulation aal0


backup peer 100.111.15.2 1402150216

!

interface Loopback0

ip address 100.111.14.1 255.255.255.255

!

!

router isis agg-acc


!

!


!#



!#




interface ATM0/2/3/0

load-interval 30!

interface ATM0/2/3/0.200 l2transport

pvc 200/4021

encapsulation aal0

!

!

!

interface Loopback0


ipv4 address 100.111.15.1 255.255.255.255

!

l2vpn


64/114


65/114

Chapter 4 Services



SDU-6516 4-21

is implemented in the CSGs to dynamically update the routing prefix-lists at the time of service

activation and deactivation, adding only the specific routes of the remote nodes necessary to support

the currently configured services. This mechanism is detailed at the end of this section.

CSG-901-K1323

route-map CSG_Community permit 10

set community 10:10 10:203 20:20

!

router bgp 1000

address-family ipv4


!

!


service instance 500 ethernet


rewrite ingress tag pop 1 symmetric


!

Core ABR K0601

route-policy BGP_Egress_Transport_Filter

if community matches-any (20:*) then

if community matches-any (20:*) then

pass

elseif community matches-any (10:*) then

drop

else

pass

endif

endif

end-policy

Core Route Reflector K0403

community-set Pass_WireLine_Community

20:20

end-set

!

community-set Deny_Transport_Community

10:10

end-set

!

route-policy pass-all

pass

end-policy

!

!

route-policy BGP_Egress_Transport_Filter

if community matches-any Pass_WireLine_Community then

pass elseif community matches-any Deny_Transport_Community then

drop

else

pass

endif

end-policy

!

For brevity, only one aggregation network configuration is shown.


66/114

Chapter 4 Services



4-22 SDU-6516

Pre-Aggregation Node K0917

router bgp 101

address-family ipv4

neighbor csg route-map BGP_Egress_Transport_Filter out

ip bgp-community new-format

ip community-list standard MTG_Community permit 1001:1001ip community-list standard Inter-Access-X2 permit 10:101

ip community-list standard WL_Community permit 20:20

!

route-map L1intoL2 permit 10

match ip address Pre-Agg

set level level-2

!

route-map PRE_AGG_Community permit 10

set community 100:100 100:104

!

route-map BGP_Egress_Transport_Filter permit 10

match community MTG_Community

set mpls-label

!

route-map BGP_Egress_Transport_Filter permit 20match community WL_Community

set mpls-label

CSG-K901-K1326

router bgp 101

address-family ipv4


network 213.26.22.0 mask 255.255.255.252


neighbor 100.111.9.17 route-map Inbound_Filter in


neighbor 100.111.9.18 route-map Inbound_Filter in

ip bgp-community new-format

ip community-list standard Allowed_Communities permit 1001:1001

!

ip prefix-list WL-Service-Destinations seq 10 permit 100.111.13.24/32




route-map Inbound_Filter permit 10

match community Allowed_Communities

!

route-map Inbound_Filter permit 20

match ip address prefix-list WL-Service-Destinations

!route-map CSG_Community permit 10

set community 10:10 10:104 20:20

!


service instance 500 ethernet


rewrite ingress tag pop 1 symmetric


!


67/114

Chapter 4 Services



SDU-6516 4-23

Each time a new wireline service is enabled on the CSG, the route-map for the inbound filter on the

CSG needs to be updated to allow the remote destination loopback of wireline service to be accepted.

This process can be easily automated using a simple Embedded Event Manager (EEM) script shown

below. With this EEM script in place on the CSG, when the operator configures a new VPWS service

on the device using the "xconnectdestination vc-idencapsulation mpls" command, the remote T-PE

loopback corresponding to the destinationargument will automatically be added to the "WL-Service-

Destinations" prefix-list of allowed wireline destinations. The script will also trigger a dynamicinbound soft reset using the "clear ip bgpdestinationsoft in" command to initiate a nondisruptive

dynamic route refresh.

event manager applet UpdateInboundFilter

event cli pattern ".*xconnect.*encapsulation.*mpls" sync no skip no

action 10 regexp " [0-9.]+" "$_cli_msg" result

action 20 cli command "enable"

action 21 cli command "conf t"

action 30 cli command "ip prefix-list WL-Service-Destinations permit $result/32"

action 31 puts "Inbound Filter updated for $result/32"

action 40 cli command "end"


action 60 cli command "clear ip bgp 100.111.9.17 soft in"


action 80 puts "Triggered Dynamic Inbound Soft Reset towards PANs"

Similarly, when a wireline service is removed from the CSG, the route-map for the inbound filter

on the CSG needs to be updated to remove the remote destination loopback of the deleted wireline

service. The following two EEM scripts will automate this process on the CSG through the following

logic:

1. The operator removes the XConnect by the "no xconnect" command. There is no IP address

which is required to remove a correct line from a prefix-list.

2. To obtain the IP address, the "tovariable" applet was used with an environmental variable $_int.

This applet is triggered by the "interface" command which informs the variable that there can be

a potential change in the configuration.

3. The second applet "UpdateInboundFilter2" is triggered by the "no xconnect" command, and usesthe interface derived from the "tovariable" applet to obtain the IP address and remove it from the

prefix-list.

event manager applet tovariable

event cli pattern "interface" sync no skip no



action 30 cli command "event manager environment _int $_cli_msg"

event manager applet UpdateInboundFilter2

event cli pattern "no xconnect" sync no skip yes


action 20 cli command "show run $_int"

action 30 regexp "xconnect.*" "$_cli_result" line

action 40 regexp " [0-9.]+" "$line" resultaction 50 cli command "enable"


action 70 cli command "no ip prefix-list WL-Service-Destinations permit $result/32"

action 80 cli command "$_int"

action 90 cli command "no xc"



action 120 puts "Triggered Dynamic Inbound Soft Reset towards PANs"


68/114

Chapter 4 Services



4-24 SDU-6516

Note Future system releases will include feature enhancements to the Unified MPLS toolbox to fully

automate the scale control in the RAN access while enabling wireline deployments without needing

manual prefix filtering and EEM scripting.


69/114


70/114

Chapter 5 Synchronization Distribution



5-2 SDU-6516

Figure 5-1. Test Topology

Notes on Figure 5-1: TP-5000 has two ethernet connections to MTG-K1501 and MTG-K1502, which provide PTP

PRC source redundancy marked with green and blue (green with priority 100/105, blue with

priority 110/115).

TP-5000 has two E1 output connects to ASBR-AG

Date post:	02-Mar-2016
Category:	Documents
Upload:	herbert-ascencio
View:	657 times
Download:	26 times