Alcatel Lucent IP MPLS Mobile Backhaul Transport Student Guide PDF

Alcatel-Lucent IP/MPLS Mobile Backhaul
Transport
Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute
Module 0 Course Introduction
Module Overview
Alcatel-Lucent Career Certification Flow

Timeline
Objectives
Prerequisites
Follow On
Introduction
Goal
Administration
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0
Module 0 |
All rights reserved 2012 Alcatel-Lucent
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. For more information on
the SRC program, see www.alcatel-lucent.com/src
To locate additional information relating to the topics presented in this manual, refer to the following:
Technical Practices for the specific product
Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts
Technical support pages of the Alcatel-Lucent website located at: http://www.alcatellucent.com/support
Module 0 - Page 2 | All rights reserved 2012 Alcatel-Lucent
General Course Information
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST I
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST II
4 DAYS / 1 COURSE / 1 WRITTEN EXAM
18 DAYS / 4 COURSES / 4 WRITTEN EXAMS /

1 PRACTICAL LAB EXAM
ALCATEL-LUCENT
ALCATEL-LUCENT
TRIPLE PLAY ROUTING PROFESSIONAL MOBILE ROUTING PROFESSIONAL
36 DAYS / 8 COURSES / 8 WRITTEN EXAMS /
1 PRACTICAL LAB EXAM
32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS /

2 PRACTICAL LAB EXAMS
ALCATEL-LUCENT
SERVICE ROUTING ARCHITECT
49 DAYS / 11 COURSES / 11 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS
Module 0 |
The Alcatel-Lucent SRC Program Five Certifications
Module 0 |
SRC Courses and Exams
Exam Number
Exam Pre-requisites
(4A0-XXX)
Alcatel-Lucent Scalable IP Networks
4A0-100
NA
Alcatel-Lucent Interior Routing Protocols
4A0-101
NA
Alcatel-Lucent Border Gateway Protocol
4A0-102
NA
Alcatel-Lucent Multiprotocol Label Switching
4A0-103
NA
Alcatel-Lucent Services Architecture
4A0-104
NA
Exam Name
Alcatel-Lucent Virtual Private LAN Services
4A0-105
NA
Alcatel-Lucent Virtual Private Routed Networks
4A0-106
NA
Alcatel-Lucent Quality of Service
4A0-107
NA
Alcatel-Lucent Multicast Protocols
4A0-108
NA
Alcatel-Lucent Triple Play Services
4A0-109
NA
Alcatel-Lucent Advanced Troubleshooting
4A0-110
NA
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport
4A0-M01
NA
Alcatel-Lucent Mobile Gateways for the LTE Evolved

Packet Core
4A0-M02
NA
Alcatel-Lucent Network Routing Specialist II Lab Exam
NRSII4A0
100, 101, 103, 104
Alcatel-Lucent Mobile Routing Professional Lab Exam
MRP4A0
100, 101, 103, 104, 107, M01, M02, NRSII4A0
Alcatel-Lucent Service Routing Architect Lab Exam
ASRA4A0
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,
NRSII4A0
Module 0 |
SRC Program Exam Profile
Exam Delivery
Written Exams
Delivered by Prometric
Global provider of testing services
Register at:
www.prometric.com/alcatel-lucent
Lab Exams
Written at Alcatel-Lucent sites
NRS II Certification
Half-day lab exam
MRP Certification
Half-day lab exam
SRA Certification
Full-day lab exam
Register at:
www.alcatel-lucent.com/src/examreg
Module 0 |
5000+ test sites worldwide
SRC Program
Global Reach, Flexible Delivery Options
APAC
Shanghai, China
Sydney, Australia
Melbourne, Australia
Wellington, New Zealand
Bangalore, India
Chennai, India
Gurgaon, India
Mumbai, India
Europe
Antwerp, Belgium
Newport, UK
Paris, France
Americas
Plano, USA
Ottawa, Canada
Mexico City, Mexico
Sao Paulo, Brazil
Class schedules posted @ www.alcatel-lucent.com/src

Registration online @ www.alcatel-lucent.com/src/coursereg
Module 0 |
On-site delivery at your business location anywhere in the world

Delivery from any of the following Alcatel-Lucent University locations
globally
Your Own Service Router Lab Now you can have one
Need access to a lab to help you:

Practice and build your service routing knowledge and configuration skills?
The Alcatel-Lucent Exam Preparation service provides:

Remote, private access (724) to an Alcatel-Lucent service router lab:
six-node fully meshed network three-hour time slots available
Access to a suite of over 30 lab practice scenarios with optimal solutions
Access to traffic simulation and analysis tools
To find out more and sign up visit http://www.alcatel-lucent.com/src/examprep
Module 0 |
Prepare for your NRS II and SRA exams?
Credit for other IP Certifications
You can receive exemptions from

some of the SRC exams, if you
hold any one of the Cisco or
Juniper certifications identified
Certifications must be valid to
receive exemptions
Submit your request for
exemptions at: http://www.alcatellucent.com/src/exemptions
Module 0 |
Cisco or Juniper certified?
Day 1
Module 0 Course Introduction
Module 1 IP/MPLS Mobile Backhaul Transport Network
Architectures
Day 2
Module 2 Implementing the Mobile Backhaul
Transport Network
Day 3
Module 2 Implementing the Mobile Backhaul Transport
Network (cont)
Module 3 Mobile Backhaul Transport Services
Day 4
Module 3 Mobile Backhaul Transport Services (cont)
Module 0 |
10
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport Timeline
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Objectives
Mobile Backhaul Transport Network (2/3/4G) standards bodies

and terminology
Mobile Backhaul Transport Network physical topology options
How Alcatel-Lucent SROS-based products are used in the
backhaul transport network
Backhaul Transport Network timing and synchronization
requirements, protocols, and their configuration
Cell Site and Mobile Telephone Switching Office (MTSO) router
TDM and Ethernet access interface configurations
Routing protocol use and configuration in the Backhaul
Transport Network
Module 0 |
11
After successful completion of this course, you will

understand:
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport Objectives

(cont.)
Mobile Backhaul Transport service deployment and

configuration (VPWS, VPLS, VPRN)
Network resiliency requirements and configuration (VRRP,
pseudowire redundancy, MC-LAG, MC-APS, BFD)
CLI OAM tools to verify network configuration and operation
Module 0 |
12
After successful completion of this course, you will

understand:
Prerequisites
In order to fully appreciate the concepts to be discussed in this

course, we strongly recommended that you successfully
complete the following courses and certifications:
Alcatel-Lucent Scalable IP Networks
Alcatel-Lucent Interior Routing Protocols and High
Availability
Alcatel-Lucent Multiprotocol Label Switching
Alcatel-Lucent Services Architecture
Alcatel-Lucent Network Routing Specialist II
(NRS II) hands-on lab exam
Alcatel-Lucent Quality of Service
Module 0 |
13
Suggested Prerequisites
Follow On
Based in the material covered in this course, we recommend

that you follow this course with:
Alcatel-Lucent Mobile Gateways for the LTE Evolved
Packet Core
Additionally, we encourage you to continue your efforts towards
the Service Router Architect (SRA) certification status.
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport Exam

Following successful completion of this course, and to ensure
that you fully comprehend the material it covers, we
recommend that you register for and take the Alcatel-Lucent
IP/MPLS Mobile Backhaul Transport certification exam.
Module 0 |
14
Suggested Follow-on Courses
With the rising demands for mobile broadband services, operators

realize a sharp increase in bandwidth requirements. Hence, they
must evolve their strictly TDM-based networks to new packet
backhaul networks that offer increased capacity at lower cost, while
providing the service reliability and quality of service their customers
expect.
The Alcatel-Lucent IP/MPLS Mobile Backhaul Transport supports Any
G mobile traffic - 2G, 3G, 4G/LTE, and beyond - offering flexible
Radio Access Network (RAN) access/aggregation transport options.
This course focuses on IP/MPLS transport options implemented via
Service Router Operating System (SROS) features and services.
This network ties the cell site aggregation nodes to the Mobile
Switching Office (MSO), and provides a common transport for TDM,
ATM, and Ethernet-based mobile services.
Module 0 |
15
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Introduction
Describe and implement the transport and services used

in two current solutions to IP/MPLS Mobile Backhaul Transport
bandwidth and service quality requirements, as major wireless
service providers have deployed them.
Module 0 |
16
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Course Goal
Presentation Graphics
Service Packet
PE when
block diagram used
PE
Payload
Service Label
MPLS Label
Ethernet
Generic L2
Switch
SDP
SAP
SAP
Generic routers
Optical Transport
UNI/NNI
7750 SR
Generic Base
Station
7705 SAR
PRC
Pipe service
or tunnel
Generic NC
Element
Generic EPC
Element
Module 0 |
17
MSC
Typical graphic symbols found in this courseware.
Network Cloud
Administration
Registration
Restrooms
Communications
Materials
Schedule
Introductions
Name and Company
Experience
Familiarity with MPLS and Services
Questions ?
Module 0 |
18
Facility Information
www.alcatel-lucent.com/src

Transport
Module 1 IP/MPLS Mobile Backhaul Transport Network

Architectures
Upon successful completion of this module, you will be able to:

Explain the Mobile Backhaul physical transport options
Identify key components found in 2, 3, and 4G Mobile Networks
Define Mobile Backhaul Transport Network Standards bodies and
basic terminology
Differentiate key aspects of two possible Mobile Backhaul solution
architectures
Hub and spoke
Ring/subtended ring
Place Alcatel-Lucent SROS-family products in the Backhaul
Transport
Verify the physical hub and spoke architecture configuration
Module 1 |
Alcatel-Lucent Mobile Backhaul Transport Network

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See
www.alcatel-lucent.com/src for more information on the SRC program.
To locate additional information relating to the topics presented in this manual, refer to the
following:
Internet Standards documentation such as protocol standards bodies, RFCs, and IETF
drafts
Technical support pages of the Alcatel-Lucent website located at: http://www.alcatellucent.com/support
Module Objectives
Module 1 IP/MPLS Mobile Backhaul

Transport Network Architectures
Section 1 Mobile Backhaul Standards Bodies and Terminology
Section Objectives
Terminology used to describe the Mobile Backhaul transport

architecture and components
The two Backhaul transport service provider types, their
functions, and interfaces
Trends driving the consumers needs for increased mobile service
features and bandwidth
Industry standards bodies defining the transport architecture and
its operation
Module 1 |
In this section, we will introduce:
The IP/MPLS Mobile Backhaul Transport:

Provides high bandwidth, packet-based transport for 2, 3, and
4G voice, data, and Operations, Administration, and
Maintenance (OAM) traffic
Incorporates network nodes with high capacity, Quality of
Service (QoS)-aware interfaces
Enables end-to-end OAM capabilities
Supports the networking models and transport services as
defined by industry recognized standards bodies
Provides a lower Total Cost of Ownership (TCO) than legacy
TDM, SONET/SDH, ATM, or Ethernet hybrid networks
Supports Any-G, including 4G/LTE, application and user
bandwidth requirements
Module 1 |
What is the IP/MPLS Mobile Backhaul Transport?

According to the Next Generation Mobile Networks (NGNM) Alliance, A backhaul network serves as the transport
medium for a mobile Radio Access Network (RAN) and connects the base stations to their relevant controllers.
Put another way, the Mobile Backhaul transport network ties together the 2, 3 and 4G/Long Term Evolution (LTE)
cell site Base Stations (BS) and the Mobile Telephone Switching Office (MTSO)-located Network Controllers (NC)
and related management stations using standards-based, class-of-service (COS)-aware transport solutions.
Why A Packet-based Transport?
The only way to LTE is a packet network. As wireless networks built for legacy voice and Short Message Service
(SMS) saturate with web, video, Multimedia Messaging, Peer-to-Peer (P2P) Music and Video and the data
explosion continues unabated they need to evolve and change. This change is occurring in the transformation of
wireless networks to an all-IP paradigm.
With an IP/MPLS Mobile Backhaul Transport, Mobile Wireless Providers can economically and efficiently upgrade
their RAN and wireless packet core networks to a flatter, IP/Ethernet network while increasing its bandwidth to
support new and emerging broadband wireless services.
With an IP/MPLS Mobile Backhaul Transport, wholesale service providers gain the capability to deliver new wireless
wholesale services to an expanding service market opportunity.
What is the IP/MPLS Mobile Backhaul Transport?
The Mobile Backhaul Network:

Provides connectivity between Base Stations (BS)
and Network Controllers (NC) and directly between 4G BSs.
May include TDM, SONET/SDH, ATM, and Ethernet access and network
interfaces
Module 1 |
Mobile Backhaul Transport Components

The image above shows three functional areas of a backhaul transport network. These are:
The Cell Site Where the mobile Base Stations (BS) and Cell Site Aggregator (CSA) nodes are found.
The Base Stations (BS)
The BS are the 2G Global Systems for Mobile (GSM) Base Transceiver Station (BTS), 3G Universal Mobile
Telecommunications System (UMTS) or Code Division Multiple Access (CDMA) NodeBs, and 4G/Long Term Evolution
(LTE) eNodeBs
The Cell Site Aggregator (CSA)
The Cell Site Aggregator (CSA) is the first demarcation device where user traffic enters and leaves the backhaul
transport network. It is also called the Cell Site Gateway (CSG) and the Demarcation device.
The CSA aggregates traffic for potentially 100s of users, and may support TDM, ATM, and Ethernet connected BS.
The Backhaul Transport The physical backhaul network transport could be bundled DS1/E1 or DS3/E3,
SONET/SDH, Ethernet over SONET (EoS), or straight Ethernet, or a combination of some or all of these. Feeding
these circuits could be Ethernet, Asynchronous Transport Mode (ATM), or Time Division Multiplexing (TDM) BSs, and
microwave, Digital Subscriber Line (DSL), Ethernet, and wireless access networks. The transport network accepts
voice, data, and control traffic and delivers this traffic bi-directionally to and from the BS and MTSO elements. A
4G/LTE physical transport is all Ethernet, enabling direct BS-BS communications.
The EoS User Network Interface (EoS UNI) This serves as the CSAs gateway to the Metro Ethernet, SONET/SDH,
TDM, or ATM transport network. In the example above, the EoS UNI accepts Ethernet traffic from the CSA and
transports these frames and their payload over the SONET/SDH Metro Ethernet Network (MEN) ring.
The Metro Ethernet Network (MEN) Provides resilient, optical transport of the IP/MPLS backhaul service traffic.
The Multiservice Provisioning Platform (MSPP) Delivers traffic to the MTSO gateway routers over redundant
Ethernet or SONET/SDH links.
Continued on the next page...
Mobile Backhaul Transport Components
The Mobile Backhaul Network:

Aggregates at the Mobile Telephone Switching Office (MTSO) traffic for
1000s of cell service users
Delivers user voice, data, and BS OAM and control traffic to and from
the NC elements and external networks
Module 1 |
Mobile Backhaul Transport Components (cont)

As shown in this slide, the transport network offers service-aware QoS and physical and virtual point-to-point and
multi-point transport services which move bearer and signaling traffic through the EoS MEN. CSA routers and L2
services forward cell site traffic into the transport network, and MSP Aggregation Gateway (MG) routers deliver
this traffic to the Network Controllers (NC). The BS, CSA, MTSO, and the transport network could belong to the
Mobile Service Provider (MSP), or the MSP could lease MEN access from a Backhaul Transport Provider (BTP). The
transport network components ensure accurate BS, TDM circuit, and network element synchronization and per
customer/per service traffic differentiation.
The MTSO/Evolved Packet Core (EPC) The MTSO is the greatest point of aggregation, where traffic for 1000s of
users enters and leaves the backhaul transport. Here are found the BS controllers, gateway routers, and call
switching elements.
The Mobile Service Provider (MSP) Aggregation Gateway (MG) routers Provide high forwarding capacity to
aggregate traffic from 100s of cell sites. Also know as the Multi-Level Switch (MLS) and the Mobile Aggregation
Site Gateway (MASG), these devices originate and terminate MPLS Label Switch Paths (LSPs), maintain routing
adjacencies both in the transport network and with external network devices, provide both Ethernet and ATM
access to the Network Control (NC) elements, and originate and terminate L2 and L3 services.
The MG routers acts as the counterparts to the CSA routers, delivery user and management traffic end-to-end
across the backhaul transport.
The Network Control (NC) Elements
The NC are the GSM Base Station Controller (BSC), the UMTS Radio Network Controller (RNC) and the CDMA 1x
voice and Evolution-Data Optimized (EV-DO) data RNCs. For LTE, the NC are the Evolved Packet Core (EPC)
Serving Gateway (SGW) and the Mobility Management Entity (MME). Additionally, built-in to the eNodeB is the
RNC function.
Additional Call Control Elements
Other components found in the MTSO are the GSM/UMTS Mobile Switching Center (MSC), Serving GPRS Support
Node (SGSN), and Gateway GPRS Support Node (GGSN). CDMA includes the Packet Data Serving Node (PDSN).
Additional EPC elements are the Packet Data Network Gateway (PDN GW) and the Policy and Charging Rules
Function (PCRF).
Mobile Backhaul Transport Components (cont)
Mobile Service Provider (MSP) network

The service provider owns the end-to-end
network
The UNI-BS may be DS1/E1, ATM, or Ethernet
The UNI-NC may be ATM over SONET or Ethernet
The Transport Network may be Ethernet, EoS, or TDM
Module 1 |
Mobile Service Provider (MSP)

A Mobile Backhaul Transport customer may be a Mobile Service Provider (MSP) or a Backhaul Transport Provider
(BTP). This course focuses on the MSP components, but will show MSP traffic carried through a BTP network.
Shown here is a diagram representing an MSPs network, where the service provider owns the end-to-end network,
from the base stations (BSs) on the left to the MTSO on the right. The BTP model is shown on the next slide.
MSP Terminology
Mobile Telephone Switching Office (MTSO)
The MTSO controls the cellular network operations and houses the MG routers, the BSC, the RNCs, and other call
control and switching components. In an LTE environment, the MTSO may house the EPC components.
The MSP owns the cell site and MTSO, operating all the network elements that compose the Base Station, the MGs
and the network control functions. The MSP could own the transport network, as shown here, or lease capacity
from a Backhaul Transport Provider (BTP).
MSP Aggregation Gateway (MG)
The MG aggregates and grooms traffic received from multiple cells sites and delivers it to the network controllers.
This device is also known as the Mobile Aggregation Site Gateway (MASG) or Multi-Level Switch (MLS).
MSP Termination Device (MT)
The MT aggregates base station traffic and terminates the Mobile Backhaul network at the cell site. This is also
know as the CSA, CSG, or the Demarcation device.
User Network Interface Base Station (UNI-BS)
Interface between the Base Station equipment and the MT. This could be wired or wireless - Ethernet, TDM,
microwave, Digital Subscriber Line (DSL), or WiMAX.
User Network Interface Network Control (UNI-NC)
Interface between the MG and the network controllers. These are either Ethernet, ATM, or TDM interface.
The MSP may use the services of a BTP
MSP owns the cell site and MTSO

BTP provides the transport network
BTP offers E-line (ePipe) or transport services to the MSP
BTP may offer SONET/SDH path diversity
Module 1 |
Backhaul Transport Provider (BTP)

).
The Backhaul Transport Provider (BTP) supplies to the MSP a Metro Ethernet, SONET/SDH, or TDM transport,
moving traffic from the MSPs cell site aggregators (the MT) to the MTSO MGs. The backhaul network still includes
the MT and MG, but the BTP owns the MEN, SONET/SDH, TDM, or Ethernet transport network and its interfaces,
including the BTP Aggregation Gateway (BG) and the BTP Termination Device (BT). The MSPs demarcation points
are the MT and the MG ingress/egress interfaces, the UNI-MT and the UNI-MG.
The MSP may access the BTPs transport network via Ethernet, SONET/SDH, or TDM links. The BTP may offer the
MSP native Ethernet Virtual LAN (VLAN), EoS, TDM, or Virtual Private Wire Service (VPWS) services. The BTP
provisions and maintains the transport network, and may aggregate traffic for multiple MSPs.
BTP Terminology
BTP Aggregation Gateway (BG)
The BTP Aggregation Gateway (BG) could reside in the MTSO, part of the MSPs facility, but belongs to the BTP.
The BG terminates the BTPs transport interfaces, and forwards packets on toward the MG.
BTP Termination Device (BT)
The BTP Termination Device (BT) provides backhaul network termination and cell site base station traffic
aggregation from one or more mobile operators. The BT belongs entirely to the BTP, and includes the BTPs MSPfacing interfaces. BTP transport services originate and terminate at the BT and the BG nodes.
User Network Interface MG (UNI-MG)
For a BTP customer, the interface between the BG and the MG.
User Network Interface MT (UNI-MT)
For a BTP customer, the interface between the MT and the BT.
Backhaul Transport Provider (BTP)
In mobile networks, the term MG can stand for MSP Aggregation

Gateway, Mobile Gateway, or Media Gateway
In the remainder of this course, we will use the term Multi-Layer
Switch (MLS) in place of the term MSP Aggregation Gateway (MG)
This avoids confusion with the term Mobile Gateway (MG) used in
LTE deployments
Both the term MG and MLS appear in our design documents, so
both are valid to describe the SROS routers located in the MTSO
Module 1 |
10
Course Note: Terminology - MLS versus MG
To avoid copying any part of a customers configurations, we are

using IP addresses in the RFC 5735 documentation address ranges:
192.0.2.0/24
198.51.100.0/24
The example addressing scheme may not be consistent with
current design guidelines, i.e, addresses from the same space in
the base and service routing instances
Module 1 |
11
Course Note: Addressing
Mobile Backhaul Transport Standards Bodies
The 3rd Generation Partnership Project (3GPP) www.3gpp.org

The 3GPP2 www.3gpp2.org
The International Telecommunications Union Telecommunications
Sector (ITU-T) www.itu.int/ITU-T
The Internet Engineering Task Force (IETF) www.ietf.org
The Metro Ethernet Forum (MEF) www.mef.org
The Institute of Electrical and Electronics Engineers (IEEE)
www.ieee.org
Next Generation Mobile Networks (NGMN), www.ngmn.org
Module 1 |
12
Mobile Backhaul Transport Standards Bodies

Several organizations have developed standards and guidelines pertinent to the development and deployment of
Mobile Backhaul transport architectures:
The 3rd Generation Partnership Project (3GPP) www.3gpp.org
The International Telecommunications Union Telecommunications Sector (ITU-T) www.itu.int/ITU-T
The Internet Engineering Task Force (IETF) www.ietf.org
The Metro Ethernet Forum (MEF) www.mef.org
The Institute of Electrical and Electronics Engineers (IEEE) www.ieee.org
The Next Generation Mobile Networks (NGMN) Alliance www.ngmn.org
The following pages introduce these organizations.
Several organizations have developed standards and guidelines

pertinent to the development and deployment of Mobile Backhaul
transport architectures:
Standards Bodies: 3GPP
Founded by the European Telecommunications Standards Institute

(ETSI)
Originally described Global Systems for Mobile communication
(GSM) networks
Release 8-10 specifications describe LTE networks
Describes Quality of Service (QoS) (R5) and radio time and
frequency synchronization requirements (R8)
Module 1 |
13
Standard Bodies: 3GPP

In 1998, the European Telecommunications Standards Institute (ETSI) founded the 3GPP to produce technical
specifications and technical reports covering Global Systems for Mobile communication (GSM) core networks and
radio access technologies. Later, the 3GPP became responsible for maintaining and developing technical
specifications and reports for GSM General Packet Radio Service (GPRS) and Enhanced Data rates for GSM
Evolution (EDGE) technologies. The term Universal Mobile Telecommunications System (UMTS) is a blanket term
for all these technologies.
3GPP committees, know as Technical Specification Groups (TSGs) or Working Groups (WGs), develop the technical
specifications that describe the GSM EDGE Radio Access Network (RAN) (the TSG GERAN), the Radio Access
Network (TSG RAN), the services and systems aspects (TSG SA) and the core network and terminals (TSG CT). The
3GPP specification Release 8 become the design basis for current LTE networks, and Release 9 added a few
enhancements.
Notable is that 3GPP Release 8 and 9 LTE deployments adhere to the ITUs International Mobile
Telecommunications-2000 (IMT-2000) specifications, which define a peak mobile data rate of 200 kilobits
(kbits)/second. The 3GPP has submitted to the ITU-T its Release 10 and 11 specifications as LTE-Advanced,
candidates for the ITU IMT-Advanced standard establishing worldwide interoperable equipment supporting a peak
data rate of at least 100 Megabits (Mb)/second.
The 3GPP www.3gpp.org
Standards Bodies: 3GPP2
Produces Code Division Multiple Access (CDMA) network

specifications
3G standards
cdma2000
EV-DO Revision A
Describes QoS and synchronization requirements for CDMA
networks
Module 1 |
14
Standard Bodies: 3GPP2

The 3GPP2 is an organization functioning in parallel to the 3GPP, focused on producing specifications for CDMA
networks following American National Standards Institute (ANSI), Telecommunications Industry Association (TIA)
and Electronic Industries Association (EIA ) standards.
The 3GPP2 consists of five member Standard Development Organizations (SDOs), representing the US and Asia.
Four 3GPP2 Technical Specification Groups (TSGs), TSG-A- Access Network Interfaces, TSG-B - cdma2000, TSG-C Services and Services Aspects, and TSG-X - Core Networks, meet several times annually to update and create
technical specifications.
The cdma2000 and EV-DO Revision A (EV-DO Rev. A) standards set current 3GPP2 voice and data communications
techniques. EV-DO Rev. A networks can support downstream data rates of up to 3.1Mbits/second, and are entirely
IP-based.
Standards Bodies: ITU-T
Core network functionality

Broadband service delivery
Next-generation services
Transport connectivity requirements, Operations, Administration
and Maintenace (OAM) functions, and synchronization
Module 1 |
15
Standard Bodies: ITU-T

The ITU-T develops and maintains recommendations which define core network functionality, broadband service
delivery, and next-generation services. ITU-T recommendations standardize telecommunications network
operations and inter-working, and range from defining tariff principles to telecommunications equipment
maintenance standards to Internet protocol Quality of Service and charging functions.
The ITU-Ts G-series recommendations define digital systems and networks design and operations aspects, including
voice coders/decoders (codecs) and the H-series recommendations describe audiovisual and multimedia systems
characteristics.
The ITU-T www.itu.int/ITU-T, develops recommendations which

define:
Standards Bodies: IETF
The goal of the IETF is to make the Internet work better,

www.ietf.org
Develops Requests for Comments (RFC) defining Internet:
Applications Virtual Private Wire Services (VPWS)
Protocols Internet Protocol (IP)/Multi-Protocol Label
Switching (MPLS)
Network Management Simple Network Management Protocol
(SNMP)
Routing Open Shortest Path First (OSPF)
Module 1 |
16
Standard Bodies: IETF

To quote the www.ietf.org site home page, The goal of the IETF is to make the Internet work better. [5] The
IETF serves to improve the Internet by engineering technical solutions to Internet communications challenges. The
IETF does not set policy, nor is it involved in developing business practices.
The IETF creates standards in 8 areas (www.ietf.org/iesg/area.html). Within each area, working groups (WGs)
manage the work performed, defining a charter on the type of work and when it is due. The WGs produce
Internet Drafts, which the WGs frequently publish as Requests for Comment (RFCs).
Hundreds of RFCs now in force define applications, Internet protocols, network management, routing and other
key Internet functions.
The IETF www.ietf.org
Standards Bodies: MEF
The defining body for Carrier Ethernet www.mef.org
Defines architectures, protocols and management techniques for

Metro Ethernet Networks (MEN)
Describes MEF-6 E-line and E-LAN and MEF-22 Mobile Backhaul

over Ethernet
Module 1 |
17
Standard Bodies: MEF

Formed in 2001, the MEF calls itself The defining body for Carrier Ethernet. [6] Their stated mission is to
accelerate the worldwide adoption of Carrier-class Ethernet networks and services. An alliance of over 150
organizations, the MEF develops Carrier Ethernet specification and implementation agreements to support Carrier
Ethernet interoperability worldwide.
Metro Ethernet transport networks play a key role in todays Mobile Backhaul network deployments. Legacy TDM
networks cannot scale to meet current and future mobile bandwidth requirements, and Ethernet is the only
technology that can meet these needs; additionally, 4G and LTE networks only work with Ethernet transport. The
MEF technical specifications define the architectures, protocols, and management techniques for metro Ethernetbased networks, whether built over native Ethernet links or transported over Synchronous Optical Network
(SONET) transmission media.
E-line A point-to-point or multi-point Ethernet virtual private line services. The point-to-point service is called
an Ethernet Private Line (EPL), and the multi-point service is called an Ethernet Virtual Private Line (EVPL)
service.
The difference between the EPL and EVPL is the difference between a 1:1 mapping of a BS physical port to a UNINC physical port (EPL) and a many-to-one mapping of multiple BS physical ports to a single UNI-NC port. The EVPL
can be implemented by assigning unique VLAN tags to each BS and maintaining those mappings end-to-end.
E-LAN Ethernet Private LAN (EP-LAN) and Ethernet Virtual Private LAN (EVP-LAN) services provide multi-point L2
switched connectivity between multiple BS and NC elements, and support BS-BS and BS-NC connectivity. These
services act as virtual Ethernet broadcast domains, allows for BS-BS communications within the same service.
Traffic destined for a BS on another E-LAN service must be routed.
Mobile Backhaul over Ethernet MEF 22 is an implementation agreement that is intended to standardize
equipment and services used in Ethernet-based mobile backhaul deployments. It includes:
Specifications for OAM functions based on established standards
Class-of-service definitions
Recommendations for resiliency
Usage cases as examples of backhaul scenarios Non-ethernet UNI-BS and UNI-NC over Ethernet
transport, and Ethernet UNI-BS and UNI-NC over Ethernet transport
The MEF www.mef.org
Standards Bodies: IEEE
The worlds largest professional organization for the

advancement of technology
Defines many Ethernet network standards
Example: IEEE 1588v2/Precision Time Protocol (PTP) v2, 802.3

Ethernet
Module 1 |
18
Standard Bodies: IEEE

The IEEE is The worlds largest professional association for the advancement of technology. [7] We know the
IEEE for its work defining Ethernet networking standards, but the organization also publishes documents including
research articles, many other standards, and conference publications.
Discussed in detail later in this course is the IEEE 1588v2/PTPv2 standard for delivering packet-based timing over
an IP network.
IEEE also defines Ethernet OAM standards, standards for delivering Ethernet traffic over wireless networks, and
Slow Protocols for delivering SyncE Ethernet Synchronization Messaging Channel (ESMC) SSM messages.
The IEEE www.ieee.org
Standards Bodies: NGMN Alliance
the engine of broadband wireless innovation
Aims to direct mobile broadband services to a single, integrated

network
Example: Whitepapers and use cases focused on defining terms

and functions as components of a mobile broadband deployment
Module 1 |
19
Standard Bodies: NGMN Alliance

The NGNM Alliance is organized to allow sharing between organizations information on broadband technologies
focusing on LTE and EPC deployments and evolution.
According to the website, www.ngnm.org, their mission is:
1. To establish clear performance targets, fundamental including spectrum and deployment scenarios
2. To give guidance to equipment developers and standardization bodies, leading to the implementation of a costeffect network evolution
3. To drive implementation of NGMN recommendations and to avoid duplication of work, establish liaison
statements, project-agreements as needed with SDOs and industry organisations
4. To provide a forum for the industry for presentation and early assessment of new technology trends and
application enablers as they apply to LTE & EPC environment
5. To share experiences and lessons learnt from initial network deployments to further drive development by
offering a management and leadership network e.g. by establishing open high-profile Industry Workshops
6. To actively drive communication raising public awareness on the technologys performance, availability and
customer benefits
7. To deliver all of the above in supporting a transparent and predictable IPR regime
NGMN Products
The NGMN Alliance develops studies and publishes whitepapers on backhaul deployment topics such as:
User data rates in mobile data
LTE Backhauling Deployment Scenarios
Guidelines for LTE Backhaul Traffic Estimation
The NGMN Alliance www.ngmn.org
Module 1 |
20
Evolution to all-IP Wireless Broadband Services 3GPP

The 3GPP standards covers the following technologies:
2G GSM: Offers voice and Short Message Service (SMS) over a circuit-switched network.
GPRS: Adds a packet-switched network and offers Internet on mobile handsets.
EDGE : Allows improved data transmission rates and reduced latency over GPRS. Industry watchers labeled
EDGE 2.75G.
3G UMTS: Uses Wideband-CDMA (W-CDMA) as its main radio technology. High Speed Packet Access (HSPA)
offers improvement in UMTS spectrum efficiency. Evolved High Speed Packet Access (HSPA+) introduces
new functionalities and allows 40 Mbps downlink speeds and 10 Mbps uplink speeds.
4G LTE: Offers a throughput of 100Mbps in the downlink and 50Mbps in the uplink.
The evolution of the radio access and mobile core network was needed to support the requirements of the new
services and applications. End users now have access to various types of content-rich and real-time applications.
The transport network is also evolving from traditional TDM to an all-IP Ethernet network.
Evolution to all-IP Wireless Broadband Services 3GPP
Module 1 |
21
Evolution to all-IP Wireless Broadband Services - 3GPP2

In parallel, and competing with the 3GPP standards, the 3GPP2 standard body was developing its own
technologies:
2G Code Division Multiple Access One (cdmaOne ): it is based on Interim Standard 95 (IS-95) and competes
with 2G GSM.
CDMA2000 1X: Offers a downlink and uplink rate of 153 Kbps
3G EV-DO: Rev.A offers a downlink rate of 3.1Mbps and an uplink rate of 1.8Mbps. Rev.B offers a downlink
rate of 73 Mbps and an uplink rate of 27 Mbps.
The intended 4G successor to CDMA2000 was Ultra Mobile Broadband (UMB). However in November 2008, UMB
was dropped and 3GPP2 endorsed LTE as the 4G wireless standard.
High Rate Packet Data (HRPD) covers EV-DO and its revisions.
Evolution to all-IP Wireless Broadband Services 3GPP2
Module 1 |
22
3GPP Releases Towards LTE Key Milestones

3GPP work is organized into releases. Every release offers many new and improved functionalities. The main
functionalities with respect to the evolution of the mobile core are summarized below:
R4 introduces NGN (Next Generation Network). NGN is a packet-based network that transports all information
as IP packets.
R5 introduces IMS (IP Multimedia Subsystem) and HSDPA (High Speed Downlink Packet Access).
IMS is an architectural framework for delivering IP multimedia services to various access networks. The IMS
provides support for multimedia sessions based on SIP (Session Initiation Protocol).
HSPA (High Speed Packet Access) extends and improves the performance of W-CDMA. HSPA includes 2
protocols, the High Speed Downlink Packet Access (HSDPA) and the High Speed Uplink Packet Access
(HSUPA). Many HSPA rollouts can be achieved by a software upgrade to existing 3G networks.
R6 introduces HSUPA and IP QoS and adopts the all-IP packet networks.
R7 introduces Policy and Charging Rules Function (PCRF), Direct Tunnel and Evolved High Speed Packet Access
(HSPA+)
PCRF: Designed for both 3G and 4G/LTE Evolved Packet Core networks, the PCRF controls the interaction
of users and applications with the network, in order to satisfy different services with different quality of
service levels and charging rules.
Direct Tunnel allows the data path to bypass the SGSN node.
HSPA+ provides higher data rates with multiple input, multiple output technologies.
R8 introduces LTE
Covers the S3, S4 and S12 logical interfaces that are needed to provide interworking of LTE with existing
UMTS/HSPA radio networks.
R9 focuses on LTE/EPC enhancements
Due to an aggressive schedule, R8 was limited to essential features hence the R9s focus on enhancements.
R10 introduces LTE Advanced
Significant enhancements to LTE/EPC to comply with the aggressive ITU IMT-Advanced requirements.
3GPP Releases Towards LTE Key Milestones
Section Summary
In this section, we learned:

The two Mobile Backhaul customer types; the MSP and the BTP
The Mobile Backhaul Transport standards bodies
Trends driving the move to higher capacity backhaul networks
Module 1 |
23
The purpose and use of the Mobile Backhaul Transport Network

Section 2 Backhaul Service Architectures
Section Objectives
Model 1 Hub and spoke

Virtual Private Wire Services (VPWS) transporting cell site
traffic into MLS Local VPLS and VPRN Services
Model 2 Subtended ring
VPWS transporting cell site traffic into Distributed Virtual
Private Routed Network (VPRN) services
We will use these models as guides as we study the protocols and
services that create the Mobile Backhaul Transport Network.
Module 1 |
26
In this section, we will introduce two Mobile Backhaul Transport

model architectures:
Hub and spoke redundant, point-to-point services

transport between CSA and MLS
MLS routers are the hub nodes and points of greatest traffic
concentration
CDMA or GSM/UMTS
LTE-ready with E-line or E-LAN services
Module 1 |
27
Backhaul Network Physical Topologies Hub and Spoke

A backhaul topology can take many forms and incorporate many different physical layer technologies. The
topology used depends on the customers needs.
1.
Do they wish to reuse their existing TDM, fiber, or Ethernet infrastructure?
2.
Are they an MSP who owns the entire transport network, or do they lease transport access from a BTP?
3.
Are they a BTP providing only point-to-point Ethernet (E-Line) services?
4.
Does their MEN offer native Ethernet or Packet over Ethernet transport?
5.
Are they upgrading an existing site (brownfield), or are they installing a new site (greenfield)?
6.
Are they routing or using MPLS transport?
7.
Do they plan to grow the number of sites supported off of an existing CO?
Hub and Spoke Model

The Hub and Spoke model most frequently uses the services of a BTP to provide Leased Ethernet or EoS transport.
MLS routers become the hub sites, aggregating traffic for potentially thousands of cells.
The MSP services are transparent to the BTP devices, which merely move PPP or Ethernet frames between the UNIMT and UNI-MG. There is no routing in the BTP network, only point to point connections from the cell sites to the
MTSO.
For Ethernet base stations, the UNI-BS and UNI-NC are 100Mb/s or 1Gb/s Ethernet ports.
For ATM and TDM BS, the UNI-BS is SONET/SDH or bundled DS1s/E1s and the UNI-NC is ATM over SONET or
Ethernet.
The UNI-MT and UNI-MG could be either Ethernet, TDM, or SONET/SDH.
Backhaul Network Physical Topologies Hub and Spoke
Ring/Subtended ring partial or full mesh logical connectivity between

CSA and MLS
Subtended ring - Rings of greater traffic concentration nearer the MTSO
Rings provide physical and logical path redundancy and dual-homing
capability
Module 1 |
28
Backhaul Network Physical Topologies Ring/Subtended Ring

Ring and Subtended Ring
The ring and subtended ring topologies support partial or full mesh logical connectivity for high service reliability
and resiliency. The subtended rings provide increasingly greater traffic aggregation levels at the MTSO, and
support physical and logical path resiliency with dual-homed network nodes.
The rings may consist of 1Gb/s or 10Gb/s Ethernet links, or EoS links.
As in the Hub and Spoke model, Ethernet BS UNI-BS are 100Mb/s or 1Gb/s Ethernet ports. ATM and TDM UNI-BS is
SONET/SDH or bundled DS1s/E1s. The UNI-MT and UNI-MG could be either Ethernet or SONET/SDH, and the UNINC is ATM over SONET or Ethernet.
Backhaul Network Physical Topologies Ring/Subtended Ring
Points of concentration higher capacity nodes are located

closer to the MTSO
Helps reduce costs and complexity by placing lower cost nodes
nearer to cell site
Module 1 |
29
Points of Concentration
The Points of Concentration (POC) illustrate traffic concentration, or aggregation, levels. As traffic flows
downstream from the MTSO to the cell site, each POC level handles smaller aggregated traffic flows.
POC1
A POC1 (MLS) routers aggregate RNC, BSC, and EPC traffic for hundreds and possibly up to a thousand cell sites.
The POC1 routers must be highly reliable and support very high data rates, on average greater than 10Gbps. The
MLS routers provide redundant NC element links and load balance cell traffic between the redundant MLS pairs.
POC2
The aggregate ring POC2 routers concentrate traffic for an average of 50 to 60 cell sites, delivering toward the
POC3 routers an average of up to 500Mbps of traffic. They typically serve as MPLS LSRs, and may connect CSAs
directly to the aggregate ring.
POC3
The POC3 routers form the aggregate hub sites, concentrating traffic from up to 10 cell sites or more, handling an
average of up to 200Mbps of downlink traffic. These routers may be LSR, LERs, or both, and may switch traffic
from a VPWS to a L3 VPN. They may act as border routers between IGP areas.
CSA
The CSA can host 2, 3 and 4G base stations.
A 2G cell sector generates an average of up to 800 Kb/s downlink traffic
A 3G sector generates an average of about 4.2 Mb/s of downlink traffic
A 4G sector generates an average of about 24 Mb/s of downlink traffic
A 3-sector LTE cell site can generate an average of around 50 Mbp/s of combined downlink traffic.
NOTE: These are average figures, and a 4G base station might generate bidirectional peak traffic greater than
200Mbps. Hence, the various concentration levels must be capable of effectively handling peak data rates as well.
Points of Concentration (POC)
One-sector cell site average downlink bandwidth requirements

Common three-sector site multiply the one-sector bandwidth
requirement by 1.5-2.0
Module 1 |
30
Cell Site Average Downlink Data Rates

For TDM and ATM backhaul, the cell site traffic requirements are typically stated in terms of the aggregate
number of E1/T1 links. Typically, 1-2 E1/T1 links are required for 2G and 3G voice and low speed data per BS, plus
additional capacity for high speed data according to demand.
For IP backhaul, the aggregate traffic requirements at a cell site will depend on the technology and service mix at
the site. The table above gives representative average peak downlink requirements for a one-sector cell site. The
number of users a cell site can support varies depending on the type of traffic, location, population density, and
so forth, and can range from as few as 50 to over 100 users.
Cell site sectors
A sector is a channel or frequency. A transmission technology enables a set of frequencies, and a cell sites radios
support a sub-set of those frequencies. Adjacent cells cannot use the same frequency, otherwise co-channel
interference occurs. However, to insure full geographical coverage, cell site clusters can reuse frequencies as
long as they arent adjacent and are sufficiently separate to avoid co-channel interference.
The example above shows a cell site installation covering three sectors, with three sets of directional antennas
covering 120 degrees and creating a full circle. Adjacent towers dont use the same frequency in the same
coverage area. One example of a 3-sector cell site uses a single transmit and two receive antennas per sector,
with each sectors antennas operating on different channels. Each cell supports three channels, one in each of
the three directions.
To determine the bandwidth requirements for a three-sector cell, one could multiply the one-sector bandwidth by
a factor of 1.5-2.0 to arrive at an average peak downlink value.
Cell Site Average Downlink Data Rates
Model 1 Example Physical Architecture

This model employs a hub and spoke design
It supports both legacy IPBH traffic forwarded over bundled DS1s and EBH over
Ethernet and EoS
Leased BTP access provides the backhaul transport
Module 1 |
31
Model 1 Hub and Spoke Topology

VLL into MLS-hosted Local VPN Services
The Model 1 example architecture uses Ethernet and IP Inter-working pseudowires, ePipes and iPipes, respectively,
to transport cell site traffic, both TDM and Ethernet, to and from the MTSO MLS routers. The CSA router supports
both TDM and Ethernet-connected base stations, including LTE eNodeBs. The diagram also shows bundled DS-1s
terminating directly at the MLS routers to support 2 or 3G IP Backhaul (IPBH).
Not all customers use all VPWS, and Model 1 only describes e- and iPipe services. Though this diagram shows CDMA
components, this design is suited to GSM/UMTS applications, as well.
Physical Connectivity Hub and Spoke
The 2/3G CDMA NodeB and LTE eNodeB base stations connect to the CSA over bundled DS1s or 100Mbps (NodeB) or
1Gbps (eNodeB) Ethernet links. The CSA routers connect to the MEN over Gigabit Ethernet (GigE) links. The MLS
routers also connect to the MEN over GigE LAGs.
The EoS UNI and Multi-service Provisioning Platform (MSPP) devices are SONET Add/Drop Muxes accepting Ethernet
frames from the UNI-MT and UNI-MG.
TDM BS uplinks, whether terminated at the CSA or at the MLS routers, are bundled DS1s. IPBH bundles transit a T1
concentrator that delivers voice, data, and control traffic to the redundant MLS routers over protected OC-3 or
OC-12 links.
In this model, some customer cell sites include both Ethernet and TDM base stations.
Model 1 Hub and Spoke Topology
Model 1 - Ethernet Backhaul (EBH) - ePipes

3G voice, data and OAM ePipes terminate into MLS VPLSs
VPLS-VPRN cross-connect forwards traffic toward NC elements
Module 1 |
32
Model 1 ePipes, VPLS, and VPRN for 3G Ethernet Traffic

Ethernet Backhaul (EBH) - ePipes
EBH supports 2 and 3G voice and data over an Ethernet transport. At the CSA, E-Line, or ePipe services, accept
802.1Q-tagged Ethernet base station traffic on an access port. The base station forwards traffic on three VLANs;
one for 1x voice, another for DO data, and another for OAM traffic. The CSA passes these frames to one of three
individual ePipe services, one for each traffic type, passes the tunneled traffic to the MEN, and the MEN delivers it
to the MLS router.
Outer VPLS
At the MLS router, the ePipes terminate into one of three E-LAN, or Virtual Private LAN Service (VPLS), one for
each traffic type. The outer VPLS ties the base station ePipes into Ethernet broadcast domains. All base station
VLANs of the same traffic type terminate in a common outer VPLS, and the base station interface addresses come
from a common subnet, typically /29. A VPLS can support several hundred spoke-SDPs, and so each VPLS could
support 100s of base stations. The base stations host multiple interfaces, one for each traffic type.
Inner VPLS
An inner VPLS is used to support pooled NC elements and Virtual Routing and Redundancy Protocol (VRRP) NC
element virtual gateway interfaces. The inner VPLS services use interchassis LAG SAPs to provide redundancy and
forward VRRP signaling messages.
VPRN
Each VPLS service cross-connects to a VPRN interface, either through a physical loopback connection or a virtual
cross-connect. Optionally, in SROS release 8 and later, a routed VPLS (R-VPLS) might be used in place of the cross
connects to create a direct VPLS-VPRN L3 termination.
This VPRN interface becomes each base stations next-hop, or default gateway, to the NC elements and Packet
Data Network (PDN). Each VPRN isolates each traffic type to a virtual routing instance and runs an IGP to share
routes between redundant MLS VPRN instances.
The VPRNs include MTSO NC component interfaces; interfaces to the RNCs, the packet switch, the mobility
manager, and the data network. These interfaces run VRRP to present the NC elements redundant interfaces.
VRRP ensures only one active interface at a time, and allows automatic failover from the active to the standby
interface.
ePipes spoked into VPLS

Each NodeB interface has /27 address
Only one VPRN interface per subnet
Smaller VRF size, but added complexity of VPLS
Module 1 |
33
ePipe Spoke to VPRN Service Interface

The approach used in the Model 1 example is to terminate the CSA-MLS ePipes one VPLS per traffic type.
Again, the CSA routers provide the NodeB SAPs. Spoke SDPs carry tunneled traffic toward the MLS routers, and
terminate into a VPLS service.
The VPLS ties into a VPRN interface through either a physical hairpin or a Cross Connect Aggregate Group (CCAG)
provisioned on an SROS Versatile Services Module (VSM). The hairpin connects a VPLS Ethernet SAP to a VPRN port
using a jumper between the two physical ports. The VSM provides a 10Gb/s half-duplex virtual path between the
Layer 2 and Layer 3 services, and requires the VSM installed in one of the routers MDA slots. The VSM provides no
physical ports.
Address Allocation
Each ePipe acts as an extension of a VPLS virtual switch port. Since the VPLS is a Layer 2 service, it makes its
forwarding decisions based on MAC addresses, not IP addresses. Hence, each NodeB is addressed on the same subnet,
and the single VPRN hairpin or cross-connect interface becomes the NodeB gateway interface.
In the Routing Tables
The MLS router only maintains a route entry per NodeB subnet.
VPLS Forwarding Database (FDB)
The VPLS service FDB would contain an entry for the VPRN interface plus each NodeB. However, the VPLS services do
not share FDBs with the redundant MLS services, reducing inter-chassis control plane traffic compared the the ePipeVPRN approach.
ePipe Spoke to MLS Service VPLS Termination
ePipes spoked into VPRN interfaces

Each ePipe-VPRN spoke requires /30 address
VPRN VRF hosts separate entry for each NodeB
Module 1 |
34
ePipe Spoke to VPRN Service Interface

A possible alternate approach to terminating the CSA-MLS ePipes is to use spoke-sdp bindings into a VPRN service. As
shown above, the CSA routers provide the NodeB-facing Ethernet SAP. Spoke SDPs carry tunneled traffic from the CSA
routers to the MLS routers. Configured at the MLS are three VPRN services; one for voice, one for data, and another
for OAM traffic.
Address Allocation
Each ePipe acts as an extension of a VPRN virtual router port. Each VPRN interface must be on a different subnet, so
assigned to each is a /30 or /31 address. The NodeB at the other end of the wire also is assigned a /30 or /31
address. The directly attached VPRN interface is the individual NodeBs default gateway.
In the Routing Tables
The MLS router would maintain in the VPRN a VRF entry for each NodeB. The number of VRF entries would match the
number of NodeBs, up to several hundred in a large MTSO.
Also consider that the two MLS routers in a redundant MTSO would share these routes between like services, creating
significant inter-chassis control plane traffic.
ePipe Spoke to MLS Service VPRN Termination
R-VPLS takes the place of the VSM or external cross-connects

For routed connectivity, a VPLS may be bound to a single Layer 3
service interface
This interface becomes the gateway to the VPLS broadcast domain
The VPLS must be named and bound to the L3 interface by that name
Module 1 |
35
R-VPLS for VPLS-VPRN Service Cross-connect

Routed VPLS (R-VPLS) is another option for cross connecting L2 and L3 services (VPLS to IES or VPRN), supported in
SROS Release 8 and later. Routed VPLS allows binding a L3 service interface to a VPLS service.
Service Name
The VPLS requires an associated name. This is a text value configured on the service in addition to the service ID.
When you assign a service a name, SROS registers that name and its associated service ID. Each name can be
associated with only one service.
Allow the IP Interface Binding
Within the VPLS service, you must allow an IP interface binding. The router attempts to bind the service to an
interface if one is configured to bind to the service name.
Bind the L3 Interface to the VPLS
Within the IES or VPRN service interface context, you specify the VPLS service, by name, to which you want the
interface to bind.
Forwarding Between the Services
The bound interface becomes the gateway for customer traffic, just as was the cross connect interface. However,
this binding requires no loopback cables nor a VSM.
7705 SAR does not support R-VPLS.
R-VPLS for VPLS to VPRN Service cross connect
Model 1 Hub and Spoke Topology iPipes
Model 1 - Ethernet Backhaul (EBH) - iPipes

3G iPipes cross-connect into MLS VPRN interfaces
Carried over same transport as are ePipes
Module 1 |
36
Model 1 Hub and Spoke Topology - iPipes

Ethernet Backhaul (EBH) - iPipes
CSA iPipes accept TDM base station traffic over bundled DS1s. Configured on the BS and CSA are Multilink Bundles;
the CSA multilink bundles become the iPipe SAPs.
The BS is a Multilink-PPP (ML-PPP) endpoint. During the PPP network layer signaling phase the CSA uses the
Internet Protocol Control Protocol (IPCP) to send to the BS its IP address, usually with a /30 mask. The BS
forwards PPP encapsulated IP packets into the service SAP, and the CSA extracts the IP packets from PPP frames.
The CSA only tunnels the packets through the iPipe service.
At the MLS, the iPipe cross-connects into the MLS router VPRN, requiring another virtual cross-connect SAP and
interface. This interface has a /30 address assigned on the same subnet as that the CSA assigned to the URC.
Since the iPipe uses redundant pseudowires, the two MLS VPRN-iPipe cross-connect interfaces can share the same
IP address. Only one of the pseudowires is active, thus the MLS routers will only forward cell traffic through the
active pseudowire VPRN interface.
The VPRN routes the IP packets to the appropriate external network or NC element, and the NC facing interfaces
run VRRP for protection.
EPC
iPipes cross-connected to VPRN interfaces

Each iPipe endpoint gets /30 address
iPipe context at CSA and MLS routers
Module 1 |
37
iPipe to MLS Service Cross-connect Termination

An iPipe service transports the IP payload through a pseudowire, and on to a Layer 3 interface on the far end. This
diagram shows iPipes dedicated to each TDM NodeB or BTS. Both the CSA and the MLS routers are iPipe PEs, with both
SAPs and spoke-sdps associated with the service.
Address Allocation
Each iPipe gets its own /30 address space. iPipe CE devices must be IP capable, though the SAPs are Layer 2. On the
CSA, the iPipe terminates NodeB ML-PPP bundles. The NodeB is assigned an IP address, either statically or
dynamically using IPCP. We discuss IPCP more in the Module 2 ML-PPP section.
The MLS end uses a CCAG tied to a VPRN interface. As with the ePipe-VPRN configuration we discussed earlier, each
iPipe-VPRN interface is in its own subnetwork, requiring one VPRN VRF table entry per NodeB.
iPipe Applications
iPipes allow the service provider to maintain their current TDM NodeBs while upgrading to an Ethernet transport.
iPipes support a variety of Layer 2 interfaces, including ATM, Frame Relay, PPP and Ethernet, and support pseudowire
redundancy.
iPipes can only transport IP traffic.
iPipe to MLS Service Cross-connect Termination
iPipes spoked into VPRN interfaces

Each iPipe-VPRN spoke requires /30 address
Supported in SROS 8 and later
Module 1 |
38
iPipe to MLS Service Spoke VPRN Termination

SROS 8 and later add direct iPipe-VPRN spoke terminations. The iPipe CE must still be IP capable, and the iPipe must
cross connect to a Layer 3 interface at the PE. However, there is no need for the VSM cross connects.
Address Allocation
Each iPipe acts as an extension of a VPRN virtual router port. Each VPRN interface must be on a different subnet, so
assigned to each is a /30 or /31 address. The NodeB at the other end of the wire also is assigned a /30 or /31
address. The directly attached VPRN interface is the individual NodeBs default gateway.
In the VPRN Routing Tables
The MLS router would maintain, per VPRN, a VRF entry per NodeB. The number of VRF entries would match the
number of NodeBs, up to several hundred in a large MTSO.
Also consider that the two MLS routers in a redundant MTSO would share these routes between redundant VPRN
services, potentially creating significant inter-chassis control plane traffic.
iPipe to MLS Service Spoke VPRN Termination
Model 1 - IP Backhaul (IPBH)

2G IPBH traffic transported over bundled DS1s
Bundled DS1s terminate into VPRN interfaces
Module 1 |
39
Model 1 Hub and Spoke Topology - IPBH

IP Backhaul (IPBH)
IPBH supports 2G and 3G voice and data traffic transported over TDM links. The BS forwards ML-PPP frames to the
Digital Access Cross-Connect (DACS). The DACS multiplexes cell site traffic over Multi-chassis Automatic
Protection Switching (MC-APS) protected OC-3 or OC-12 circuits. The working and protect OCs connect to the 2
MLS routers.
Since this is purely routed service, the bundled DS1s become access ports associated with an MLS local VPRN
(shown above) or Internet Enhanced Service (IES) L3 interface. The base station and L3 interfaces have IP
addresses on the same subnet, usually with a /30 mask, and the MLS router interface becomes the next-hop for
packets leaving the base station into the carrier network. As in the iPipe example, the MLS uses IPCP to deliver the
BS address.
Model 1 Timing and Synchronization
EBH base stations derive their air interface and TDM interface timing from a local Global Positioning Service (GPS)
receiver. Since the EBH model uses an all Ethernet transport with only IP and Ethernet Protocol Data Units (PDUs)
tunneled between the CSA and MLS, the EBH CSAs need not implement a frequency or time distribution protocol.
The IPBH BSs may derive the air interface and circuit timing from a local GPS or the received DS1 signal.
Model 1 - Hub and Spoke Topology - IPBH
Model 1 - 4G LTE
4G ePipes terminate into MLS IES
BS-BS traffic routed through MLS IESs
MME VRRP interface supported through MLS local VPLS
Module 1 |
40
Model 1 ePipes, IES, and Local VPLS for LTE Traffic

4G/LTE
The 4G/LTE cell sites implement ePipes, as does the EBH deployment. The eNodeB uplinks are GigE links. Each
CSA terminates a User and and OAM ePipe. The ePipes spoke SDPs terminate into MLS layer 3 IES service
interfaces, which either forward traffic directly to the EPC components, or into an inner VPLS..
Since this model uses a hub and spoke topology, all traffic, including BS-BS traffic, must route through the MLS IES.
EBH/LTE Cell Site to MLS Logical Connectivity
In the EBH/LTE, static routes or a routing protocol provide routes to and from the CSA and MLS router System IDs.
Depending on the CSA used, IGP scaling limitations may dictate static routes. These routes support Multiprotocol
Label Switching (MPLS) Label Switch Paths (LSPs), one each between the CSA router and MLS1 and MLS2. The
VPWS used these tunnels as redundant pseudowires.
Bidirectional Forwarding Detection (BFD) ensures the PE routers, the CSA and MLS, learn of link failures quickly. In
this example, the PE routers may not know a link failure occurred in the MEN between the BT and BG nodes. BFD
runs between the UNI-MT and the UNI-MG interfaces, and informs the PEs if communication fails between the
interfaces.
The MLSs and the CSAs belong to the same OSPF area.
Model 1 4G/LTE Services
Model 2 Physical Architecture
Subtended Ring topology; access and aggregation rings

VPWS transport 2 and 3G legacy traffic to MLS routers
VPWS spoked to POC3 distributed VPRN for 3G and 4G Ethernet traffic
POC2 routers are service-transparent LSRs
Module 1 |
41
Model 2 Subtended Ring Topology

VPWS into Distributed Virtual Private Network (VPRN)
Model 2 uses a subtended ring architecture to extend a distributed VPRN service from the MTSO MLS router to the
POC3 routers. VPWS carry cell site traffic to the POC3 routers, which in turn forward it into the VPRN.
This model also supports legacy TDM and ATM BS, forwarding this traffic through cPipe and aPipe services
originating and terminating on the CSA and MLS routers.
Physical Connectivity Subtended Ring
Two rings handle cell traffic; the access ring dual homes up to 8 CSA routers while the aggregation ring dual homes
six POCx routers. The CSA routers physically connect to the access rings via 1Gbps Ethernet links and logically
dual-home to the two POC3 routers.
On the aggregation ring, the six POCx routers enable network scalability and redundancy and handle increasingly
greater amounts of aggregated cell site traffic.
The POC3 routers can host up to 3 access rings. They are dual-homed to the access and aggregation rings.
The POC2 routers could also host access rings, and are dual-homed.
The POC1 (MLS) routers aggregate traffic for hundreds of cell sites. All POC routers dual home to the 10GigE
aggregation ring. The POC1 routers dual-home to the NC elements using MC-APS, MC-LAGs, and VRRP.
Model 2 Subtended Ring Topology
Model 2 - Cell Site to MLS Base Connectivity

Access and aggregation rings are in separate ISIS areas
LSPs run between CSAs and POC3 routers, and between POC3 and POC1 routers
Psuedowire switching tunnels traffic across area boundaries
Module 1 |
42
Model 2 Subtended Ring Topology (cont)

Cell Site to MLS Base Connectivity
Routing
Each access ring is provisioned as separate ISIS level 1 area and all CSA routers on that ring form Level 1
adjacencies with their directly connected peers, including the POC3 routers if they are so connected. The POC3
routers serve as Level 1/2 routers, while the POC1 and 2 routers are in separate level 2 areas. Hence, the CSA
routers only maintain a Level 1 database, while the POC3 routers become the gateways to the other ISIS areas.
MPLS
MPLS LSPs exist between the POC1 and POC3 routers, and between the POC3 and the CSA routers, supporting
tunneled services across the ISIS areas and avoiding the need for a full LSP mesh between the POC1 and CSA
routers. For aPipe and cPipe services, pseudowire switching ties these LSPs together at the POC3 routers, which
act as the Switching PEs (S-PE) and switch service traffic from one area, LSP, and service tunnel to the next. The
S-PE swaps both the service and the tunnel labels when switching between areas.
MPLS FRR provides resiliency and fast failure detection for the distributed VPRN and VPWS. Upper and lower LSPs
configured with admin groups and standby paths provide efficient, redundant traffic paths between the LERs. BFD
insures timely failure recovery.
Model 2 Subtended Ring Topology Logical Connectivity
Model 2 - Backhaul Services

ePipes cross-connect into POC3 VPRNs
BS-BS traffic routed at POC3 interfaces
Module 1 |
43
Model 2 Subtended Ring Topology EBH Services

Backhaul Services
Each cell sites base stations may present to the CSA routers bundled DS1s (2G), Inverse Multiplexing over ATM
(IMA) interfaces (3G), and/or Ethernet (2, 3, and 4G) interfaces. As shown, the CSA routers connect either directly
to the POC3 routers or to other CSA routers on the same access ring.
ePipes
Redundant ePipes tunnel Ethernet base station traffic between the CSA and the POC3 routers. Each redundant
pseudowire terminates on a different POC3 router. A spoke binding connects the ePipe to the distributed VPRN
service.
Since the ePipes use redundant psuedowires, only one psuedowire can be active at a time. Hence, the CSA
forwards BS traffic only to the VPRN interface associated with the active pseudowire. Both POC3 routers can
assign the same /30 IP address to the spoke interfaces.
(continued on next page...)
Model 2 Subtended Ring Topology EBH Services

cPipe and aPipes terminate directly into MLS router STM-1 access ports
POC3 routers switch tunneled traffic from access to aggregate rings
Module 1 |
44
Model 2 Subtended Ring Topology Legacy Services

Backhaul Services (continued from previous page)
Redundant Circuit Emulation pseudowires (cPipes) and ATM Pipes (aPipes) deliver TDM and IMA traffic directly to
the two MLS routers. At the MLS routers, MC-APS protected, channelized Synchronous Transport Mode (STM)-1
TDM SAPs deliver packets to the Base Station Controllers (BSC).
cPipes
The cPipe service can transport either structure-aware (channelized) or unstructured (unchannelized) E1 carriers.
For Mobile Backhaul applications, structure-aware cPipes more efficiently utilize the E1 bandwidth, as a single E1
can support multiple DS0 channel groups and associated SAPs.
aPipes
The aPipe transports User Network Interface (UNI) cells to a set of n x E1 ports configured as IMA group members.
Up to 16 base station ports can be members of the same IMA group.
Using N:1 cell mode encapsulation configured for virtual channel concatenation, the aPipe service transports a
specific virtual channels complete cells to the far end ATM switch.
Model 2 Subtended Ring Topology Legacy Services
BTS
Switches service traffic from one SDP to another at intermediate node

Reduces full mesh requirement between CSA and MLS routers
Connects traffic engineered LSPs across routing areas
Requires vc-switching configured in S-PE service context
Module 1 |
45
Pseudowire Switching on VPWS

The SROS pseudowire switching feature allows you to create a VPWS by cross-connecting two spoke SDPs at an
intermediate node. This supports network scaling to increase the number of Terminating PE (T-PE) devices while
reducing the number of T-LDP bindings on the service endpoints. It also extends traffic engineered services across
area boundaries while eliminating additional protocol sessions, such as those created when using LDP-over-RSVP
tunnels.
Service configuration, Terminating PE (T-PE) nodes
Each PE requires a SAP and an SDP per service. The SDP, however, targets the switching node, here shown as POC3,
rather than the far-end PE, the MLS router. Service configuration on the T-PEs requires no additional steps besides
those required for the basic service.
Service configuration, Switching PE (S-PE) nodes
The switching node has a like service configured, with two spoke SDP bindings, one to carry traffic to the CSA router
and another to the MLS router. Adding the command vc-switching to the S-PE service configuration tells it to act as
a passive, slave device in the service context.
The T-PE passes SAP configuration information, such as MTU size, along with the service label to the S-PE. The S-PE,
upon receipt of this label message, verifies the message and appends a pseudowire switching TLV to the service FEC
TLV. The S-PE then forwards the label message to the far-end T-PE node, where the service terminates.
SDP Bindings
As shown in the diagram, each service requires CSA-POC3 and POC3-MLS router spoke SDPs. The MLS does not
terminate each CSA spoke; these terminate at the POC3 routers. Instead, the services travel the same SDP set
between the POC3 and MLS routers.
In other words, the MLS router does not terminate 100s of SDPs, one for each CSA router. Instead, it only terminates
one SDP set per POC3 router.
We discuss pseudowire switching in more detail in Module 3.
Pseudowire Switching on VPWS
Model 2 - Timing and Synchronization SyncE and SSM

MLS1 distributes network timing from Primary Reference Clock (PRC)
Nodes use Synchronous Ethernet (SyncE) for TDM interface and
NodeB/eNodeB RF timing
Nodes forward Synchronization Status Message (SSM) messages for clock
traceability
Module 1 |
46

Timing and Synchronization
C and aPipe services support synchronous access interfaces. Additionally, the cellular radios require accurate
timing for frequency and phase synchronization to support reliable handoff between cells.
To ensure proper timing at the base station and MLS routers, this network incorporates Synchronous Ethernet
(SyncE) with Synchronization Status Message (SSM) timing reference distribution on the access and aggregation
rings.
The MLS1 router derives its primary timing from the MTSO Building Integrated Timing System (BITS) reference
clock. The MLS router access and aggregate ring ports are SyncE enabled. This model also incorporates SSM to
provide each node clock quality and traceability information. The receiving nodes track the master clock source
and avoid timing loops, only slaving to a single, qualified source.
The network nodes, including MLS2, synchronize their master clocks off the ring ports, which in turn provides the
CSA TDM interface timing references.
Resilient hub and spoke topology

Support for 2, 3 and 4G services
Overlay services possible over same infrastructure
Scalable to thousands of base stations
Module 1 |
47
Model 1 Network Key Design Points

The Model 1 network design uses a hub and spoke physical topology. All Layer 2 (pseudowire) services terminate
at the MTSO MLS routers. ePipes and iPipes deliver IP voice, data and control traffic to the MLS routers via spoke
SDPs terminated into Layer 2 or 3 VPN services.
EPipe and iPipe services support 2 and 3G BSs, while ePipes support 4G/LTE BSs. The MPLS transport can carry all
traffic types simultaneously; this is called an overlay model. The MLS routers become routing hubs for all the
various components, both legacy and 4G. For IPBH , MC-APS protects the working and protection OCx circuits.
The overlay model ensures easy network expansion by simply adding additional cell sites, CSA routers, and
pseudowires without impacting current customer traffic. Physical, transport, and service redundancy ensures
predictable service levels, and advanced Quality of Service (QoS) features guarantee the appropriate traffic
treatments end-to-end.
Static routes are deployed to address cell site router scalability limitations, such as the maximum number of OSPF
adjacencies the router can support. BFD ensures rapid failover between physical links, and LDP simplifies
administration.
Efficient, resilient 2, 3 and 4G connectivity

Scalable - Dynamic cell site learning
Efficient eNodeB to eNodeB routing
Module 1 |
48

The Model 2 subtended ring topology ensures full link layer redundancy throughout this network. The access ring
physically connects the CSA routers into two different POC3 routers, and the network control elements terminate
onto redundant POC1 routers. The aggregation ring connects each POC1 router to two POC2 routers.
This design leverages pseudowire switching and multilevel routing hierarchies to potentially scale a region to
thousands of cell sites per MTSO. By terminating the Ethernet pseudowires at the POC3 level, they efficiently
route LTE eNodeB-to-eNodeB traffic as near the cell sites as possible. Pseudowire redundancy protects the service
endpoints.
The distributed VPRN services learn new cell site networks as soon the service provider adds them, and
Multiprotocol-BGP (MP-BGP) automatically distributes the sites forwarding information to other POC1 and 3
routers.
aPipes and cPipes switched at the POC3 routers transport Legacy BS traffic. Service-aware QoS ensures that
routers at all levels treat the network traffic appropriately.
MPLS Fast Reroute (FRR) provides sub-50ms ring failure detection. For additional protection, this design augments
the IGP timers and FRR with BFD for rapid link failure detection.
Section Summary
The physical Backhaul topology options

Hub and spoke The MLS routers are the hub nodes and the
CSAs are the spoke nodes
Ring/subtended ring Multilevel aggregation over two or
more redundant physical rings
Roles of the POC1, 2, and 3 and CSA routers
POC1 for large scale aggregation averaging greater than 500
cell sites
POC2 for aggregating up to 60 cells
POC3 as hub sites aggregating up to 10 or more cells
CSA routers to originate cell services for an average of
around 50Mb/s of traffic
Module 1 |
49
Section Summary (cont)

VPWS terminated into MLS-hosted local Layer 2 and Layer 3
VPNs
ePipes for Ethernet base station traffic
iPipes for TDM base station traffic
VPLS and VPRN services for hub site traffic aggregation

ML-PPP bundles for IPBH traffic
BFD on cell to MTSO links for rapid link failure detection
GPS timing and line timing cell site for air and TDM
interface synchronization
Module 1 |
50
The Model 1 architecture Hub and Spoke to provide:

ePipes terminated into distributed VPRN services
aPipes for ATM base station traffic
cPipes for TDM base station traffic
Hierarchical routing for forwarding table stability and
smaller CSA and POC3 forwarding databases
Pseudowire switching to connect traffic engineered tunnels
across area boundaries and reduce meshing requirements
SyncE and SSM for network timing distribution
Module 1 |
51
The Model 2 architecture Subtended Ring to provide:

Section 3 Mobile Backhaul Transport Network Components
Section Objectives
Position Alcatel-Lucent network elements in the IP/MPLS Mobile

Backhaul Transport network
Learn each network elements functional role supporting 2 and 3G
traffic
Learn each network elements functional role supporting 4G/LTE
traffic
Module 1 |
54
In this section, we will:
Alcatel-Lucents Mobile Backhaul Solution
Suitable to either MSP or BTP customer

Leverage existing physical network
Supports array of access technologies
Support for 2, 3, and 4G backhaul
7750 SR Family
7450 ESS Family
7705 SAR Family
Module 1 |
55
7210 SAS Family
Alcatel-Lucents Mobile Backhaul Solution

Alcatel-Lucents service router portfolio ideally implements a Mobile Backhaul Transport end-to-end solution:
Suitable for either MSP or BTP customer An MSP can extend their own infrastructure with additional ports and
interfaces. A BTP can build upon their current physical plant to support multiple MSP customers.
MPLS support to leverage existing physical network MPLS enables ATM, TDM and Ethernet pseudowires over a
single transport infrastructure.
Supports many access technologies Fiber, microwave, TDM, Digital Subscriber Line (DSL), Ethernet leased lines.
Allows service provider to reuse existing access technologies and deploy high rate voice and data services.
Support for 2, 3, and 4G backhaul ATM, TDM/SONET, and Ethernet ports all supported on a single chassis.
Ethernet, PPP, ML-PPP, and Ethernet over SONET support on a single node, depending on the product installed.
Psuedowire and VPN support VPWS, VPLS, and VPRN supported on all but the 7210 Service Aware Switch (SAS).
Advanced hierarchical QoS for meeting strict Service Level Agreements (SLAs)
Physical and logical resiliency MC-APS, MC-LAG, MPLS FRR, and pseudowire redundancy support. Non-stop
routing (NSR) and Non-stop forwarding (NSF) on products with control plane redundancy built in.
Alcatel-Lucents service router portfolio ideally implements an endto-end Mobile Backhaul Transport solution:
Alcatel-Lucent supports the Backhaul Transport Network end-toend with a wide range of service router products
Module 1 |
56
Alcatel-Lucent Product Placement

Alcatel-Lucent (ALU) offers products ideally suited for each Backhaul Network point of concentration.
POC1
The POC1 (MLS) routers terminate the MSP services. They handle an aggregate average of 10Gbps of traffic from
300 to 1000 cell sites. When connected to a BTP network, these routers accept traffic delivered from the BG
nodes and groom that traffic for delivery to the NC elements. When the MSP owns the network, they physically or
logically cross-connect the MSPs L2 and L3 services. They may terminate a- and cPipes for 2G and 3G TDM and
ATM traffic.
The POC1 routers route traffic to external networks, maintain IGP and EGP peering sessions, and may route LTE
BS-BS traffic. They overcome any NC element Address Resolution Protocol (ARP) cache and Media Access Control
(MAC) address table limitations. They support Multichassis-LAG (MC-LAG) and MC-APS and bundle ATM IMA traffic
into STM-1, OC-3, or n x T1/E1 links. They connect the MTSO to the Backhaul core network.
They are highly available, easily expanded, and support a wide array of physical ports.
POC2
For the MSP, the POC2 routers serve as MPLS LSRs; when they belong to the BTP, they act as PE devices. POC2
routers service traffic from an average of 50 to 60 BSs, handling an average of 500Mbps of cell site traffic.
The POC2 routers support 1 and 10Gbps Ethernet uplinks, MPLS FRR, LAGs, and Layer 2 VPN services. They are
highly available and easily expanded.
Continued on next page...
Alcatel-Lucent Product Placement
Alcatel-Lucent supports the Backhaul Transport Network end-toend with a wide range of service router products
Module 1 |
57
Alcatel-Lucent Product Placement (cont)

POC3
The POC3 routers may either originate and terminate MSP or BTP Layer 2 and 3 VPN services, or act as an MSP or
BTP LSR, forwarding traffic through the transport network. For the MSP that owns the transport network, the
POC3 routers aggregate traffic from multiple CSAs.
For a BTP, the POC3 routers may aggregate multiple MSPs cell site traffic into VPWS SAPs, Ethernet VLANs, or
TDM uplinks. These routers handle average aggregate cell site traffic of 200Mbps, and support MPLS FRR, Ethernet
OAM, Ethernet timing distribution, control and data plane redundancy and TDM and Ethernet ports. They are
highly available and may be temperature hardened.
The CSA Router
The CSA router performs TDM and Ethernet media conversion, and acts as an MSP Provider Edge (PE) router,
originating the cell site VLL or VPRN services. For an MSP connected through a BTP, the CSA router consolidates
BS traffic for delivery into the leased Ethernet or TDM circuits.
The CSA must deliver reference timing to the TDM interfaces, including the BTS or NodeB. It supports end-to-end
QoS and OAM functionality. The CSA handles average cell site traffic of 50Mbps, and supports MPLS FRR, Ethernet
OAM, TDM and Ethernet access ports, Link State routing protocols, and BFD. It is temperature hardened and may
include high availability features.
Alcatel-Lucent Product Placement (cont)
Alcatel-Lucent 7750 SR-7 and SR-12
250 Gb/s FD capacity
7750 SR-12
The 7750 SR-7 and -12 are ideal for POC1 and POC2 roles
High availability Redundant control, power, and cooling
Highly scalable forwarding tables - >200k IGP routes and >30k MPLS
FIB entries
Modular upgrades
Wide array of physical interfaces
Module 1 |
58
Alcatel-Lucent 7750 SR-7 and SR-12

At POC1 and POC2, the routers must provide high forwarding table scalability, high reliability, control and data
plane resiliency and support for converged gateway functions to support service upgrades. The Alcatel-Lucent
7750 SR-7 and SR-12 platforms are ideal in this application.
Common features (9.0R2):
Cooling, power and control plane redundancy
Load sharing and redundant dual switch fabric modules supporting graceful degradation
IPv4 and IPv6 BGP, ISIS, and OSPF support
Full SR-OS feature set
Full featured MPLS support FRR, RSVP-TE, Label Distribution Protocol over Resource Reservation Protocol
(LDPoRSVP) tunnels, inter-area RSVP-TE
Full SROS service set VPRN, VPLS, VPWS (aPipe, cPipes, ePipe, fPipe, iPipe), redundant pseudowires,
pseudowire switching, Routed-VPLS (R-VPLS)
Line rate (50Gb/s) filter, routing and QoS policy processing
Highly scalable routing and forwarding databases
Multiple access technologies support: TDM, ATM, Ethernet, Dense Wavelength Multiplexing (DWDM), 100Gb/s
Ethernet, OC-768/STM-256c DWDM,
IP, MPLS and Ethernet OAM and service assurance tools
7750 SR-7
58
Alcatel-Lucent 7750 SR-c12
45 Gb/s FD capacity
The 7750 SR-c12 is ideal for POC1 and POC2 roles

Highly scalable forwarding tables - >200k IGP routes and >32k MPLS
FIB entries
Wide array of physical interfaces
Lower cost than SR-7 or SR-12, but supports the same feature set
Module 1 |
59
Alcatel-Lucent 7750 SR-c12

At POC1 or POC2, the Alcatel-Lucent 7750 SR-c12 platform is ideal when the greater port density of an SR-7 or SR12 is not required.
Features (9.0R2):
IPv4 and IPv6 BGP, ISIS, and OSPF support
Full SR-OS feature set
Full featured MPLS support FRR, RSVP-TE, Label Distribution Protocol over Resource Reservation Protocol
(LDPoRSVP) tunnels, inter-area RSVP-TE
Full SROS service set VPRN, VPLS, VLL (aPipe, cPipes, ePipe, fPipe, iPipe), redundant pseudowires, pseudowire
switching, Routed-VPLS (R-VPLS)
Line rate (4 Gb/s/CMA, 10Gb/s MDA) filter, routing and QoS policy processing
Multiple access technologies support: TDM, ATM, 10Gb/s Ethernet
7750 SR-c12
Alcatel-Lucent 7450 ESS-6, ESS-7, and ESS-12
80 Gb/s FD capacity
7450 ESS-7
7450 ESS-12
The 7450 ESS-6, -7, and -12 are ideal for POC2 and POC3 roles
Support for modular upgrades
1 and 10 Gb/s Ethernet support
Investment protection through mixed mode (ESS and SR features)
support
Module 1 |
60
Alcatel-Lucent 7450 ESS-6, ESS-7 and ESS-12

At POC2 and POC3, the routers must provide resilient control planes and modularity to support additional
interfaces and grow with the service mix. They must leverage high capacity rings, and be optimized to support
fiber optic links. The Alcatel-Lucent 7450 ESS-6, -7, and -12 platforms are ideal in this application.
Common features (9.0R2):
Load sharing and redundant dual switch fabric modules supporting graceful degradation
IPv4 ISIS and OSPF support Full featured MPLS support FRR, RSVP-TE, Label Distribution Protocol over Resource
Reservation Protocol (LDPoRSVP) tunnels, inter-area RSVP-TE
Full Ethernet service set support VPLS, ePipe, redundant pseudowires, pseudowire switching, Routed-VPLS (RVPLS)
Line rate filter, routing and QoS policy processing
Multiple access technologies support: Ethernet, 100Gb/s Ethernet, MPLS and Ethernet OAM and service assurance
tools
ESS-7 and -12 only
Mixed mode operation supported on ESS-7 and ESS-12 to allow use of certain 7750 SR Input/Output Modules
(IOMs), Integrated Media Modules (IMMs), MDAs, and features, including VPRN support
BGP and IPv6 supported in Mixed mode on ESS-7 and -12
VPRN supported in Mixed mode
TDM, ATM, and OC-768/STM-256c DWDM IP in Mixed mode on the corresponding SR family IOMs and MDAs
7450 ESS-6/6V
Alcatel-Lucent 7705 SAR Family
1 Gb/s FD capacity
7705 SAR-8
7705 SAR-18
6 Gb/s FD capacity
70 Gb/s FD capacity
The 7705 SAR-F is ideal for CSA role

The 7705 SAR-8 is ideal for POC3 and CSA roles
The 7705 SAR18 is ideal for POC1, 2 and 3 roles
High availability SAR-8 and SAR-18 feature redundant control,
power, and cooling
SAR-8 Extended Temperature Range (ETR) variant available
Module 1 |
61
Alcatel-Lucent 7705 SAR-8 and SAR-18

At the cell site the routers must be compact, temperature hardened, rugged, low cost, and provide an appropriate
mix of interfaces for multiple generations of base stations and media.
SAR-F, SAR-8, and SAR-18 common features (4.0R2):
IPv4 BGP, ISIS, and OSPF support, IPv6 interfaces and static routes
Full featured MPLS support FRR, RSVP-TE, primary and secondary LSP paths, Shared Risk Link Groups (SRLG)
SROS service set support VPRN, VPLS, VLL (aPipe, cPipes, ePipe, iPipe), redundant pseudowires, pseudowire
switching
Media conversion supporting multiple access technologies: TDM, ATM, Ethernet, ML-PPP
SAR-8 and SAR-18 common features (4.0R2):
Cooling, power, control plane, and switch fabric redundancy
SAR-18-unique features (4.0R2):
70 Gb/s full duplex capacity sufficient to place at POC1, 2 or 3
12 2.5 Gb/s and 4 10Gb/s (future use) MDA slots
Higher port density and capacity for higher aggregation rates
SAR-8-unique features (4.0R2):
Temperature hardened variants for cell site installation
7705 SAR-F
7210 SAS-D
7210 SAS-E
7210 SAS-M
Up to 10 Gb/s FD capacity
The 7210 SAS family is ideal for the CSA role

Low cost and rugged - ETR variants available
Up to 64 Gb/s switching fabric on SAS-M 10GigE model
Support for TDM and Ethernet interfaces
Module 1 |
62
Alcatel-Lucent 7210 SAS-E, M, and D

7210 SAS features (3.0R3):
SAS-D with 6 fixed Gigagit Ethernet SFP ports and 4 fixed 10/100/1000Base-TX copper ports
SAS-E with 12 fixed Gigabit Ethernet SFP ports and 12 fixed 10/100/1000Base-TX copper ports
SAS-M, SAS-M 10Gigabit Ethernet, and SAS-M 10Gigabit Ethernet-ETR variants available
Extended temperature range variants available
44 Gb/s and 64 Gb/s (10GigE variant) switching capacity
4 x T1/E1 expansion module available (standard SAS-M)
Common features:
Compact, edge devices
SROS based operating system
Layer 2 VPN support: VPLS, ePipe; SAS-M - cPipe
H-QoS
MPLS support (SAS-M)
SyncE and IEEE 1588v2 support
Alcatel-Lucent 7210 SAS-E, M, and D
.5 Hour
Module 1 |
63
Lab Objectives:
Verify pre-provisioned cards and ports using show commands
Verify Ethernet and TDM port characteristics
Verify pre-provisioned interfaces using show and OAM commands
Verify the routing configuration and route tables
Lab 1: Verify the Model 1 Ethernet Transport
Section Summary
Each nodes role in transporting 2, 3 and 4G traffic through the

backhaul transport
Where the Alcatel-Lucent SROS products best fit in the Backhaul
Network
Module 1 |
64
Module Summary
The names and descriptions of the network elements found in the

cell sites, the transport network, and in the MTSO
Of the two Backhaul Transport customer types the Mobile
Service Provider (MSP) and the Backhaul Transport Provider (BTP)
The demarcation points between the BTP and the MSP networks
Key services provided by Mobile Backhaul Transport standards
bodies
Factors which have driven the move toward a converged Backhaul
Transport architecture
Of two Backhaul Transport architectures in use today hub and
spoke and subtended ring
The traffic aggregation levels provided by the network nodes
Module 1 |
65
In this module, we learned:
Module Summary (cont)

In this module, we learned:
The services used to aggregate traffic from hundreds of cells sites

at the MLS routers VPLS and VPRN
Redundancy capabilities available to both hub and spoke and
subtended ring topologies
Timing and synchronization options available for both TDM and RF
timing
Where the SROS products fit in the listed concentration levels
7750 SR-7, -12 and -c12 at POC1 and 2
7450 ESS-6, -7, and -12 at POC2 and 3
7705 SAR at POC3 and CSA
7210 SAS at CSA
Module 1 |
66
The service types used to transport cell site traffic to the MTSO
routers ePipes, iPipes, aPipes and cPipes
Module Review Questions
a) Base Station Controller (BSC)

b) Radio Network Controller (RNC)
c) Serving Gateway (SGW)
d) Policy and Charging Rules Function (PCRF)
2. Which two NC elements are found in the Evolved Packet Core (EPC)?
(choose two)
a) Serving Gateway (SGW)
b) Gateway GPRS Support Node (GGSN)
c) Mobile Switching Center (MSC)
d) Mobility Management Entity (MME)
Module 1 |
67
Answers:
1. a, b
2. a, d
1. Which two of the following are considered Global Systems for Mobile
(GSM) Network Control (NC) elements? (choose two)
3. Which statement is a true characteristic of a Backhaul Transport Provider

(BTP)?
a) The BTP owns the entire network, end-to-end
b) The BTP owns the BTP Aggregation Gateway and the BTP Termination
devices
c) The BTPs demarcation points are the MSP Termination and MSP
Gateway devices
d) The BTP always transports traffic from a single MSP
4. Which two of the following devices are parts of a Mobile Service Provider
(MSP) network? (choose two)
a) Base stations (BS)
b) Evolved Packet Core (EPC)
c) BTP Aggregation Gateway (BG)
d) BTP Termination Device (BT)
Module 1 |
68
Answers:
3. B
4. a, b
Module Review Questions (cont)
5. Which standards body developed the current LTE network specifications?

b) 3GPP2
c) MEF
d) 3GPP
6. Which standards bodys work included developing standards for cdma2000
and EV-DO Rev A?
a) IEEE
b) 3GPP
c) 3GPP2
d) IETF
Module 1 |
69
Answers:
5. D
6. c
a) ITU-T
a) Core network functionality

b) Internet applications and protocols
c) Next-generation services
d) Broadband service delivery
8. The 3GPP standards cover what two technologies? (Choose two.)
a) GPRS
b) cdmaOne
c) EV-DO
d) LTE
Module 1 |
70
Answers:
7. a, c, d
8. a, d.
7. The ITU-T develops and maintains recommendations for what three

network functions? (choose three)
a) Point of Concentration (POC) 1

b) POC2
c) POC3
d) Cell Site Aggregator (CSA)
10. A combined 3G and 4G cell site CSA node handles, on average, how much
downlink cell site traffic?
a) 50 Mb/s
b) 200 Mb/s
c) 500 Mb/s
d) 50 Gb/s
Module 1 |
71
Answers:
9. a.
10. a.
9. In a hub and spoke Backhaul topology, which nodes aggregate the

greatest amount of cell site traffic?

11. In a subtended ring topology, how might the carrier overcome the need
for a full mesh between the CSA and the POC1 routers?
b) Deploy hierarchical routing at different concentration levels
c) Use only point-to-point services between the cell sites and the Network
Control (NC) elements
d) Use distributed services between the cell sites and the POC1 routers
12. How do IP Backhaul (IPBH) services differ from Ethernet Backhaul (EBH)
services?
a) IPBH services only use IP Interworking Pipes (iPipes) from the cell site
to the MTSO while EBH may use all Virtual Private Wire Service (VPWS)
b) EBH services include both bundled DS1s and Ethernet links as the
Backhaul Transport while IPBH exclusively uses Ethernet links
c) IPBH services carry cell site traffic to the MTSO over bundled DS1 links,
while EBH uses either Ethernet or Ethernet over SONET (EoS) transport
d) EBH services support all but Circuit Emulation Service (CES) Pipe (cPipe)
services; IPBH bundled DS1s must carry cPipe traffic
Module 1 |
72
Answers:
11. b.
12. c.
a) Terminate all cell site tunnels on only one of the MLS routers
a) Directly at the CSA node

b) Within the LTE VPLS at the MLS
c) Within the LTE IES at the MLS
d) Through the MLS to the Serving Gateway (SGW)
14. In the subtended ring model presented in this module, what function do
the POC2 routers provide?
a) They switch traffic between routing areas
b) They serve as Label Switch Routers (LSRs)
c) They terminate cell site tunnels
d) They provide access ring redundancy
Module 1 |
73
Answers:
13. c.
14. b.
13. In the hub and spoke model mentioned in this module, how does eNodeBto-eNodeB traffic route?
Module 1 |
74
www.alcatel-lucent.com

Transport
Module 2 Implementing the Mobile Backhaul Transport Network
Module Objectives
VLAN Tagging
Port MTU
Port hold timers
Describe TDM access port components and configuration
SONET/SDH framing formats
SONET/SDH hierarchical payload transport
Channelized and unchannelized OC-x/STM-x port build out
Provision ATM IMA and ML-PPP bundles for services access
View the completed bundle configuration and status
Module 2 |
Alcatel-Lucent Mobile Backhaul Transport Network

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See www.alcatellucent.com/src for more information on the SRC program.
To locate additional information relating to the topics presented in this manual, refer to the following:
Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts
Technical support pages of the Alcatel-Lucent website located at: http://www.alcatel-lucent.com/support

Describe Backhaul Ethernet access port components and configuration
Module Objectives (cont)
Describe the Building Integrated Timing Supply (BITS) and the North
American Timing Hierarchy
Explain node and circuit timing options, both physical and packet-based
Physical TDM line timing, GPS, Synchronous Ethernet
Packet-based IEEE 1588v2/Precision Time Protocol (PTP) v2
Compare and contrast frequency and phase/Time of Day (ToD) timing
requirements and techniques
Explain and trace Synchronous Ethernet and Synchronization Status
Message (SSM) operations and message flow
Configure and observe SyncE and SSM in the Model 1 network
Module 2 |
Module Objectives (cont)

Configure and observe IEEE 1588v2 and PTPv2 in the Model 1 network
Describe routing as implemented in the Model 1 and Model 2 topologies
Configure BFD and LDP-Sync on static routes in the Model 1
topology
Adjust IGP timers to support faster convergence and reduced SPF
processing
Implement IGP routing in the Model 1 Hub and Spoke topology
Provision iBGP route reflectors to support L3 VPN services
Implement MPLS LSPs and SDPs in the Model 1 network
Module 2 |
Describe the PTPv2 message format and trace IEEE 1588v2/PTPv2

message flow in the Model 2 network
Module 2 Implementing the Mobile

Backhaul Transport Network
Section 1 Mobile Backhaul Service Access Interfaces

Describe Ethernet port configuration requirements
MTU
VLAN tagging
Port hold timers
Describe TDM port configuration requirements
SONET Virtual Tributary (VT) and VT Group build out
SDH Virtual Container (VC), Tributary Unit (TU), Tributary Unit Group
(TUG) build out
7750 SR Any Service Any Port (ASAP) MDA port provisioning procedures
DS1/E1 access port provisioning clock source, channel groups,
encapsulation
Inverse Multiplexing over ATM (IMA) bundle provisioning
Multilink-PPP bundle provisioning
Configure Ethernet and TDM access ports to support Backhaul services
Module 2 |
Section Objectives
A base station, an NC element, or the transport network may require

the following Ethernet port configurations:
VLAN tagging
Large or small frame size support
Fixed port speed and duplex settings
Port hold time settings
7705 SAR 8-Port GigE/FastE Ethernet MDA v2

Part number 3HE02776AB
7750 SR 20-Port 10/100/1000 Mb/s RJ45 MDA XP

Part number 3HE03613AA
Module 2 |
7x50 Ethernet Port Configuration

The BS and NC elements gain access to the Backhaul Transport services through router access ports. When an
Ethernet transport interconnects the CSA and POC routers, router network ports move traffic up and downstream.
Where the network elements require Ethernet connectivity, the designer must configure the router network and
access ports to suit the traffic delivered into and out of the backhaul services.
A number of factors come into play when choosing how to configure the Ethernet ports. The type of devices
connected to the UNI-BS and UNI-NC, the CSA and MLS physical capabilities, the deployed service types, and the
service and network port MTUs all have a bearing on the access port configurations. For example, a NodeB may
only accept 100Mb/s half-duplex links, where an eNodeB requires 1Gb/s full duplex.
Alcatel-Lucent solutions design teams work from a set of blueprint documents when planning for a customers
network deployment, and those blueprints specify the required and optional specifications the design must meet.
The design teams also must consider the types of base stations and network control elements the customer has in
place or plans to install, and configure the network nodes to meet all these design needs.
The 7x50 products offer many Ethernet port configuration options. Depending on the platform and port type,
ports can be configured to support tagged or untagged frames, a range of MTU sizes up to jumbo frames, fixed
data rates and duplex settings, and more.
7x50 Ethernet Port Configuration
Ethernet network port encapsulation type can be configured as one of

the following:
null no tags, all traffic on that port is on the same VLAN
dot1q accepts a 4 byte VLAN tagged frame
Additionally, on access ports, all products but the 7705 SAR support:
qinq - adds two stacked VLAN TAGs
Module 2 |
Ethernet Port Encapsulation

Not all devices set or expect VLAN tags. For example, a customers eNodeB may set no tag on egress and expects
no tag on ingress. Thus, the connected routers access port is set for null encapsulation.
On the other hand, an Ethernet capable NodeB uses the same Ethernet port for voice, data, and OAM data, and
each traffic type must be isolated to its own broadcast domain. The NodeB sets a unique VLAN tag per traffic
type, and expects the same in return. The NodeBs access port is set for dot1q encapsulation.
Encapsulation Options All platforms
All SROS platforms present these two access and network port encapsulation options:
null The port can only be used by a single service SAP.
dot1q The router uses incoming VLAN tags to determine the service to which the data belongs. The access
port can be used by multiple service SAPs. The router will set a VLAN tag on data egressing toward the BS or NC.
Encapsulation Options Access ports, all except the 7705 SAR
The 7210 SAS-M, 7450 ESS and 7750 SR support a third access port encapsulation option:
qinq Stacked VLAN tags identify the VLAN and the customer to which a frame belongs. An MSP would not
normally use stacked tags at the BS or MTSO, but a BTP could potentially use these when transporting traffic for
multiple MSPs, assigning to each a unique tag value. This outer tag value identifies the MSP customer while
maintaining the tags the MSP set to identify the transported service traffic.
Ethernet Port Encapsulation
Ethernet Port MTU Size
Eth. Frame
Bytes
Network
Null
Dot1q
Null
Dot1q
IFG
12
Preamble
DA
SA
Type
VLAN
Tunnel
PW Header
CW (opt)
12
12
RTP Header (opt)

Payload
1500
FCS
1500
1500
1514
1518
1514
1518
1552
1560
4
Total:
Module 2 |
Ethernet Port MTU Size

MTU
The port MTU determines the largest Layer 2 PDU the router can accept on a port. Each encapsulation type sets a
unique default MTU size to allow for the additional VLAN tag header fields, as required. The routers do not count
the Frame Check Sequence (FCS) in the MTU calculated, and the MTU is CLI configurable.
On network ports, the MTU needs to allow for MPLS tunnel and service labels and control words. The 7x50 routers
will not fragment Layer 2 service payloads, so the network port MTUs must be sufficiently large to carry the
largest customer payload plus overhead. Layer 3 services transport just the packet, and IP allows fragmentation.
Control Word (CW) and Real-Time Transport Protocol (RTP) Header
When transporting ATM and TDM services across an Ethernet/MPLS core, the edge routers may set an MPLS Control
Word and RTP header.
In an ATM service, the control word is optional, but supports packet reordering when the circuit requires it. For
example, if an aPipe requires packet reordering, the ingress PE router will set a control word with flags, a
sequence number and a length field. The control word goes between the payload and the service header, and is 4
bytes long.
For a cPipe transporting structured (channelized) DS0s, RFC 5086 requires that a control word accompany the
payload. Additionally, this RFC allows for an RTP header when timing information must be transported along with
the payload. The RTP header carries a timestamp and a sequence number, and is 12 bytes long.
Access
Configuring an Ethernet Access Port
Syntax:
Syntax:
[no]
[no] mode
mode {access|network|hybrid}
{access|network|hybrid}
[no]
[no] encap-type
encap-type {dot1q|null|qinq}
{dot1q|null|qinq}
[no]
[no] autonegotiate
autonegotiate [limited]
[limited]
speed
speed {10|100|1000}
{10|100|1000}
duplex
duplex {full|half}
{full|half}
[no]
[no] mtu
mtu mtu-bytes
mtu-bytes
Example:
Example: config#
config# port
port 1/1/3
1/1/3
config>port#
config>port# ethernet
ethernet
config>port>ethernet#
config>port>ethernet# mode
mode access
access
config>port>ethernet# encap-type
encap-type dot1q
dot1q
config>port>ethernet# autonegotiate
autonegotiate limited
limited
config>port>ethernet# speed
speed 100
100
config>port>ethernet# duplex
duplex half
half
mtu
config>port>ethernet# mtu 1518
1518
config>port>ethernet# back
back
config>port#
config>port# no
no shutdown
shutdown
Module 2 |
10
Configuring an Ethernet Access Port

Port Mode
The port mode determines the encapsulation options. A hybrid port can be both an access and a network port,
and is available only on the 7750 and 7450 products
A:NodeA# configure port 1/1/3 ethernet mode access
Port encapsulation
Dot1q or null for network ports; dot1q, null or qinq (except 7705 SAR) for access ports.
A:NodeA# configure port 1/1/3 ethernet encap-type dot1q
Autonegotiation
Some circumstances dictate that the port have auto-negotiation shut down. A base station may require fixed
duplex and speed settings, or, if a port is a LAG member, the LAG configuration requires that the port have full
auto-negotiate disabled.
Limited autonegotiate allows the endpoints to indicate the fixed port speed and duplex when the link comes up.
A:NodeA# configure port 1/1/3 ethernet autonegotiate limited
Speed and duplex
Set when autonegotiate is disabled or limited.
A:NodeA# configure port 1/1/3 ethernet speed 100
A:NodeA# configure port 1/1/3 ethernet duplex half
MTU
Adjust to suit the connected network and services.
A:NodeA# configure port 1/1/3 ethernet mtu 1518
Context:
Context: config>port>ethernet
config>port>ethernet
The port hold time holds down ports connected to flapping links
Allow network to stabilize before transitioning a ports operational
state
Example: On all network ports:
A:NodeA>config>port>ethernet# hold-time up 5
Module 2 |
11
Ethernet Network Port Hold Time

Link Flapping
The 7x50 system reports the port state immediately to the related system objects. This means a flapping link can
cause frequent changes to interface, LSP, and service objects.
Normally, one would want to know immediately when a port transitions from up to down. However, flapping links
could cause transport instability, resulting in high CPU utilization, excessive signaling traffic, and data loss as LSP
paths rapidly change states
Up Hold Time
To allow the network to stabilize, the CSA and MLS network ports may set an up hold time. In the example shown,
the system waits 5 seconds from the time the port recovers until it reports to the rest of the system that the port
has changed states.
Down Hold Time
Down hold timers can be used to delay a port transitioning to the down state, allowing graceful transition to
redundant entities, such as a VRRP backup interface.
The up and down hold time settings depend on the customer requirements and network design.
Ethernet Network Port Hold Time
7x50 TDM Port Configuration
SONET or SDH framing

Path configuration STS3, STS1, DS3, DS1, vt15, vt2
ATM/IMA or MLPPP bundles
Timing
1+1 Single-chassis/Multi-chassis APS
7705 SAR 2-Port Channelized OC3/STM1 MDA

7750 SR 4-Port OC3/STM1 Channelized ASAP MDA

Module 2 |
12
7x50 TDM Port Configuration

In the Backhaul Transport Network, the CSA connects TDM and ATM base stations to the MEN or the TDM transport.
TDM base stations may also connect directly to the MLSs.
The 7x50 products support a variety of TDM MDAs. Regardless of the MDA chosen, both ATM/IMA and MLPPP
bundles over SONET or SDH require the same basic configuration.
SONET or SDH
The Any Service Any Port (ASAP) MDAs and the channelized and unchannelized OCx/STMx MDAs require the
SONET/SDH path configuration. This includes the framing (ASAP MDA), path type, SONET or SDH, the TDM
timeslots, encapsulation type, and channel groups, and the virtual tributary group (VTG) or tributary unit group
(TUG).
ATM/IMA groups or ML-PPP Bundles
ATM/IMA and ML-PPP bundle E1 or DS1 interfaces to transport the specified payload between devices. Once you
have the TDM circuits configured, you associate the resulting channel groups with an IMA or ML-PPP bundle. A
channel group can include all 32 or 24 timeslots, or a subset. The latest SROS releases support fractional DS1/E1
channel groups with any timeslot order.
Timing
You may configure the OC-x/STM-x ports to synchronize transmission off the line or the node. Each E1/DS1 may
be individually configured to synchronize off the line, the node, or to use adaptive timing. Adaptive timing is used
on E1 and DS1 channels to synchronize to the received data rate rather than the framing bits.
APS/MC-APS
The 7450 and 7750 products support both 1+1 single-chassis APS (SC-APS) and MC-APS. The 7705 SAR supports 1+1
SC-APS only on the 4-port OC3/STM1 Clear Channel MDA.
A base station, an NC element, or the transport network may require

the following TDM port configurations:
SONET and SDH are related

standards used for IPBH and
in the MEN
SONET in the US, initiated
by Bellcore and
standardized by the
American National
Standards Institute (ANSI)
SDH is the ITU international
version
Both define optical and
electrical characteristics for
transporting voice and data
traffic over a high speed,
optical transport
Module 2 |
13
SONET and SDH Data Transmission Rates and Structures

Synchronous Optical Network (SONET) in the US, or Synchronous Digital Hierarchy (SDH) internationally, are the
ANSI and ITU standards for transporting synchronous traffic over an optical transport. SONET and SDH transport all
types of voice and data traffic at high speeds, currently up to OC-768 (40 Gb/s). SONET and SDH differ in frame
format, overhead, and aggregation levels, but both provide similar functions in the Backhaul Transport Network.
A SONET or SDH signal is bandwidth-flexible and can support transmission of a combination of services including
broadband data switching, high-speed packet-switching and video conferencing. A basic SONET or SDH signal is a
structured frame that is divided into overhead layers and a payload envelope.
The overhead layers contain transport and payload information and can be used for maintenance operations. The
payload carries signals that have been mapped into a payload envelope.
SONET frames are called STS-n frames; SDH frames are called STM-n frames.
In STS-n, n represents the number of STS-1 signals that are combined to form an STS frame. In STM-n, n represents
the number of STM-1 signals that are combined to form an STM frame. Each STS-n and STM-n frame has an
associated line rate that increases by 51.840 Mb/s and 155.520 Mb/s, respectively, each time that n increases by
one.
SONET/SDH commonly provide the Ethernet transport between the CSA and the MLS. A BTPs network often uses a
SONET transport. Additionally, SONET/SDH efficiently bundles and transports traffic between IPBH base stations
and the MLS routers.
SONET and SDH in the Backhaul Transport
Module 2 |
14
SONET and SDH Signal Levels and Line Rates

The table above lists and compares STS-n and STM-n frame line rates. Rates are defined as integer multiples of
the base STS-1 and STM-1.
The most widely implemented rates are:
STS-1 51.84 Mb/s
OC/STS-3/STM-1 155.52 Mb/s
OC/STS-12/STM-4 622.08 Mb/s
OC/STS-48/STM-16 2488.32 Mb/s
OC/STS-192/STM-64 9963.28
SONET and SDH Signal Levels and Line Rates
STS-1 Frame
Bandwidth is 51.84 Mb/s
Frame consists of 9 rows by 90 columns (9 x 90 bytes)
Module 2 |
15
SONET/SDH Overview
Basic STS-1 Frame
The basis STS-1 frame is 810 bytes long, and typically illustrated as 9 rows of 90 columns each, each column one
byte wide. The sender transmits the frame by rows and in bit order, meaning that it sends row 1, bit 0 first, then
row 1, bit 1, and so forth.
SONET transmits each frame in 125us for a data rate of 51.840 Mb/s. The frame includes 27 overhead bytes, for
an effective payload data rate of 49.536 Mb/s.
SONET Frame Overhead
Each frame includes 27 bytes of frame overhead, called the Transport Overhead (TOH). The TOH includes the
Section Overhead (SOH) and the Line Overhead (LOH):
SOH - 9 bytes; The SOH occupies the first 3 bytes in the first 3 rows transmitted, and handles point-to-point
communications, performs framing, and STS-n performance monitoring
LOH 18 bytes; The LOH uses the first 3 bytes in the remaining 6 rows. It handles individual STS-1
performance monitoring, provides data channels for OAM&P, includes pointers to identify where the payload
is located in the frame, supports APS, and alarming functions.
SONET Payload
The SONET frame payload is the Synchronous Payload Envelope (SPE). The sender includes Path overhead (POH)
with each payload, and the POH remains with the payload until the receiver de-multiplexes it. The POH is 9
bytes, and included bits that identify the path and its status.
The path is the media and NEs between the payloads assembly and disassembly.
SONET/SDH Overview
Basic STM-1 Frame

STM-1 bandwidth 155.52 Mb/s
Frame consists of 9 rows by 270 columns (2430 bytes)
Module 2 |
16
SONET/SDH Overview (cont)

Basic STM-1 Frame
The STM-1 frame, at three times the data rate of an STS-1, is three times the size, at 2430 bytes. The SDH
network transmits each frame in 125 us, for a data rate of 155.52 Mb/s.
SDH Frame Overhead
Each frame includes Section Overhead (SOH). The SOH uses the first 9 bytes in the first 9 rows. The SOH includes:
The Regenerator Section Overhead (RSOH) - 27 bytes: Located in the first three rows of columns 1-9. Provides
framing alignment for STM-n signals and OAM&P capabilities.
The Multiplex Section Overhead (MSOH) 45 bytes: Located in rows 5 through 9 of the first nine columns. Used
for transmission error detection, signaling, and synchronization. The MSOH includes pointers to an Administrative
Unit (AU), which carries the payload.
Data (SDH) Payload
The data payload is called a container. The container may contain a single circuits payload, or multiple smaller
payloads. A Virtual Container (VC) includes both the data (the container) and the Path Overhead.
Path Overhead (POH) Assigned to a VC, the Path Overhead uses rows 1-9 of the first column in the VC.
STS-1 payload may be sub-divided into Virtual Tributaries (VTs)

and Virtual Tributary Groups (VTGs)
Frame can transport mix of VTs, but each VTG may carry only
identical VTs
Legend
VT1.5 = 1.728Mb/s
VT 2 = 2.304 Mb/s
VT 3 = 3.456 Mb/s
VT 6 = 6.912 Mb/s
Module 2 |
17

Virtual Tributaries and Virtual Tributary Groups
SONET STS-1 was designed to carry an entire DS3, and can transport a DS1 with bandwidth to spare. However,
giving the entire STS-1 payload capacity to a single DS1 circuit wastes a large amount of bandwidth.
SONET standards allow you to allocate the STS-1 payload in smaller pieces, called virtual tributaries (VTs) and
virtual tributary groups (VTGs). An STS-1 may be divided into seven VTGs, which in turn carry sub-STS traffic in
virtual tributaries. VTs can be configured as:
VT 1.5 9 rows x 3 columns. Transports an entire DS1 at 1.728Mb/s. An STS-1 can carry 28 VT 1.5s, four per
VTG.
VT 2 9 rows x 4 columns. Transports an E1 frame at 2.304 Mb/s. An STS-1 can carry 21 VT 2s, three per VTG.
VT 3 9 rows x 6 columns. Transports a DS1C (two DS1s) at 3.456 Mb/s.
VT 6- 9 rows x 12 columns. Transports a DS2 (four DS1s) at 6.912 Mb/s.
As shown in the slide, you may mix and match VTs, but each VTG must transport like-VTs. A VTG may carry 4-VT
1.5s, 3-VT-2s, 2-VT-3s, or a single VT-6, but not a combination of VT-3s and VT-1.5s, for example. A pointer in the
POH indexes the VTs location in the payload.
STM-1 payload may be subdivided into Virtual

Containers (VCs) and
Tributary Units (TUs)
TUG-3=51.84 Mbps
TUG-2=3xE1
Legend
VC 12 = 2.304 Mb/s
TUG-2 = 3x VC-12
TUG-3 = 7x TUG-2
AU-4 = 3x TUG-3 = 3x STS1
Module 2 |
18

SDH Virtual Containers and Tributary Units
An SDH Virtual Container (VC) carries multiple Tributary Units (TUs). A TU is a sub-rate circuit multiplexed into
the STM-1 frame. VCs can be:
VC-11 (VC one-one) 9 rows x 3 columns at 1.728 Mb/s. An STM-1 can transport 74 VC-11s (DS1s).
VC-12 (VC one-two) 9 rows x 4 columns at 2.304 Mb/s.
VC-2 9 rows x 12 columns at 6.912 Mb/s.
A VC equates to a Tributary Unit Group (TUG), and a TUG multiplexes multiple TUs. A TU feeds a TUG, which may
feed other, higher-level TUGs, which in turn feed VCs and AUs.
E1 in STM-1 Frame
A VC-12 transports an E1 circuit. SDH multiplexes these circuits for transport in a STM-1 container, called an AU4.
TUG-2
At the lowest level, SDH multiplexes three 4 column x 9 row VC-12s into a 12 column wide TUG-2.
TUG-3
A TUG-3 concatenates seven 12 column wide TUG-2s, for a total of 84 columns. Each TUG-3 includes a column of
POH and a column of pointers and stuffing bits, for a total of 86 columns.
AU-4
An AU-4 carries three 86 column wide TUG-3s, plus one column of VC-4 POH and two stuffing columns, for a total
of 261 columns. This fills out the VC capacity area of the STM-1 frame.
Add to this the 9 bytes of SOH, and this completes the frame.
OC-12/OC-3 VT Group Circuits
Module 2 |
19
OC12/OC3 VT Group Circuits

The OC-x/STM-x ASAP MDAs support STS or SDH framed DS1s transported either in DS3s, in Virtual Tributary Groups
(VTGs), or in TUGs. Each STS-1 transports seven VTGs, each transporting multiple VTs. If configured as VT 1.5s,
each VT transports a DS1.
The diagram above illustrates three STS-1s carrying 28 DS1s each. An OC-3/STM-1 MDA port can then transport a
total of 72 DS1s. An OC-12/STM-3 MDA can transport 288 DS1s.
When you provision your DS1s in a SONET framed STS-3 circuit, you identify them by their location in the
aggregate STS-1 frame in the form <STS-3.STS-1.VTG.VT>. For example, given the command:
A:NodeA>config>port>tdm# ds1 1.2.3.4 no shutdown
This command turns up the DS1 transported in the fourth VT 1.5, located in the third VTG, transported by the
second STS-1 on the first STS-3 on an OC-12/STM-3 port.
A:MLS1>config>port>tdm#
A:MLS1>config>port>tdm# ds1
ds1 1.2.3.4
1.2.3.4 no
no shutdown
shutdown
Module 2 |
20
OC12 VT Group Circuits SONET Framing

VTG Mode
This diagram shows a SONET OC-12 interface provisioned to transport VT 1.5s. An OC-12 operates at 622 Mb/s and is
composed of four STS-3s. A SONET OC-3 interface operates at a rate 155.52 Mb/s and transports three STS-1s. The
STS-1 SPE can carry one DS3 (44.736 Mb/s) or 28 DS1 channels.
As shown here, we divide the STS-1 SPE into seven Virtual Tributary Groups (VTGs), each of which can contain four
VT1.5 VTs. Each VT1.5 carries one DS1.
Each VT Group can be unstructured or structured. Unstructured mode allows access down to the DS1 circuit level.
Structured mode allows access down to the N x 64 Kb/s circuit level.
The provisioning process is as follows:
1. Identify the framing type.
2. Provision each STS-1.
3. Provision the VTGs and VTs. Each STS-1 transports up to seven VTGs. Each VTG supports four VT 1.5s.
4. Configure the individual DS1s created when you built out the STS-1.
OC-12 VT Group Circuits SONET Framing
Module 2 |
21
OC12 VT Group Circuits SDH Framing

TUG Group Mode
The Synchronous Digital Hierarchy (SDH) supports TDM circuits of different channel rates transported in containers. A
container is the basic synchronous payload, and can be an E3, E1, DS3, DS1, or some higher multiple of a DSx or Ex. SDH
then maps the containers to Virtual Containers (VCs), and VCs into Tributary Units (TUs). It multiplexes TUs into
Tributary Unit Groups (TUGs), and then maps the TUGs into Administrative Units (AUs). Each level, VC, TU, TUG, and
AU, adds overhead for control, error detection, alignment, and other OAM functions. POH pointers locate the AU and
TUs in the STM-1 frame.
Setting the OC-12 ports framing to SDH and the path to STS-3 creates the AU-4s (155.52 Mbps). From there, you create
each of your TUG-3 groups, and define their payload. In this example, our payload is a VT 2 (VC-12), or an E1 container.
Note that the SROS CLI uses the SONET terminology for the path (STS-3 v. STM-1) and for the VC and TU, calling them a
VT 2 vice a VC-12.
We define our VT path by identifying the <AU-4.TUG-3.TUG-2.VT>. For example...
A:NodeA>config>port>sonet-sdh# framing sdh
A:NodeA>config>port>sonet-sdh# path sts3-1 (1st STS-3)
A:NodeA>config>port>sonet-sdh# group tug3-1.1 payload vt2 (1ST STS-1)
...allows us to create up to 21 VT 2s in a TUG-3.
This command...
A:NodeA>config>port>sonet-sdh# path vt2-1.1.4.3
...creates the third VT2 on the fourth TUG-2 on the first TUG-3 on the first AU-4.
OC12 VT Group Circuits SDH Framing
Configuring OC-3/STM-1 ASAP Port Characteristics
Syntax:
Syntax:
framing
framing {sonet|sdh}
{sonet|sdh}
path
path {sonet-sdh-index}
{sonet-sdh-index}
vt15-[sonet-sdh-index].[sonet-sdh-index].[sonet-sdh-index]
vt15-[sonet-sdh-index].[sonet-sdh-index].[sonet-sdh-index]
Context:
Context: config>port>sonet-sdh>path
config>port>sonet-sdh>path
Syntax:
Syntax:
payload
payload {sts3|tug3|ds3|e3|vt2|vt15|ds1|e1}]
{sts3|tug3|ds3|e3|vt2|vt15|ds1|e1}]
Example:
Example: config#
config# port
port 1/2/1
1/2/1 sonet-sdh
sonet-sdh
config>port>sonet-sdh#
config>port>sonet-sdh# framing
framing sonet
sonet
config>port>sonet-sdh# path
path sts1-1
sts1-1
config>port>sonet-sdh>path$
config>port>sonet-sdh>path$ payload
payload vt15
vt15
config>port>sonet-sdh>path$ no
no shutdown
shutdown
config>port>sonet-sdh>path$ back
back
path vt15-1.1.1
vt15-1.1.1
config>port>sonet-sdh>path$ no
no shutdown
shutdown
back
config>port>sonet-sdh>path$ back
config>port>sonet-sdh# back
back
config>port#
config>port# no
no shutdown
shutdown
Module 2 |
22
Configuring OC-3/STM-1 ASAP Port Characteristics

Shown here are the commands required to configure an OC-3/STM-1 port to support STS-1 VT15 DS1s. Each STS1
can transport 28 vt15s arranged in 7 groups of 4 vts (DS1s) each. The SROS default framing is SONET.
Set SONET/SDH framing
A:NodeA# configure port 1/2/1 sonet-sdh
Enable the STS-1
A:NodeA>config>port>sonet-sdh# path sts1-1 payload vt15
Define the payload
A:NodeA>config>port>sonet-sdh# path vt15-1.1.1 (vt15-sts1-1.vtg 1.vt15 1)
Turn up the payload
A:NodeA>config>port>sonet-sdh# path vt15-1.1.1 no shutdown
Turn up the STS-1
A:NodeA>config>port>sonet-sdh# path sts1-1 no shutdown
Turn up the port
A:NodeA>config>port>sonet-sdh# back
A:NodeA>config>port# no shutdown
Context:
Context: config>port>sonet-sdh
config>port>sonet-sdh
Configuring DS1 ATM Access Ports
Context:
Context: config>port>tdm
config>port>tdm
[no]
[no] ds1
ds1 ds1-id
ds1-id
clock-source
clock-source node-timed
node-timed
Context:
Context: config>port>tdm>channel-group
config>port>tdm>channel-group
Syntax:
Syntax:
channel-group
channel-group channel-group-id
channel-group-id
encap-type
encap-type {atm|bcp-null|ipcp|ppp-auto|frame-relay|wan-mirror|cisco-hdlc|cem}
{atm|bcp-null|ipcp|ppp-auto|frame-relay|wan-mirror|cisco-hdlc|cem}
Example:
Example: config#
config# port
port 1/2/1
1/2/1
config>port#
config>port# description
description ATM
ATM delivery
delivery IMA
IMA 2x
2x DS1
DS1
tdm
config>port#
config>port# tdm
config>port>tdm#
config>port>tdm# ds1
ds1 1.1.1
1.1.1
config>port>tdm>ds1$
config>port>tdm>ds1$ clock-source
node-timed
config>port>tdm>ds1$ channel-group
channel-group 11
config>port>tdm>ds1>channel-group$
config>port>tdm>ds1>channel-group$ encap-type
encap-type atm
atm
config>port>tdm>ds1>channel-group$ no
no shutdown
shutdown
config>port>tdm>ds1>channel-group$ back
back
config>port>tdm>ds1#
config>port>tdm>ds1# no
no shutdown
shutdown
config>port>tdm>ds1# back
back
config>port>tdm#
config>port>tdm# back
back
config>port>#
config>port># back
back
Module 2 |
23
Configuring DS1 ATM Access Ports

Configure the ports according to the connected equipment. In our example, we configure the DS1s as follows:
Set the channel type
We choose DS1 channels here. Defining the payload created the DS1s.
A:NodeA# configure port 1/2/1 tdm ds1 1.1.1 (ds1 sts1-1.vtg 1.vt15 1)
Set the DS1 clock source to node-timed
A:NodeA>config>port>tdm>ds1$ clock-source node-timed
Create the channel group
Create only one channel group; ATM encapsulation requires all 24 timeslots.
A:NodeA>config>port>tdm>ds1$ channel-group 1
Set the encapsulation type to ATM
By default, this assigns all 24 timeslots to the link and enables payload scrambling.
A:NodeA>config>port>tdm>ds1>channel-group$ encap-type atm
Turn up the channel group
A:NodeA>config>port>tdm>ds1>channel-group$ no shutdown
Turn up the DS1
A:NodeA>config>port>tdm>ds1# no shutdown
Syntax:
Syntax:
View the STS-1 show port 1/2/1.1
===============================================================================
===============================================================================
Path
Path Info
Info
===============================================================================
===============================================================================
Description
:: STS1
Description
STS1
Admin
:: up
Oper
:: up
Admin Status
Status
up
Oper Status
Status
up
Mode
:
N/A
CRC
:
Mode
: N/A
CRC
: N/A
N/A
Encap
:: N/A
Configured
:: N/A
Encap Type
Type
N/A
Configured MTU
MTU
N/A
Operational
:: N/A
Operational
:: N/A
Operational MTU
MTU
N/A
Operational MRU
MRU
N/A
Last
Path
:: 574652477
Last State
State Change
Change :: 05/16/2011
05/16/2011 23:03:34
23:03:34
Path IfIndex
IfIndex
574652477
Scramble
:: N/A
Payload
:: vt15
Scramble
N/A
Payload
vt15
Accounting
Policy
:
N/A
Collect-Stats
:
Accounting Policy : N/A
Collect-Stats
: N/A
N/A
Net.
Net. Egress
Egress Que
Que Pol:
Pol: N/A
N/A
Signal
Label
:: 0x02
Rx
:: 0x01
Signal Label
0x02
Rx Signal
Signal Label
Label
0x01
Trace
:: Alcatel
Trace String
String
Alcatel 7750
7750 SR
SR
Rx
Rx Trace
Trace Str(Hex)
Str(Hex) :: 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00 00
00
...output
...output truncated
truncated
Cfg
:: plop
Cfg Alarm
Alarm
plop pplm
pplm puneq
puneq
Alarm
::
Alarm Status
Status
...output
...output truncated
truncated
Module 2 |
24
View the STS-1 show port 1/2/1.1 (iom/mda/port.sts1-1)

The show port 1/2/1.1 command shows the resulting STS1 configuration.
The description, set by the router, indicates this is an STS1 framed circuit.
The payload is set to vt15, to carry one DS1 per virtual tributary.
The Cfg Alarm fields indicate the following:
pais Reports path alarm indication signal errors.
Default - pais alarms are not issued
plop Reports path loss of pointer (per tributary) errors.
Default - plop traps are issued
prdi Reports path remote defect indication errors.
Default - prdi alarms are not issued
pplm Reports a path payload mismatch, as a result the channel will be operationally downed.
Default - pplm traps are issued
prei Reports a path error condition raised by the remote as a result of b3 errors received from this node.
Default - prei traps are not issued
puneq Reports path unequipped errors. Reports path unequipped signal errors.
Default - puneq traps are issued
A:NodeA#
A:NodeA# show
show port
port 1/2/1.1
1/2/1.1
View the DS-1 show port 1/2/1.1.1.1
===============================================================================
===============================================================================
TDM
TDM DS1
DS1 Interface
Interface
===============================================================================
===============================================================================
Description
:: DS1
Description
DS1
Interface
:: 1/2/1.1.1.1
Interface
1/2/1.1.1.1
Type
:: ds1
Framing
:: esf
Type
ds1
Framing
esf
Admin
:: up
Oper
:: up
Admin Status
Status
up
Oper Status
Status
up
Physical
:: yes
Clock
:: node-timed
Physical Link
Link
yes
Clock Source
Source
node-timed
Last
Channel
:: 574653943
Last State
State Change
Change :: 05/16/2011
05/16/2011 23:34:29
23:34:29
Channel IfIndex
IfIndex
574653943
Loopback
:: none
Invert
:: false
Loopback
none
Invert Data
Data
false
Remote
Loop
respond:
false
In
Remote
Loop
:: false
Remote Loop respond: false
In Remote Loop
false
Load-balance-algo
Egr.
:: N/A
Load-balance-algo :: default
default
Egr. Sched.
Sched. Pol
Pol
N/A
BERT
:: N/A
BERT
:: none
BERT Duration
Duration
N/A
BERT Pattern
Pattern
none
BERT
:: 00h00m00s
Err
BERT Synched
Synched
00h00m00s
Err Insertion
Insertion Rate
Rate :: 00
BERT
:: 00
BERT
:: idle
BERT Errors
Errors
BERT Status
Status
idle
BERT
:: 00
BERT Total
Total Bits
Bits
Cfg
:: ais
Cfg Alarm
Alarm
ais los
los
Alarm
::
Alarm Status
Status
BER
BER
:: 50
BER SD
SD Threshold
Threshold :: 55
BER SF
SF Threshold
Threshold
50
===============================================================================
===============================================================================
...
... output
output truncated
truncated
Module 2 |
25
View the DS1 show port 1/2/1.1.1.1 (iom/mda/port.sts1-1.vtg1.vt15 1)

The show port 1/2/1.1.1.1 command shows the DS1 status and configuration.
The description shows this as a DS1 interface.
The DS1 framing is the default, ESF.
The clock source must be node-timed for use in an ATM IMA bundle.
The Cfg Alarm fields indicate the following:
ais Reports alarm indication signal errors.
Default - ais alarms are issued
los Reports loss of signal errors.
Default - los traps are issued.
oof Reports out-of-frame errors.
Default - oof alarms are not issued.
rai Reports resource availability indicator events.
Default - rai alarms are not issued
looped Reports looped packets errors.
Default - looped alarms are not issued
A:NodeA#
A:NodeA# show
show port
port 1/2/1.1.1.1
1/2/1.1.1.1
View the Channel Group show port 1/2/1.1.1.1.1
===============================================================================
===============================================================================
TDM
TDM DS0
DS0 Chan
Chan Group
Group
===============================================================================
===============================================================================
Description
:: DS0GRP
Description
DS0GRP
Interface
:: 1/2/1.1.1.1.1
Interface
1/2/1.1.1.1.1
TimeSlots
:: 1-24
TimeSlots
1-24
Speed
:
CRC
:: 32
Speed
: 64
64
CRC
32
Admin
:: up
Oper
:: up
Admin Status
Status
up
Oper Status
Status
up
BER
BER SF
SF Link
Link Down
Down :: disabled
disabled
Last
Chan-Grp
:: 574653944
Last State
State Change
Change :: 05/17/2011
05/17/2011 00:10:20
00:10:20
Chan-Grp IfIndex
IfIndex
574653944
Configured
Configured mode
mode
Admin
Admin MTU
MTU
Scramble
Scramble
Physical
Physical Link
Link
Idle
Idle Cycle
Cycle Flags
Flags
Payload
Payload Fill
Fill Type
Type
Signal
Signal Fill
Fill Type
Type
Ing.
Ing. Pool
Pool %% Rate
Rate
Egr.
Sched.
Egr. Sched. Pol
Pol
:: access
access
:: 1524
1524
:: true
true
:: yes
yes
:: n/a
n/a
:: n/a
n/a
:: n/a
n/a
:: 100
100
:: N/A
N/A
Encap
Encap Type
Type
Oper
Oper MTU
MTU
:: atm
atm
:: 1524
1524
Bundle
Bundle Number
Number
Load-balance-algo
Load-balance-algo
Payload
Payload Pattern
Pattern
Signal
Signal Pattern
Pattern
Egr.
Egr. Pool
Pool %% Rate
Rate
:: 11
:: default
default
:: N/A
N/A
:: N/A
N/A
:: 100
100
...
... output
output truncated
truncated
Module 2 |
26
View the Channel Group show port 1/2/1.1.1.1.1 (iom/mda/port.sts1-1.vtg1.vt15

1.channel-group 1)
The show port 1/2/1.1.1.1.1 command shows the channel group status and configuration.
All 24 timeslots in the DS0GRP belong the the channel group, resultant of the ATM encap-type setting.
The channel group is set to access mode by default.
The Admin MTU value is the 7x50 default for an ATM access port.
The Physical Link is Up, and payload scrambling is enabled.
A:NodeA#
A:NodeA# show
show port
port 1/2/1.1.1.1.1
1/2/1.1.1.1.1
An IMA bundle inverse multiplexes, or splits, an ATM cell stream

over multiple DS1/E1 links
The IMA bundle group combines the individual links to create a
fatter pipe between the two endpoints
The logical link concept is called an IMA Group
IMA bundles only operate as access ports
Module 2 |
27
Inverse Multiplexing over ATM (IMA)

The SAR and SR routers support IMA on ASAP MDA access ports. IMA provides to the ATM cell stream more
bandwidth than a single DS1/E1 link, but doesnt require a dedicated DS3/E3 or OCx. IMA creates a logical link, or
IMA group, consisting of multiple physical links.
On Router Ingress (from BS)
The IMA group terminates on a service SAP. The router converts the incoming cell streams on each of the bundled
ATM channels to a single ATM stream before passing the traffic to service functions, such as an aPipe service.
On Router Egress (to BS)
The router distributes the single cell stream over all IMA group paths. Since the IMA group logically appears as a
single link, the service considers the individual links components of a single, logical SAP.
Cell Processing
IMA uses a round-robin cell distribution technique, sending the first cell on the first available link, the second on
the second, and so forth. The receiver removes the cells from the bundle in the same order as which they were
transmitted to maintain sequencing.
The endpoints send 128 cell IMA frames, consisting of both data and control traffic. When the sender doesnt have
enough data to fill the frame, it inserts filler cells. The control cells identify cell sequencing, status, and control
information. The control cells also indicate stuff cell use. The sender inserts stuff cells to compensate for delay
variations across the group members.
Inverse Multiplexing over ATM (IMA)
IMA Bundle Configuration Commands

Context:
Context: config>port
config>port
[no]
[no] bundle-ima-slot/mda.bundle-num
bundle-ima-slot/mda.bundle-num
multilink-bundle
multilink-bundle
Context:
Context: config>port>ml-bundle
config>port>ml-bundle
Syntax:
Syntax:
ima
ima atm
atm
member
member port-id
port-id
Example:
Example: config#
config# port
port bundle-ima-1/2.1
bundle-ima-1/2.1
config>port#
config>port# multilink-bundle
multilink-bundle
config>port>ml-bundle#
config>port>ml-bundle# ima
ima atm
atm
config>port>ml-bundle# member
member 1/2/1.1.1.1.1
1/2/1.1.1.1.1
member
config>port>ml-bundle# member 1/2/1.1.1.2.1
1/2/1.1.1.2.1
back
config>port>ml-bundle# back
config>port#
config>port# no
no shutdown
shutdown
A:MLS1>config>port>ml-bundle#
member iom/mda/port.sts1-1.vtg-1.vt-1.channel-group1
Module 2 |
28
IMA Bundle Configuration Commands

Create the IMA bundle
You must type out bundle-ima-port.bundle-num.
A:NodeA# configure port bundle-ima-1/2.1 (iom/mda.bundle id 1)
Configure the bundle characteristics
A:NodeA>config>port# multilink-bundle
A:NodeA>config>port>ml-bundle# ima atm
Define the bundle member DS1s
You should use at least two members.
A:NodeA>config>port>ml-bundle# member 1/2/1.1.1.1.1
(iom/mda/port.sts1-1.vtg 1.vt15 1.channel-group 1)
Turn up the bundle
Syntax:
Syntax:
View the Completed IMA Bundle
show multilink-bundle bundle-ima-1/2.1

Operation state remains Down until other end becomes operational
A:NodeA#
A:NodeA# show
show multilink-bundle
multilink-bundle bundle-ima-1/2.1
bundle-ima-1/2.1
===============================================================================
===============================================================================
Bundle
Bundle Summary
Summary
===============================================================================
===============================================================================
Bundle
Type
Admin
Oper
Port
Min
Total/
Bundle
Type
Admin
Oper
Port
Min
Total/
Id
State
State
State
Links
Id
State
State
State
Links Active
Active Links
Links
------------------------------------------------------------------------------------------------------------------------------------------------------------bundle-ima-1/2.1
ima-grp
Up
Up
11
2/2
bundle-ima-1/2.1
ima-grp Up
Up
Up
Up
2/2
------------------------------------------------------------------------------------------------------------------------------------------------------------Bundles
Bundles :: 11
===============================================================================
===============================================================================
Module 2 |
29
View the Completed IMA Bundle

The show multilink-bundle bundle-ima-1/2.1 command shows the bundles status.
The Admin State is Up. The Operational State remains Down until the other end is configured and operational.
The Port State indicates the physical link is Up.
The Total/Active Links field indicates the bundle consists of two links and both are active.
Only one bundle is currently configured on the router.
The bundle is Admin Up, Port State Up
ML-PPP is a method of splitting, recombing, and sequencing PPP

frames across multiple datalinks
PPP signals the Multilink Protocol (MP) option during individual
link Link Control Protocol (LCP) negotiations
SROS supports up to 16xE1 or DS1 ML-PPP bundled links per
bundle group on network interfaces; 8 on access
Module 2 |
30
Point to Point Protocol (PPP) / MultiLink-PPP

RFC1990 describes ML-PPP as an extension to the PPP protocol which allows distributing PPP frames across
multiple PPP links grouped together into a bundle. These bundled PPP links provide a single, virtual connection
between two devices. ML-PPP allows more bandwidth than a single circuit can provide alone, and reduces
costs when the required bandwidth is greater than one circuit, but less than the next higher aggregation level.
ML-PPP transmits a single data stream by splitting and sequencing the datagram into multiple ML-PPP frames, and
evenly distributing them across multiple physical links (that are logically grouped) for transmission. The far-end
equipment recombines the received multi ML-PPP frames back to a single datagram.
Fragmenting the datagram and transmitting it across multiple physical links allows the service provider to
incrementally increase the bandwidth and lower the latency of the transmitting data. All datagram transiting
through MLPPP are subject to fragmentation.
ML-PPP Setup
ML-PPP is signaled during a standard PPP sessions initial Link Control Protocol (LCP) option negotiations. A router
sends the PPP Multilink Protocol (MP) option to its peer to indicate its desire to implement ML-PPP.
This negotiation indicates the following:
1. The system offering the option is capable of combining multiple physical links into one logical link
2. The system is capable of receiving upper layer protocol data units (PDU) fragmented using the MP header and
reassembling the fragments back into the original PDU for processing.
3. The system is capable of receiving PDUs of n octets where n is specified as part of the option even if n is larger
than a single physical links the maximum receive unit (MRU). MRU is the links maximum supported frame
size, similar to MTU.
Once the peers successfully negotiate ML-PPP, the systems are free to send PDUs encapsulated with and/or
fragmented with the MP header.
Point to Point Protocol (PPP)/MultiLink-PPP
PPP is a Data Link Layer protocol for encapsulating datagrams for

transport over serial links
PPP consists of:
Link Control Protocol (LCP) establishes, configures, and tests
the data link connection
Network Control Protocol (NCP) establishes and configures
different network layer protocols
Module 2 |
31
Point to Point Protocol (PPP)

PPP is based on High-level Data Link Protocol (HDLC), and provides an L2 transport for data carried over serial,
point-to-point links. All PPP frames start with the same bit pattern in the first 3 bytes, 0x7EFF03, and include no
addressing information.
The protocol field, either 8 or 16 bits long, identifies the frames payload. PPP is flexible in that it can carry
multiple L3 payloads over the same physical link and PPP session.
The PPP data field is variable, and the protocol uses padding to fill out the data field on byte boundaries. The 2
byte Frame Check Sequence (FCS) and 1 byte trailer, 7E, finish out the frame.
Link Control Protocol Protocol 0xc021
LCP negotiates the physical link characteristics. When two endpoints negotiate the links characteristics, they tell
the far end what it expects to receive, rather than what it can send. LCP defines 10 states, and the endpoints
have to agree on the links characteristics for it to reach the Open state. LCP messages are carried in the PPP
frame data field with protocol ID 0xc021.
Network Control Protocol Protocol 8021, Internet Protocol Control Protocol (IPCP)
PPP can support multiple L3 protocols, and uses the NCP to configure the protocols characteristics. NCP
negotiations occur after LCP succeeds and sends an Up event to the NCP protocol engine.
IPCP is the PPP Network Control Protocol for IP, using PPP protocol number 0x8021. IPCP uses the same frame
format as LCP, passing IP specific optional information between the endpoints. In SROS, once a bundle is
associated with an IP interface and the interface specifies IPCP as its NCP, the bundle initializes IPCP. You
configure the IPCP options on the interface. If the interface goes down, IPCP terminates on the associated
bundle.
IPCP configuration options include:
IP address Used to negotiate address assignments on the bundle interfaces. An endpoint can pass an IP address
to its peer, or request its peer supply it an IP address.
Primary and Secondary DNS Described in Informational RFC 1877, the DNS options allow an endpoint to send to
its peer a primary and secondary DNS server address.
SROS routers can send these values, but do not accept them upon receipt.
IPCP can be enabled explicitly on an access bundle. A network bundle will choose IPCP if the bundle supports IP
routing. If the bundle carries MPLS over ML-PPP traffic, the network bundle will choose MPLS Control Protocol
(MPLSCP). RFC 3032 defines MPLSCP as a protocol for enabling MPLS packet switching over a PPP link.
Point-to-Point Protocol (PPP)
Before the endpoints can transmit data, they must signal the links
and bundles
MP initialization occurs after individual link LCP signaling
MP acts as a logical PPP link on top of the member links
Data flows once the endpoints negotiate the bundles Layer 3
characteristics
Module 2 |
32
Link Negotiation/Bundle Negotiation

ML-PPP runs on top of physical PPP, so its member links negotiate their characteristics before the bundle
initializes. Member links can join or leave the bundle without impacting its operation, assuming that at least
one active member link remains in the bundle. The bundle can only initialize and remain operational if a valid
link is active in the bundle.
PPP Link Negotiations
PPP links negotiate the links characteristics using the LCP. These characteristics include authentication, packet
format, packet sizes, and error detection. At least one link must complete LCP negotiations before the bundle
can initialize.
Bundle (MP) Negotiations
The individual links set the MP options when they run LCP; bundles do not negotiate LCP. The bundle LCP options
are:
1. Multilink Maximum Received Reconstructed Unit (MRRU) This first tells the remote endpoint that the local
endpoint wishes to implement ML-PPP. If a link does not set the MRRU option, it moves on to the link NCP
phase. MRRU also identifies the maximum packet size of the reconstructed packets. ML-PPP can fragment
larger packets and distributed those fragments over member links, and the endpoints have to agree on a
maximum reconstructed packet size. If a remote system rejects the MRRU option, the local node assumes that
the remote system does not support ML-PPP.
2. Short Sequence Number (SSN) header format If a node sends the SSN option, it is suggesting the bundle use
a 12 bit versus a standard, 24 bit sequence number. When SSN is configured between the endpoints, they can
use two bits in the header to identify four service classes, as detailed in RFC 2685, The Multi-class Extension to
Multi-Link PPP.
3. Endpoint discriminator option This option identifies the bundle to which a link belongs. This can take the
form of an endpoints interface IP address. Both endpoints can use a different discriminator value, but all links
on one end must use the same discriminator value.
Network Control Protocol (NCP) Negotiations
Once LCP succeeds, PPP uses NCP to determine the higher layer protocols used on the link. PPP supports multiple
Layer 3 protocols, and PPP requires that each L3 protocol be initialized over the link or bundle.
Link Negotiation/Bundle Negotiation
IETF RFC 1990 describes the PPP

Multilink Protocol (MP)
Unique protocol ID 0x003D
Supports L2 fragmentation,
each frame has sequence
number assigned
IPCP PDU carried in MP frame
payload
Optional support for RFC 2686
Multi-Class Extension to MultiLink PPP through two bit Class
(CLS) field
Module 2 |
33
Multilink Protocol (MP) Frame

The PPP Multilink Protocol (MP) frame carries the bundled payload. The MP protocol ID 0x003D identifies this as a
bundled payload, and includes a sequence number header field to support L2 fragmentation. The MP frames carry
the IPCP PDU in the frames data field.
L2 v. L3 Fragmentation
The MP frame sequence number field allows L2 fragmentation on the IPCP payload. This L2 fragmentation reduces
the overhead traditional IP fragmentation imposes on the payload.
IP fragments include copies of the original packet header modified to include the identification, fragmentation
offset, and flags used to reassemble the packet at the next hop.
MP fragments include a sequence number, but only the first fragment includes the IPCP PDU header and IP packet
header. MP can fragment the payload wherever convenient, and does not include the L3 header along with each
fragment. The following fields support MP fragmentation:
B bit Set to one on the first fragmented frame carrying a fragmented higher layer PDU.
E bit Set to one on the last fragmented frame carrying a fragmented higher layer PDU.
Sequence number Identifies a fragment in a fragment string carrying a fragmented higher layer PDU. The first
sequence number used on a bundle is zero, and increments by one for each fragment transmitted on the bundle.
You can set a fragmentation threshold on the multilink bundle. This tells the router the largest fragment that can
be sent across the bundle.
Multi-Class Extension to Multi-Link PPP (MC-MLPPP)
MC-MLPPP uses two of the MP frame header bits to identify four Classes of Service (CoS). You set the multi-class
options on the bundle.
Multilink Protocol (MP) Frame
Module 2 |
34
Bundle Creation and Maintenance

Establish communication phase (over a P2P link)
Each end sends LCP packets to configure and test the data link.
Once established, the peer may optionally be authenticated. SROS does not support authentication on PPP links.
If MP is desired, the nodes set the MRRU option.
Initialize bundle
In SROS, the bundle configuration sets the MRRU, fragment threshold, short sequence, and multiclass options for
the member links. The endpoints need to agree on the short sequence and multiclass values for the bundle to
initialize; they negotiate the MRRU and fragment threshold. Once the bundle initializes, PPP can move on to the
NCP phase.
Configure network-layer protocols phase
Send NCP packet to choose and configure Network-layer protocol
Datagram from each network-layer protocol can be sent over the link
MP Encapsulation
Bundled messages uses a unique protocol ID, 0x003D. This distinguishes bundle member from link level
transmissions. IPCP packets are transported in the payload field, after the MP protocol ID field.
Bundle Creation and Maintenance
Configuring DS1 PPP Access Ports
Context:
Context: config>port>tdm
config>port>tdm
[no]
[no] ds1
ds1 ds1-id
ds1-id
clock-source
node-timed
Context:
Context: config>port>tdm>channel-group
config>port>tdm>channel-group
Syntax:
Syntax:
channel-group
channel-group channel-group-id
channel-group-id
encap-type
encap-type {atm|bcp-null|ipcp|ppp-auto|frame-relay|wan-mirror|cisco-hdlc|cem}
{atm|bcp-null|ipcp|ppp-auto|frame-relay|wan-mirror|cisco-hdlc|cem}
Example:
Example: config#
config# port
port 1/2/1
1/2/1
config>port#
description MLPPP
MLPPP bundle
bundle 2
2
config>port#
tdm
config>port# tdm
config>port>tdm#
ds1
1.1.1
config>port>tdm# ds1 1.1.1
config>port>tdm>ds1$ clock-source
node-timed
config>port>tdm>ds1$ channel-group
channel-group 11
config>port>tdm>ds1>channel-group$ encap-type
encap-type ipcp
ipcp
config>port>tdm>ds1>channel-group$ timeslots
timeslots 1-24
1-24
config>port>tdm>ds1>channel-group$ no
no shutdown
shutdown
config>port>tdm>ds1>channel-group$ back
back
config>port>tdm>ds1# no
no shutdown
shutdown
config>port>tdm>ds1# back
back
config>port>tdm#
back
config>port>#
config>port># back
back
Module 2 |
35
Configuring DS1 PPP Access Ports

Configure the ports according to the connected equipment. In our example, we configure the DS1s as follows:
Set the channel type
We choose DS1 channels here. Defining the payload created the DS1s.
A:NodeA# configure port 1/2/1 tdm ds1 1.1.1 (ds1 sts1-1.vtg 1.vt15 1)
Set the clock source to node-timed
A:NodeA>config>port>tdm>ds1$ clock-source node-timed
Create the channel group
Create the channel group.
A:NodeA>config>port>tdm>ds1$ channel-group 1
Set the encapsulation type to IPCP
IPCP is only allowed on access ports. This allows the node to pass the IPCP options during the bundles NCP phase.
A:NodeA>config>port>tdm>ds1>channel-group$ encap-type ipcp
Set the timeslots
SROS (on the 7750 SR) allows subrate channel groups as members of ML-PPP bundles. You must identify the
number of timeslots in the channel group.
A:NodeA>config>port>tdm>ds1>channel-group$ timeslots 1-24
Turn up the channel group
A:NodeA>config>port>tdm>ds1>channel-group$ no shutdown
Turn up the DS1
A:NodeA>config>port>tdm>ds1# no shutdown
Syntax:
Syntax:
===============================================================================
===============================================================================
TDM
TDM DS0
DS0 Chan
Chan Group
Group
===============================================================================
===============================================================================
Description
:: DS0GRP
Description
DS0GRP
Interface
:: 1/2/1.1.1.1.1
Interface
1/2/1.1.1.1.1
TimeSlots
:: 1-24
TimeSlots
1-24
Speed
:
CRC
:: 16
Speed
: 64
64
CRC
16
Admin
:: up
Oper
:: up
Admin Status
Status
up
Oper Status
Status
up
BER
BER SF
SF Link
Link Down
Down :: disabled
disabled
Last
Chan-Grp
:: 574652503
Last State
State Change
Change :: 07/28/2011
07/28/2011 10:42:57
10:42:57
Chan-Grp IfIndex
IfIndex
574652503
Configured
:: access
Configured mode
mode
access
Admin
:: 1502
Admin MTU
MTU
1502
Scramble
:: false
Scramble
false
Physical
:: yes
Physical Link
Link
yes
Idle
Cycle
Flags
Idle Cycle Flags :: flags
flags
Payload
Payload Fill
Fill Type
Type :: n/a
n/a
Signal
Fill
Type
Signal Fill Type :: n/a
n/a
Ing.
Ing. Pool
Pool %% Rate
Rate :: 100
100
Egr.
:: N/A
Egr. Sched.
Sched. Pol
Pol
N/A
...
... output
output truncated
truncated
Encap
Encap Type
Type
Oper
Oper MTU
MTU
:: ipcp
ipcp
:: 1502
1502
Bundle
Bundle Number
Number
Load-balance-algo
Load-balance-algo
Payload
Payload Pattern
Pattern
Signal
Signal Pattern
Pattern
Egr.
Egr. Pool
Pool %% Rate
Rate
:: 11
:: Default
Default
:: N/A
N/A
:: N/A
N/A
:: 100
100
Module 2 |
36

This command shows the port configuration on a 7750 SR node.
Description: - All 24 timeslots in the DS0GRP belong the the channel group.
Configured mode: - The channel group is set to access mode by default.
Encap Type: - Set to IPCP on the DS1.
Admin and Oper MTU: - Set to 1502, the SROS default for an IPCP access port; 1500 byte IP packet plus 2 bytes
of PPP overhead.
The Physical Link and Channel Group are operational.
NOTE: Though the physical DS1 link may show operational, the channel group must be part of an operational
bundle in order to become operational itself.
A:NodeA#
A:NodeA# show
show port
port 1/2/1.1.1.1.1
1/2/1.1.1.1.1
ML-PPP Bundle Configuration Commands

Context:
config>port
[no]
[no] bundle-ppp-slot/mda.bundle-num
bundle-ppp-slot/mda.bundle-num
multilink-bundle
multilink-bundle
Context:
Context: config>port>ml-bundle
config>port>ml-bundle
Syntax:
Syntax:
member
member port-id
port-id
short-sequence
short-sequence
mrru
<mrru>
mrru <mrru>
mlppp
mlppp
Context:
Context: config>port>ml-bundle>mlppp
config>port>ml-bundle>mlppp
Syntax:
Syntax:
endport-discriminator
endport-discriminator class
class {ip-address|global-mac-address|null}
{ip-address|global-mac-address|null} discriminator-id
discriminator-id
<discrimator-id>
<discrimator-id>
Example:
Example: config#
config# port
port bundle-ppp-1/2.1
bundle-ppp-1/2.1
config>port#
config>port# multilink-bundle
multilink-bundle
config>port>ml-bundle# short
short sequence
sequence
config>port>ml-bundle# member
member 1/2/1.1.1.1.1
1/2/1.1.1.1.1
member
config>port>ml-bundle# member 1/2/1.1.1.2.1
1/2/1.1.1.2.1
mlppp
config>port>ml-bundle# mlppp
config>port>ml-bundle>mlppp#
endpoint-discriminator
config>port>ml-bundle>mlppp# endpoint-discriminator class
class ip-address
ip-address
discriminator-id
discriminator-id 10.10.10.10
10.10.10.10
config>port>ml-bundle>mlppp#
back
config>port>ml-bundle>mlppp# back
config>port#
config>port# no
no shutdown
shutdown
Module 2 |
37
ML-PPP Bundle Configuration Commands

Create the ML-PPP bundle
You must type out bundle-ppp-port.bundle-num.
A:NodeA# configure port bundle-ppp-1/2.1
Configure the bundle characteristics
A:NodeA>config>port# multilink-bundle
Define the bundle member DS1s. You should use at least two members.
Set the MRRU and short-sequence, if required. The default MRRU on a PPP bundle is 1524. Short-sequence
supports multiclass PPP, which uses two of the header bits to specify one of four frame Classes of Service.
A:NodeA>config>port>ml-bundle# short-sequence
A:NodeA>config>port>ml-bundle# mlppp
Set the endpoint discriminator value
A:NodeA>config>port>ml-bundle>mlppp# endpoint-discriminator class ip-address
discriminator-id 10.10.10.10
A:NodeA>config>port>ml-bundle>mlppp# back
Fragment Threshold
You may set the fragment threshold value on the bundle (not shown). The range is 128-512 bytes for MLPPP. The
default is 128.
A:NodeA>config>port>ml-bundle# fragment-threshold <fragment-threshold>
Syntax:
Syntax:
Multi-Class (MC) MLPPP Overview
Multi-Link Point-to-Point Protocol

Allows operators to converge multiple
services and traffic types over a
T1/E1 link
Limitation:
No ability to prioritize specific
applications
Multi-class MLPPP
Multi-Class MLPPP adds QoS for Multi-Link

Groups
Uses MP frame Class bits
Four Classes of Service (CoS)
Enables prioritization of different
services over a common network link
Module 2 |
38
MC MLPPP Overview
If so required, you may differentiate the traffic passed over the multilink bundles by enabling Multi-Class support.
A:NodeA>config>port>ml-bundle>mlppp# multiclass <count>
The options are 2 to 4. As shown in the illustration above, multiclass 4 enables 4 CoS and allows you to use QoS
profiles to prioritize the traffic sent across the bundle.
7750 SROS defines one default ingress and 3 default egress MLPPP QoS profiles. Egress QoS profiles buffer and
schedule traffic leaving the MDA. Ingress QoS profiles set reassembly timeout values for rebuilding fragmenting
frames on port ingress. See the 7750 SR OS QoS Guide for more information on MLPPP QoS profiles.
A:MLS1# show qos mlppp-profile-egress
===============================================================================
Multi-class MLPPP Egress Profiles
===============================================================================
Profile-Id Description
------------------------------------------------------------------------------1
Default egress multi-class profile 1.
2
3
===============================================================================
A:MLS1# show qos mlppp-profile-ingress
===============================================================================
Multi-class MLPPP Ingress Profiles
===============================================================================
Profile-Id Description
------------------------------------------------------------------------------1
Default ingress multi-class profile 1.
===============================================================================
MLPPP
View the Completed ML-PPP Bundle No IPCP

show multilink-bundle bundle-ppp-1/2.1
Operation state remains down until the bundle is associated with an IP
interface
A:NodeA#
A:NodeA# show
multilink-bundle bundle-ppp-1/2.1
bundle-ppp-1/2.1
===============================================================================
===============================================================================
Bundle
Bundle Summary
Summary
===============================================================================
===============================================================================
Bundle
Type
Admin
Oper
Port
Min
Total/
Bundle
Type
Admin
Oper
Port
Min
Total/
Id
State
State
State
Links
Id
State
State
State
Links Active
Active Links
Links
------------------------------------------------------------------------------------------------------------------------------------------------------------bundle-ppp-1/2.1
mlppp
Down
Link
2/2
bundle-ppp-1/2.1
mlppp Up
Up
Down
Link Up
Up 11
2/2
------------------------------------------------------------------------------------------------------------------------------------------------------------Bundles
Bundles :: 11
===============================================================================
===============================================================================
Module 2 |
39
View the Completed ML-PPP Bundle No IPCP

The show multilink-bundle bundle-ppp-1/2.1 command shows the bundles status. In this example, the
local and remote bundles are configured and turned up but not associated with an operational L3 interface.
The Admin State is Up. The Operational State remains Down until the bundle is associated with an IP interface
and can signal IPCP.
The Port State indicates the physical links are Up.
The Total/Active Links field indicates the bundle consists of two links and both are active.
Only one Bundle is currently configured on the router.
The bundle is Admin Up, Port State Link Up
A:NodeA#
A:NodeA# show
bundle-ppp-1/2.1 detail
detail
===============================================================================
===============================================================================
Bundle
Bundle bundle-ppp-1/2.1
bundle-ppp-1/2.1 Detail
Detail
===============================================================================
===============================================================================
Description
:: MultiLink
Description
MultiLink Bundle
Bundle
Bundle
Id
:
bundle-ppp-1/2.1
:: mlppp
Bundle Id
: bundle-ppp-1/2.1 Type
Type
mlppp
Admin
:: up
Oper
:: up
Admin Status
Status
up
Oper Status
Status
up
Minimum
:: 11
Bundle
:: 574619649
Minimum Links
Links
Bundle IfIndex
IfIndex
574619649
Total
:: 22
Active
:: 22
Total Links
Links
Active Links
Links
Red
:: 00
Yellow
Red Diff
Diff Delay
Delay
Yellow Diff
Diff Delay
Delay :: 00
Red
Diff
Delay
Act
:
none
MRRU
:: 1524
Red Diff Delay Act : none
MRRU
1524
Short
:: true
Oper
:: 1524
Short Sequence
Sequence
true
Oper MRRU
MRRU
1524
Oper
:: 1526
Fragment
Oper MTU
MTU
1526
Fragment Threshold
Threshold :: 128
128 bytes
bytes
Up
:: 0d
Bandwidth
:: 3968
Up Time
Time
0d 00:01:56
00:01:56
Bandwidth
3968 KBit
KBit
PPP
Primary
PPP Input
Input Discards
Discards :: 00
Primary Member
Member Port:
Port: 1/2/1.1.1.1.1
1/2/1.1.1.1.1
Mode
:: access
Mode
access
Interleave-Frag
:: false
Interleave-Frag
false
------------------------------------------------------------------------------------------------------------------------------------------------------------Member
#TS
Up
Member Port
Port Id
Id
#TS Admin
Admin Oper
Oper Act
Act Down
Down Reason
Reason
Up Time
Time
------------------------------------------------------------------------------------------------------------------------------------------------------------1/2/1.1.1.1.1
31
up
0d
1/2/1.1.1.1.1
31 up
up
up yes
yes N/A
N/A
0d 00:04:56
00:04:56
1/2/1.1.1.2.1
31
up
up
yes
N/A
0d
1/2/1.1.1.2.1
31
up
up
yes N/A
0d 00:04:57
00:04:57
===============================================================================
===============================================================================
...
... output
output truncated
truncated
Module 2 |
40
View the Completed ML-PPP Bundle IPCP Complete

Once the bundle is associated with an L3 interface, the bundle status becomes operationally up. The show
multilink-bundle bundle-ppp-1/2.1 detail command shows the bundles detailed status.
Oper Status: - The bundle operational state is up.
Minimum Links: - The minimum number of bundle members links required for the bundle to operate. The
default is 1.
Total/Active Links: - The total number of bundle links, and the number operational. The number active must
equal the minimum links value for the bundle to be operational.
MRRU: - The local MRRU value.
Oper MRRU: - The LCP negotiated MRRU value.
Oper MTU: - The largest L3 packet that can be sent on the bundle.
Fragment Threshold: - The maximum size of a fragment sent over the bundle. The default is 128 bytes.
Bandwidth: - The bandwidth across all operational bundle members.
View the Completed ML-PPP Bundle IPCP Complete
A:NodeA#
A:NodeA# show
bundle-ppp-1/2.1 ppp
ppp
===============================================================================
===============================================================================
Bundle
Bundle bundle-ppp-1/2.1
bundle-ppp-1/2.1 Multilink
Multilink PPP
PPP Information
Information
===============================================================================
===============================================================================
Local
Local EpId
EpId Class
Class :: IP
IP Address
Address
Local
Local Discriminator:
Discriminator: 10.10.10.10
10.10.10.10
Yellow
Short
:: true
Yellow Diff
Diff Delay
Delay :: 00
Short Sequence
Sequence
true
MRRU
:
1524
Oper
MRRU
:: 1524
MRRU
: 1524
Oper MRRU
1524
Interleave-Frag
:: false
PPP
Interleave-Frag
false
PPP Input
Input Discards
Discards :: 00
Multiclass
Classes
:
4
Multiclass Classes : 4
Ing
Egr
Ing QoS
QoS Profile
Profile Id
Id :: 00
Egr QoS
QoS Profile
Profile Id
Id :: 00
Magic
:: Disabled
Magic Number
Number
Disabled
===============================================================================
===============================================================================
===============================================================================
===============================================================================
PPP
PPP Protocols
Protocols for
for bundle-ppp-1/2.1
bundle-ppp-1/2.1
===============================================================================
===============================================================================
Protocol
Last
Restart
Protocol State
State
Last Change
Change
Restart Count
Count Last
Last Cleared
Cleared
------------------------------------------------------------------------------------------------------------------------------------------------------------ipcp
opened
11/16/2011
33
11/15/2011
ipcp
opened
11/16/2011 12:17:56
12:17:56
11/15/2011 12:05:10
12:05:10
...
... output
output truncated
truncated
===============================================================================
===============================================================================
Local
Local Mac
Mac address
address :: 60:39:01:02:00:05
60:39:01:02:00:05 Remote
Remote Mac
Mac address
address ::
Local
IPv4
address
:
203.0.113.9
Remote
IPv4
Local IPv4 address : 203.0.113.9
Remote IPv4 address:
address: 203.0.113.10
203.0.113.10
...
... output
output truncated
truncated
Module 2 |
41
View the Completed ML-PPP Bundle IPCP Complete (cont)

Once the bundle is associated with an L3 interface, the bundle status becomes operationally up. The show
multilink-bundle bundle-ppp-1/2.1 ppp command shows the bundles ppp status.
Local Discriminator: - The local bundle endpoint discriminator address.
Short Sequence: - Enables short sequence numbers in the MP frame header. This must match on each end.
Multiclass Classes: - The number of multiclass classes configured on the bundle. The class range is 2-4, and must
match on each end. Multiclass must be enabled in the bundle MLPPP context.
PPP Protocols for bundle-ppp-1/2.1
Protocol ipcp is the NCP for IP over MP bundles
State opened indicates the bundle NCP succeeded and the bundle is forwarding traffic
Restart Count The number of times IPCP has reached the opened state
Other states: initial, starting, closed, stopped, closing, stopping, requestSent, askReceived, ackSent
Local IPv4 address: - The local bundle L3 interface IP address
Remove IPv4 address: - The local bundle L3 interface address
Magic Number: - The magic number provides a method to detect loopbacks. If the value of the local magic
number is the same as the value of remote magic number, then it is possible that the link might be looped back. If
the two magic numbers do not match, then the link is not looped back. Default disabled.
View the Completed ML-PPP Bundle IPCP Complete (cont)
1 Hour
Lab Objectives:
On the CSA routers, provision three IMA DS1s and create an IMA bundle to
support 3G base station traffic
On the CSA routers, configure three ML-PPP DS1s and create an ML-PPP
bundle to support 3G base station traffic
Module 2 |
42
Lab 2: Configure TDM ATM IMA Interfaces
Section Summary
How to configure Ethernet access port mode, encapsulation type,

autonegotiation, MTU, and hold time
How to build out OC-3 virtual tributaries, DS1s and channel groups
Commands and procedures used to create and monitor ATM IMA
and ML-PPP bundle groups
Module 2 |
43

Section 2 Timing and Synchronization in the Backhaul Transport

Network
Section Objectives
Explain the need for synchronization in the Backhaul Transport

Network
Describe network synchronization techniques physical layer and
packet-based
Locate synchronization sources in the Model 2 architecture
Building Integrated Timing Supply (BITS)
Synchronous Ethernet (SyncE)/Ethernet Synchronization
Messaging Channel (ESMC)
IEEE 1588v2/Precision Time Protocol (PTP)v2
Implement BITS, SyncE, and PTPv2 in the Backhaul Transport
Module 2 |
46
Backhaul networks require accurate synchronization sources

Air interfaces require frequency and phase synchronization for proper
RF operations and smooth hand-off between base stations
TDM interfaces require frequency synchronization to avoid bit errors,
jitter, and frame delay
Module 2 |
47
Synchronous Network Timing Requirements

What is synchronization?
Synchronization is the ability to achieve equivalent values for time, frequency, and phase at different elements
in the network. Alcatel-Lucent. 7705 SAR Synchronization 1.0 v1.0.
Timing and Synchronization Requirements
In the backhaul transport, synchronization addresses two important requirements:
1. Air interface timing To avoid RF interference, the base station RF interfaces must meet 3GPP-prescribed
minimum frequency and phase accuracy requirements. Base stations communicate with the handsets and
neighboring base stations via RF signals.
Frequency accuracy Frequency Division Duplexing (FDD) radio technologies such as GSM 2G and WCDMA
must meet a frequency accurancy of +/- 50 parts per billion (ppb). One ppb is equal to one bit per one
billion bits. [63] For example, an 840MHz GSM carrier must be accurate to within 42Hz, or 50 ppb.
Many operators set a more stringent requirement to provide base station error margins when modulating the
signal for transmission. For example, the BS transport interface requirement is 16ppb to allow for BS HW
oscillator limitations.
Phase (time) accuracy Time Division Duplexing (TDD) radio technologies such as CDMA, CDMA2000, and LTE
TDD require a varying clock accuracy between +/- 3us to +/- 1.25us. The general standard is 1us +/- 500ns.
This insures proper handover between CDMA and LTE networks, proper LTE Multiple Input/Multiple Output
(MIMO) mechanism operation and supports future LTE features which might require phase synchronization.
Most often a carrier addresses both FDD and TDD synchronization to improve BS handover performance.
2. TDM timing The CSA and backhaul transport TDM interfaces require frequency synchronization to meet Bit
Error Rate (BER), frame delay, bit jitter, delay difference, and other requirements.
ITU-T G.824 allows for a maximum jitter (delay variation) of .1 Unit Interval (UI) Peak-to-Peak (UIpp) on a
DS1 interface, where a UI measures 647ns for a T1 signal, and 488ns for an E1.
Synchronous Network Timing Requirements
Hierarchical master-slave topology at physical layer

Arranged by Stratum level
Best quality clocks at the central office level
Downstream clocks follow upstream clock frequency
Module 2 |
48
North American Network Timing Hierarchy

This hierarchy, described in ANSI/T1.101-1998, specifies network timing level sources. The Stratum value
describes the sources distance from the reference clock. An important factor is that each clock can trace timing
to a single reference source.
Stratum 1
T1.101-1998 calls this a Primary Reference Source (PRS). The Stratum 1 reference is directly connected to a
reliable time source, such as a GPS receiver. Stratum 1 sources have a free run fractional frequency (f/f)
accuracy of +/- 1x10-11. This equals 1 frame slip every 4-5 months. This clock may also be called the Primary
Reference Clock (PRC).
Stratum 2
Tracks the Stratum 1 reference, and will experience a free run accuracy of +/- 1.6x10-8 per year, equaling one
frame slip in 7 days when running in holdover mode. A stratum 2 clock compares its local clock to that of the
received PRC UI. If the received rate is lower, the stratum 2 clock decreases its clock rate; if the received UI is
higher, the local clock increases its clock rate.
Stratum 3
Provides a free run accuracy of +/- 4.6 x10-6 per year and a holdover stability of +/- 3.7 x10-7 for 24 hours, or 255
frame slips/day. As the stratum 2 clock adjusts to the PRC, the stratum 3 clock adjusts its rate to that of the
stratum 2 clock.
Stratum 4
No input drift up to 3.2x10-5 per day.
Stratun 3E (not shown)
Developed for SONET equipment, stratum 3E sources a 1.544 MHz input, provides a free run accuracy of +/- 4.6
x10-6 per year and a holdover stability of +/- 1.2 x10-8 for 24 hours, or less than 4 frame slips/day.
Frame Slip
Frame slips occur because of timing problems on a circuit. A device sends a frame timed to a reference that
differs from the receivers reference. This causes the frame to start in a different position in the clock pulse on
either end, resulting in lost data.
Holdover
If a clock loses its master clock signal, it goes into holdover mode. In holdover, it must maintain its clock
accuracy depending on its stratum level.
North American Network Timing Hierarchy
BITs provides timing to the CO equipment

All CO timing is traceable to a BITS master clock, an ITU-T G.812
Synchronization Supply Unit (SSU)
BITS SSU may be Stratum 2, 3, or 3E
A CO SSU must only reference an equal or higher stratum level
clock
Module 2 |
49

Also known as Building Integrated Timing Service (BITS), BITS ensures all CO digital devices nodes have the same
average frequency.
Interoffice links carry timing between COs over primary and secondary links, commonly DS1s. The COs BITS
master timing distribution unit distributes a stratum 2, 3, or 3E reference throughout the CO.
The BITS acts as the CO synchronization supply unit (SSU) in accordance with the ITU-T G.812 recommendation.
According to G.812, the SSUs master may be a PRC, another SSU, or an SDH Equipment Clock (SEC). ITU-T G.813
defines the SEC as a SONET/SDH slave clock, a term used in reference to timing on SONET and packet networks
(see IEEE 1588v2 later in this Module).
Jitter and Wander
Jitter represents a rapid change in a clock rate. A slave clock adjusts its clock rate according to the received
master UI, and may adjust rapidly. This nearly instantaneous change in clock rate can result in bit errors. Jitter is
measured as Unit Interval Peak-to-Peak (UIpp), the difference between the maximum and minimum time intervals
of the measured UI compared to the nominal UI.
Wander represents a long term clock rate drift, over hours or days. Temperature changes, component aging, and
slave clock inaccuracies result in wander. Wander is measured over a period of time, and the measurement is
called Time Interval Error (TIE), also known as phase error.
An SEC must be able to attenuate jitter and wander. They do this by averaging out these differences and slowly
adjusting their reference clocks.
The ITU-T G.813 recommendation requires:

A slave clock traceable to a PRC
Multiple reference inputs
A slave capable of maintaining holdover within ITU prescribed
limits (see the North American Timing Hierarchy earlier in this
Module.)
Module 2 |
50
ITU-T SDH Equipment Clock (SEC)
Synchronization Frequency v. Phase and Time
Phase/time synchronization
Clock frames start simultaneously across all nodes, tA=tB
Module 2 |
51
Synchronization Frequency v. Phase and Time

All Backhaul base stations require frequency synchronized clocks. This ensures correct RF operation and avoids
frame slips on the TDM uplinks.
Synchronizing both frequency and phase/Time of Day (ToD) is more challenging. A node can recover the clock
frequency from a physical layer technique, such as the bit stream on a DS1 or the RF carrier on a microwave
circuit. However, physical-layer techniques dont tell the node at exactly what time the next clock pulse will
occur, so they cannot synchronize the clock phase or time. The next frame may leave Node A a microsecond
earlier or later than a frame leaving Node B; the Nodes know how often to send a frame, but not at what time.
Packet-based timing techniques can delivery ToD information. A master advertises a timestamp, and a slave runs
an algorithm against this timestamp information to determine when the next clock pulse should occur. This
algorithm has to compensate for delay variation the packet experiences end-to-end, termed Packet Delay
Variation (PDV).
Frequency Synchronization - Important for RF carrier alignment and to avoid data-over or underruns.
Phase Synchronization - Ensures transmit frame timeslot alignment to avoid overlap between base stations.
Time Synchronization Necessary for event correlation, alarming, billing, security, and transaction processing.
Frequency synchronization
Clock frequencies match within 50 parts per billion, x = y
Physical timing
A receiver sets its
SEC from transitions
in the received
physical bit stream
Lines up clock pulses
and frequency, but
transitions still may
occur at different
points in time
Module 2 |
52
Physical versus Adaptive Timing Techniques

Physical Timing
Physically timed nodes recover the clock from the received bit stream. By referencing the transitions on the wire,
the receiver can set its local clock pulses to match the transition rate. Physical timing occurs on a link-by-link
basis. The link encoding method must ensure enough transitions, even if the source is sending no data.
An SROS router can derive physical timing from an external BITS port, a DSx, Ex, or OC-x port, or a Synchronous
Ethernet port.
Physical versus Adaptive Timing Techniques
Adaptive timing
A receiver sets its SEC frequency by a calculated time offset
A receivers sets its ToD and phase by the timestamp values
Recovery algorithm must compensate for Packet Delay Variation
(PDV)
Module 2 |
53
Physical versus Adaptive Timing Techniques (cont)

Adaptive Timing
Adaptive timing techniques delivery the timing reference information in a series of packets delivered by a wellknown source. SROS routers support two different adaptive techniques.
Adaptive Clock Recovery (ACR)
The node sets its clock by the incoming packet rate. The ACR algorithm recovers the network clock from the
constant packet arrival rate. A cPipe service from the timing source carries the timing packets. ACR supports
frequency synchronization.
IEEE 1588v2 Precision Timing Protocol (PTP) v2
The node sets its frequency and clock from timestamps carried in the received packets. The clock recovery
algorithm calculates a clock offset value based on the mean difference between sampled timestamps. The
slave sets its ToD and phase from the timestamp values.
IEEE 1588v2/PTPv2 supports frequency, phase, and ToD synchronization. SROS only currently supports PTP v2
frequency synchronization.
Physical versus Adaptive
A benefit to using adaptive timing over physical timing is that nodes can not only set their clock frequency, but
also the phase and time of a day. Another is that adaptive timing is an end-to-end technique.
A challenge to implementing adaptive timing, however, is that PDV influences the packet delivery times, causing
varying offset values between received packets. The algorithm used must sample enough packets to effectively
negate PDVs influence, taking a long term sample to calculate an average offset value.
Physical versus Adaptive Timing Techniques (cont)
Synchronization techniques
Physical External GPS,
Synchronous Ethernet, Line
Timing
Packet-based IEEE 1588v2,
Adaptive Clock Recovery
Module 2 |
54
Packet Network Synchronization Techniques

Physical Layer Based-Techniques
External sources, such as GPS or BITS, line-derived timing, or Synchronous Ethernet are all examples of physical
synchronization techniques. A Backhaul Transport Network uses a combination of these sources.
For example, a cell site could use a GPS receiver to set phase and time. However, it might use line timing for its
outbound TDM packets.
Another example, Synchronous Ethernet, adds a more accurate clock reference to the standard Ethernet physical
layer (PHY). Ethernet coding can deliver a reliable clock to meet the 3GPP 50 ppb frequency accuracy standard.
Packet-Based Synchronization
IEEE 1588v2/PTPv2 and ACR are both packet-based techniques. Also known as adaptive techniques, packet-based
synchronization techniques recover the clock from a well known source-delivered packet stream. A PTP capable
node measures path delay between a master and slave, calculates its time offset in comparison to the master,
and sets the local slave oscillator rate.
Timing Distribution Design Considerations
All timing distribution schemes must ultimately trace back to a single, Stratum 1 source. If more than one source
exists on the network, frame slips, frame misalignment, co-channel interference, and location service failures will
occur.
Timing loops can easily occur when multiple sources are used. If network elements choose timing sources other
than the master source, their timing will float from the masters causing bit errors and even large scale traffic
loss.
Quality of service policies must give packet-based timing solutions the best possible treatment, Network Control
(NC) class, to avoid delay and jitter. Both effect the derived clocks reliability. High bandwidth links should carry
timing packets, and the number of hops between the master and slave should be few, five or less according to
current design recommendations. Though PTP packets are routed, requiring no service for transport, ACR packets
must be transported in a cPipe service, requiring a service infrastructure in place.
Packet Network Synchronization Techniques
Application
Frequency
Relative Phase
Solutions
GSM
W-CDMA FDD
MBMS*
50 ppb
10 to 100 ms
Timing over Packet

(ACR, 1588v2)
SyncE
E1/T1 Line timing
LTE FDD
LTE MBMS
50 ppb
10 to 100 ms
Timing over Packet

SyncE
CDMA2000
50 ppb
6 us
(20 us worst
case)
GPS
W-CDMA TDD
LTE TDD
50 ppb over
one timeslot
2.5 us
GPS
1588v2 and SyncE
e911 LBS**
N/A
200 ns
GPS
1588v2 and SyncE
Module 2 |
55
Synchronization Requirements
This table shows the synchronization requirements for various backhaul applications as defined by ITU-T and 3GPP
recommendations and standards. Notice that although the reference specifies phase accuracy requirements for
FDD applications, the TDD application requirements are much more stringent.
SyncE
Synchronous Ethernet provides an accurate frequency reference, but no phase or Time of Day (ToD) reference. It
is suited well for FDD applications, and is easily deployed.
IEEE 1588v2 and PTPv2
PTPv2 provides phase and ToD accurancy, but is susceptible to network conditions, such as delay and packet loss.
It is more accurate as a reference on high bandwidth links versus lower bandwidth links, where PDV negatively
impacts PTPs reliability. On a properly planned and engineered network PTP provides a viable solution for
meeting TDD phase accuracy requirements on IP networks.
Physical Timing
Traditional physical layer techniques, GPS and line timing, are also viable choices, where available and feasible.
ACR
ACR is another possible packet-based approach, but only within the context of a cPipe service. This technique
would require cPipes running between the CSA and the POC routers, and the reference needs to be a TDM port.
*Multimedia Broadcast Multicast Service (MBMS) A 3GPP point-to-multipoint interface for delivering broadcast
and multicast services on cell and core networks.
**E911 Location Based Services (LBS) use RF patterns and signal characteristics to determine a callers location.
This requires phase accuracy for reliable operation.
Synchronization Requirements
Current solutions may use a mixture of physical and packet-based

techniques
Physical, such as GPS, SyncE, or line timing at the cell site
SyncE or 1588/PTP in the packet transport
Line timing on TDM interfaces
Module 2 |
56
Synchronizaton Source Locations

This slide illustrates where to apply our various timing source options. The actual design depends on the
customers requirements, and there are no hard-fast rules. The goal, however, is to synchronize each node to
a common, master source.
MTSO
In all cases, the MTSO nodes have access to a Stratum 1 traceable source, and so clearly the MLS routers would
become the master timing source for the Backhaul Transport nodes.
MLS1 and MLS2 connect to the PRC via their BITS ports. Both support both external and line timing sources. One
could set both MLS routers to time off BITS as their primary source, or alternately, set one or the other as the
network timing master, and slave the other off a TDM, SyncE, or PTP interface connecting it to the master.
Aggregation Network
In the aggregation network, the POC routers could use GPS or another external timing reference, though this is not
always practical for cost reasons. They could use SyncE, if capable, or they could use ACR or PTP.
If ACR is used, a full mesh of cPipe services is required. If PTP is used, you must consider the distance between
the slave and the master. Multiple PRCs may be used, as well. Alcatel-Lucent proposed solution recommend
either ACR or PTP, but not both in the same network.
In locations where SyncE cannot be deployed throughout, such as in a BTP network, SyncE and PTP may be
combined, with SyncE to the MLS/MT, and PTP between the MLS and MT.
Redundancy may be provisioned, to allow a node to choose a PTP or ACR source based on priority and optionally,
Quality Level. SyncE SSM and PTP can pass source Quality Level to allow the nodes to chose the best available
clock source. We discuss Quality Levels in more detail in the SyncE/SSM section.
Access Network
At the CSA, again we might use physical, adaptive, or a combination of the two. The CSA can deliver SyncE or PTP
timing to the cell site base station. The base station could also use a local timing source or TDM line derived
timing. The source chosen depends on the base station type.
Synchronization Source Locations
Section Summary
Why the Backhaul Transport Network needs timing for proper

operations
The differences between physical layer and packet-based
synchronization techniques
Where current design guidelines place the synchronization sources
in the Backhaul Transport Network
Module 2 |
57

Section 3 Timing and Synchronization Synchronous Ethernet
Section Objectives

Explain how SyncE can provide air and TDM interface
synchronization in the Backhaul Transport Network
Describe the Ethernet Synchronization Messaging Channel (ESMC)
Synchronization Status Message (SSM) format and event codes
Trace SSM message flow in normal and failure operations
Configure SyncE/SSM in the Backhaul Transport network
Module 2 |
60
Explain Synchronous Ethernet (SyncE) operation
ITU-T G.8261/Y.1361 physical layer-based timing technology

unaffected by network load
The POC1 physical layer transmit clock is locked to a high-quality
reference clock (BITS port)
The receivers lock their clock the received signals physical layer
clock
Each node in the path is Sync-E capable and enabled
A node can be both a slave and a master
Module 2 |
61
Synchronous Ethernet
Nodes running Synchronous Ethernet (SyncE) synchronize their clocks to the Ethernet bit stream. The usually free
running Ethernet physical layer clocks synchronize to a PRC traceable throughout the network. Synchronous
Ethernet replaces a portion of the standard Ethernet preamble with a 4-bit synchronization pattern and a 4-bit
coding violation pattern.
At the source, the PRC drives the Ethernet PHY. Each node derives their reference clock from the PHY layer, based
on the ITU-T G.813 SDH Equipment Clock (SEC) model.
G.813 requires:
A slave clock traceable to a PRC
Multiple reference inputs
A slave capable of maintaining holdover within ITU prescribed limits (see the North American Timing
Hierarchy earlier in this Module.)
Synchronous Ethernet
Each SyncE capable node maintains a Synchronous Ethernet

Equipment Slave Clock (EEC)
EEC should be accurate to </= 4.6 part per million (.0001%) per
year
Two options according to ITU-T G.8262/Y.1362
EEC Option 1 SDH Mode for 2048 Kb/s hierarchy
EEC Option 2 SONET Mode for 1544 Kb/s hierarchy
Module 2 |
62
Synchronous Ethernet (cont)

Ethernet Equipment Clock (EEC)
ITU-T G.8262/Y.1362 describes the timing characteristics of the Synchronous Ethernet Equipment Slave Clock
(EEC), the equivalent of the G.813 SEC. The EEC slave clocks must perform in a manner consistent with the SDH
SEC slave clocks.
The EEC contains two options:
EEC Option 1 - Synchronous Ethernet equipments designed to inter-work with networks optimized for the
2048 kb/s hierarchy. This equates to the G.813 Option 1 SDH mode using a 2048 kb/s hierarchy.
EEC Option 2 - Synchronous Ethernet equipments designed to inter-work with networks optimized for the
1544 kb/s hierarchy. This equates to the G.813 Option 2 SONET mode using a 1544 kb/s hierarchy.
G.8262 outlines minimum requirements for clock accuracy, noise transfer, holdover performance, noise tolerance,
and noise generation.
The recommended clock accuracy for both options is </= 4.6ppm per year, though G.8262 leaves EEC1 open to 4.6
ppm per month. EEC2 requires </= 4.6ppm per year maintained over a 30 day holdover period.
4.6 ppm is the equivalent of 148.2 seconds per year.
Synchronous Ethernet (cont)
ITU-T G.704/707 describe SSM as a

means to carry clock quality
information on SONET/SDH
networks
ITU-T G.8264/Y.1364 describes an
Ethernet Synchronization
Messaging Channel (ESMC) used to
transport reference clock quality
level information
Quality messages carried by IEEE
802.3 Slow Protocol frames,
EType 0x8809
Augments SyncE with clock
traceability and loop detection
Module 2 |
63
Synchronization Status Messages (SSM) and SyncE

Though SyncE provides an accurate synchronization bit pattern, it provides no protection against timing loops nor
PRC traceability. The ITU-T G.8264/Y.1364 Ethernet Synchronization Messaging Channel (ESMC) addresses these
conditions by extending the ITU-T G.781 SSM format for use in Ethernet networks.
SSM
ITU recommendations define SSM as a means of conveying clock quality information on a SONET/SDH network.
According to ITU-T G.707, SDH frames carry a 4-bit SSM code in the circuits overhead. SONET and T1 Extended
Superframe (ESF) framed circuits may also carry these codes. SyncE SSM carries these codes in the IEEE 802.3
Slow Protocol data TLV fields.
ESMC
G.8264/Y.1364 describes the ESMC as a transport mechanism for SONET SSM events in an Ethernet network.
According to the G.8264 recommendation, ESMC is The logical channel carrying the SSM code representing the
quality level of the synchronous Ethernet equipment clock (EEC), which is bonded to the physical layer. In other
words, ESMC provides clock quality level messages transported by Ethernet frames between SSM-enabled Ethernet
port. These ESMC messages, carried by an IEEE 802.3 -2008, Annex 57B, Slow Protocol Organizational Specific
Slow Protocol (OSSP) subtype frame, allow a slave device to trace its synchronization trail in the direction of the
highest quality clock source. The IEEE 802.3 Slow Protocol has these characteristics:
No more than 10 frames transmitted per second
An interface may support a maximum of 10 Slow Protocol subtypes
The maximum Slow Protocol recommended frame size is 128 bytes
Slow Protocols support Ethernet functions such as Link Access Control Protocol (LACP) for LAGs, subtype 1. Slow
protocols use the Slow Protocols multicast destination MAC address 01-80-C2-00-00-02, and include the Slow
Protocols Type field value 0x8809. OSSP is Slow Protocol subtype 10.
Other ITU-T Synchronous Ethernet related recommendations include:
G.8261/Y.1361 - Defines the framework for synchronization over a packet switched network
G.8262/Y.1362 - The Synchronous Ethernet equipment clocks.
Synchronization Status Message (SSM) and SyncE
Slow protocol Subtype 0x0A (10)

message frame format
Uses the Slow Protocol
multicast destination MAC
address
Specifies the ITU-T OUI and
subtype
Includes flags to identify the
data type contained in the
TLV
Padding included as necessary
to bring frame to minimum
Ethernet size of 64 bytes
Module 2 |
64
Synchronization Status Messages (SSM) and SyncE (cont)

OSSP ESMC PDU
IEEE 802.3 describes the OSSP PDU format. G.8264/Y.1364 describes the ESMC PDU unique field values.
Destination address Always multicast destination 01-80-C2-00-00-02
Source address Senders MAC address
Slow protocol Ethertype 0x8809
Slow protocol subtype 0x0A (10)
ITU-T OUI 00-19-A7
ITU-T Subtype 00-01
Version 1
Event flag 0= Informational PDU, sent as an announcement message and Hello PDU.
- 1= Event PDU, sent whenever the clock quality level changes
Data Contains the Quality Level (QL) TLV describing the SSM event the message conveys. G.781 describes the
SSM event codes, discussed in the following slides.
Synchronization Status Messages (SSM) and SyncE (cont)
SSM Events, G.781 Option 1- SDH Mode
1111
Name
Quality PRC
Quality SSU-A
Quality SSU-B
Quality
SEC/EEC1
Quality DNU
Quality
Level
Best
Lowest
Description
Trail source is PRC clock (Stratum 1)
Trail source is type I* or V* slave clock
Trail source is type VI* slave clock
Trail transports a timing quality
generated by a synchronous equipment
clock (SEC)
Do not use for synchronization
* ITU-T G.812 defines the clock type by stratum level
Type II = Stratum 2
Type III = Stratum 3E
Type IV = Stratum 3
Type V, VI = Local node clock
Type I = Undefined by G.812
These codes received on SDH and

E1 ports
ESMC passes in QL TLV
QL-PRC highest quality source
QL-DNU used for loop prevention and acknowledgement
Module 2 |
65
SSM Events, G.781 Option 1 SDH Mode

ITU-T G.781 defines the SSM QL event codes. SDH networks use the Option 1 codes to indicate the SDH 2048 khz
clock source quality levels.
QL-PRC SDH PRC Traceable - Indicates the source as the PRC, or the reference clock for all slaves in the
network. A receiving node will synchronize its SEC to the source and forward the QL-PRC to its neighbors.
QL-SSU-A and QL-SSU-B SDH Primary Level SSU Traceable (SSU-A) and Second Level SSU Traceable (SSU-B) Indicate the slave clock type.
QL-SEC SDH SEC Traceable - Indicates the slave has gone into holdover because it has lost contact with the
PRC. Upon receipt of a QL-SEC, the slave looks for a new PRC in incoming QL-PRC messages.
QL-EEC1 is SDH mode SyncE equivalent.
Not considered for source qualification:
QL-DNU SDH Do Not Use (DNU) - Indicates to the source that the slave has received the QL-PRC. This insures
source clock traceability and prevents timing loops in the case of a link failure toward the PRC.
Nodes downstream of the PRC determine the sources quality level, and can autonomously reconfigure their
timing path to find the best source and avoid timing loops. For example, Model 2 uses a ring topology and
timing messages flow in both directions at once. Without SSM support, a downstream node may choose a less
desirable primary timing path.
SSM
Code
0010
0100
1000
1011
SSM Events, G.781 Option 2- SONET Mode

Name
1100
Quality PRS
Quality STU
Quality ST2
Quality TNC
Quality ST3E
Quality
ST3/EEC2
Quality SMC
1110
1111
Quality PROV
Quality DUS
Quality
Level
Best
Lowest
Description
Trail source is PRS clock (Stratum 1)
Does not carry source QL TLV
Trail source is stratum 2 clock
Trail source is transit node clock
Trail source is stratum 3E clock
Trail source is stratum 3 clock
Trail source is SONET/Ethernet selftimed node
Network operator provisioned
Do not use for synchronization
These codes received on SONET and T1 Extended Super Frame (ESF) ports
QL-PRS highest quality source
QL-DUS used for loop prevention and acknowledgement
Module 2 |
66
SSM Events, G.781 Option 2 SONET Mode

SONET networks use the Option 2 codes to indicate the SONET 64 or 1544 khz clock source quality level.
QL-PRS SONET PRS Traceable - Equivalent of QL-PRC. Stratum 1 Trail source clock (ITU-T G.812 Type I).
QL-STU SONET Synchronous Traceability Unknown (STU) - Trail source clock unknown. SF-framed DS1s do
not carry SSM bits, so the router shows this source with QL STU.
QL-ST2 SONET Stratum 2 Traceable (ST2) - Stratum 2 clock trail source (G.812 Type II).
QL-TNC SONET Transit Node Clock Traceable (TNC) - TNC trail source (G.812 Type V).
QL-ST3E SONET Stratum 3E Traceable (ST3E) - Stratum 3E trail source clock (G.812 Type III).
QL-ST3 SONET Stratum 3 Traceable (ST3) - Stratum 3 trail source clock (G.812 Type IV).
Ethernet Equipment Clock2 (QL-EEC2) is SONET mode SyncE equivalent.
Not considered for source qualification:
QL-SMC SONET Minimum Clock Traceable (SMC) - SONET or Ethernet self-timed node trail source clock.
QL-PROV SONET Provisioned by the network operator (PROV). Shown is the default position for QL-PROV,
though the operator may change it.
QL-DUS SONET Do Not Use The equivalent of the Option 1 QL-DNU.
SSM
Code
0001
0000
0111
0100
1101
1010
SSM Internal Events, Both Options 1 and 2
Quality INVx
Quality NSUPP
Quality FAILED
Quality UNC
Quality
UNKNOWN
Quality
Level
Internal
Use
Internal
Use
Internal
Use
Internal
Use
SROS
Only
Description
Generated when a node receives an
unallocated SSM value, x= the value
Generated when the node doesnt support
SSM processing
Generated if the synchronization trail is in
signal fail
Generated when node clock is in holdover
SSM port received no message
G.781 Internal Events

For internal use only, never passed to physical interface
SROS also defines QL-UNKNOWN
Module 2 |
67
SSM Internal Events, Both Options 1 and 2

Internal QL TLVs
For both Option 1 and Option 2 networks, internal QLs may appear in the CLI but not in the physical interfaces.
These include:
QL-INVx Indicates an invalid SSM value
QL-NSUPP - G.781 defined but not used in SROS.
QL-FAILED Indicates the distribution trail is in fail state.
QL-UNC Indicates node clock is in holdover.
QL-UNKNOWN Indicates a SyncE port with SSM disabled or that the port is configured for SSM but no QL
message received. The port transitions to QL-FAILED if it receives no valid message in 5 seconds
(configurable).
Name
Configuring Synchronous Ethernet
SR Default is bits ref1 ref2

SAR Default is external ref1 ref2
2.You may configure the router to

choose by quality level, then
reference order
3.You may override the
reference quality level
4.Enable Synchronous Ethernet
on the SR MDAs
config>system>sync-if-timing#
config>system>sync-if-timing# ref-order
ref-order bits
bits ref1
ref1 ref2
ref2
config>system>sync-if-timing# ql-selection
ql-selection
config>system>sync-if-timing# bits
bits ql-override
ql-override prc
prc
config#
config# card
card 11 mda
mda 11 sync-e
sync-e
Enabled by default on SAR MDAs
5.Enable SSM on ring ports
config>port#
ethernet ssm
ssm no
no shutdown
shutdown
Module 2 |
68
Configuring Synchronous Ethernet

SROS CLI uses the term SSM to describe ESMC configuration and management. Hence, in this section we use the
term SSM in reference to ESMC operation.
To configure synchronous Ethernet on the Backhaul Network:
Set the router timing sources and timing reference order. The order you choose depends on the network
design and the clock source node locations. Setting the timing reference order correctly is key to ensuring the
nodes choose the correct primary, secondary, and tertiary timing reference sources.
Additionally, you may allow the router to pick references by the sources advertised quality level. In this case,
the router first chooses the reference with the best QL. If two references share the same QL, the priority
order breaks the tie.
You may override the QL received on a port. For example, the SROS sets a SF-framed DS1 to QL-STU. You can
tell the router to override QL-STU and advertise QL-PRC (or -PRS) instead so that it can influence downstream
nodes reference selections.
Enable SyncE on the MDAs. The 7450 ESS and 7750 SR routers support SyncE/SSM only on the optical port
equipped GigE MDA-XPs and IMMs.
The SAR-8 and SAR-F must have the Ethernet v2 MDAs installed. SyncE support is enabled by default on the SAR
platforms.
The optical SFPs must also be SyncE capable.
Enable SSM on the ring ports.
Configure Synchronous Ethernet Support

1.Set router timing reference order
Nodes set timing references based on their position and relation to the
two MLS routers
MLS1 is the network SSU; reference selection is hop-by-hop
Based on their configurations, MLS2 and others trace their clock
reference to MLS1 as SSU
QL Selection allows ring nodes to choose alternate source if better
quality available
Module 2 |
69
SSM Operation Model 2 Subtended Ring

SSM Normal Operation Reference Clocks
In this section, we use the SROS CLI term SSM to describe ESMC configuration and management.
POC1 MLS1 Network SSU
The POC1 MLS1 sets its clock references as follows bits ref1 ref2:
1. Priority 1 BITS External GPS or other Stratum 1 source (PRC)
2. Priority 2 Reference 1, loop-timed from SONET/STM mux interface (not shown)
3. Priority 3 Reference 2, SyncE-timed on Ethernet port facing MLS2
MLS1 falls back from BITS to STM, then to SyncE/SSM at priority 3 if the BITS and STM loop timing become
unavailable.
POC1 MLS2
MLS2 reference order: ref1 bits ref2:
1. Priority 1 Reference 1, SyncE-timed on Ethernet port facing MLS1
2. Priority 2 BITS From Stratum 1 source
3. Priority 3 Reference 2, loop-timed from SONET/STM mux interface (not shown)
POC2-1, POC3-1, and CSA1 routers
Reference order: ref1 ref2 external (external shut down). ql-selection is enabled.
1. Priority 1 Reference 1, SyncE-timed on Ethernet MLS1-facing port
3. Priority 3 shutdown
POC2-2, POC3-2, and CSA2 routers
These reverse the POC2-1, POC3-1, and CSA1 reference order. ql-selection is enabled.
3. Priority 3 shutdown
QL selection is enabled on the POC2, POC3, and CSA routers.
NOTE: If SARs, the POC2, 3 and CSA router priority 1 and 2 reference ports must be on different MDAs (except SARF); if SRs, the ports must be on different IOMs, as well.
SSM Operation Model 2 Subtended Ring
1 MLS1 sends QL-PRC out of its SSM-enabled ports

2 Other ring nodes choose their reference source by timing reference
priority, advertised quality, or both
3 Each node returns QL-DNU towards selected source, MLS1
Module 2 |
70
SSM Operation Model 2 Normal Operations

SSM Normal Operation Message Flow SDH Mode
The SROS sets the SSM port operation modes to SDH (Option 1) by default. This determines the SSM messages sent
in the network.
POC1 MLS1
POC1 MLS1 sends a QL-PRC out on all SyncE/SSM enabled ports. MLS1s advertised QL value depends on that nodes
reference clock quality level, though the SROS allows you to override this value, if desired. For example, the
router assigns an SF-framed DS1 QL-STU, but you can override that value in the BITS configuration.
Each node generates its own quality level on each SSM enabled port, based on its chosen reference QL. So, if
POC2-1 chooses as its reference a source advertising QL-STU, it will send QL-STU, unless you override this behavior
(ql-override on the reference).
In our example, POC2-1 advertises QL-PRC towards POC3-1, based on the MLS1 advertised QL-PRC.
QL-PRC on Redundant ports
In normal operations, as shown above, the nodes can receive QL-PRC messages on all ring ports- all SSM-enabled
ports deliver ESMC messages. In this example, however, we configure our timing references on the ports providing
the most direct link to the network SSU, MLS1. Splitting the network as shown helps speed convergence in the
case a reference goes offline, while maintaining traceability to the primary SSU.
Reference configuration is a static process; there is no dynamic selection protocol involved. The nodes update
their clocks from the bit stream received on the highest priority reference port (unless QL selection is enabled).
QL-DNU
For source traceability, each node returns to the chosen source a QL-DNU message.
POC1 MLS2
MLS2s primary timing reference is its MLS1 facing port. MLS2 receives MLS1s QL-PRC and returns QL-DNU. As
configured, POC2-2 chooses MLS2 as its reference and returns QL-DNU toward MLS2.
Clock Traceability
From the cell site back to the network SSU, the network nodes can trace their clock to the MTSO PRC. Each node
only has one port slaved to the upstream clock source.
SSM Operation Model 2 Normal Operations
Break in MLS1 to POC2-1 link

1 POC2-1 no longer qualifies link to MLS1
2 POC2-1 sends QL-EEC1 towards POC3-1
3 Remaining nodes remain on priority 1 reference
Module 2 |
71
SSM Operation Failure on MLS1 Link

Prior to the link failure, both MLS1 and MLS2 are sending QL-PRC into the ring. The nodes in the top part of the
diagram, POC2-1, POC3-1 and CSA1, all choose their MLS1-facing ports as their SSM source.
The nodes in the bottom part of the diagram choose their MLS2 facing ports, but all can trace their references to
MLS1 as the network SSU.
Note that the following steps happen almost simultaneously.
If the link between MLS1 and POC2-1 fails, the following occurs:
1. POC2-1 disqualifies its link to MLS1 and goes into free run.
2. POC2-1 sends QL-EEC1 toward POC3-1.
3. All routers remain synchronized to their reference 1 source. They are unaware of any change on the link
between POC2-1 and MLS1.
SSM Operation Failure On MLS1 Link
At time of break, other nodes are unaware that

MLS1 is unavailable
4 POC3-1 receives QL-EEC1 on its primary reference
5 With ql-selection enabled, POC3-1 chooses its
qualified reference 2 source, POC3-2

6
All other nodes except POC2-1 remain on reference 1; POC2-1 chooses
POC3-1 as its primary reference
Module 2 |
72
SSM Operation Failure on MLS1 Link (cont)

4. POC3-1 receives QL-EEC1 from POC2-1.
5. QL Selection tells POC3-1 to select its POC3-2 facing port as its reference. This overrides the reference
priority order, as the POC3-2 advertised QL-PRC overrides QL-EEC1 received on the POC2-1 port.
POC3-1 sends QL-DNU to POC3-2.
6. POC3-2, 2-2, and the CSAs all remain on their qualified, priority 1 references.
POC2-1 chooses POC3-1 as its primary reference.
QL-PRC in the Access Ring
The access ring nodes choose their reference by their configured reference priority, regardless of which POC1
router becomes the primary reference. The loss of the MLS1 router link does not effect the access ring nodes
chosen reference. POC3-1 forwards QL-PRC into the ring as it did before. Note however that POC3-2 also
sends QL-PRC into the access ring, so the CSA routers choose by QL and then by reference order, if necessary.
SSM Operation Failure On MLS1 Link (cont)
Set the MLS1 router Timing References
Syntax:
Syntax:
begin
begin
bits
bits interface-type
interface-type {ds1
{ds1 [{esf|sf}]
[{esf|sf}] || e1
e1 [{pcm30crc|pcm31crc}]}
[{pcm30crc|pcm31crc}]}
ref1
ref1 source-port
source-port slot/mda/port[.channel]
slot/mda/port[.channel]
ref2
ref2 source-port
source-port slot/mda/port[.channel]
slot/mda/port[.channel]
[no]
[no] ref-order
ref-order <first>
<first> <second>
<second> [<third>]
[<third>]
[no]
revert
[no] revert
[no]
ql-selection
[no] ql-selection
commit
commit
abort
abort
Example:
Example: config#
config# system
system sync-if-timing
sync-if-timing
config>system>sync-if-timing# begin
begin
config>system>sync-if-timing# ref1
ref1 source-port
source-port 1/2/1
1/2/1
ref1
config>system>sync-if-timing# ref1 no
no shutdown
shutdown
ref2
source-port
5/1/1*
config>system>sync-if-timing# ref2 source-port 5/1/1*
ref2 no
no shutdown
shutdown
bits interface-type
interface-type ds1
ds1 sf
sf
bits no
no shutdown
shutdown
ref-order bits
bits ref1
ref1 ref2
ref2
config>system>sync-if-timing# revert
revert
ql-selection
config>system>sync-if-timing# ql-selection
* Reference 2 must be on last IOM set and
config>system>sync-if-timing# commit
commit
SyncE and SSM must be enabled on
config>system>sync-if-timing# back
back
Ethernet MDAs and ports
config>system#
back
config>system# back
Module 2 |
73
Set the Node Timing References

Configure the node timing references and reference order in the configure system sync-if-timing
context.
begin Enter edit or create mode
bits - Set the BITS port characteristics. Options are DS1, ESF or SF, or E1 PCM30 or PCM31. You must turn
up the BITS port.
ref1 Set the first timing reference port. If configured on an SR-7, the port must be on IOMs 1 or 2; if on an
SR-12, the port must be on IOMs 1-5. On the SAR-8, ref1 and ref2 must be on different MDAs. If ref1 or ref2
point to an Ethernet port, SyncE must be enabled on the MDA. To allow the router to choose the source by
QL, SSM must be enabled on the port.
ref2 Set the second timing reference port. The port must be on an SR-7 IOMs 3-5 or an SR-12 IOMs 6-10. On
the SAR-8, ref1 and ref2 must be on different MDAs. See ref1 for Ethernet port requirements.
You must turn up ref1 and ref2.
ref-order Determines the order in which the node chooses its reference source. The SR/ESS default is bits
ref1 ref2.
If the ref-order specifies bits on a redundant CPM-equipped 7750 SR7 or SR12, the active CPM first takes its
BITS input from the active CPM BITS port. If that input becomes disqualified, it will take its input from the
standby CPM BITS port.
revert Revert allows the clock to switch back to a higher priority reference if the current reference
becomes unqualified. The default is no revert.
ql-selection Allows the node to select the timing reference by quality level rather than the configured
reference order. It uses the reference order as a tie breaker, if necessary.
commit Saves changes to the timing configuration. Until you issue commit, the changes have no effect.
Context:
Context: config>system>sync-if-timing
config>system>sync-if-timing
View the timing configuration show system sync-if-timing
===============================================================================
===============================================================================
System Interface Timing Operational Info
===============================================================================
===============================================================================
System Status CPM A
: Master Locked
System Status CPM A
: Master Locked
Reference Input Mode
: Revertive
: Revertive
Quality Level Selection
: Enabled
: Enabled
Reference Selected
: BITS A
Reference Selected
: BITS A
System Quality Level
: stu
: stu
Current Frequency Offset (ppm) : +0
Reference Order
Reference Order
: bits ref1 ref2

: bits ref1 ref2
Reference BITS A
Reference BITS A
Input Admin Status
Input Admin Status
Rx Quality Level
Rx Quality Level
Quality Level Override
Qualified For Use
Qualified For Use
Selected For Use
Selected For Use
Interface Type
Interface Type
Framing
Framing
Line Coding
Line Coding
...output truncated
...output truncated
: up
: up
: stu
: stu
: prs
: prs
: Yes
: Yes
: Yes
: Yes
: DS1
: DS1
: SF
: SF
: B8ZS
: B8ZS
...output
...output truncated
truncated
Module 2 |
74
View the timing configuration show system sync-if-timing

The show system sync-if-timing command shows the system timing configuration.
System Status CPM A indicates the CPM Master is locked to the primary reference.
Reference selected indicates BITS A is the current reference.
System quality level represents the systems master clock quality level. For an SF-framed DS1, it is QL-STU.
For ESF and E1, the quality level represents the QL passed in the SSM bits.
Reference order indicates the provisioned clock reference order.
BITS A is admin up, and qualified for use.
BITS A is the selected reference.
The router allows you to override the reference input Rx Quality Level. In this example, without QL override, the
system advertises QL-STU in its SSM messages.
If you wish to advertise a better QL, then you can use the ql-override feature on any of the references.
A:NodeA>config>system>sync-of-timing>bits# ql-override prs
A:MLS1#
A:MLS1# show
show system
sync-if-timing
Configuring MLS1 for SyncE Support
Context:
Context: config>card>mda
config>card>mda
[no]
[no] sync-e
sync-e
Context:
Context: config>port>ethernet>ssm
config>port>ethernet>ssm
Syntax:
Syntax:
ssm
ssm
[no]
[no] code-type
code-type {sonet|sdh}
{sonet|sdh}
Example:
Example: config#
config# card
card 55 mda
mda 11 sync-e
sync-e
config>card>mda#
config>card>mda# back
back
config>card#
config>card# back
back
config#
config# port
port 5/1/1
5/1/1
config>port#
ethernet
config>port>ethernet# ssm
ssm
config>port>ethernet>ssm#
config>port>ethernet>ssm# code-type
code-type sonet
sonet
no
config>port>ethernet>ssm# no shutdown
shutdown
config>port>ethernet>ssm# back
back
config>port>ethernet# back
back
config>port#
config>port# back
back
Module 2 |
75
Configuring MLS1 for SyncE Support

MDA SyncE Support
The MDA must support synchronous Ethernet. To turn up SyncE support on the MDA:
A:NodeA# configure card 5 mda 1 sync-e
On the 7705 SAR with the Ethernet version 2 and later MDAs, sync-e is enabled by default.
Port SSM Support
If you want the nodes to exchange ESMC messages, you must enable SSM on the ports. Optionally, you may set the
SSM code type; the default is SDH. This determines the clock type and events exchanged.
A:NodeA# configure port 5/1/1 ethernet ssm code-type sonet
Turn up SSM on the port.
A:NodeA# configure port 5/1/1 ethernet ssm no shutdown
Syntax:
Syntax:
View MLS1 Port SSM Configuration show port 5/1/1
===============================================================================
===============================================================================
Ethernet
Ethernet Interface
Interface
===============================================================================
===============================================================================
Description
Description
Interface
Interface
Link-level
Link-level
Admin State
Admin State
Oper State
Oper State
Physical Link
Physical Link
Single Fiber Mode
Single Fiber Mode
: 10/100/Gig Ethernet SFP

: 10/100/Gig Ethernet SFP
: 5/1/1
: 5/1/1
: Ethernet
: Ethernet
: up
: up
: up
: up
: Yes
: Yes
: No
: No
Oper Speed
Oper Speed
Config Speed
Config Speed
Oper Duplex
Oper Duplex
Config Duplex
Config Duplex
MTU
MTU
: 1 Gbps
: 1 Gbps
: 1 Gbps
: 1 Gbps
: full
: full
: full
: full
: 9212
: 9212
...output truncated
...output truncated
Sync. Status Msg. : Enabled
Sync. Status Msg. : Enabled
Tx DUS/DNU
: Disabled
Tx DUS/DNU
: Disabled
SSM Code Type
: sonet
SSM Code Type
: sonet
Rx Quality Level : 0xf(dus)

Rx Quality Level : 0xf(dus)
Tx Quality Level : 0x1(prs)
Tx Quality Level : 0x1(prs)
...output truncated
...output truncated
Module 2 |
76
View MLS1 SSM configuration show port 5/1/1

The show port 5/1/1 command shows the port SSM configuration and state.
SSM is Enabled
Code type is set to SONET to support a 1544 kb/s clock rate.
RX quality level represents the received QL on this port. Since this is the PRS (Option 1 PRC), the far end
device returns a DUS (Option 1 DNU).
TX quality level shows this node sent QL PRS to the next hop.
A:MLS1#
A:MLS1# show
show port
port 5/1/1
5/1/1
View POC2-1 timing configuration
===============================================================================
===============================================================================
===============================================================================
===============================================================================
System Status CSM A
: Master Locked
System Status CSM A
: Master Locked
: Non-revertive
: Non-revertive
: Enabled
: Enabled
Reference Order
Reference Order
Reference Input 1
Reference Input 1
Admin Status
Admin Status
Configured Quality Level
Rx Quality Level
Rx Quality Level
Qualified For Use
Qualified For Use
Selected For Use
Selected For Use
Source Port
Source Port
...output truncated
...output truncated
: ref1 ref2 external

: up
: up
: none
: none
: prs
: prs
: Yes
: Yes
: Yes
: Yes
: 1/2/7
: 1/2/7
POC2-1 Reference 1 set to MLS1-facing SyncE/SSM port

MLS1 sends QL-PRS
POC-2 chooses SyncE/SSM source port as its reference
Module 2 |
77
View POC2-1 timing configuration

POC2-1 has locked its clock to its MLS1-facing port SyncE reference. The clocking source is MLS1 connected
through SyncE/SSM source port 1/2/7.
Quality Level Selection Enabled.
Rx Quality Level The level set by MLS1, QL PRS
Qualified For Use The port is properly configured for SyncE and SSM support.
Selected For Use POC2-1 has selected this port as its timing reference.
Source Port The port through which POC2-1 receives timing for this reference input.
A:POC2-1#
A:POC2-1# show
show system
sync-if-timing
View MLS1 timing configuration SyncE/SSM port not selected
===============================================================================
===============================================================================
===============================================================================
===============================================================================
...
...
Reference Input 2
Reference Input 2
Admin Status
Admin Status
Rx Quality Level
Rx Quality Level
Qualified For Use
Qualified For Use
Selected For Use
Selected For Use
Not Selected Due To
Not Selected Due To
Source Port
Source Port
...output truncated
...output truncated
: up
: up
: dus
: dus
: none
: none
: Yes
: Yes
: No
: No
:
ssm quality
:
ssm quality
: 5/1/1
: 5/1/1
MLS1 Reference 2 set to MLS2 return port 5/1/1

MLS2 sends QL-DUS in response to MLS1 QL-PRS
MLS1 does not select its reference 2 for reason ssm quality
If MLS1 loses both BITS and ref1, it can select its ref2 SSM source
Module 2 |
78
View MLS1 timing configuration SyncE/SSM port not selected

The MLS1 router sets ref2 to the MLS2-facing SSM port.
Since MLS1 is the PRC and sends QL PRS to MLS2, MLS2 returns QL-DUS.
Rx Quality Level QL-DUS returned by MLS2.
Qualified For Use Yes, it is a valid SyncE port.
Selected For Use No, since MLS2 set QL-DUS and better reference available.
Not Selected Due To ssm quality. Node will not select QL-DUS (Option 1 DNU) over another, better QL.
The MLS1 router will select this port if MLS2 router sends a better QL than the current MLS1 reference and QL
selection is enabled. This could occur if the BITS reference fails, the ref1 SONET port becomes unavailable, and
MLS1 goes into free run.
A:MLS1#
A:MLS1# show
show system
sync-if-timing
.75 Hour
Lab Objectives:
Configure BITS timing on MLS1 and MLS2
Configure MLS1 as PRS (SONET coding) with BITS as its primary reference
Configure MLS2 to synchronize off of its MLS1 port then BITS
Configure the SARs to synchronize off of MLS1 then MLS2
Disable MLS1 BITS then CSA1 ports and observe how the routers choose
new references
Module 2 |
79
Lab 3 : Configure SyncE and SSM
Section Summary
SyncE and SSM deliver a traceable physical-layer clock to the

Backhaul Transport Network nodes
SyncE uses the Ethernet Synchronization Messaging Channel
(ESMC) to provide clock traceability and loop detection
capabilities
Nodes choose a new reference clock based on the advertised
clock quality level and reference order
To configure network nodes for Synchronous Ethernet and SSM
timing distribution
Module 2 |
80

Section 4 Timing and Synchronization IEEE 1588v2 and

Precision Time Protocol (PTP) v2
Section Objectives
Explain how IEEE 1588v2 and the Precision Time Protocol (PTP) v2
provide packet-based timing in the Backhaul Transport network
Describe the PTPv2 Message format
Trace PTPv2 message flow in normal and failure operations
Provision PTPv2 in the Backhaul Transport
Module 2 |
82
IEEE L2/L3 timing distribution technique

Based on master-slave timestamp exchange process
Slaves use an offset between master and local clock to determine
reference clock frequency
Packets routed in-band (no service required)
Intermediate nodes do not have to be PTP-aware (but design must
be)
Module 2 |
83

IEEE 1588v2 describes a master/slave timing distribution method where the network nodes route the timing
reference data. The core nodes need not support the timing distribution scheme, but must route packets between
the master and slave nodes. The master and slave can be on entirely different network segments, as long as the
intermediate nodes can route packets between them. PTPv2 defines the message format for use in an IEEE 1588v2
model.
The slave nodes choose a master by running a Best Master Clock Algorithm (BMCA). The slaves run the BMCA
against a range of master clock characteristics, and based on these characteristics, chooses the best available
reference. A slave may choose a different reference later, if a better one becomes available. We will discuss the
BMCA in more detail later in this section.
PTP Operation
SyncE nodes slave off of the Ethernet bit stream. PTP nodes slave off of a calculated frequency offset value based
upon timestamps transported in PTP messages. PTP and SyncE/SSM may be used in the same network in what is
called a hybrid timing model for redundancy or to overcome physical network limitations, such as when SyncE is
not supported on the MEN.
As the PTP domains time source, a PTP master delivers a series of time stamped packets to a set of slave nodes.
The slave(s) compare the masters timestamp against their own time reference. The slave runs a frequency
calculation algorithm to determine by how much it needs to adjust its clock frequency (offset and phase) to match
that of the masters. This calculated figure becomes the slaves clock offset value.
PTP Message Types
PTP defines two message types:
Event messages Event messages are time critical, affecting the slaves frequency calculation accuracy.
General messages Convey information for the protocols use, but are not time critical.
PTP uses UDP as its transport layer protocol. PTP event messages target UDP port 319 and general messages
target UPD port 320.
IEEE 1588v2 defines two synchronization operating modes

One-way mode The slave calculates its clock offset based on a
single set of timestamps, master-to-slave
Two-way mode SROS supported; The slave calculates its clock
offset based on two sets of timestamps, master-to-slave and
slave-to-master
Module 2 |
84
IEEE 1588v2 Operating Modes

IEEE 1588v2 defines two synchronization operating modes:
One-way The slave uses a single master to slave message set to determine its clock offset.
Two-way The slave uses two message sets, master to slave and slave to master, to determine its clock offset.
One-Way versus Two-Way Operation
One-way operation allows the slave to calculate its clock offset in relation to the master based on two
timestamps.
1. The master sends a time stamped Sync message to the slave. The timestamp represents the masters best
estimate of the actual time the packet left the master clocks physical port.
2. The slave takes a timestamp when it receives the Sync message. It calculates the difference between the two
time stamps and uses this value as its clock offset. Since the slave only uses this master slave exchange, it has
no way of adjusting the calculated offset to allow for delays the packet might experience in transit.
One-way operation is suitable for frequency calculations, but does not suit phase and time of day distribution
requirements. Although the slave can determine how frequently the master clock transitions, it cannot
calculate when the transitions occur.
Two-way operation can support frequency, phase, and time distribution, and is the preferred approach to
frequency distribution, as well.
1. The master sets a time stamp on the Sync message, as in one-way. The slave records the time it received the
message.
2. The slave sends a Delay-Req(uest) message to the master, recording the time it sent the message.
3. The master takes a time stamp when it receives the Delay-Req(uest), and returns this time stamp in a DelayResp(onse) message.
4. The slave calculates the master slave delay, and adjusts the offset to allow for these variations. This avoids
any one-way delay induced skew, and results in a more accurate calculated slave clock.
Two-way, if combined with two-step clock, explained in the next slide, can provide full synchronization,
frequency and phase, and time of day. SROS supports two-way operation.
IEEE 1588v2 and PTPv2 Operation Modes
IEEE 1588v2 defines two clock operation modes:

One-step clock SROS supported; The slave adjusts its clock
offset considering one-way delay only
Two-step clock The slave considers Packet Delay Variation
(PDV) in its offset calculation
Module 2 |
85
IEEE 1588v2 Clock Operation Modes

IEEE 1588v2 defines two clock operating modes:
One-step The slave uses the two-way message exchange to calculate the frequency offset.
Two-step The master sends two timestamps with the first message exchange, one with an estimated timestamp
and the second carrying the actual time the Sync message left the port.
One-Step versus Two-Step Operation
In one-step operation, the slave uses the difference between message transmit and receive times to calculate its
clock offset. The slave considers the delay between the master and the slave.
To calculate this delay value, and compensate accordingly, the slave and master exchange two message sets. The
first set, called Sync messages, records the time the master sent the message and the time the slave received it.
The second set, called Delay_Req(uest) and Delay_Resp(onse) messages, records the time the slave sent the
message and the time the master received it. From these two message exchanges, the slave is then able to
determine how much to adjust its clock, and calculate and subtract the delay from this clock offset.
For a more accurate delay measurement, two-step operation verifies the Sync message timestamp with a second
message, called a Follow Up message. The Follow Up message timestamp represents the precise time the master
processed the Sync message. This allows the slave to compensate for the processing time the packet experienced
as the master prepared it for delivery. Additionally, when configured as transparent clocks, (presented in the
next slide), the intermediate nodes can record residence delay by adjusting the masters timestamp in the Follow
Up messages.
Both one-step and two-step clock operation assume symmetric delay from the master to the slave. SROS currently
only supports one-step operation.
IEEE 1588v2 Clock Operation Modes
IEEE 1588v2 defines four clock types

Ordinary clock a PTP client with a single port
Boundary clock a clock with multiple ports that can be a time
source
End-to-end Transparent clock Computes the time a PTP
packet is in residence and passes this to the downstream node.
Peer-to-peer Transparent clock - Computes residence time and
propagation delay and passes this to the downstream node.
Module 2 |
86
IEEE 1588v2 Clocks

IEEE 1588v2 describes four clock types:
Ordinary Clock: A PTP client that has a single PTP port in the domain and maintains the domain timescale. It
could be a master, delivering the time reference, or a slave-only clock.
Boundary Clock (BC): A clock that has multiple PTP ports in a domain and maintains the domain timescale. It
may serve as the master and may synchronize to another clock as a slave. BCs can break up an end-to-end
flow into more manageable PDV segments. In addition, BCs permit scaling and can reduce the number of PTP
packets in the network.
Transparent Clock (TC): A device that time stamps the ingress and egress packet flows to account for the
time the packet is in residence in the TC device. A TC updates the event messages correction fields as the
messages pass through it and then forwards the messages towards the slave port. The TC does not necessarily
keep time but assists in minimizing PDV. A transparent clock can take 2 general forms:
End-to-End TC - Computes the residence time within the device. The downstream slave clock uses the
corrections to adjust its local time base to be in sync with the master.
Peer to Peer TC - Computes the message residence time in a node and also provides corrections for the
propagation delay of the link between nodes. It provides this correction information to the slave so it can
adjust its time.
A domain can have either an End-to-End or a Peer-to-Peer TC, but not both.
TCs require two-way operation and two-step clocks. As of this writing, SROS does not support transparent
clocks.
Grandmaster Clock: This is the source that originates the time stamped packet flow using some other
reference as its source, such as an external GPS for time or BITS for frequency. The grandmaster clock is a
PTP master clock from which the timing domain determines its timescale and timescale properties.
IEEE 1588v2 Clock Types
Event Messages for time critical information; time stamped by the

sender
Sync Carries the initial timestamp delivered from master clock.
Delay_Req Requests a second timestamp, the time at which the
recipient received the request, for PDV calculation
General Messages Not timestamped, but used for clock maintenance.
Announce Provides clock status and characteristics for both the
slave and its master. This information is used by the BMCA.
Follow_Up Delivers to the slave an accurate egress Sync message
timestamp for two-step clock operation.
Delay_Resp Returns to the slave the second time stamp for PDV
calculation.
Management Provide access to IEEE 1588v2 specific parameters.
Signaling Carry requests and commands between clocks.
Module 2 |
87
SROS Supported PTP Message Types

SROS supports ordinary master or slave clocks, and so supports the messages necessary to synchronize and
maintain the domains clocks.
Event Messages
Carry time critical information. These are:
Sync Carries the masters initial timestamp value.
Delay_Req(uest) The slave requests the master send another timestamp to represent the time the request is
received. The slave can then calculate the delay in the masters direction by comparing the time the master
received the request to the time the slave sent the Delay_Req message.
General Messages
The are messages used for clock maintenance, but not for synchronization.
Announce Provides master and slave clock status and characteristics. The slave announces the intervals over
which it wants to receive messages from the master, and the master announces its clock quality, accuracy, and
other characteristics for the slave to use for selecting the best master.
Follow_Up Used with a two-step clock to provide the actual time the Sync message left the masters port.
Delay_Resp(onse) Delivers to the slave, in response to the Delay_Req message, the time the master received
the Delay_Req. The slave uses this timestamp value to calculate the return delay from slave to master, and adjust
its clock offset accordingly.
Management Management messages can read or change a slave or master clocks characteristics, and include
SET and GET functions, as do Simple Network Management Protocol (SNMP) messages. IEEE 1588 is designed to
provide network-neutral management capabilities.
Signaling Signaling messages may be used by one clock to request another change its packet delivery rate.
Peer clocks use the additional General messages listed below. SROS does not currently support peer transparent
clocks.
Pdelay_Req(uest) Used by a peer transparent clock to determine link delay between the peers.
Pdelay_Resp(onse) A response to the Pdelay_Req.
Pdelay_Resp_Follow_Up Used by peer two-step clocks.
SROS Supported PTP Message Types
34-byte long header included with

each PTP message
Indicates the message type
Includes a sequence ID and
correction field for
transparent clock use
Sent out all PTP logical ports
PTP uses UDP transport
Port 319 Event port
Port 320 General message
port
Module 2 |
88
PTP Message Header

IEEE 1588 describes the PTP message header format.
Transport Bit 0 is used for compatibility with 1588v1 and is set to 0 for v2. Bits 1-3 are reserved (000).
Message Type Identifies the PTP message type. The current standard describes 10 message types, carried
after the header in TLV format. The following are supported in SROS:
Announce Message type B
Delay_Req(uest) Message type 1
Delay Res(ponse) Message type 9
Management Message type D
Signaling Message type C
Sync Message type 0.
Version PTP Version. Currently version 2.
Message Length Total PTP message length, in octets including the header.
Domain Number 0-255. Default is 0. Identifies the messages originating domain. Clocks belong to domains,
and the domain identifies a logical grouping of clocks that sync to each other.
Flags Set to indicate status. For example, a unicast transmission sets Bit 2.
Correction A value, in nanoseconds, used by a TC to set a residence time correction value.
Source Port Identity A unique identifier for each PTP peer unicast session. Not the senders UDP port
number, but a numeric value set by the session.
Sequence ID Individual message sequence number.
Control Field Used for version 1 compatibility. Identifies the message type.
Log Message Interval Depending on the message type, sets timer values or represents frequency values, such
as timestamps.
PTPv2 Message Header
Ex: Announce-request (slave)

and Announce-grant (master)
Slave requests a session with
the master (request)
Master grants the session
Identifies the logical PTP port
for which this message is
addressed
Can carry one or more TLVs
TLVs represent type of
message desired and signaled
peer characteristics (ex:
message interval)
Module 2 |
89
PTPv2 Signaling Message

Signaling messages indicate a PTP devices desire to exchange information with another PTP peer.
For example, a slave clock requests communications with the master by sending an Announce Request message.
The master can respond with an Announce Granted message. Each message type and its characteristics are
transported as a Type Length Value (TLV) following the message header.
IEEE 1588v2 defines many TLVs. The two mentioned in this course are:
Request Unicast Transmission TLV Type 0x0004, Length 6 bytes, Value identifies the type of message
requested, Announce or Sync, the log message interval (the time between requested message types, and how long
the messages should be transmitted. Sent from slave to master to request Announce messages.
Grant Unicast Transmission TLV Type 0x0005, Length 8 bytes, Value identifies the type of message granted,
Announce or Sync, the time between requested messages, and for how long the messages will be sent. A value of 0
indicates the request was denied. Sent from the master to the slave to grant the request.
PTP Port
A PTP port is a logical entity, not an actual physical port. According to IEEE 1588v2, a PTP port is A logical
access point of a clock for PTP communications to the communications network.
On the SROS, you configure a peer and its characteristics in the context of a PTP port. The peers exchange port
identifiers when they exchange messages on the PTP domain.
PTPv2 Signaling Message
PTP General Message used to

establish the synchronization
hierarchy
Indicates the quality of the
senders signaled clock
Master sends periodically
based on the slave requested
announce interval
Contents used by the slave
BMCA to select the best clock
Module 2 |
90
PTPv2 Announce Message

IEEE 1588 describes the PTP Announce message format.
Origin Timestamp Set within +/- 1 sec of originators clock.
Current UTC Offset Current Coordinated Universal Time (UTC) offset from International Atomic Time (TAI).
UTC is based on TAI but has leap seconds added at random intervals to synchronize with the Earths rotation.
Grandmaster Priority1 Used by the BMCA to choose the best clock, ranges from 0-255.
Grandmaster Clock Quality Represents the Grandmasters clock quality level.
Grandmaster Priority2 Used by the BMCA to choose the best clock, ranges from 0-255.
Grandmaster Identity A unique clock identifier, based on the MAC address OUI and an extension identifier
according to the IEEE EUI-64 address format. In SROS, the Clock Identity is based on the senders chassis MAC
address.
Steps Removed The number of hops between the local clock and the grandmaster. Use by the BMCA to
choose the best clock.
Time Source From where the Grandmaster has obtained its clock source.
PTPv2 Announce Message
Sync and Delay_Req Messages

10-bytes
Carries origin timestamp
PTP Event messages
Delay_Resp Messages
20-bytes
Carries Delay_Req message
receipt timestamp
Identifies requesting PTP port
PTP General message
Module 2 |
91
PTP Sync and Delay Messages

The One-step message set includes the Sync, Delay-Req and Delay-Resp Messages.
Sync - Sent by the master to deliver the initial timestamp. The slave records the time it receives this message
to use in it offset calculations. The timestamp takes the form <seconds nanoseconds>, with 48 bits for the
seconds and 32 bits for nanoseconds. A timestamp might look like this: 0000 0000 000216 0000 0000116 .
Delay_Req(uest) Sent by the slave to begin the second part of the two-way operation mode.
Delay_Resp(onse) Returned by the master in response to the Delay_Request. The message identifies the
slaves requesting PTP port ID and the time the master received the Delay_Request.
PTPv2 Sync and Delay Messages
Slave Unicast Negotiation:

1 Slave sends signaling Announce Request
Unicast message-type to the configured
master
2 Master responds to the slave with Grant
Unicast Transmission message, either
granting or denying the request. The
master only answers messages targeting
its configured PTP ports.
3
Slave sends signaling Sync Request
Unicast message-type to the master
4 Master responds to the slave with Sync
Granted message
Module 2 |
92
IEEE 1588 PTP Unicast Negotiation Sequence

Announcement
1. An IEEE 1588 slave announces itself on the network with a PTP Request Unicast Announce TLV, signaling
message type 0xb0. A receiving device only answers messages targeting its configured PTP port, as specified in
the messages Target Port Identifier field.
This TLV sets the slaves requested announce, sync, and delay request message frequencies. These frequency
values determine how often the master sends the referenced message types.
Announce messages Default 1 message every 2 seconds, and ranges from -3 (8/second) to 4 (1 every 16
seconds). The slave uses these as Hello messages to determine when to choose a new master, based on a
timeout value.
Sync messages Default 64 messages/second, and may be set to 128 messages/second. The Sync messages
include the master timestamps the slave uses in its offset calculations. The slave records the time it
receives each Sync message.
Delay_Resp(onse) messages Default 64 messages/second, and may be set to 128 messages/second. The
Delay_Resp messages allow the slave to calculate the end-to-end packet delay, and subtract this value from
its clock offset calculations. The slave sends a time stamped Delay_Req(uest) message, and the master
returns a time stamped Delay_Resp(onse) message.
2. The master responds with an Grant Unicast Transmission TLV, either to grant or deny the request.
3. The slave requests Sync message negotiation with a sync signaling message type 0x00.
4. The master grants the Sync request.
IEEE 1588 PTP Unicast Negotiation Sequence
Synchronization in two-way, one-step

operation
1 The master sends periodic Announce
messages at rate set by slave
2 The master timestamps each Sync
packet (t1), in hardware, at egress
3 The slave takes a timestamp (t2) when
the message arrives
4 The slave sends a Delay_Req(uest)
message to the configured master and
sets a timestamp (t3)
5 The master responds to the slave with
Delay_Resp(onse) message (t4)
6 The slave calculates the mean* one-way
delay and the clock offset, and adjusts
its clock accordingly
Module 2 |
93
IEEE 1588 Two-Way, One-Step Time Transfer Sequence

The SROS nodes take all time stamps in hardware. By time stamping messages in hardware, the sender and
receiver more accurately reflect the actual transmission and reception times, and are not influenced by their
own processing delays.
1. The master sends periodic Announce messages at the rate set by the slave in the Announce Request message.
2. The master sends Sync messages at rate set by the slave. The master timestamps the Sync messages (t1).
3. The slave records the time it receives the Sync messages (t2), and uses this difference in its delay and offset
calculations.
4. The slave sets a timestamp (t3) and sends a Delay_Req(uest) message.
5. The master sets a timestamp (t4) sends a Delay_Resp(onse) message.
6. The slave uses the cumulated timestamps in its delay and offset calculations.
The time the slave takes to synchronize its clock will vary, but it can take in excess of 10 minutes for the
synchronization process to complete. Once completed the slave locks its SSU to the masters clock frequency.
*mean According to Wikipedia, the mean of a data set is the sum of the values divided by the number of values.
The mean describes the central tendency of the data sample, and provides an approximate average of the
sampled data.
IEEE 1588 PTP Two-Way, One-Step Time Transfer Sequence
A slave node may receive announcements from multiple masters

The slave captures information from each potential master
The slave runs a Best Master Clock Algorithm (BMCA) against each
masters information to select the best master
Module 2 |
94
1588v2 Best Master Clock Selection

A 1588v2 slave can have multiple potential masters, each announcing their characteristics on different domains.
The slave chooses the best master by running a BMCA against the masters announced characteristics.
The slave considers the following characteristics, in the order listed, when determining the best master:
1. Priority1 Ranges from 0-255. The lower numeric value is preferred.
2. Clock Class Ranges from 0-255. IEEE 1588v2 describes the clock classes and their designators. The master
sends this in the Announce Message Clock Quality field.
Clock quality 6 indicates the master is synchronized to the PRC, while 7 indicates the master had been
synchronized to the PRC, but is now in free run.
1. Clock Accuracy A hexadecimal value, from 0x00-0xFF, which represents the accuracy of the grandmaster
clock within a range of nano, milli, or seconds.
2. PTP Variance A hexadecimal value calculated by each master to estimate the precision of its timestamps,
based on a variance algorithm described in the IEEE 1588v2 standard.
3. Priority2 - Ranges from 0-255. The lower numeric value is preferred.
4. Grand Master Clock Identity
5. Distance The number of boundary clocks between the slave and master. Boundary clocks pass the distance in
the Announce message stepsRemoved field. This represents the number of communications paths between the
local clock and the grandmaster.
1588v2 Best Master Clock Selection
IEEE 1588v2 is designed to support many applications

Profiles define a specific applications timing requirements
SROS supports the ITU-T G.8265.1 profile
ITU-T PTP Profile for Frequency Distribution without Timing Support
from the Network (Unicast Mode)
Choose by clock quality, then reference order
Module 2 |
95
1588v2 Alternate BMCA

1588v2 allows for an alternative BMCA (ABMCA) which may use additional criteria for master clock selection.
1588v2 Profiles
1588v2 profiles define unique clock characteristics based on an application, such as when using 1588v2 in a
telecommunications environment. This profile may set specific announce and sync intervals, time out values,
clock mode and operation, and master clock selection criteria.
SROS Profiles
SROS supports two profiles:
The IEEE 1588-2008 profile This profile uses the standard BMCA described previously.
The ITU-T G.8265.1-2010 Telecom profile - SROS supports the ITU-T G.8265.1 ITU-T PTP Profile for
Frequency Distribution without Timing Support from the Network (Unicast Mode) profile. This profile allows
for an ABMCA which considers the masters advertised G.781 Option 1 or 2 quality level in the master selection
criteria.
The G8265.1 profile allows for only one master active at a time per timing domain, though a slave may
communicate with masters in other domains. The slave chooses a master in each domain by quality level, and
then, if it has multiple masters available per quality level, chooses its master by the reference order.
1588v2 Alternate BMCA
PTP Slave Logical PTP Port State Machine
Module 2 |
96
PTP Slave Logical PTP Port State Machine

PTP ports start in the initial state. Once the clock is configured and turned up, the ports go to the listening state.
The PTP grandmaster announces its presence on the network. Once the slave receives the master clocks
information, it begins acquiring the master reference.
The port transitions to the Slave state once the slave node has synchronized its SEC to the grandmaster.
It will transition to un-calibrated after 5 minute loss of sync, or to listening if the GM announcements time out.
The time out value is set when the master and slave agree on the message intervals.
The show system ptp clock <clock-id> summary command displays the master and slave port states.
Once configured and turned up, the PTP slave port goes through the
following states:
Each node is configured as a boundary clock*

Only one PTP slave port per node
Nodes can be masters to multiple slaves
Passive PTP ports to provide redundancy
Timing domain design ensures clock traceability
Module 2 |
97
*Note: SROS 9R4 only

supports master or
slave
PTP in the Model 2 Ring Architecture

Within the configure system ptp context, the nodes clock-type can be set as an ordinary master or slave or
as a boundary clock (boundary only available on 7705 SAR).
Ordinary can be either a PTP master or slave
Boundary master and slave simultaneously
Boundary Behavior
When operating as a boundary clock, the routers provide the following functionality:
They initiate unicast sessions with all configured peers.
They use a BMCA to choose which clock is the best available. The resulting calculation determines the PTP
port states and the external clock from which the router will draw its frequency reference.
The router can maintain a standby session to an alternate clock.
Passive Port
ITU-T G.8265.1 allows a slave to connect to multiple masters, providing timing redundancy. A PTP passive port is
neither a master or a slave, though it is PTP capable. A node can only slave to one master, so once it chooses its
master, it sets all other potential slave ports to the passive state.
PTP in the Model 2 Ring Architecture
Each node chooses a single PTP master

Only one traceable path back to the
master
Redundant paths available in case
master goes offline or becomes
unavailable
Module 2 |
98
Resulting Model 2 Timing Distribution Tree

Based on the advertised clock source quality and their level reference order, the nodes prune redundant paths
back to the master. Each node uses the ABMCA to choose its PTP slave and master ports.
Since a node cannot have two masters, those ports that the node does not select as PTP slaves or masters become
PTP passive ports - this eliminates potential loops. The ABMCA ensures that only one PTP master exists on each
network segment.
PTP Port States
The 1588v2 standard defines the following PTP port states:
Initializing The node initializes PTP data, hardware, and communications. No messages leave the PTP port in
this state.
Faulty The protocol is failed. The PTP port will only send management messages in response to other
management messages on the ports communications path. This state will not effect other ports, unless the fault
cannot be confined to just one port.
Disabled The PTP port will not send message and will discard received messages.
Listening The PTP port is waiting to receive announcement messages from the master. The master announces
itself on the segment, and the slave nodes listen for these announcements.
Master The port is a PTP master port.
Passive - The PTP port can receive messages, but only forwards signaling messages or responses to management
messages.
Uncalibrated The node has selected the master, and is preparing to synchronize to the master port.
Slave The PTP port is synchronizing to the master port.
Pre-master The PTP port behaves as if it were a master, but only sends transparent, peer-to-peer clock messages.
SROS currently does not support transparent clocks.
Resulting Model 2 Timing Distribution Tree
1 Send message at:
MLS1t1=1278.663325s
2 Receive message at:
CSA1t2 = 1278.663375s
1 The PTP Master, MLS1, sets a timestamp in the Sync

message; at the same time, t1, CSA1 clock is fast by
20KHz
2 CSA1 receives the packet with no delay
3 CSA1 adjusts its clock by the difference, -20 KHz
Module 2 |
Adjust to:
MLS1t1 1278.663325s
- CSA1t2 1278.663375s
MLS1t1-CSA1t2 = -50us
1/-50us = -20KHz
99
Offset Calculation with no Path Delay

With no path delay, CSA1 receives the packet at the same time MLS1 sent it.
1. MLS1 sends a sync message with a timestamp of 1278.663325s. This is the exact time at which MLS1 sampled
its clock in hardware, MLS1t1. At the same point in time, CSA1 time is at 1278.66375s, a difference of 50us.
2. CSA1 receives the time stamped packet at CSA1t2. It assumes this is the same point in time as MLS1 sent it,
MLS1t1.
3. CSA1 adjusts its clock frequency by 1/the offset value. 1/-50us=20Khz.
Offset Calculation with no Path Delay
3 Receive message
at CSA1t2:
1278.663377s
1 Send message at:
MLS1t1=1278.663325s
Adjust to:
MLS1t1 1278.663325s
- CSA1t2 1278.663377s
MLS1t1-CSA1t2 = -52us
1/-52us = -19.3KHz
1 The Master, MLS1, sets a timestamp in the

Sync message; at the same time, t1, the CSA1
clock is fast by 20KHz
2 The intermediate nodes impose residence delay of 1us

each as the packet travels to the slave node
3 CSA1 receives the message 2us after MLS1 sent it
4 CSA1 adjusts its clock by the difference plus the delay,
1/-52 us = -19.3KHz
Module 2 |
100
Path Delay Effect on Received Timestamp

CSA1 is set to slave off of the PTP master, MLS1.
1. MLS1 sends a sync message with a timestamp of 1278.663325s. This is the exact time at which MLS1 sampled
its clock in hardware, MLS1t1. At the same point in time, CSA1t1 is at 1278.66375s, a difference of 50us.
2. Each downstream node delays the packet as it processes it for forwarding to the next node. In this example,
the MEN nodes delay the packet for 1us each.
3. CSA1 receives the time stamped packet at CSA1t2. It assumes this is the same point in time as MLS1 sent it,
MLS1t1, but in fact the packet was delayed by 2us.
Since CSA1 is unaware of the delay imposed by the upstream nodes, it assumes that its clock is off by the
difference between the timestamp and its current clock time, MLS1t1-CSA1t2.
Since frequency = 1/time, a greater time difference results in a smaller frequency adjustment, and the CSA1
clock still runs at a higher frequency than does the reference.
4. CSA1 adjusts its clock by the difference plus the delay, 1/-52 us = -19.3Khz. It is still running .7 Khz fast.
Path Delay Effect on Received Timestamp
Clock offset = 152-100 = 52 usecs (not considering

path delay)
Mean path delay = [(152-100)+(109-157)]/2 = 2 usecs
(result of t3-t4 timestamps)
Clock offset less mean path delay = 52 usecs 2 usecs
= -50 usecs
Module 2 |
101
IEEE 1588 PTP Delay and Offset Calculations

Through the Sync and Delay_Req(uest) and Delay_Res(ponse) message exchange process the slave can calculate its
clock offset from the master.
The time error between the slave and a master ordinary or boundary clock are defined as:
slave offset = time on the slave clock time on the master clock, where the nodes measure the
time at the same instant
Path Delays Influence on the Offset Calculation
If the slave only measured the difference between the t2 and t1 time stamps, its offset would be skewed by the
delay imposed by the upstream intermediate nodes and links. Without considering the downstream path delay, the
slave would have adjusted its clock by 52 usecs, leaving its clock frequency still out of synchronization with the
master.
To negate path delay, the slave and master exchange a second message set. This second set of messages measure
just the downstream path delay.
From this second exchange, we can calculate the mean path delay:
Mean path delay
[(t2-t1) + (t4-t3)]/2 = mean path delay = 2 usecs
With these values, the slave calculates a clock offset, corrected for path delay:
Clock Offset
(t2-t1) 2 = 50 usecs, or
[(t2-t1) - (t4-t3)]/2 = clock offset less mean path delay = 50 usecs
In this example, it adjusts its clock by -20KHz (-50 usecs), the clock offset less the mean path delay.
By taking two measurements, it can correct the clock offset calculation to allow for master-slave propagation
delay.
IEEE 1588 PTP Offset Calculations
Ex: Each node is configured as a boundary clock

Each node chooses a master from its configured domain
Each node requests announce and sync messages from potential masters, and
chooses its master by reference order and/or quality level
To avoid timing loops, BMCA chooses only one slave port per node
Module 2 |
102
PTP Message Flow Model 2 Unicast Negotiations

The MLS, POC2 and 3 and CSA routers are PTP enabled and configured as boundary clocks. This means that they
act both as masters and slaves. The routers timing configuration determines which clock they select as their
master.
Master Selection
Depending on the device, each boundary clock can be configured to choose from up to two masters, accessible via
timing references 1 and 2. The node slaves off of different MDAs (except the 7705 SAR-F), one for each PTP
reference clock, providing redundancy in the case of a port, MDA (SAR-8 and -18), and an IOM failure (7450 ESS or
7750 SR).
Each node goes through the master selection process; the message exchange illustrated above occurs on a link-bylink basis. MLS1 and POC2-1 exchange announce and sync messages, and depending on the PTP profile used, the
slave node chooses the reference by priority, quality level, or both. The same process occurs on all PTP enabled
nodes.
Clock Traceability and Loop Avoidance
A PTP node chooses only one master; the BMCA ensures a node only has one slave port active at a time.
The ITU-T G.8265.1 Telecom Frequency profile allows the nodes to choose their master by quality level. The
nodes timing reference configuration ultimately determines which source becomes the nodes current master, but
the G.8265.1 profile ensures only one master on each domain, or network segment. Multiple masters could send
messages into the domain, but the nodes slave to only one master.
Clocks and Domains
The SROS nodes refer to a 1588v2 reference source by a clock ID. The clock, in turn, is configured as a member of
a timing domain. The SROS derives its Clock ID from the nodes chassis MAC address. Once you associate a clock
with a timing reference, for that reference the node will choose its master only from potential masters
advertising themselves on a particular clocks domain.
Since the announce and request messages target unicast destinations, no other interface acts upon these messages
but those to which the messages are addressed.
PTP Message Flow - Model 2 Unicast Negotiations
The PTP domain master sends periodic announce messages at the specified rate
- Default 1 every 2 seconds
The master forwards time stamped periodic sync messages Default 64
messages per second
The slave sends Delay request
The master returns Delay response Default 64 messages per second
Module 2 |
103
PTP Message Flow - Model 2 Synchronization

Once the master grants the slaves requests for announce and sync messages, it sends these messages at a
frequency requested in the signaling messages.
Each peer sets a Wait to Restore (WTR) timer when it misses its peers Announce or Sync messages. The peer goes
into holdover after 5 minutes of lost messages. It can then select a new peer from any others available on the
domain. If the timer is running, the next received message of the missing message type resets the timer.
The slave sets its local oscillator based on the calculated offset between its clock and the masters. It can then
propagate this adjusted clock value downstream to its slave peer(s).
PTP Message Flow - Model 2 Synchronization
Link failure between MLS1 and POC2-1

1 POC2-1 goes into holdover after 5 minutes of missing MLS1 messages
2 POC2-1 sends QL-EEC toward POC3-1
3 POC3-1 receives QL-PRC from direction of MLS2
4 Nodes choose better reference according to their configurations
Module 2 |
104
PTP Message Flow Failure on MLS1 Link

POC2-1 must find another timing source in the case it loses sync with MLS1. The networks behavior depends on
each nodes timing configuration, but if each is configured to support the G.8265.1 profile and have both a
primary and secondary reference configured, we could anticipate the following behavior:
1. POC2-1s MLS1 WTR timer expires. It goes into free run and looks for another reference.
2. POC2-1 advertises QL-EEC instead of QL-PRC, and each node which had slaved in the direction of POC2-1 now
will select a better quality source, if available.
Each node sees QL-PRC coming from the direction of MLS2, and chooses its second reference.
3. POC2-1 receives QL-PRC from POC3-1, and selects reference 2. This is the MDA to which POC3-1 is connected.
4. POC3-1 remains the master to CSA1, and CSA1 is the master for CSA2. No changes occur in the access ring.
PTP Message Flow Failure on MLS1 Link
Configuring for PTP Master 7750 SR

Context:
Context: config>system
config>system
ptp
ptp
Context:
Context: config>system>ptp
config>system>ptp
Syntax:
Syntax:
clock-type
clock-type ordinary
ordinary {master|slave}
{master|slave}
[no]
[no] domain
domain <domain-value>
<domain-value>
network-type
network-type {sdh|sonet}
{sdh|sonet}
[no]
[no] shutdown
shutdown
Example:
Example: config>system#
config>system# ptp
ptp
config>system>ptp#
config>system>ptp# clock-type
clock-type ordinary
ordinary master
master
config>system>ptp#
config>system>ptp# domain
domain 44
config>system>ptp#
config>system>ptp# network-type
network-type sonet
sonet
config>system>ptp#
no
config>system>ptp# no shutdown
shutdown
Configure the master clock configure system ptp context

The master and slave domains must match
The master and slave network type must match
You must turn up the clock once you complete its configuration
Module 2 |
105
Configuring for PTP Master 7750 SR

The clock configuration steps differ for the 7750 SR and the 7705 SAR.
7750 SR Master
Configure the clock in the configure system ptp context:
A:NodeA# configure system ptp
clock-type Currently supported is clock type ordinary master or slave.
domain The PTP domain specifies one or more devices communicating with each other as defined by the 1588v2
protocol. Domain membership defines messages, operations, and data exchange. Each domain gets a unique
numeric identifier, from 0-255.
0 is the default domain
1-3 are alternate domains
4-127 are user defined
128-255 are Reserved.
SROS on the 7750 uses the default domain 0 to identify the 1588 profile, and domain 4 to identify the G.8265.1
telecom profile.
network-type Identifies the SSM QL codes passed in the clockClass values for the G.8265.1 telecom profile.
PTP configuration requires that you set a number of variables, so the configuration process covers several slides.
Syntax:
Syntax:
Configuring for PTP Slave 7705 SAR
Syntax:
Syntax:
clock-type
clock-type {{ordinary
{{ordinary {master|slave}
{master|slave} || boundary}
boundary}
source-interface
source-interface <ip-if-name>
<ip-if-name>
clock-mda
clock-mda <mda-id>
<mda-id>
domain
<domain-value>
priority1
priority1 [0-255]
[0-255]
priority2
priority2 [0-255]
[0-255]
profile
profile {ieee1588-2008|itu-telecom-freq}
{ieee1588-2008|itu-telecom-freq}
ptp-port
ptp-port [1-10]
[1-10]
Example:
Example: config>system>ptp>clock#
config>system>ptp>clock# clock-type
clock-type ordinary
ordinary slave
slave
config>system>ptp>clock#
config>system>ptp>clock# source-interface
source-interface loop_ptp
loop_ptp
config>system>ptp>clock# clock-mda
clock-mda 1/2
1/2
config>system>ptp>clock# domain
domain 44
config>system>ptp>clock# profile
profile itu-telecom-freq
itu-telecom-freq
config>system>ptp>clock# ptp-port
ptp-port 11
Module 2 |
106
Configuring for PTP Slave 7705 SAR

Under the configure system ptp clock context, several options determine the nodes operation. In most
cases, the clock must be shutdown to set or change these values:
First, on the SAR master or slave, you must create the clock:
A:NodeA# configure system ptp clock 1 create
Then, configure the clocks characteristics:
clock-type Choices are ordinary master, ordinary slave or boundary. The default is ordinary slave.
A:NodeA>config>system>ptp>clock# clock-type ordinary slave
source-interface - The source interface determines from what address the node sends its messages. This
interfaces IP address becomes the peer nodes peer IP address. The source interface could be a network
interface or a loopback interface, and the interface must already exist.
A:NodeA>config>system>ptp>clock# source-interface loop_ptp
clock-mda - This identifes the MDA from which the node will recover the 1588v2 clock.
A:NodeA>config>system>ptp>clock# clock-mda 1/2
domain - The PTP domain defines the set of PTP devices which exchange PTP messages. A node could host more
than one domain, so you must define them. The default is domain 0. The master and slave domains must match.
A:NodeA>config>system>ptp>clock# domain 4
priority1 and priority2 - The priority1 and priority2 values allow the slave to choose the best of multiple possible
masters. The nodes use a Best Master Clock Algorithm (BMCA) to choose between the sources. The default for
both values is 128.
A:NodeA>config>system>ptp>clock# priority1 128
A:NodeA>config>system>ptp>clock# priority2 128
continued on the next page...
Context:
Context: config>system>ptp>clock
config>system>ptp>clock
Configuring for PTP Slave 7705 SAR (cont)
Syntax:
Syntax:
clock-type
clock-type {{ordinary
{{ordinary {master|slave}
{master|slave} || boundary}
boundary}
source-interface
<ip-if-name>
source-interface <ip-if-name>
clock-mda
clock-mda <mda-id>
<mda-id>
domain
<domain-value>
priority1
priority1 [0-255]
[0-255]
priority2
priority2 [0-255]
[0-255]
profile
profile {ieee1588-2008|itu-telecom-freq}
{ieee1588-2008|itu-telecom-freq}
ptp-port
ptp-port [1-10]
[1-10]
Example:
Example: config>system>ptp>clock#
config>system>ptp>clock# clock-type
clock-type ordinary
ordinary slave
slave
source-interface
config>system>ptp>clock# source-interface loop_ptp
loop_ptp
config>system>ptp>clock# clock-mda
clock-mda 1/2
1/2
config>system>ptp>clock# domain
domain 44
config>system>ptp>clock# profile
profile itu-telecom-freq
itu-telecom-freq
config>system>ptp>clock# ptp-port
ptp-port 11
Module 2 |
107

profile - The profile determines the clock recovery algorithm and variables the nodes use to choose the best clock.
The ITU-T Study Group 15, Question 13 (ST15Q13) defines the itu-telecom-freq profile. This profile allows the
node to run an Alternate BMCA (ABMCA) and choose the master by SSM and ESMC quality level. PTP maps the
masters QL to the Announce and Sync messages clock class field.
The 7705 SAR supports both the IEEE-1588v2 and the ITU-T G.8265.1 profile. The default is ieee1588-2008. To use
the ABMCA for quality level selection, use the itu-telecom-freq profile.
A:NodeA>config>system>ptp>clock# profile itu-telecom-freq
NOTE: The 7750 SR only supports ITU G.8265.1, itu-telecom-freq.
ptp-port Configures a PTP logical port. The clock-type determines the number of ports available.
A:NodeA>config>system>ptp>clock# ptp-port 1
continued on the next page...
Context:
Context: config>system>ptp>clock
config>system>ptp>clock
Syntax:
Syntax:
[no]
[no] shutdown
shutdown
peer
peer [1..10]
[1..10]
Context:
Context: config>system>ptp>clock>ptp-port>peer
config>system>ptp>clock>ptp-port>peer
Syntax:
Syntax:
description
description description
description
ip-address
ip-address <ip-address>
<ip-address>
Example:
Example: config>system>ptp>clock>ptp-port#
config>system>ptp>clock>ptp-port# peer
peer 11
config>system>ptp>clock>ptp-port>peer#
config>system>ptp>clock>ptp-port>peer# ip-address
ip-address 192.0.2.0
192.0.2.0
config>system>ptp>clock>ptp-port>peer# description
description peer_MLS1
peer_MLS1
config>system>ptp>clock>ptp-port>peer# back
back
config>system>ptp>clock>ptp-port#
config>system>ptp>clock>ptp-port# no
no shutdown
shutdown
config>system>ptp>clock>ptp-port#
config>system>ptp>clock>ptp-port# back
back
config>system>ptp>clock# no
no shutdown
shutdown
config>system>ptp>clock# exit
exit all
all
Module 2 |
108

peer Configures a remote PTP peer. The peer IP address is the peers source interface address.
A:NodeA>config>system>ptp>clock>ptp-port# peer 1
A:NodeA>config>system>ptp>clock>ptp-port>peer# ip-address 192.0.2.0
* Not shown on the slide, but configurable in the ptp-port context
anno-rx-timeout Range 2 to 10. Defines the number of announce timeouts on the slave port or boundary clock
before the node determines it has lost communications with the master. One timeout equals the log-anno-interval.
log-anno-interval Range 0 to 3. Sets the slaves expected received announce message interval. The default is 1,
where:
0 = 1 message/second
1 = 1 message/2 seconds
A:NodeA>config>system>ptp>clock>ptp-port>peer# log-anno-interval 1
log-sync-interval Range -6 or -7. Sets the slaves expected received Sync and Delay_Resp(onse) message
interval. The default is -6, where:
-6 = 64 packets/second
-7 = 128 packets/second
A:NodeA>config>system>ptp>clock>ptp-port>peer# log-sync-interval -6
unicast-negotiate IEEE 1588v2 supports multicast synchronization messages. Unicast messages are supported by
default, and better conserve network resources by allowing the routers to exchange messages only with configured
peers.
Context:
Context: config>system>ptp>clock>ptp-port
config>system>ptp>clock>ptp-port
Set the Node Timing References 7705 SAR
Syntax:
Syntax:
begin
begin
[no]
[no] ref-order
ref-order <first>
<first> <second>
<second> [<third>]
[<third>]
commit
commit
abort
abort
Example:
Example: config#
config# system
sync-if-timing
config>system>sync-if-timing# begin
begin
ref-order ref1
ref1 ref2
ref2 external
external
ref1 source-ptp-clock
source-ptp-clock 11
ref1 no
no shutdown
shutdown
config>system>sync-if-timing# commit
commit
config>system>sync-if-timing# back
back
config>system#
config>system# back
back
Enable PTP as a timing reference

Modify reference order to specify PTP source as required
Configure the PTP reference source
Module 2 |
109
Set the Node Timing References

Configure the node timing references and reference order in the configure system sync-if-timing context.
begin Enter edit or create mode
ref-order Determines the order in which the node chooses its reference source. The 7705 SAR default is
ref1 ref2 external. The 7750 SR default is bits ref1 ref2 ptp.
ref1|ref2 - When configuring the node as a ptp slave, you must specify the reference clock. When
configured as a master, this step is not necessary. Note that the clock must exist, there are no default PTP
clock sources.
A:NodeA>config>system>sync-if-timing# ref1 source-ptp-clock 1
commit Saves changes to the timing configuration. Until you issue commit, the changes have no effect.
Context:
Context: config>system>sync-if-timing
config>system>sync-if-timing
A:MLS1#
A:MLS1# show
show system
system ptp
ptp
===============================================================================
===============================================================================
IEEE
IEEE 1588/PTP
1588/PTP Clock
Clock Information
Information
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Local
Local Clock
Clock
------------------------------------------------------------------------------------------------------------------------------------------------------------Clock
:: ordinary,master
PTP
:: ITU-T
Clock Type
Type
ordinary,master
PTP Profile
Profile
ITU-T G.8265.1
G.8265.1
Domain
:: 44
Network
:: sonet
Domain
Network Type
Type
sonet
Admin
:: up
Oper
:: up
Admin State
State
up
Oper State
State
up
Clock
:: 0003fafffe688fc0
:: 80
Clock Id
Id
0003fafffe688fc0 Clock
Clock Class
Class
80 (prs)
(prs)
Clock
Accuracy
:
unknown
Clock
Variance
:
ffff
Clock Accuracy
: unknown
Clock Variance
: ffff (not
(not computed)
computed)
Clock
Clock
:: 128
Clock Priority1
Priority1 :: 128
128
Clock Priority2
Priority2
128
PTP
:: master
Last
:: 10/21/2011
PTP Port
Port State
State
master
Last Changed
Changed
10/21/2011 16:12:45
16:12:45
===============================================================================
===============================================================================
The default profile is ITU-T Telecom Profile G.8265.1

The network type default is SDH, must be set to SONET
The clock class identifies the clock quality level
Module 2 |
110
View the Master PTP Configuration 7750 SR

A:NodeA# show system ptp
PTP Profile: Domain 4 sets the ITU-T Telecom Profile. This allows the nodes to select their Master by quality
level. When set to ITU-T G.8265.1, the node chooses its master first by the QL value advertised in the PTP
Announce message Clock Quality field. If it receives the same QL value on different domains, it chooses by the
Priority values sent in the Announce messages.
Network Type: - The default is SDH. Set to SONET to support SONET quality levels.
Clock Class: - Indicates the master clock class as defined in G.8265.1 Table 1.
PTP Port State: - The logical PTP port state.
View the PTP Master Configuration 7750 SR
View the PTP Master Peers 7750 SR
===============================================================================
===============================================================================
IEEE
IEEE 1588/PTP
1588/PTP Peer
Peer Information
Information
===============================================================================
===============================================================================
IP
:: 192.0.2.1
Announce
IP Address
Address
192.0.2.1
Announce Direction
Direction :: tx
tx
Clock
:: 0003fafffe6bd7c0
:: 11
Clock Id
Id
0003fafffe6bd7c0 Remote
Remote PTP
PTP Port
Port
------------------------------------------------------------------------------------------------------------------------------------------------------------IP
:: 192.0.2.227
Announce
IP Address
Address
192.0.2.227
Announce Direction
Direction :: tx
tx
Clock
Id
:
7c2064fffec348b8
Remote
PTP
:: 11
Clock Id
: 7c2064fffec348b8
Remote PTP Port
Port
------------------------------------------------------------------------------------------------------------------------------------------------------------IP
:: 192.0.2.228
Announce
IP Address
Address
192.0.2.228
Announce Direction
Direction :: tx
tx
Clock
Id
:
7c2064fffec3040e
Remote
PTP
:: 11
Clock Id
: 7c2064fffec3040e
Remote PTP Port
Port
===============================================================================
===============================================================================
The MLS routers can peer by system ID

The CSA routers peer by the source interface address
The clock ID is based on the chassis MAC address
Module 2 |
111
View the PTP Master Peers 7750 SR

A:NodeA# show system ptp peers detail
IP Address: Lists the peers IP address.
Announce direction: - tx for master, rx for slave
Clock ID: - 8 bytes based on the chassis MAC address
Remote PTP Port: - The logical PTP port number for this peer.
A:MLS1#
A:MLS1# show
show system
system ptp
ptp peers
peers detail
detail
View the PTP Master Peer Details 7750 SR
===============================================================================
===============================================================================
IEEE
IEEE 1588/PTP
1588/PTP Peer
Peer Information
Information
===============================================================================
===============================================================================
IP
:: 192.0.2.227
Announce
IP Address
Address
192.0.2.227
Announce Direction
Direction :: tx
tx
Clock
Id
:
143e60fffe7eada6
Remote
PTP
:: 11
Clock Id
: 143e60fffe7eada6
Remote PTP Port
Port
===============================================================================
===============================================================================
===============================================================================
===============================================================================
IEEE
IEEE 1588/PTP
1588/PTP Unicast
Unicast Negotiation
Negotiation Information
Information
===============================================================================
===============================================================================
IP
Dir
Rate
Duration
Time
IP Address
Address
Dir Type
Type
Rate
Duration State
State
Time
------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.227
Tx
Granted
192.0.2.227
Tx Announce
Announce 11 pkt/2
pkt/2 ss 300
300
Granted 11/22/2011
11/22/2011 14:48:37
14:48:37
192.0.2.227
Tx
64
Granted
192.0.2.227
Tx Sync
Sync
64 pkt/s
pkt/s 300
300
Granted 11/22/2011
11/22/2011 14:46:12
14:46:12
192.0.2.227
Tx
Granted
192.0.2.227
Tx Delay
Delay Resp
Resp 64
64 pkt/s
pkt/s 300
300
Granted 11/22/2011
11/22/2011 14:46:12
14:46:12
===============================================================================
===============================================================================
...continued
on
the
next
slide
...continued on the next slide
Module 2 |
112
View the PTP Master Peer Details 7750 SR (cont)

The SROS collects PTP statistics for each peer clock. Counters are available for all the message types discussed in
this section. These counters, in conjunction with the system logs, provide tools useful to monitor slave clock
performance, diagnose a timing problem, or analyze the networks performance when transporting
synchronization messages.
IEEE 1588/PTP Unicast Negotiation Information
IP Address: - Peers source interface IP address
Dir Unicast information direction, Transmit (Tx) or Receive (Rx)
Type The Message type, Anno, Sync, or Delay Resp(onse)
Rate The rate the slave set for the messages in packets/second
Dur The lease duration for the session. This value is set by the PTP grandmaster, and is not configurable in
SROS. The ITU-T Telecom profile sets the lease to 300s, and the master renews it an 150s.
State The result (reply) to the last of the message type sent. The possible values are:
Pending When the node has made a request to a peer but the peer has not responded.
Granted When the node has initiated a request and it was granted by the peer, or a peer has made a
request from the node and the node granted the request.
Rejected A peer rejected the nodes request.
Canceled The node sent or received a cancel request to or from a peer.
Expired A unicast session between the nodes and its peer has expired without being renewed.
Time The time the information was received.
A:MLS1#
A:MLS1# show
show system
system ptp
ptp peer
peer 192.0.2.227
192.0.2.227 detail
detail
A:MLS1#
A:MLS1# show
show system
system ptp
ptp peer
peer 192.0.2.227
192.0.2.227 detail
detail
...
...
===============================================================================
===============================================================================
IEEE
IEEE 1588/PTP
1588/PTP Packet
Packet Statistics
Statistics
===============================================================================
===============================================================================
Input
Output
Input
Output
------------------------------------------------------------------------------------------------------------------------------------------------------------PTP
4946482
9930069
PTP Packets
Packets
4946482
9930069
Announce
0
38635
Announce
0
38635
Sync
0
4944952
Sync
0
4944952
Follow
00
00
Follow Up
Up
Delay
Request
4944951
00
Delay Request
4944951
Delay
00
4944951
Delay Response
Response
4944951
Signaling
1531
1531
Signaling
1531
1531
Request
1531
00
Request Unicast
Unicast Transmission
Transmission TLVs
TLVs
1531
Announce
511
00
Announce
511
Sync
510
00
Sync
510
Delay
510
00
Delay Response
Response
510
Grant
Unicast
Transmission
(Accepted)
TLVs
0
1531
Grant Unicast Transmission (Accepted) TLVs
0
1531
Announce
00
511
Announce
511
Sync
0
510
Sync
0
510
Delay
00
510
Delay Response
Response
510
...
... Continued
Continued on
on next
next slide
slide
Module 2 |
113
View the PTP Master Master Peer Details 7750 SR (cont)

The SROS collects PTP statistics for each peer clock. Counters are available for all the message types discussed in
this section. These counters, in conjunction with the system logs, provide tools useful to monitor slave clock
performance, diagnose a timing problem, or analyze the networks performance when transporting
synchronization messages.
IEEE 1588/PTP Packet Statistics
The counters indicate the number of received and transmitted PTP packets.
Input
The master receives signaling messages: Request Announce, Request Sync, and Delay Request.
Output
The master sends Announce and Sync messages. It also sends Delay Response messages.
A:MLS1#
A:MLS1# show
show system
system ptp
ptp peer
peer 192.0.2.227
192.0.2.227 detail
detail
...
...
Grant
00
00
Grant Unicast
Transmission (Denied)
(Denied) TLVs
TLVs
Announce
00
00
Announce
Sync
00
00
Sync
Delay
Response
0
00
Delay Response
0
Cancel
00
00
Cancel Unicast
Transmission TLVs
TLVs
Announce
0
0
Announce
0
0
Sync
00
00
Sync
Delay
00
00
Delay Response
Response
Ack
00
00
Ack Cancel
Cancel Unicast
Transmission TLVs
TLVs
Announce
00
00
Announce
Sync
00
00
Sync
Delay
00
00
Delay Response
Response
Other
TLVs
0
00
Other TLVs
0
Other
00
00
Other
Discards
00
00
Discards
Bad
00
00
Bad PTP
PTP domain
domain
Alternate
00
00
Alternate Master
Master
Other
0
00
Other
0
===============================================================================
===============================================================================
Module 2 |
114
View the PTP Master Master Peer Details 7750 SR (cont)

Cancel Unicast Transmission TLVs
Either the master or the slave wish to cancel a unicast session.
Ack Cancel Unicast Transmission TLVs
Acknowledge cancel unicast messages.
Discards
PTP packets originating on an unsupported domain.
A:MLS2# show system ptp

A:MLS2# show system ptp
===============================================================================
===============================================================================
IEEE 1588/PTP Clock Information
IEEE 1588/PTP Clock Information
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Local Clock
Local Clock
------------------------------------------------------------------------------------------------------------------------------------------------------------Clock Type
: ordinary,slave
PTP Profile
: ITU-T G.8265.1
Clock Type
: ordinary,slave
PTP Profile
: ITU-T G.8265.1
Domain
: 4
Network Type
: sonet
Domain
: 4
Network Type
: sonet
Admin State
: up
Oper State
: up
Admin State
: up
Oper State
: up
Clock Id
: 0003fafffe6bd7c0
Clock Class
: 255 (slave-only)
Clock Id
: 0003fafffe6bd7c0
Clock Class
: 255 (slave-only)
Clock Accuracy
: unknown
Clock Variance
: ffff (not computed)
Clock Accuracy
: unknown
Clock Variance
: ffff (not computed)
Clock Priority1
: 128
Clock Priority2
: 128
Clock Priority1
: 128
Clock Priority2
: 128
PTP Port State
: slave
Last Changed
: 11/22/2011 15:13:04
PTP Port State
: slave
Last Changed
: 11/22/2011 15:13:04
PTP Recovery State: locked
Last Changed
: 11/22/2011 15:13:04
PTP Recovery State: locked
Last Changed
: 11/22/2011 15:13:04
Frequency Offset : -82.985 ppb
Frequency Offset : -82.985 ppb
------------------------------------------------------------------------------------------------------------------------------------------------------------Parent Clock
Parent Clock
------------------------------------------------------------------------------------------------------------------------------------------------------------IP Address
: 192.0.2.0
IP Address
: 192.0.2.0
Parent Clock Id
: 0003fafffe688fc0
Remote PTP Port
: 1
Parent Clock Id
: 0003fafffe688fc0
Remote PTP Port
: 1
GM Clock Id
: 0003fafffe688fc0
GM Clock Class
: 80 (prs)
GM Clock Id
: 0003fafffe688fc0
GM Clock Class
: 80 (prs)
GM Clock Accuracy : unknown
GM Clock Variance : ffff (not computed)
GM Clock Accuracy : unknown
GM Clock Variance : ffff (not computed)
GM Clock Priority1: 128
GM Clock Priority2 : 128
GM Clock Priority1: 128
GM Clock Priority2 : 128
===============================================================================
===============================================================================
Module 2 |
115
View the PTP Slave Configuration 7750 SR

A:NodeA# show system ptp
Clock Type: Configured as an ordinary slave.
PTP Port State: Slaved to the master clock.
PTP Recovery State: The slave SEC frequency is locked to the master reference.
Frequency Offset: The slave clocks calculated offset from the master.
IP Address: The master peers IP address.
View The PTP Slave Configuration 7750 SR
A:CSA1# show system ptp clock 1

A:CSA1# show system ptp clock 1
===============================================================================
===============================================================================
IEEE1588 PTP Clock Information
IEEE1588 PTP Clock Information
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Local Clock
Local Clock
------------------------------------------------------------------------------------------------------------------------------------------------------------Clock Type
: ordinary,slave
Admin State
: up
Clock Type
: ordinary,slave
Admin State
: up
Source I/F
: loop_ptp
Clock MDA
: 1/2
Source I/F
: loop_ptp
Clock MDA
: 1/2
PTP Profile
: ituTelecomFreq
Dynamic Peers
: not allowed
PTP Profile
: ituTelecomFreq
Dynamic Peers
: not allowed
Clock ID
: 7c2064fffec348b8 Clock Class
: 255
Clock ID
: 7c2064fffec348b8 Clock Class
: 255
Clock Accuracy
: unknown(254)
Clock Variance
: not computed
Clock Accuracy
: unknown(254)
Clock Variance
: not computed
Clock Priority1
: 128
Clock Priority2
: 128
Clock Priority1
: 128
Clock Priority2
: 128
Domain
: 4
Two-Step
: unknown
Domain
: 4
Two-Step
: unknown
------------------------------------------------------------------------------------------------------------------------------------------------------------Operational Data
Operational Data
------------------------------------------------------------------------------------------------------------------------------------------------------------Parent Clock ID
: 0003fafffe688fc0 Parent Port Number
: 1
Parent Clock ID
: 0003fafffe688fc0 Parent Port Number
: 1
GM Clock Id
: 0003fafffe688fc0 GM Clock Class
: 80
GM Clock Id
: 80
GM Clock Accuracy
: unknown(254)
GM Clock Variance
: not computed
GM Clock Accuracy
: unknown(254)
GM Clock Variance
: not computed
GM Clock Priority1
: 128
GM Clock Priority2
: 128
GM Clock Priority1
: 128
GM Clock Priority2
: 128
------------------------------------------------------------------------------------------------------------------------------------------------------------Slave Port Index
: 1
Slave Port State
: slave
Slave Port Index
: 1
Slave Port State
: slave
Slave Peer Index
: 1
Slave Peer IP
: 192.0.2.0
Slave Peer Index
: 1
Slave Peer IP
: 192.0.2.0
Forward Weight
: 100
Reverse Weight
: 0
Forward Weight
: 100
Reverse Weight
: 0
Recovery State
: locked
Recovery State
: locked
===============================================================================
Alcatel-Lucent
IP/MPLS Mobile Backhaul Transport v1.0
Module 2 | 116
===============================================================================
View the PTP Slave Configuration 7705 SAR

A:NodeA# show system ptp clock 1
Forward Weight: The percentage of sync packet direction being used to recover the clock from the
selected peer.
Recovery State: - The current clock recovery state. The values are:
Free-run
Acquiring
Phase-tracking
locked
View The PTP Slave Configuration 7705 SAR
A:CSA1# show system ptp clock 1 ptp-port 1 peer 1 detail

===============================================================================
===============================================================================
Peer-1
Peer-1
===============================================================================
===============================================================================
IP Address
: 192.0.2.0
static/dynamic
: static
IP Address
: 192.0.2.0
static/dynamic
: static
Current Master
: TRUE
Current Master
: TRUE
Description
: peer_MLS1
Description
: peer_MLS1
Clock Id
: 0003fafffe688fc0 Port Number
: 1
Clock Id
: 0003fafffe688fc0 Port Number
: 1
GM Clock Id
: 80
GM Clock Id
: 80
GM Clock Accuracy
: unknown(254)
GM Clock Variance
: not computed
GM Clock Accuracy
: unknown(254)
GM Clock Variance
: not computed
GM Clock Priority1
: 128
GM Clock Priority2
: 128
GM Clock Priority1
: 128
GM Clock Priority2
: 128
Step Type
: one-step
Step Type
: one-step
Last Rx Anno Msg
: 11/22/2011 14:54:36
Last Rx Anno Msg
: 11/22/2011 14:54:36
----------------------------------------------------------------------------------------------------------------------------------------------------Unicast Info
Unicast Info
----------------------------------------------------------------------------------------------------------------------------------------------------Dir Type
Rate
Dur Result
Time
Remain
Dir Type
Rate
Dur Result
Time
Remain
----------------------------------------------------------------------------------------------------------------------------------------------------Rx Anno
1 pkt/2 s 300 granted
11/22/2011 14:53:35
241
Rx Anno
1 pkt/2 s 300 granted
11/22/2011 14:53:35
241
Sync
64 pkts/s 300 granted
11/22/2011 14:53:41
249
Sync
64 pkts/s 300 granted
11/22/2011 14:53:41
249
DelayResp 64 pkts/s 300 granted
11/21/2011 14:53:41
249
DelayResp 64 pkts/s 300 granted
11/21/2011 14:53:41
249
----------------------------------------------------------------------------------------------------------------------------------------------------===============================================================================
===============================================================================
...continued on next page
Module 2 |
117
View the PTP Slave PTP Port Peer 7705 SAR

A:NodeA# show system ptp clock 1 ptp-port 1 peer 1 detail
Peer-1
IP Address: Lists the peers IP address and type.
Current Master: The peer is the master clock source.
Description: The peer clock description.
Clock Id: The peer clock ID.
Port Number: The peer clock PTP port number.
GM Clock ID: The grand master clock ID. This example has no GM, so the master node sends its own clock ID as the GM
Clock ID.
GM Clock Class: The GM clock class.
GM Clock Accuracy: The accuracy advertised by the GM clock, used by the BMCA to choose the best source.
GM Clock Variance: An estimate of the GMs clock variance.
GM Clock Priority1 and Priority2: The GM advertised Priority1 and 2 values used by the BMCA to choose the best source.
Step Type: One- or two-step. The GM advertises this capability in its announce messages.
Last Rx Anno Msg: - The time the slave received the last announce message sent by the peer.
Unicast Info
Dir Unicast information direction, Transmit (Tx) or Receive (Rx)
Type The Message type, Anno(unce), Sync, or DelayResp(onse)
Rate The rate the slave set for the messages in packets/second
Dur The lease duration for the session. This value is set by the PTP grandmaster, and is not configurable in SROS.
Result The result (reply) to the last of the message type sent.
Time The time the information was received.
Remain The remaining lease time.
View The PTP Slave PTP Port Peer 7705 SAR

...continued from previous page
...output truncated
...output truncated
===============================================================================
===============================================================================
PTP Peer 1 Algorithm State Statistics (in seconds)
===============================================================================
===============================================================================
Free-run
: 604
Free-run
: 604
Acquiring
: 120
Acquiring
: 120
Phase-Tracking
: 1440
Phase-Tracking
: 1440
Hold-over
: 0
Hold-over
: 0
Locked
: 75504
Locked
: 75504
===============================================================================
===============================================================================

Module 2 |
118
View the PTP Slave Configuration 7705 SAR (cont)

Displays how long the slave clock has been in each of the listed states.

...output truncated
...output truncated
===============================================================================
===============================================================================
PTP Peer-1 Clock Recovery
PTP Peer-1 Clock Recovery
- Internal Digital Phase Locked Loop (DPLL) Statistics
- Internal Digital Phase Locked Loop (DPLL) Statistics
===============================================================================
===============================================================================
sync
delay-req
phase
phase
sync
delay-req
phase
phase
pkt delay
pkt delay
error
error
pkt delay
pkt delay
error
error
stddev
stddev
stddev
stddev
stddev
stddev
time
(ns)
(ns)
(ns)
(ns)
time
(ns)
(ns)
(ns)
(ns)
------------------------------------------------------------------------------------------------------------------------------------------------------------11/22/2011 14:55:51
7
233
-327
21
11/22/2011 14:55:51
7
233
-327
21
11/22/2011 14:53:51
7
225
-376
12
11/22/2011 14:53:51
7
225
-376
12
11/22/2011 14:51:50
6
206
-445
25
11/22/2011 14:51:50
6
206
-445
25
11/22/2011 14:49:50
10
223
-513
16
11/22/2011 14:49:50
10
223
-513
16
11/22/2011 14:47:50
19
236
-551
9
11/22/2011 14:47:50
19
236
-551
9
11/22/2011 14:45:50
4
223
-563
7
11/22/2011 14:45:50
4
223
-563
7
11/22/2011 14:43:50
0
249
-589
13
11/22/2011 14:43:50
0
249
-589
13
11/22/2011 14:41:50
3
233
-599
7
11/22/2011 14:41:50
3
233
-599
7
11/22/2011 14:39:50
3
230
-609
8
11/22/2011 14:39:50
3
230
-609
8
...output truncated
...output truncated
Module 2 |
119

PTP Peer-1 Clock Recovery Internal Digital Phase Locked Loop (DPLL) Statistics
These statistics, refreshed by the node every 2 minutes, shows the peer clock phase and delay error values.
View the Slave Timing References 7750 SR
===============================================================================
===============================================================================
===============================================================================
===============================================================================
System Status CPM A
: Master Locked
System Status CPM A
: Master Locked
: Non-revertive
: Non-revertive
: Disabled
: Disabled
Reference Selected
: ptp
Reference Selected
: ptp
: prs
: prs
Reference Order
: ptp ref1 ref2 bits
Reference Order
: ptp ref1 ref2 bits
...output truncated
...output truncated
Reference PTP
Reference PTP
Admin Status
: up
Admin Status
: up
Rx Quality Level
: prs
Rx Quality Level
: prs
: none
: none
Qualified For Use
: Yes
Qualified For Use
: Yes
Selected For Use
: Yes
Selected For Use
: Yes
===============================================================================
===============================================================================
Module 2 |
120
View the Slave Timing References 7750 SAR

The MLS2 slave has locked its master clock to reference input 1. Note that this can take some time, up to
15 minutes or more for the slave to synchronize with and qualify the master clock.
System Status CPM A: Slaves SEC locked to the selected Master reference
Reference Selected: The selected reference is the configured PTP clock.
Reference PTP
Rx Quality Level: The quality level advertised by the selected master.
Qualified For Use: The slave qualifies this as a valid reference source.
Selected For Use: The slave is synchronized off of this reference source.
A:MLS2# show system sync-if-timing

A:MLS2# show system sync-if-timing
===============================================================================
===============================================================================
===============================================================================
===============================================================================
System Status CSM A
: Master Locked
System Status CSM A
: Master Locked
: Non-revertive
: Non-revertive
: Disabled
: Disabled
Reference Order
Reference Order

Reference Input 1
Reference Input 1
Admin Status
Admin Status
Rx Quality Level
Rx Quality Level
Qualified For Use
Qualified For Use
Selected For Use
Selected For Use
Source Port
Source Port
Source PTP Clock
Source PTP Clock
...output truncated
...output truncated
: up
: up
: none
: none
: prs
: prs
: Yes
: Yes
: Yes
: Yes
: None
: None
: 1
: 1
Module 2 |
121

The CSA slave has locked its master clock to reference input 1. Note that this can take some time, up to 15
minutes or more for the slave to synchronize with and qualify the master clock.
Rx Quality Level The level set by master, QL-PRS
Qualified For Use The reference PTP clock is synchronized to a suitable master port.
Selected For Use The CSA has selected this port as its timing reference.
Source Port There is no source port for PTP.
Source PTP Clock The slave is configured to synchronize off PTP clock 1.
A:CSA2# show system sync-if-timing

A:CSA2# show system sync-if-timing
To ensure reliable and accurate time delivery:

Use only high bandwidth, low latency links between the clocks
Assign PTP packets to Forwarding Class Network Control (NC) and
ensure elevated treatment for these packets
Limit the number of hops between the master and slave to no
more than 5 intermediate nodes (PTP over fiber)
Use boundary or transparent clocks to extend the PTP domain
reach without increasing PDV
Keep the ports on which the PTP packets are sent or received local
to the PTP master or slave MDA
If MDA 1/1 hosts the PTP master source interface network port,
then the ports through which it sends and receives PTP packets
should be 1/1/1, 1/1/2, etc.
Module 2 |
122
IEEE 1588v2/PTPv2 Design Considerations
.5 Hour
Lab Overview:
Configure MLS1 as the PTP master and slave the SAR routers off
MLS1
Configure MLS2 as the SAR router secondary reference
Fail the MLS1 reference and observe MLS2 become the master
NOTE: 7750 will not operate as PTP slave without SF/CPM-3 installed
Module 2 |
123
Lab 4 : Configure IEEE 1588v2 and PTP
Section Summary
IEEE 1588v2 and the Precision Time Protocol (PTP) v2 provide

packet-based timing in the Backhaul Transport network
Nodes choose the master clock using information contained in the
PTP messages and by running the Best Master Clock Algorithm
PTP clock types: Grandmaster, ordinary slave and master,
boundary, and transparent
PTP nodes calculate clock offset using the timestamps exchanged
in PTP event messages
PTP event messages use UDP port 319 and general messages use
UDP port 320
Using the ITU-T G.8265.1 profile, PTP slaves can choose their
master by clock quality level, then reference order
Module 2 |
124

Section 5 Routing and Routing Protocols
Section Objectives
Explore the unique routing challenges offered by the Mobile

Describe routing in the Model 1 network
Floating static routes for CSA-MLS routing
LDP-Sync used to hold down routes until LDP converges
BFD for rapid fault detection on static-routes
OSPF for routing between MLS routers
Modified OSPF timers to reduce SPF run frequency
Module 2 |
126
Section Objectives (cont)

Hierarchical ISIS with multiple levels
Modified SPF timers to control SPF runs
iBGP for distributed VPRN services
Redundant route reflectors to reduce BGP full mesh
requirements
BGP peer-tracking for reliability and recovery
Explain eBGP use for routing between the MLS routers and
network elements outside the Backhaul Transport routing domain
Module 2 |
127
Describe routing in the Model 2 network
Routing in the Backhaul Transport warrants special considerations

The network must support concurrent 2, 3, and 4G services
It must support a service overlay model
The customer may be a BTP, MSP, or both
The transport may be TDM, Ethernet, or both
Protocols must rapidly converge in the case of a link outage
Module 2 |
128
Routing in the Mobile Backhaul Transport Network

In the Mobile Backhaul Transport Network, routing design must consider some unique circumstances compared to
traditional data or converged networks.
Mixed Transport Infrastructure
Though new backhaul deployments will likely be Ethernet-based, many existing sites may still use only TDM
uplinks. In some circumstance, a carrier may use wireless technologies, such as IEEE 802.16 WiMAX or microwave
links as the transport. No matter what technology they chose, the routing infrastructure must be adaptable to the
transport.
Service Support
The routed network must provide high availability while supporting a service overlay model, so that it might carry
traffic for a variety of 2, 3, and 4G customers over a common transport.
Rapid Convergence
The routing domain design must consider the effect that routing convergence will have on the networks
performance. The network must recover quickly enough to prevent dropped calls and subsequent resignaling
bursts in the case of an outage. Control traffic must flow reliably as well. The network must provide hotredundant paths between the cell sites and the MTSO.
Routing in the Mobile Backhaul Transport Network
Transport may be TDM, Ethernet, or both

Strictly L3 services for 2G IPBH over TDM uplink
Routed or MPLS for 3G EBH and LTE traffic
May use static routes from CSA to MLS routers
Floating static routes between CSA and MLS routers
BFD on static routes for rapid failure detection
LDP-sync used to avoid discarded traffic while waiting for label
signaling
May use hierarchical routing protocol between CSA and MLS
routers
Module 2 |
129
Routing in Model 1 Hub and Spoke Topology

The Model 1 topology uses both a TDM and Ethernet transport. For 2G IPBH traffic delivered over bundled DS1s,
no routing protocol is necessary. From the BTS and MLS perspective, the ML-PPP bundle interfaces are directly
connected and on the same subnet.
However, the EBH NodeB and eNodeB are separated from the MLS router by the CSA router, requiring routing
between the network segments. In this model 1 topology, the design engineers chose to use static routing, though
they could have used an IGP, as well.
Although dynamic routing could work here as well, static routing keeps the CSA forwarding tables small, and the
few point-to-point links simplify the routing domain to the point where static routing is manageable.
Reasons for using static routes in a Backhaul Transport
The design may implement static routes in case where:
Customer equipment does not support dynamic routing
1000s of network elements impose Forward Information Base (FIB) scaling concerns on lower capacity nodes
Need to keep the number of LDP, T-LDP, and/or RSVP peers to a minimum
Reduce the number of adjacencies the MLS/BG must maintain where these nodes act as the hub sites
Network element security concerns demand strict forwarding controls
In the Model 1 hub and spoke design, a routing protocol will not add functional value on the spoke connected sites.
Routing in the Model 1 Hub and Spoke Topology
CSA to MTSO floating static routes

Two paths to each MLS router
Set higher preference on backup path
Module 2 |
130
Routing in the Model 1 Hub and Spoke Topology (cont)

Floating static routes in the Model 1 topology provide redundant routes to each nodes system IP address. In the
example above, CSA1 must run LDP and Targeted LDP sessions between itself and MLS1 and MLS2. It needs routes
to both MLS router system IPs.
Configured on CSA1 are two static routes for each of the two MLS routers. One route is the CSAs primary,
preferred path to the MLS router, while the second is the backup. A higher preference set on the backup route
keeps it inactive, unless the primary route becomes invalid.
Of course, the MLS routers need routes back to the CSA router. Each of them also have two routes back to the
CSA, targeting the CSAs system IP. Additionally, the MLS routers have static routes defined to each others
system IP, and additional static routes to the EPC elements.
BFD on Static Routes
Configured on both static routes is BFD. Since the routers wont know if a link failure occurs in the MEN, they run
BFD on the CSA to MLS interfaces. If the BFD session fails, the routers know a link failure likely occurred and can
move traffic to the alternate route. Without BFD running on the interfaces, the routers could continue to route
traffic to the MENs failed link. Each router sees a valid link between themselves and the MEN UNI, and so would
not be aware of a failure somewhere in the MEN cloud. BFD ensures that they know if the MEN link is unavailable.
LDP-Sync on Static Routes
When an interface on the primary static route recovers, the router could attempt forwarding traffic along this
route before it has a label for the target network. If this were to occur, the sending router would drop packets for
the target network. To preclude this situation, ldp-sync is enabled on the primary static route, and an LDP sync
timer configured on the interfaces, to hold down the route until the sending node has a label for the target FEC.
Routing in the Model 1 Hub and Spoke Topology (cont)
A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.5

A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.13 preference 10
A floating static route provides a means for traffic to follow a

backup static route in the event the router detects a failure
along the path used by the primary static route.
Module 2 |
131
Floating Static Routes in the Model 1 Network

In the example above, CSA1 has two static routes configured. The top static route points all traffic destined for
MLS1s system IP out the primary path. Because there is no preference setting explicitly stated on this route, CSA1
uses the SROS default static route preference value, 5.
On the second route, CSA1 routes traffic to MLS1 via MLS2. In this case, the routes preference value is 10. CSA1
chooses the lower numeric preference route, if available.
Primary Route Choice
CSA1 chooses the active static route with the lowest preference value. As a result, all traffic between CSA1 and
MLS1 will use the primary route, as long as it is operational. In the event the primary route fails, the routers
remove the primary static route(s) from their FIBs and replace them with the secondary static route. The
secondary route now has the lowest preference value.
Configuration
For bidirectional traffic flow, there must be a return route. Therefore, the MLS routers also need static routes
configured:
A:MLS1>config>router# static-route 192.0.2.1/32 next-hop 192.0.2.22
A:MLS1>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.22 preference 10
Note: If the interface connects to an intermediate device, such as a switch or hub, one router interface could fail
while the router at the other end still has an active interface. When this happens, traffic may flow in one
direction only, making it impossible to establish a connection over this link. BFD running on the interfaces helps
mitigate this situation.
Floating Static Routes in the Model 1 Network
A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.5 bfd-enable

CSA and MLS routers have no view of MEN link status

BFD sessions on primary route interfaces enable failure detection over
MEN transport
BFD must be enabled on the interfaces
Module 2 |
132
BFD on the Model 1 Network Static Routes

BFD is a network protocol intended to provide lightweight, low-overhead, short-duration failure detection in the
path between two systems. If a system stops receiving BFD messages, it assumes that a failure along the path has
occurred and the notifies the associated protocol. The routing protocol must then take action to bypass the
failure.
If more than one link exists between two systems, multiple BFD sessions may be established to monitor each one
of them.
BFD on Static Routes
BFD must be tied to the routing instance it will protect. Additionally, BFD must be enabled on the interfaces.
BFD runs on a hop-by-hop basis, and must be configured on every link between the source and the destination.
Once the BFD sessions are running, BFD can detect and report a link failure to the routing instance in less than a
second.
BFD may be enabled only on the preferred static routes. This depends on the customers design.
BFD on the Interfaces
You must enable BFD on the router interfaces through which the router forward traffic for the target network.
config>router>interface
bfd transmit-interval [receive receive-interval] [multiplier multiplier]
transmit-interval Sets the interval, in milliseconds, at which the node will send BFD messages
receive-interval Sets the interval, in milliseconds, at which the node expects to receive BFD messages
multiplier Sets the number of packets the node can miss before declaring the BFD session, and thus the
interface, down
A:CSA1>config>router# interface CSA1_MLS1 bfd 500 receive 500 multiplier 3
A:CSA1>config>router# interface CSA1_MLS2 bfd 500 receive 500 multiplier 3
A:MLS1>config>router# interface MLS1_CSA1 bfd 500 receive 500 multiplier 3
A:MLS1>config>router# interface MLS1_MLS2 bfd 500 receive 500 multiplier 3
A:MLS2>config>router# interface MLS2_MLS1 bfd 500 receive 500 multiplier 3
This configuration tells the CSA1 and MLS routers to transmit and expect to receive BFD messages every 500 ms,
and declare the BFD session down after 1500 ms (three missed messages).
BFD on the Model 1 Network Static Routes
LDP-Sync protects against black holed LDP packets

Prevents router from sending packets over path for which it has no label
Router holds down route until it has label in LFIB for target FEC
Requires timer set on each IP interface where the feature is used
Module 2 |
133
LDP-Sync on the Static Routes

LDP Sync on the static routes ensures that the ingress router does not forward packets over a path until it has a
label for it. Since LDP and the IGP converge independently, the ingress router could black hole packets for
which it has a valid route but does not yet have a label.
Assume that the CSA1-MLS1 link failed and CSA1 and MLS1 had moved traffic to their secondary routes. Without
LDP-Sync enabled:
1. The link between CSA1 and MLS1 recovers, causing the routers to activate the primary routes and place them in
their FIBs.
2. Due to the link failure, both routers had removed from their LFIB the labels they once had for the primary
route. The routers activate the route immediately, but find no corresponding label in their LFIB.
Because the secondary route is not longer the best, the routers remove that routes labels from their LFIBs.
3. Until the routers have labels for the recovered route, they will drop LDP packets targeting MLS1.
Based on the interface LDP sync timer value, the routers hold down the new route until their timer expires. This
causes the router to hold down the routes using the interface as a next hop, giving LDP time to convergence.
Once the timer expires, the head-end router finds a label for the prefix in its LFIB and forwards the data on.
NOTE: The static-routes on which you have configured LDP-Sync stay down until LDP is configured on the router.
LDP-Sync on the Static Routes
A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.5 bfd-enable ldp-sync

LDP-Sync is only enabled on the primary route

It requires timers set on the CSA1 to MLS primary interfaces
For the route to become active, LDP must be running on the
interfaces
Module 2 |
134
LDP-Sync on Primary Static Route

On the primary static routes, the CSA and MLS routers enable LDP-Sync.
Static Route Configuration
A:MLS1>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.6 bfd-enable ldpsync
A:MLS2>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.14 bfd-enable ldpsync
Interface Configuration
config>router>interface
ldp-sync-timer seconds
seconds Ranges from 1-1800. This determines for how long the ingress router holds down the static route
before it will place it in the FIB.
A:CSA1>config>router# interface CSA1_MLS1 ldp-sync-timer 180
A:MLS1>config>router# interface MLS1_CSA1 ldp-sync-timer 180
LDP Configuration
The static routes will not activate until LDP is running on the associated interfaces.
A:CSA1>config>router# ldp interface-parameters interface CSA1_MLS1
A:MLS1>config>router# ldp interface-parameters interface MLS1_CSA1
LDP-sync on Primary Static Route
View the CSA Primary Static Route
===============================================================================
===============================================================================
Static
Static Route
Route Table
Table (Router:
(Router: Base)
Base) Family:
Family: IPv4
IPv4
===============================================================================
===============================================================================
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Prefix
:: 192.0.2.0/32
Prefix
192.0.2.0/32
Nexthop
:: 192.0.2.5
Nexthop
192.0.2.5
Type
:: Nexthop
Nexthop
:: IP
Type
Nexthop
Nexthop Type
Type
IP
Interface
:: CSA1_MLS1
Active
:: YY
Interface
CSA1_MLS1
Active
Prefix
:: n/a
Prefix
Prefix List
List
n/a
Prefix List
List Type
Type :: n/a
n/a
Metric
:
1
Preference
:: 55
Metric
: 1
Preference
Admin
:: Up
Tag
:: 00
Admin State
State
Up
Tag
BFD
:
enabled
BFD
: enabled
CPE-check
:: disabled
CPE-check
disabled
LDP
:: enabled
LDP Sync
Sync
enabled
LDP
:: enabled
LDP Sync
Sync
enabled
...
... output
output truncated
truncated
------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Static Routes: 4
No. of Static Routes: 4
===============================================================================
===============================================================================
Module 2 |
135
View the CSA Primary Static Route

A:NodeA# show router static-route detail
BFD: Enabled on all CSA interfaces and static routes.
LDP Sync: - Enabled on primary route only
Preference: - The default preference is used for the primary route.
A:CSA1#
A:CSA1# show
show router
router static-route
static-route detail
detail
View the CSA BFD Sessions
===============================================================================
===============================================================================
BFD
BFD Session
Session
===============================================================================
===============================================================================
Interface
State
Tx
Interface
State
Tx Intvl
Intvl Rx
Rx Intvl
Intvl Multipl
Multipl
Remote
Protocol
Tx
Remote Address
Address
Protocol
Tx Pkts
Pkts Rx
Rx Pkts
Pkts Type
Type
------------------------------------------------------------------------------------------------------------------------------------------------------------CSA1_MLS1
Up
500
500
33
CSA1_MLS1
Up (3)
(3)
500
500
192.0.2.5
static
8709
7477
iom
192.0.2.5
static
8709
7477
iom
CSA1_MLS2
Up
(3)
500
500
3
CSA1_MLS2
Up (3)
500
500
3
192.0.2.13
static
9719
9719
iom
192.0.2.13
static
9719
9719
iom
------------------------------------------------------------------------------------------------------------------------------------------------------------No.
No. of
of BFD
BFD sessions:
sessions: 22
===============================================================================
===============================================================================
Module 2 |
136
View the CSA BFD Sessions

A:NodeA# show router bfd session
The CSA routers maintain a separate BFD session for each MLS router.
The MLS routers maintain a BFD session for only the primary CSA link.
A:MLS1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
Remote Address
State
Tx Intvl
Rx Intvl
Multipl
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------MLS1_CSA1
192.0.2.6
Up (3)
static
500
500
2753
2751
iom
------------------------------------------------------------------------------No. of BFD sessions: 1

===============================================================================
A:CSA1#
A:CSA1# show
show router
router bfd
bfd session
session
View LDP Sync Status
===============================================================================
===============================================================================
Sync
Sync Status
Status of
of LDP
LDP interfaces
interfaces
===============================================================================
===============================================================================
If
If
Timer
Time
If Ind*
Ind*
If Name
Name
Timer Running?
Running? Timeout
Timeout
Time
Yes/No
used
Left
Yes/No
used
Left
------------------------------------------------------------------------------------------------------------------------------------------------------------22
MLS1_CSA1
Yes
180
174
MLS1_CSA1
Yes
180
174
44
MLS1_MLS2
No
00
00
MLS1_MLS2
No
===============================================================================
===============================================================================
indicates
indicates that
that the
the corresponding
corresponding row
row element
element may
may have
have been
been truncated.
truncated.
Module 2 |
137
View LDP Sync Status

A:NodeA# tools dump router static-route ldp-sync-status
Once an interface on which a timer is configured recovers, the router starts the LDP sync timer on that interface.
While the Time Left is greater than 0, the router holds down the associated static routes.
A:MLS1# show router static-route
===============================================================================
Static Route Table (Router: Base)
Family: IPv4
===============================================================================
Prefix
Next Hop
Tag
Met
Pref Type Act
Interface
------------------------------------------------------------------------------192.0.2.1/32
192.0.2.22
192.0.2.2/32
192.0.2.22
NH
NH
10
NH
MLS1_MLS2
0
192.0.2.6
192.0.2.2/32
n/a
0
MLS1_MLS2
------------------------------------------------------------------------------No. of Static Routes: 3

===============================================================================
MLS1 continues to forward traffic to CSA1 via MLS2, until the LDP sync timer on the MLS1-CSA1 interface recovers.
A:MLS1#
A:MLS1# tools
tools dump
dump router
router static-route
static-route ldp-sync-status
ldp-sync-status
The Model 1 topology uses OSPF to advertise routes between MLS

routers
Share routes for L3 service redundancy
Adjust SPF timers to reduce calculation frequency
A:MLS1>config>router>ospf#
A:MLS1>config>router>ospf# timers
timers spf-wait
spf-wait 2000
2000 50
50 100
100
Event
2nd run = 100ms
400ms
1600ms
SPF Event Timeline

1st run = 50ms
200ms
800ms
max wait = 2000ms
Module 2 |
138
OSPF in Model 1
To ensure full L3 service redundancy, the Model 1 topology runs OSPF between the two MLS routers. The system
interfaces, MLS-to-MLS interfaces, and some NC element interfaces belong to area 0. Only the MLS-MLS
interfaces advertise routes, the others are passive interfaces.
Routing policies export directly connected interfaces and the static routes to the other MLS router.
OSPF Timers
You may modify the default OSPF timers to enable faster convergence.
Ideally, the routers should run the SPF calculation only once per event. To facilitate this, the Model 1 design
specifies the SPF timer values shown in the diagram above. Times are measured in milliseconds (ms).
config>router>ospf>timers
spf-wait max-spf-wait [spf-initial-wait [spf-second-wait]]
max-spf-wait 2000 ms. The maximum interval between consecutive SPF calculations. The default is 1000ms.
spf-initial-wait 50ms. This allows the sender time to flood the update before running its SPF algorithm on the
update. This also gives the other routers in the domain time to collect additional updates for the same event,
and run their SPF calculation for the same event. The default is 1000ms.
spf-second-wait 100ms. This doubles the wait period before running another SPF calculation. This
exponential interval reduces router CPU utilization. The default is 1000ms.
Each interval doubles until the router reaches the max-spf-wait value, then remains at the max-interval until the
router receives no new events.
OSPF in Model 1
Routing protocol convergence is affected by the following conditions:

1. Link failure detection
2. Time to generate and send a Link State Advertisement (LSA)/Link
State Packet (LSP) after a topology change occurs
3. Time to flood the LSAs/LSPs throughout the network
4. SPF timers
5. Time to update the Routing Information Base (RIB) and FIB
Module 2 |
139
Routing Protocol Convergence Factors
Transport is Ethernet or Ethernet over SONET

Hierarchical routing with POC3 routers as ISIS area border routers
Traffic engineering enabled on both areas
Aggregation ring as Level 2 only shares default route with access
area
Each POC1, 2, and 3 router is in its own area
Access ring is common Level 1 area
iBGP for VPRN route distribution
Module 2 |
140
Routing in Model 2 Subtended Ring Topology

The Model 2 topology may use Ethernet or Ethernet over SONET transport. To support routing from the CSA to
the MTSO, this solution uses hierarchical ISIS routing.
Benefits of a Hierarchical Routing Scheme
Dynamic routing is clearly the best choice where multiple, redundant paths connect the network nodes. Static
routes are cumbersome to maintain, and do not allow the network to take advantage of traffic engineering
techniques for advanced network design and redundancy.
Additionally, ISIS allows for a hierarchical design, providing the network engineer better control over route
propagation and convergence times. For example:
The CSA routers need only know how to route to all other networks, not to each individually. Level 1 ISIS
areas learn from Level1/Level2 routers a default route, significantly reducing their FIB sizes.
L1/L2 routers, the POC3 routers in this design, maintain two link-state databases. This isolates L1 and L2
routes to their respective areas, and the POC3 routers do not pass L2 routes to L1 areas.
The L2 routers exchange routes with other L2 or L1/L2 routers, including routes to L1 areas.
ISIS supports route summarization, where the L1/L2 routers summarize the access ring routes, rather than
advertising each subnet individually. This reduces the number of routes the L2 routes must learn and
maintain.
ISIS convergence time can be controlled by adjusting the SPF timers to avoid duplicate SPF runs.
ISIS used in the Model 2 topology ensures a stable and scalable routing domain.
Routing in the Model 2 Subtended Ring Topology
Hierarchical ISIS routing

CSA routers on same access ring in same L1 area
POC3 L1/L2 routers summarize access ring networks to L2 routers
Each POC1, POC2 and POC3 router in its own L2 area to ensure
they only form L2 adjacencies
Module 2 |
141
Routing in the Model 2 Subtended Ring Topology (cont)

Routed Domain Design
Level1 - As shown in the diagram, all CSA (access ring) routers are in the same L1 area. This allows them to
share routes between themselves and the POC3 routers. However, they do not learn routes from the aggregation
routers, so the CSA router databases remain small. Since the CSA routers only learn routes from the same level
routers and the default routes from the POC3 routers, their routes tables would contain fewer than 30 routes.
Level1/2 The POC3 routers are L1/L2 routers, each in their own individual areas. They learn the Level1 routes
from the access ring, and distribute those as summarized routes to the other L2 routers. Since the L1/L2 routers
summarize the L1 routes, a flapping link in the summarized L1 address space will not cause a new set of LSPs
propagated into the L2 area.
Level2 The L2 routers learn the summarized L1 addresses and the system and network prefixes only in their
level. The L2 routes are not advertised to the L1 routers.
ISIS Timers
As we learned in the Model 1 topology OSPF configuration, we can modify the IGP timers to save resources and
improve convergence.
SPF-Wait
We can modify the SPF timer values to control SPF calculations performed per event.
config>router>isis
spf-wait spf-wait [spf-initial-wait [spf-second-wait]]
spf-wait 2s. The maximum interval between two consecutive SPF calcutions.
spf-initial-wait 50ms. The initial SPF calculation delay in milliseconds after a topology change.
spf-second-wait 100ms. The hold time, in milliseconds, between the first and second SPF calculation.
Routing in the Model 2 Subtended Ring Topology (cont)
iBGP supports VPRN route distribution

iBGP Configured only on the POC1 and POC3 routers
POC1 route reflectors reduce the number of BGP peers at POC3 routers
Next-hop tracking removes VPRN prefixes immediately if the
IGP removes the route to next hop
Module 2 |
142
iBGP in the Model 2 Topology

Internal BGP is required to support route distribution in RFC4364 IP VPNs (VPRN). Since the Model 2 topology uses
distributed VPRN services between the POC1 and POC3 routers, iBGP must be configured between these routers.
Note that the POC2 routers do not run BGP.
BGP Route Reflectors
BGP route reflectors (RR) reduce the full mesh requirement when running iBGP sessions. In this example, the
POC1 routers are configured as BGP route reflectors, and the POC3 routers act as RR clients. The grouping of
clients to RRs is called a cluster. MLS1 and MLS2 use different Cluster IDs to provide RR redundancy. This ensures
the RRs accept each others routes; by default when a RR sees its own cluster ID in a route, it will discard it.
Without route reflection, each node that participates in a VPRN service must be BGP peered with each other VPRN
node; this results in n(n-1) peering sessions. A full mesh poses scalability problems as the number of iBGP peers
grow.
Deploying RRs can reduce this number significantly. Rather than require that the POC3 routers peer with both
each other and the POC1 routers, resulting in 3 peering sessions per router, the POC3 routers need only peer with
the two MLS routers. This reduces the total number of iBGP peerings from 12 to 10.
The RR nodes accept iBGP routes from the clients, and forward (reflect) the best BGP routes to other clients as
well as other iBGP peers, except the peer from which it received the route.
Multiple RRs provide redundancy in the case one of the RRs go offline. The clients forward their routes to both
MLS routers, which propagate the routes to the other client and RR.
When you assign a Cluster ID to an SROS node, it automatically becomes an RR. From there, you configure your
peers as you would for any VPRN iBGP mesh, but without peering the two CSA nodes. We show the configuration
on the next slide.
Next Hop Tracking
SROS enables next hop tracking by default, and it cannot be disabled. This allows the router to remove prefixes
from the VPRN VRF if the IGP removes the route to the next hop. Without this feature, the routes will remain in
the VRF until the BGP hold timer, 90 seconds by default, expires.
iBGP in the Model 2 Topology
iBGP in the Model 2 Topology (cont)
A:MLS1#
A:MLS1# show
show router
router bgp
bgp neighbor
neighbor
===============================================================================
===============================================================================
BGP
BGP Neighbor
Neighbor
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Peer
Peer :: 192.0.2.2
192.0.2.2
Group
Group :: Aggregate
Aggregate
------------------------------------------------------------------------------------------------------------------------------------------------------------Peer
:: 65100
Peer
:: 00
Peer AS
AS
65100
Peer Port
Port
Peer
:: 192.0.2.2
Peer Address
Address
192.0.2.2
Local
:: 65100
Local
:: 00
Local AS
AS
65100
Local Port
Port
Local
:: 0.0.0.0
Local Address
Address
0.0.0.0
Peer
:: Internal
Peer Type
Type
Internal
State
:: Connect
Last
:: Idle
State
Connect
Last State
State
Idle
...
...
Module 2 |
143
iBGP in the Model 2 Topology (cont)

BGP Peer Tracking
The Model 2 topology enables BGP peer tracking on the VPRN peer nodes.
Without peer tracking enabled, if a BGP peer goes down or becomes unreachable, its peer routers maintain their
peering sessions for the duration of the BGP hold timer, by default 90 seconds. Enabling peer tracking allows the
router to drop the peering session immediately after the IGP removes its route to the peer address, enabling faster
convergence and failure recovery.
In the slide above, the POC3 router with the System ID 192.0.2.2 goes offline, and MLS1s IGP removes its POC3
route. Upon notification of this change, MLS1s BGP process immediately changes the peering state from
Established to Connect.
To configure peer tracking:
config>router>bgp
config>router>bgp>group
config>router>bgp>group>neighbor
enable-peer tracking
BGP peer tracking enabled

Router drops peer connection
immediately
Configure the BGP Route Reflectors

Context:
Context: config>router
config>router
Syntax:
Syntax:
autonomous-system
autonomous-system as-number
as-number
Context:
Context: config>router>bgp
config>router>bgp
group
group name
name
Context:
Context: config>router>bgp>group
config>router>bgp>group
Syntax:
Syntax:
[no]
[no] cluster
cluster cluster-id
cluster-id (0.0.0.1-255.255.255.255)
(0.0.0.1-255.255.255.255)
[no]
[no] enable-peer-tracking
enable-peer-tracking
[no]
neighbor
ip-address
[no] neighbor ip-address
[no]
[no] next-hop-self
next-hop-self {[ipv4][vpn-ipv4][ipv6][mcast-ipv4][l2-vpn]}
{[ipv4][vpn-ipv4][ipv6][mcast-ipv4][l2-vpn]}
[no]
[no] peer-as
peer-as as-number
as-number
[no]
[no] type
type {internal|external}
{internal|external}
Example:
Example: configure
configure router
router autonomous-system
autonomous-system 65100
65100
configure
configure router
router bgp
bgp group
group Aggregate
Aggregate
config>router>bgp>group$
config>router>bgp>group$ cluster
cluster 10.10.10.10
10.10.10.10
enable-peer-tracking
config>router>bgp>group$ enable-peer-tracking
config>router>bgp>group$ next-hop-self
next-hop-self
config>router>bgp>group$ peer-as
peer-as 65100
65100
config>router>bgp>group$ type
type internal
internal
config>router>bgp>group$ neighbor
neighbor 192.0.2.2
192.0.2.2
config>router>bgp>group>neighbor$
config>router>bgp>group>neighbor$ back
back
Module 2 |
144
Configure the BGP Route Reflectors

On the MLS routers, configuring the cluster ID automatically causes the routers to become Route Reflectors.
autonomous-system BGP requires an autonomous system configured on the node. Here we use private AS
numbers, from 64512 to 65534. These AS numbers should not be advertised onto the public Internet or to
other networks.
group - BGP groups provide a means to configure BGP characteristics for a number of nodes. The group name
does not have to match between members, but should be consistent for ease of management. The group
name can be up to 32 characters long.
cluster Configures the cluster ID for the RR node. The cluster ID takes the form of a 4-octet dotted decimal
number, ranging from 0.0.0.1-255.255.255.255.
You do not configure a cluster ID on the peer nodes (POC3).
enable-peer-tracking Allows the router to drop a BGP peer immediately if the IGP route to the peer address
is removed.
next-hop-self Tells the node to set its own interface as the BGP next hop for any routes it advertises to its
peers. This helps ensures that the iBGP peer can reach the next hop for the advertised route.
peer-as - Identifies the AS number for the BGP peer. If the peer AS matches the local AS number, the
peering is internal BGP. If they differ, it is an external BGP peering.
type {internal|external} Specifies BGP peering type. Though the SROS assumes the peering type by the
peer AS value, this command explicitly defines it.
neighbor Specifies the neighbors address. For iBGP, this is the neighbors system ID. The peers must have
IGP routes to the neighbors system ID for the peering to succeed.
Syntax:
Syntax:
A:MLS1#
A:MLS1# show
show router
router bgp
bgp neighbor
neighbor
===============================================================================
===============================================================================
BGP
BGP Neighbor
Neighbor
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Peer
Peer :: 192.0.2.2
192.0.2.2
Group
Group :: Aggregate
Aggregate
------------------------------------------------------------------------------------------------------------------------------------------------------------Peer
:: 65100
Peer
:: 179
Peer AS
AS
65100
Peer Port
Port
179
Peer
:: 192.0.2.2
Peer Address
Address
192.0.2.2
Local
:: 65100
Local
:: 50834
Local AS
AS
65100
Local Port
Port
50834
Local
Address
:
192.0.2.0
Local Address
: 192.0.2.0
Peer
:: Internal
Peer Type
Type
Internal
State
:: Established
Last
:: Active
State
Established
Last State
State
Active
Last
:: recvKeepAlive
Last Event
Event
recvKeepAlive
Last
:: Hold
Last Error
Error
Hold Timer
Timer Expire
Expire
Local
Family
:
IPv4
Local Family
: IPv4
Remote
:: IPv4
Remote Family
Family
IPv4
Hold
Time
:: 90
Keep
:: 30
Hold Time
90
Keep Alive
Alive
30
Active
:: 90
Active
:: 30
Active Hold
Hold Time
Time
90
Active Keep
Keep Alive
Alive
30
Cluster
:: 10.10.10.10
Cluster Id
Id
10.10.10.10
Preference
:: 170
Num
Preference
170
Num of
of Update
Update Flaps
Flaps :: 00
...
...
Module 2 |
145
View the BGP RR Status

A:NodeA# show router neighbor 192.0.2.2
Peer: Peer node system ID.
Group: - Peer group name.
Peer AS: - Local AS number for iBGP peers. Matches on all peers.
State: - Established - The BGP peering is up.
Cluster ID: - Only set on the RR routers.
View the BGP RR Status
A:MLS1#
A:MLS1# show
show router
router bgp
bgp neighbor
neighbor
===============================================================================
===============================================================================
BGP
BGP Neighbor
Neighbor
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Peer
Peer :: 192.0.2.2
192.0.2.2
Group
Group :: Aggregate
Aggregate
------------------------------------------------------------------------------------------------------------------------------------------------------------...
...
Graceful
:: Disabled
Stale
:: n/a
Graceful Restart
Restart
Disabled
Stale Routes
Routes Time
Time
n/a
Advertise
Inactive
:
Disabled
Peer
Tracking
:: Enabled
Advertise Inactive
: Disabled
Peer Tracking
Enabled
Advertise
:: None
Advertise Label
Label
None
Auth
:: n/a
Auth key
key chain
chain
n/a
Disable
:: Disabled
Peer
:: Enabled
Disable Cap
Cap Nego
Nego
Disabled
Peer Tracking
Tracking
Enabled
Auth
key
chain
:
n/a
Auth key chain
: n/a
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Neighbors
Neighbors :: 11
===============================================================================
===============================================================================
** indicates
indicates that
that the
the corresponding
corresponding row
row element
element may
may have
have been
been truncated.
truncated.
Module 2 |
146
View the BGP RR Status (cont)

A:NodeA# show router neighbor 192.0.2.2
Peer Tracking: Enabled for the peer.
View the BGP RR Status (cont)
MLS routers may have eBGP peers in external networks

Peers configured within VPRN or on the Base router context
Use export policies to determine which routes to export
An iBGP peering is configured between MLS routers to share
externally learned routes
MLS routers tag and propagate routes according to peering policies
Module 2 |
147
eBGP in the Backhaul Transport Network

eBGP is required to support routing to external control and data networks and iBGP runs between the MLS routers
to share eBGP learned routes between the two nodes.
Routing policies specify which routes we should advertise to external networks. An example is shown below:
config>router>policy-options
begin
prefix-list BGP-FILTER
prefix 198.51.100.0/27 exact
prefix 198.51.100.32/27 exact
exit
policy-statement ANNOUNCE_AGG_ROUTES_TO_EXTERNAL
entry 10
description Tag 500 routes
from
protocol static
tag 500
exit
entry 20
from protocol direct
prefix-list BGP-FILTER
exit
action accept
origin igp
exit
default-action reject
eBGP in the Backhaul Transport Network
.5 Hour
Lab Overview:
Configure BFD on MLS to CSA interfaces

Configure BFD in the IGP
Verify traffic-engineering extensions are enabled in the IGP
Verify BFD sessions using OAM tools
Module 2 |
148
Lab 5 : Configure ISIS and BFD in the Model 1 Topology

The Backhaul Transport routed domain must support 2, 3, or 4G
voice and data traffic
The routing protocols must recover quickly from link outages
Static routes may be used when the network element FIBs cannot
handle a large number of routes or routing adjacencies
Floating static routes can provide redundancy on point-to-point
links
BFD helps ensure that the CSA and MLS routers can quickly
discover and converge around a link failure
OSPF and ISIS timers may be modified to reduce SPF algorithm run
frequency on identical events
A hierarchical routed domain reduces the number of LSPs/LSAs
flooding the network when a topology change occurs
Module 2 |
149
Section Summary
LDP-Sync holds down routes on recovered links until LDP can

converge and the peers can exchange labels associated with
routes using that link
LDP-Sync requires a timer configured on the router interfaces
iBGP route reflectors reduce the number of BGP peerings required
to support distributed VPRN services
BGP peer tracking allows the routers to remove BGP peers
immediately upon detection rather than waiting for the hold time
to expire
BGP next-hop tracking allows the router to remove routes from
the VRF immediately after the IGP removes the route to the next
hop
Module 2 |
150
The MLS routers maintain eBGP sessions with external networks

and network control elements
The MLS routers run iBGP sessions between themselves to share
external routes
Module 2 |
151

Section 6 MPLS in the Backhaul Transport Network
Section Objectives
Describe the Model 1 networks use of LDP tunnels between the

CSA routers and the MLS routers
Explain the Model 2 networks use of RSVP LSPs between the CSA
and POC routers
Regional LSPs within areas (CSA-POC3 and POC3-POC1) to
provide scalability, stability, and faster recovery
Secondary, standby paths for redundancy
Fast reroute support for fast failover
Admin groups to ensure disjointed primary and secondary
paths
Module 2 |
154
MPLS turns the connectionless, routed Backhaul Transport into a

virtual connection-oriented, multi-service network
___ MPLS supports traffic engineering and fast recovery of the end-toend transport path
___ It supports a variety of physical network and access topologies
___ For ease of network management, it allows abstraction between
the physical layer, the transport infrastructure, and the services
layers
___ It supports virtualized service overlays transporting multiple
service types for multiple customers
___ It supports standardized ATM traffic transport including idle cell
suppression and traffic classification
___ MPLS can adapt to changing network states and self-optimize to
the best available path once a failure is repaired
Module 2 |
155
Why MPLS in the Backhaul Transport?

MPLS turns a connectionless, routed network into a virtual connection-oriented, multi-service network. It allows
for traffic engineering and sub-50ms restoration of the paths carrying the service traffic from access interface A to
access interface B.
MPLS supports traffic engineering and fast recovery of the end-to-end transport path.
CSPF to build the traffic engineering database (TED) from which the LSRs can choose the best path based on
constraints defined in the LSPs configuration
Traffic engineering to support Shared Risk Link Groups, Administrative Groups, and Fast Reroute
Hot standby LSP paths
Supports a variety of physical network and access topologies while providing fast recovery and hot standby
redundancy
MPLS can run over Ethernet, Ethernet over SONET, TDM, Microwave, and Wireless links
MPLS-based services carry ATM, TDM, and Ethernet traffic end-to-end over a common transport
Allows abstraction between the physical layer (Ethernet, SONET/SDH, microwave, wireless), the transport
infrastructure (IGP, MPLS), and the services layers (VPWS, VPLS, VPRN) for ease of management
Only troubleshoot to the lowest level effected by the outage, i.e, if the service tunnel is up, then
troubleshoot the service
OAM tools are available for the physical, transport, and service layers
It supports overlays of virtualized services transporting multiple service types for multiple customers
MSP or BTP
ATM, TDM, DSL, Ethernet, or wireless access technologies
It supports standard ATM traffic transport including idle cell suppression and traffic classification
MPLS can adapt to changing network states and self-optimize to the best available path once a failure is repaired
Why MPLS in the Backhaul Transport?
The Backhaul Transport may use LDP or RSVP LSPs

Example 1: LDP in the Model 1 Topology for compatibility
Example 2: RSVP in the Model 2 Topology for path redundancy
and traffic engineering
RSVP in Model 2
Module 2 |
156
MPLS in the Mobile Backhaul Transport Network

MPLS is used to provide the service tunnels for L2 and L3 services between the CSA and POC routers.
LDP in Model 1
The Model 1 topology uses LDP signaled LSPs between the CSA and MLS routers. LDP LSPs are simple to configure
and dynamic in nature, following the IGP best path to the target Forwarding Equivalence Class (FEC). To ensure
sub-second recovery, BFD and the floating static routes ensures rapid failure detection and recovery on the point
to point links.
RSVP in Model 2
The complexity of the Model 2 ring topology merits RSVP signaled LSPs. CSPF and traffic engineering extensions to
the IGP provide the network engineer a great deal of control when designing the traffic paths through the
network.
RSVP features implemented in the Model 2 architecture are:
Standby secondary paths
Admin groups to support disjointed primary and standby paths
Fast reroute for sub-50ms recovery
Regional LSPs to support CSPF (stitched together for edge to edge services, see Module 3)
MPLS in the Mobile Backhaul Transport Network
The LDP tunnels following the route to the target node

LDP follows the IGP route, so the tunnel follows the active static
route to and from the target MLS router
LDP must be enabled on the CSA-to-MLS and MLS-to-MLS
interfaces
Module 2 |
157
Example 1: LDP in Model 1

Though RSVP could be used, this model uses LDP signaled LSPs. The topology is relatively simple, with redundant
point-to-point links connecting the nodes, and BFD ensures the routers recognize a link failure within 1500ms.
Note that RSVP could be used, and could replace LDP in future deployments.
LDP Interfaces
Enabled on the CSA-to-MLS and MLS-to-MLS router interfaces is LDP. The routers form link-level LDP adjacencies.
Since LDP tunnels follow the IGP best path to the target prefix, the LDP tunnels follow the active static route to
the target node. In most circumstances, this path is symmetric in each direction, as BFD ensures the routers take
down the static route if a link failure causes the BFD session to drop.
LDP Tunnels
These LDP sessions support redundant LDP Service Distribution Paths (SDPs). Since SDPs run between the CSAs and
MLS routers, the nodes also need Targeted LDP sessions. Once built, the SDPs cause the routers to establish T-LDP
sessions automatically, but optionally you may choose to manually enable the targeted sessions.
Example 1: LDP in Model 1
RSVP LSPs used for traffic engineering and redundancy

Disjoined, redundant paths and tunnels between CSA and POC3 and
POC3 and MLS routers
Secondary standby paths and FRR for LSP redundancy
Module 2 |
158
Example 2: RSVP in Model 2

Model 2 takes advantage of the MPLS RSVP traffic engineering and fast recovery features supported by RSVP.
Dividing the network into regions reduces the number of LSPs needed to move traffic end-to-end. Advantages of
this design include:
Scalability The POC1 routers only terminate LSPs from a few POC3 routers, rather than all the CSA routers.
This reduces the number of RSVP sessions each router must maintain.
Stability By reducing the number of RSVP sessions, we also reduce the number of RSVP messages flooded in
the network.
Faster switchover to the standby path The RSVP messages traverse fewer hops, allowing the head-end to
quickly recognize a downstream link or node failure and move traffic from a bypass tunnel to the standby
path.
Access Region
The CSA and POC3 routers are part of this region. Each CSA route has an LSP terminated on each of the two POC3
routers. Since no services exists between the CSA routers, no LSPs are defined here.
Provisioned on each LSP is a hot-standby path. To ensure disjointed primary and secondary paths, each path is
assign to an administrative group associated with the preferred links for that path.
Fast reroute facility provides N:1, sub 50ms path protection.
Aggregation Region
POC1, 2, and 3 all belong to the aggregation region. The POC1 and 3 routers are provisioned as LERs, while the
POC2 routers act only as LSRs.
LSPs carry traffic between the POC1 and POC3 routers. Each is protected by disjointed, hot-standby paths and
fast reroute facility.
Example 2: RSVP in Model 2
MPLS Admin Groups are provisioned to ensure disjoined paths

Paths associated with the target PE, upper and lower
Admin group UPPER for primary path to upper PE (POC3-1)
Admin group LOWER for primary path to lower PE (POC3-2)
A:CSA1>config>router>mpls#
A:CSA1>config>router>mpls# info
info
--------------------------------------------------------------------admin-group
admin-group "LOWER"
"LOWER" 22
admin-group
admin-group "UPPER"
"UPPER" 11
...
...
lsp
lsp "CSA1
"CSA1 to
to POC3-1
POC3-1
to
to 192.0.2.0
192.0.2.0
primary
primary "POC3-1-1"
"POC3-1-1"
include
include "UPPER"
"UPPER"
exit
exit
secondary
secondary "POC3-1-2
"POC3-1-2
standby
standby
include
include "LOWER"
"LOWER"
exit
exit
no
no shutdown
shutdown
exit
exit
Module 2 |
159
LSPs in the Access Ring

As shown above, the CSA routers have two paths to each POC3 router. Provisioned are UPPER and LOWER admin
groups, and each path includes one or the other.
CSA Path to upper POC3 router
The CSA to POC3-1 LSP follows the UPPER path on the primary LSP path. Interfaces facing POC3-1 are member of
the UPPER admin group. When the head end sets up the LSP, it refers to its traffic engineering database (TED)
and chooses the upper links for the primary path.
Interfaces facing toward POC3-2 are members of the LOWER path. When the head end signals the secondary path,
it does so over the LOWER links.
The links between the two CSA routers must be in both the UPPER and LOWER admin groups.
CSA Path to lower POC3 router
The CSA to POC3-2 LSP follows the LOWER path on the primary LSP path, and the UPPER path for the secondary
path. The configuration for the lower POC3 router LSP is as follows:
A:CSA1>config>router>mpls# info
lsp CSA1 to POC3-2
to 192.0.2.1
primary POC3-2-1
include LOWER
exit
secondary POC3-2-2
standby
include UPPER
exit
no shutdown
Paths from POC3 to CSA routers
The POC3 router return LSPs will ensure symmetric return paths, UPPER to UPPER and LOWER to LOWER.
LSPs in the Access Ring
MPLS Admin Groups provisioned to ensure disjoined paths, as

inaccess ring
POC1-1 to POC1-2 LSP has no secondary path (would be same
as bypass)
POC3-POC3 LSPs use manual bypass tunnels to keep bypass on
aggregate ring
A:POC3-1>config>router>mpls#
A:POC3-1>config>router>mpls# info
info
--------------------------------------------------------------------...
...
path
path "bypass_POC3-2
"bypass_POC3-2
hop
hop 11 192.0.2.4
192.0.2.4 strict
strict
...
...
hop
hop 55 192.0.2.3
192.0.2.3 strict
strict
no
no shutdown
shutdown
...
...
lsp
lsp "bypass_POC3-2"
"bypass_POC3-2" bypass-only
bypass-only
to
to 192.0.2.3
192.0.2.3
primary
primary "bypass_POC3-2
"bypass_POC3-2
exit
exit
no
no shutdown
shutdown
exit
exit
Module 2 |
160
LSPs in the Aggregation Ring

As in the access ring, each LSP has a primary and secondary disjoined path. LSPs connect the POC3 routers to
each of the POC1 routers, upper and lower.
The LSPs terminating on the upper POC1 and POC3 routers follow the UPPER links on the primary path, and the
LOWER links on the standby secondary path. LSPs to the lower routers follow the LOWER path, then the UPPER.
LSPs between POC1 routers
Each POC1 to POC1 router LSP includes just a primary path. Since fast reroute will choose the only possible
alternative path to the target router, there is no need for a standby path. If the traffic cant flow directly, it will
go around the ring, i.e., POC1-1 to POC2-1, to POC3-1, and so forth.
LSPs between POC3 routers
Potentially, the POC3 routers could, if allowed, dynamically build bypass tunnels through the access ring, forcing
aggregation ring traffic onto the lower bandwidth access links. To address this potential problem, the POC3
routers use strict hop, manual bypass tunnels to protect the POC3-POC3 LSPs.
The manual bypass tunnels are provisioned on the head end router, and include the directly connected POC2
router as the next hop. Additionally, the manual bypass tunnels specify each hop between the head-end and tailend of the protected LSP.
(notes continue on the next page...)
LSPs in the Aggregation Ring
Configure the POC3 Manual Bypass Tunnels
Context:
Context: config>router>mpls>path
config>router>mpls>path
Syntax:
Syntax: hop
hop <hop-index>
<hop-index> <ip-address>
<ip-address> {strict|loose}
{strict|loose}
[no]
shutdown
[no] shutdown
Context:
Context: config>router>mpls>lsp
config>router>mpls>lsp
Syntax:
Syntax: [no]
[no] to
to <ip-address>
<ip-address>
[no]
primary
[no] primary <path-name>
<path-name>
[no]
shutdown
[no] shutdown
Example:
Example: configure
configure router
router mpls
mpls
config>router>mpls#
config>router>mpls# path
path bypass_POC_3-2
bypass_POC_3-2
config>router>mpls>path$
config>router>mpls>path$ hop
hop 11 192.0.2.4
192.0.2.4 strict
strict
hop 22 192.0.2.0
192.0.2.0 strict
strict
hop 33 192.0.2.1
192.0.2.1 strict
strict
hop 44 192.0.2.5
192.0.2.5 strict
strict
hop 55 192.0.2.3
192.0.2.3 strict
strict
config>router>mpls>path$ no
no shutdown
shutdown
config>router>mpls>path$ back
back
config>router>mpls#
config>router>mpls# lsp
lsp bypass_POC3-2
bypass_POC3-2 bypass-only
bypass-only
config>router>mpls>lsp$
config>router>mpls>lsp$ to
to 192.0.2.3
192.0.2.3
config>router>mpls>lsp$
config>router>mpls>lsp$ primary
primary bypass_POC3-2
bypass_POC3-2
config>router>mpls>lsp>primary$
config>router>mpls>lsp>primary$ exit
exit
no
Alcatel-Lucent IP/MPLSconfig>router>mpls>lsp#
Mobile
Backhaul Transport v1.0
Module 2 | 161
config>router>mpls>lsp#
no shutdown
shutdown
Configure the POC3 Manual Bypass Tunnels

By default, the head end will choose a manual bypass tunnel over a dynamic tunnel.
An LSP must be configured as bypass-only to be considered as a potential manual bypass tunnel.
The protected LSP must be configured with CSPF and fast-reroute facility enabled.
The manual bypass tunnel must merge back to the protected LSP Path.
The manual bypass tunnel path must avoid the next hop router.
If the head end has more than one available manual bypass tunnel available for the protected LSP, it chooses the
one with the lowest path cost. If two or more have the same path cost, it chooses the first available.
Context:
Context: config>router>mpls
config>router>mpls
Syntax:
Syntax: path
path <path-name>
<path-name>
lsp
lsp <lsp-name>
<lsp-name> [bypass-only]
[bypass-only]
POC3-1 to POC3-2 LSPs

The manual bypass tunnel
path lists each hop explicitly
Head-end will only select
manual bypass if it avoids
the next hop node and
merges to the original LSP
path
Dynamic bypass may be
disabled
Module 2 |
162
Choosing the Manual Bypass Tunnel

When a router is configured with manual bypass LSPs, and an LSP is configured for FRR facility protection, the
head end will first check for a manual bypass tunnel that both merges on the original LSP path and avoids the next
hop LSR. If it finds one, it will select the manual tunnel for the protected LSP.
If the head end finds no suitable manual bypass tunnel for the LSP, it will signal a dynamic bypass tunnel instead.
You may provision the router to only use manual bypass tunnels.
config>router>mpls# dynamic-bypass [disable|enable]
Choosing to disable dynamic-bypass means the head end can only select manual bypass tunnels. Any LSPs for
which a manual bypass LSP does not exist will not be FRR protected.
Choosing the Manual Bypass Tunnel
LSP between POC3-1 and POC3-2 link failure example

1 BFD detects the link failure between POC3-1 and POC3-2
2 POC3-1 moves the LSPs traffic to the manual bypass tunnel,
POC3-1 - POC3-2
Standard LSP timers apply, POC3-1 will try to move back to primary
path every 30 seconds using Make Before Break
Module 2 |
163
Link Failure Example, Model 2

This slide illustrates a manual bypass tunnel used to reroute traffic from a link failure between POC3-1 and POC32.
The manual bypass must be configured on the node acting as the PLR. In this example, POC3-1 is the PLR.
An LSP is up between POC3-1 and POC3-2. POC3-1 chooses as the primary path the IGP best path to POC3-2.
The manual bypass LSP protecting the POC3-1 and POC3-2 LSP follows the strict path from POC3-1 through POC2-1,
MLS1, MLS2, POC2-2 and POC3-2.
Recovery procedure
1. POC3-1 BFD session to POC3-2 drops as a result of a link failure between the two nodes.
2. POC3-1 moves LSP POC3-1_POC3-2 traffic to the manual bypass tunnel. The bypass routes traffic through POC21 and around the ring through MLS2 toward POC3-2.
POC3-1 will try, according to its retry attempt and timer settings, to re-signal the primary path.
Link Failure Example, Manual Bypass Tunnel in Model 2
A:POC3-1#
A:POC3-1# show
show router
router mpls
mpls bypass-tunnel
bypass-tunnel protected-lsp
protected-lsp
===============================================================================
===============================================================================
MPLS
MPLS Bypass
Bypass Tunnels
Tunnels
===============================================================================
===============================================================================
Legend
dd -- Dynamic
pp -- P2mp
Legend :: mm -- Manual
Manual
Dynamic
P2mp
===============================================================================
===============================================================================
To
State
Out
Reserved
To
State Out
Out I/F
I/F
Out Label
Label
Reserved Protected
Protected Type
Type
BW
BW (Kbps)
(Kbps) LSP
LSP Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.3
Up
1/2/7
131069
00
11
mm
192.0.2.3
Up
1/2/7
131069
Protected
LSPs
Protected LSPs POC3-1_POC3-2::POC3-1_POC3-2
From:
To:
POC3-1_POC3-2::POC3-1_POC3-2
From: 192.0.2.2
192.0.2.2
To: 192.0.2.3
192.0.2.3
------------------------------------------------------------------------------------------------------------------------------------------------------------Bypass
Bypass Tunnels
Tunnels :: 11
===============================================================================
===============================================================================
The manual bypass tunnel terminating on POC3-2 via POC2-1 protects

LSP POC3-1_POC3-2
Module 2 |
164
View the Manual Bypass Tunnel Status

A:NodeA# show router router mpls bypass-tunnel protected-lsp
Type: m=Manual Bypass Tunnel.
Protected LSPs LSP POC3-1_POC3-2::path POC3-1_POC3-2
View the Manual Bypass Tunnel Status
.5 Hour
Lab Objectives:
Create MPLS Admin Groups and assign the inteface to the groups
Create RSVP LSPs with primary and secondary standby paths including and
excluding specific admin groups
Verify the LSPs using OAM commands
Module 2 |
165
Lab 6 : Configure RSVP LSPs in Model 1 Topology
Section Summary
The Model 1 LDP tunnels follow the static route paths, preferred
and secondary
The Model 2 topology uses regional LSPs to reduce the number of
RSVP sessions and flooded messages and quicken recovery
Admin-group assignments help the head-end router choose
disjoined paths for each LSPs primary and secondary paths
Fast reroute facility and manual bypass tunnels provide
predictable behavior bypass tunnel behavior
Module 2 |
166
In this Module, we learned:

The Backhaul Network uses both TDM and Ethernet access ports
for Backhaul service traffic
TDM access ports can carry ATM IMA or ML-PPP bundled traffic
SROS requires that you build out the SONET/SDH containers to
gain access to the individual DSx or Ex links
Nodes indicate their desire to implement ML-PPP during the PPP
LCP negotiations
A node may use physical, packet-based, or a combination of both
timing techniques for synchronizing TDM and air-interface circuits
BITS, GPS, line timing and SyncE are physical synchronization
techniques
IEEE 1588v2/PTP v2 and ACR are packet-based synchronization
techniques.
Module 2 |
167
Module Summary
SROS routers can choose their timing references by reference

order and quality level
Nodes using SyncE timing synchronize off the received Ethernet
bit stream
SyncE uses SSM messages carried by the ESMC to provide clock
traceability and loop detection
Nodes using IEEE 1588v2/PTPv2 synchronize off the received
timestamps
SROS supports IEEE 1588v2 two-way, one-step synchronization
A PTP timed node can only have a single master reference
IEEE 1588v2 profiles determine the BMCA and other PTP variables
Module 2 |
168
The IEEE 1588v2 BMCA uses several characteristics when choosing

the best master:
Priority
Clock class
Clock accuracy
Clock identity
The ITU-T G.8265.1 Telecom profile allows for an ABMCA that
uses quality level
LDP-Sync in the Model 1 network causes the routers to hold down
routes until LDP has converged after a network outage
Hierarchical routing controls route propagation and limits FIB size
iBGP route reflectors reduce the iBGP full mesh requirement
Module 2 |
169
The Model 2 topology uses regional RSVP LSPs to reduce number

of RSVP sessions and messages and quicken recovery.
Admin-group assignments help the head-end router choose
disjoined paths for each LSPs primary and secondary paths
Fast reroute facility and manual bypass tunnels provide
predictable bypass tunnel behavior
Module 2 |
170
a) null
b) bcp-null
c) ipcp
d) dot1q
2. Which three characteristics influence a ports MTU size setting? (Choose
three.)
a) Frame Check Sequence
b) Layer 3 payload size
c) Layer 2 header size
d) Pseudowire header
Module 2 |
171
Answers:
1. a, d
2. b, c, d
1. SROS routers support which two encapsulation types on Ethernet access

ports? (Choose two.)
a) The port mode

b) The port MTU size
c) The port speed
d) The port duplex setting
4. You want the router to wait a period of time before reporting to
the routing process that a port has recovered. What feature
would you configure?
a)
b)
c)
d)
Turn up BFD on the port

Enable auto-negotiate on the port
Set a port up hold-time
Set an LDP-Sync timer on the port
Module 2 |
172
Answers:
3. c, d
4. c
3. Ethernet auto-negotiate determines what two Ethernet port

characteristics? (Choose two.)
a) The encapsulation type

b) The clock source
c) The ports framing
d) The path payload
6. A SONET VT 1.5 can carry how many DS1 circuits?
a) 1
b) 2
c) 4
d) 28
Module 2 |
173
Answers:
5. a
6. a
5. On a DS1 channel group, what characteristic determines the type

of payload the link will transport?
a) Link NCP negotiation

b) Link LCP negotiation
c) Bundle LCP negotiation
d) Bundle NCP negotiation
8. Choose the order in which you would configure the router to
support IMA or ML-PPP. Fill in the blanks with steps 1 through 4,
in the order they must be performed.
___
___
___
___
Assign the bundle member DS1/E1s

Build out the virtual containers/virtual tributaries
Provision the channel groups
Create the multi-link bundles
Module 2 |
174
Answers:
7. b
8. 4, 1, 2, 3
7. A node signals its desire to implement ML-PPP during what phase

of the circuits initialization?
a) SyncE
b) IEEE 1588v2
c) BITS
d) ACR
10.Which is an important consideration when designing a timing
distribution scheme?
a) A node should synchronize with multiple master timing sources
for redundancy
b) Low bandwidth links most accurately distribute timing signals
c) Timing references should be traceable to a single source
d) Physical synchronization methods are best for providing phase
and ToD synchronization
Module 2 |
175
Answers:
9. a, c
10. c
9. Which two synchronization techniques sets the nodes SEC/EEC by

the received bit stream? (Choose two.)
a) QL-STU
b) QL-DNU
c) QL-UNK
d) QL-EEC1
12.According to the ITU-T G.813 recommendation, an SEC must meet
which three requirements? (Choose three.)
a) Maintain holdover according to prescribed limits
b) Inform the master that its clock is out of sync
c) Support multiple reference inputs
d) Provide a slave traceable to a PRC
Module 2 |
176
Answers:
11. d
12. a, c, d
11.A SyncE references SEC goes into holdover. On SDH mode, what
SSM quality level will it advertise to its peers?
a) QL-PRC
b) QL-SSU-A
c) QL-UNC
d) QL-EEC1
14.An SROS node receives QL-STU on its BITS port. You want it to
send QL-ST3E to its slave clocks. In what syntax will you configure
this?
a) configure system ssm override
b) configure system sync-if-timing
c) configure port <port number> ethernet ssm
d) configure port <port number> tdm
Module 2 |
177
Answers:
13. a, b, d
14. b
13.An SROS node configured for SyncE SDH mode might receive which
three advertised quality levels? (Choose three.)
a) Enable SyncE on the ports

b) Set the Ethernet ports advertised quality level
c) Set the Ethernet ports SSM code type
d) Set the timing references SSM code type
16.Which statement is true concerning the SROS IEEE 1588v2/PTPv2
implementation?
a) SROS supports phase and ToD synchronization
b) SROS 7750 SR routers can be boundary clocks
c) SROS uses a two-way, one-step clock mode
d) SROS nodes can set the slaves clock profile
Module 2 |
178
Answers:
15. C
16. c
15.You want an SR-7 to send and accept SSM SONET codes. Which
configuration step must you perform on the router to implement
this?
a) Announce
b) Sync
c) Delay_Req(uest)
d) Delay_Resp(onse)
18.An IEEE 1588v2 boundary clock has which three characteristics?
(Choose three.)
a) It can only have one slave port per node
b) It can be a master to multiple slaves
c) It can maintain standby states with alternate clocks
d) It can account for PTP packet residence delay
Module 2 |
179
Answers:
17. b, c, d
18. a, b, c
17.The SROS IEEE 1588v2/PTPv2 slave implementation uses which

three messages contents to calculate the clock offset? (Choose
three.)
19. For what reason does the Model 1 network run BFD on the CSA-MLS static
routes?
a) To allow the routers to choose the best available static route
b) On failure recovery, to hold down the routes until BFD converges
c) To recognize a possible link failure in the MEN
d) To support pseudowire redundancy
20. Which three are characteristics of the Model 2 networks ISIS
implementation? (Choose three.)
a) Route summarization reduces the effect flapping access links have on
the Level 2 area FIBs
b) Allows a hierarchical design that limits route propagation between
multiple areas
c) Eliminates the need for an IGP in the access ring, allowing for static
routes between the CSA and POC3 routers
d) Reduces the CSA router FIB sizes by delivering a default route to
represent external networks to the Level 1 area
Module 2 |
180
Answers:
19. c
20. a, b, d
21. What part of the Model 2 MPLS configuration ensures the primary and
secondary LSP paths use disjoined links?
a) Interfaces assigned to Shared Risk Link Groups (SRLG)
b) Admin-groups in the LSP path configurations
c) Fast-reroute one-to-one LSP protection
d) CSPF enabled in the LSPs
22. You want a router to use a manual bypass tunnel to protect an LSP. What
must you do to ensure the router chooses the manual bypass over a
dynamic bypass tunnel?
a) Build a manual bypass tunnel on the head end router terminating on the
egress LER
b) Enable manual bypass-only in the protected LSPs primary path
configuration
c) Build a manual bypass LSP and path on each PLR, terminating on the
egress LER
d) Disable dynamic bypass tunnels on each potential PLR
Module 2 |
181
Answers:
21. b
22. a
TTP36002 Edition 1

Transport
Module 3 Implementing Mobile Backhaul Transport Services

Explain layer 2 and 3 VPN services used in the Backhaul transport
Distributed VPWS services
Local and distributed VPRN services
Local VPLS services
Resiliency options
Implement the Backhaul Transport layer 2 and 3 services
VPWS from CSA to MLS routers
Local VPLS on MLS routers
Local VPRN on MLS routers
Pseudowire redundancy
VRRP on NC-facing interfaces
Module 3 |
Module Objectives
Module 3 Implementing Mobile

Backhaul Transport Services
Section 1 Mobile Backhaul Service Fundamentals
Section Objectives
Review SAP and SDP characteristics

Determine the type of service required to transport 2G, 3G, or 4G
traffic
Module 3 |
Review the SROS service components: Customer, Service, SAP,

SDP
Module 3 |
Service Components
The Alcatel-Lucent Router is based on the service model where service edge routers are deployed at the provider
edge. Services are provisioned on the router and transported across an IP and/or IP/MPLS provider core network in
encapsulation tunnels created using Generic Router Encapsulation (GRE) or MPLS Label Switched Paths (LSPs).
The service model uses logical service entities to construct a service. The logical service entities are designed to
provide a uniform, service-centric configuration, management, and billing model for service provisioning.
The Service model is based on the following components:
Subscribers
SAP
Customer
Service
SDP
Service Tunnels
Service Components
SAP
SAPIdentifiers
Identifiers
Physical
PhysicalEthernet
Ethernetport,
port,SONET/SDH
SONET/SDHport
portor
orchannel,
channel,TDM
TDM
port
or
channel
port or channel
Encapsulation
Encapsulationidentifier
identifier(ID)
(ID) (eg.
(eg.VLAN
VLANID,
ID,Q-tag)
Q-tag)
Can
only
be
created
on
Access
interfaces
Can only be created on Access interfaces
Module 3 |
Service Access Point (SAP)

A SAP is a logical entity that serves as the customers point of access into a service. Each subscriber service is
configured with at least one SAP. A SAP can only be configured on a port that has been configured as an access
port. The default configuration for a port is network, which means that you may need to reconfigure a port before
you can configure a SAP on it. SAPs for IES and VPRN services are configured on IP interfaces. A SAP is the
subscriber-side service entry and exit point for a service.
SAP Encapsulation Types and Identifiers
A SAP is local to the router and is uniquely identified by:
Physical Ethernet port or Packet-Over-SONET/SDH (POS) port and channel
Encapsulation identifier (ID)
The encapsulation type is an access property of a service Ethernet port or SONET/SDH or TDM channel. The
appropriate encapsulation type for the port or channel depends on the requirements to support multiple services
on a single port/channel on the associated SAP and the capabilities of the downstream equipment connected to
the port/channel. For example, a port can be tagged with IEEE 802.1Q (referred to as dot1q) encapsulation in
which each individual tag can be identified with a service. A SAP is created on a given port or channel by
identifying the service with a specific encapsulation ID.
Depending on the encapsulation used, a physical port or POS channel can have more than one SAP associated with
it. Using dot1q encapsulation or POS channels, the router can support multiple services for a customer or services
for multiple customers.
Service Access Point (SAP)
AAservice
servicedistribution
distributionpoint
point(SDP)
(SDP)acts
actsas
asaalogical
logicalway
wayto
todirect
directtraffic
trafficfrom
fromone
one
router
to
another.
router to another.
SDPs
SDPsare
arelocally
locallyunique;
unique;the
thesame
sameSDP
SDPID
IDcan
canbe
beused
usedon
onanother
anotherrouter
router
SDPs
use
the
System
IP
address
to
identify
far
end
destinations
SDPs use the System IP address to identify far end destinations
SDP
SDPisisnot
notspecific
specificto
toone
oneservice;
service;many
manyservices
servicescan
canuse
usethe
thesame
sameSDP
SDP
All
Allservices
servicesbound
boundto
toan
anSDP
SDPuse
usethe
thesame
sameencapsulation
encapsulationas
asdefined
definedby
bythat
thatSDP
SDP
(GRE
or
MPLS)
(GRE or MPLS)
Operations
Operationson
onan
anSDP
SDPwill
willaffect
affectall
allservices
servicesthat
thatare
arebound
boundto
tothat
thatSDP
SDP
Module 3 |
Service Distribution Point (SDP) Characteristics

A service distribution point (SDP) acts in a logical way to direct traffic from one router to another through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end router which directs packets to the
correct service egress SAPs on that device. A distributed service consists of a configuration with at least one SAP
on a local node, one SAP on a remote node, and an SDP binding the service to the service tunnel.
An SDP has the following characteristics:
An SDP is locally unique to a participating router. The same SDP ID can appear on other routers.
An SDP uses the system IP address to identify the far-end edge router.
An SDP is not specific to any one service or any type of service. Once an SDP is created, services are bound to
the SDP. An SDP can also have more than one service type associated with it.
All services mapped to an SDP use the same transport encapsulation type defined for the SDP (either GRE or
MPLS).
An SDP is a management entity. Even though the SDP configuration and the services carried within are
independent, they are related objects. Operations on the SDP affect all the services associated with the SDP.
For example, the operational and administrative state of an SDP controls the state of services bound to the
SDP.
An SDP from the local device to a far-end device requires a return path SDP from the far-end device back to the
local device. Each device must have an SDP defined for every remote router to which it wants to provide service.
SDPs must be created first, before a distributed service can be configured.
Service Distribution Point (SDP) Characteristics
SDPs tie the control plane service label signaling (T-LDP) to the
transport tunnels (LDP/RSVP or GRE)
In order to direct a service to use an SDP for distribution, the
service is joined to the SDP using a spoke-sdp or a mesh-sdp.
VPLS is the only service that allows the use of a mesh-sdp.
Spoke-sdp is used in all other cases where a distributed
service is required.
A service-label is not signaled until the service is bound to an SDP
using spoke or mesh
The transport may be either RSVP-TE with FRR or LDP
The term pseudowire is often used synonymously with spoke- or
mesh-sdp.
Module 3 |
All rights reserved [year] Alcatel-Lucent
Using an SDP within a Service

When an SDP is bound to a service, it is bound as either a spoke SDP or a mesh SDP. The type of SDP indicates how
flooded traffic is transmitted.
Spoke-SDP
A spoke SDP is treated like the equivalent of a traditional bridge port where flooded traffic received on the
spoke SDP is replicated on all other ports (other spoke and mesh SDPs or SAPs) and not transmitted on the port
it was received.
Mesh-SDP
All mesh SDPs bound to a service are logically treated like a single bridge port for flooded traffic where flooded
traffic received on any mesh SDP on the service is replicated to other ports (spoke SDPs and SAPs) and not
transmitted on any mesh SDPs.
Using an SDP within a Service
Module 3 |
Transport Tunnel
A Transport tunnel is used by an SDP to direct traffic from one router to another.
Multi-node VPWS and VPLS traffic is transported using uni-directional service tunnels. Service tunnels originate on
an SDP on one node and terminate at a destination node. The destination node directs packets to the correct
service egress interfaces on that device. Service tunnels can be configured to use Generic Router Encapsulation
(GRE) or MPLS Label Switched Paths (LSPs). Services that originate and terminate on the same node do not require
service tunnels or SDPs
Logical Service Level View
Service Connectivity by Technology
GSM
UMTS
CDMA 1x Voice
BS-BS
IP/Ethernet
(ePipe/VPLS
/VPRN/IES)
X
X
CDMA 1x Data
LTE
Connectivity and technology determine the type of service used

between the Base Station/NodeB and the Network Controller
TDM, ATM, and IP Inter-working VPWS for legacy 2G and 3G services
Ethernet VPWS/VPLS/VPRN or IES for Ethernet connected BS,
NodeB, and eNodeB
Module 3 |
10
Service Connectivity by Technology

In both the Hub and Spoke and Subtended Ring topologies, the type of Base Station, NodeB, and wireless
technology determine the service deployed. Additionally, the service provider type, BTP or MSP, also influences
the services used to carry traffic through the transport network.
TDM Base Stations
GSM base stations may use DS1 or E1 links to carry traffic to the CSA router. These could either be individual
links, or bundles. In the case the BS uses individual links, a cPipe services may be employed to carry traffic from
the CSA to the MLS routers. Where MP bundled links are deployed, a iPipe may be used. Ethernet-capable BS use
ePipe services, terminated either at a POC3 or MLS router.
TDM NodeB
CDMA NodeBs use MP-bundled DS1s or E1s to carry traffic to the CSA or directly to the NodeB. Where terminated
on the CSA, an iPipe provides the transport. Where terminated on the MLS directly, an IES or VPRN provides the
MTSO Layer 3 interface. Ethernet-capable NodeBs use ePipe services.
ATM NodeB
An ATM NodeB uses IMA bundles to carry ATM traffic to the CSA. The CSA could transport this traffic via an aPipe
or an iPipe service. Ethernet capable base stations use ePipe services.
Ethernet BTS, NodeB, or eNodeB
The network could use any Ethernet service, L2 or L3, depending on the design.
In this course, we use ePipes to carry BS traffic to the downstream L3 services. However, the CSAs could
terminate VPLS, VPRN, or IES, depending on the customers needs.
Wireless
Technology
Connectivity BS/NodeB to Network Controller

(NC)
Transport
TDM
IP/Ethernet
ATM
type
(cPipe/
(ePipe/VPLS/
(aPipe)
iPipe)
VPRN/IES)
Section Summary
In this section, we:
Reviewed SAP and SDP characteristics

Determined the service types required to transport 2G, 3G, or 4G
traffic
Module 3 |
11
Reviewed the SROS service components: Customer, Service, SAP,

SDP

Section 2 Model 1 Detailed Configuration 3G Voice and Data

Review the Model 1 3G Ethernet voice, data, and control traffic
paths and services
Provision the 3G Ethernet voice traffic distributed ePipe services
Configure the 3G Ethernet voice traffic outer VPLS
Provision the 3G Ethernet voice traffic VPRN service
Configure the 3G Ethernet voice traffic inner VPLS
Explore pseudowire redundancy as deployed in the Model 1 and 2
distributed VPWS
Configure PW redundancy in an ePipe service
Create Cross Connect Aggregation Groups (CCAG) for L2 and L3
service virtual Ethernet cross connects
Configure VRRP on NC element facing interfaces
Evaluate management VPLS for spanning tree in inner VPLS
services
Module 3 |
14
Section Objectives
Model 1 - Ethernet Backhaul (EBH) - ePipes

3G voice, data and OAM ePipes terminate into MLS VPLSs
VPLS-VPRN cross-connect forwards traffic toward NC elements
Module 3 |
15

This section explores the various services and service components the Model 1 network employs to deliver 3G voice
traffic to the NC elements.
Though we only follow the service configuration for voice traffic, data and OAM traffic service follow a similar
model.
For each service type, the network incorporates a separate set of ePipe, VPLS, and VPRN services.
We call the CSA-facing MLS VPLS the outer VPLS services. Notice we have added another set of VPLS services on
the NC side of the VPRN; we call this the inner VPLS. In some instances, the inner VPLS distributes traffic to the
NC elements. This depends on the customers needs.
In the following pages, we follow the service configuration in phases:
Phase 1 We build the distributed ePipes and explore pseudowire redundancy in detail
Phase 2 We build the outer VPLS and incorporate CCAGs in the configuration
Phase 3 We build the VPRN, employing VRRP for NC element L3 gateway redundancy
Phase 4- We build the inner VPLS, and explore m-VPLS for breaking L2 loops
CSA-MLS ePipes for 3G 1x CDMA NodeBs

PW redundancy on the CSAs
Distributed ePipes terminated into outer VPLS
Outer and inner VPLS cross connected into VPRN services
Inner VPLS for certain NC elements
Module 3 |
16
Model 1 3G Ethernet Services - Overview

The diagram above shows an overview of the Model 1 design services to support 3G 1x CDMA voice and data
traffic.
CSA1 to MLS ePipes
Redundant ePipes transport Ethernet frames to and from the 3G NodeB.
At the MLS, the ePipe spokes into an outer VPLS. The outer VPLS provides a virtual broadcast domain into which
multiple like BS can terminate, sharing an address on the same subnet. Split horizon groups may be necessary to
prevent direct NodeB to NodeB communications.
MLS Outer VPLS
The outer VPLS cross connects into a local VPRN through a Versatile Services Module (VSM) hosted Cross Connect
Aggregate Group (CCAG). The CCAG interface becomes the BS gateway interface.
MLS VPRN
The MLS VPRN CCAG provides bidirectional logical links between the L2 VPLS and the L3 VPRN interfaces. The
outer VPLS forwards NodeB packets to and from the VPRN through this interface.
The VPRN includes interfaces to the various NC elements, including VRRP protected interfaces cross connecting
into an inner, NC-facing VPLS.
MLS VPLS
The MLS inner VPLS provides redundant L2 interfaces to certain NC elements. A management VPLS might run STP
on behalf of some of the inner VPLS VLANs. The inner VPLS supports VRRP running on the VPRN-VPLS cross connect
interface, and includes an inter-chassis SAP.
Router-Specific Configurations
Redundant pseudowires are configured on the CSA router.
The MLS routers terminate the ePipes into outer VPLS spoke SDPs.
VRRP-protected VPRN interfaces forward traffic into inner VPLS SAPs.
OSPF runs between the local VPRNs.
Model 1 3G Ethernet Services - Overview
In the following pages, we will build these services in phases:

Phase 1 The CSA to MLS ePipes
Phase 2 The MLS outer VPLS
Phase 3 The MLS VPRN
Phase 4 The MLS inner VPLS
Module 3 |
17
Model 1 3G Ethernet Services Configuration Phases

Phase 1 - CSA1 to MLS ePipe
ePipe 1 uses redundant PWs, with the primary terminated on MLS1. To load balance traffic, alternate base
stations may terminate the primary on MLS2. QoS is applied on the router interfaces and on SAP ingress.
Phase 2 - MLS Outer VPLS
VPLS 1 terminates the ePipe spoke SDPs, and includes a cross-connect SAP. The CCAG provides a virtual Ethernet
port to the VPRN 1 base station gateway interface. The VPLS could include static MAC address entries for each
supported NodeB, tied to the spoke SDP. QoS is applied in CCAG SAP ingress.
Phase 3 - MLS Local VPRN
The VPRN is a local service; this example illustrates a 3G voice traffic VPRN. The service provides interfaces to the
cell sites, multiple external networks, and the NC elements.
The VPRN service defines its own OSPF area, and isolates traffic to a dedicate VRF. Most interfaces are passive,
though the interfaces facing the peer MLS and some external networks are active. The two MLS routers share this
services routes with each other through this adjacency.
Interface to the Outer VPLS This interface provides a gateway to and from the cell site NodeB. It is on the
opposite site of the Outer VPLS CCAG. It includes static-arp entries for the NodeB MAC addresses, and has its own
MAC address defined according to the NodeBs configuration requirements.
Interface to the Inner VPLS The inner VPLS provides L2 access to external NC elements. This interface
provides a gateway for the NC elements; its SAP is another CCAG linking the VPRN to the inner VPLS.
VRRP is enabled on this interface, with MLS1 configured as the master and MLS2 as the backup. The VRRP priority
determines which is the default master, and the MLS1 interface has the highest priority set. This VRRP instance
runs in non-owner mode, protecting a third IP address, 192.0.2.33/27. The master, backup and protected
addresses must be on the same subnet.
Interface to_MLSx
The to_MLS1 and to_MLS2 interfaces provide a routed link between the two MLS router VPRNs. The VPRNs form an
OSPF adjacency over these interfaces. A LAG physically connects the two MLS routers and the interfaces use VLAN
tag 1.
Phase 4 MLS Inner VPLS
The Inner VPLS creates a virtual broadcast domain for each traffic type. It allows the NodeB access to external
networks, NC elements, and provides a redundant layer 2 forwarding path through an inter-chassis LAG SAP. It
may be protected by a management VPLS, though for voice traffic it is not.
Model 1 3G Ethernet Services Configuration Phases

Section 1 Phase 1 Distributed ePipes with PW Redundancy
A:CSA1>config>service#
A:CSA1>config>service# epipe
epipe 11 customer
customer 11 create
create
config>service>epipe$
description
config>service>epipe$ description Distributed
Distributed epipe
epipe for
for 3G
3G Voice"
Voice"
config>service>epipe#
sap
1/1/1:100
create
config>service>epipe# sap 1/1/1:100 create
config>service>epipe>sap#
config>service>epipe>sap# back
back
config>service>epipe# no
no shutdown
shutdown
SAPs are only configured on the CSA router

Spoke SDPs terminate the ePipe into the MLS router outer VPLS
Module 3 |
20
Phase 1 Model 1 3G Distributed ePipe SAPs

To configure a distributed epipe service, you must configure service entities on the originating and far-end nodes.
You must use the same service ID on both ends (for example, epipe 1 on CSA1 and epipe 1 on MLS1). The spoke-sdp
sdp-id:vc-id must match on both sides. A distributed epipe consists of endpoints on different nodes.
By default, QoS policy ID 1 is applied to ingress and egress service SAPS. Existing filter policies or other existing
QoS policies can be associated with service SAPs on ingress and egress.
Ingress and egress SAP parameters can be applied to local and distributed epipe service SAPs.
Phase 1 Model 1 3G Distributed ePipe SAPs
Pseudowire (PW) redundancy protects against node failure in a VPWS (and VPLS)
The CSA VPWS has a spoke SDP, or PW, terminating on each MLS router
endpoint in the VPWS configuration ensures only one active egress path
The service configuration specifies the primary PW by the precedence
primary keywords
Module 3 |
21
Phase 1 - Pseudowire (PW) Redundancy

Already in place within the transport network are redundancy features, such as BFD, standby LSP paths, and FRR.
However, these techniques do not protect against service end-point failures, ie a nodal failure.
SROS allows for multi-homing a service to a primary and a backup remote PE router, a feature called pseudowire
(PW) redundancy. Within a VPWS, a multi-homed, local PE, shown here as CSA1, hosts the redundant spoke
SDPs. CSA1 chooses between two or more spoke SDPs and forwards traffic to a single egress PE router. If the
primary egress PE router fails or becomes inaccessible, the originator sends traffic to a secondary egress PE. It
is important to remember that a VPWS service can only have one active forwarding path.
The remote primary and secondary egress PEs, Remote PEs MLS1 and MLS2, share duplicated VPWS service
configurations, each with a return spoke SDP toward the local PE. To ensure that the re-directed traffic makes
it to the target CE device, the two egress PEs can protect the access ports with MC-APS or MC-LAGs.
Endpoint
A standard VPWS has two implied endpoints; the service SAP and the spoke SDP, if a distributed service, or two
SAPs, if a local service. A VPWS can have only one path to a destination, and traffic only flows from one
endpoint to another.
Within the redundant PW service configuration, you explictly specify an endpoint. The endpoint is an additional
service component, and is a named entity.
A:NodeA>config>service>epipe$ endpoint <endpoint-name> create
Defining the endpoint allows you to add up to four spoke SDPs, only one of which will be active at a time. The
endpoint ensures that the source PE only sends traffic down one path, the active spoke SDP. Once the
redundant spoke SDPs are associated with the endpoint, the following forwarding rules apply:
1. The local PEs switch fabric will only forward traffic between different endpoints. Traffic entering through one
endpoint, for example, the SAP, has to exit through another. Two objects in the same endpoint (the two spoke
SDPs) cannot exchange traffic. The local service SAP becomes a second, implied endpoint.
2. An endpoint can only have one active forwarding object. Other endpoint objects are in standby, and do not
forward traffic to the remote PE router. In the case of redundant PWs, the forwarding object is a spoke SDP,
though it could also be a SAP.
Phase 1 - Pseudowire (PW) Redundancy
Phase 1 - Configuring Redundant Pseudowires

Context:
Context: config>service>epipe
config>service>epipe
[no]
[no] endpoint
endpoint <endpoint-name>
<endpoint-name> create
create revert-time
revert-time [revert-time|infinite]
[revert-time|infinite]
[no]
spoke-sdp
<sdp-id:vc-id>
endpoint
[no] spoke-sdp <sdp-id:vc-id> endpoint <endpoint-name>
<endpoint-name> create
create
Context:
Context: config>service>epipe>spoke-sdp
config>service>epipe>spoke-sdp
Syntax:
Syntax:
[no]
[no] precedence
precedence <precedence-value>|
<precedence-value>| primary
primary
Example:
Example: config>service>epipe#
config>service>epipe# endpoint
endpoint ENET_BTS1_URC1
ENET_BTS1_URC1 create
create
config>service>epipe>endpoint$
revert-time
config>service>epipe>endpoint$ revert-time 90
90
config>service>epipe>endpoint$ back
back
config>service>epipe# spoke-sdp
spoke-sdp 1:1
1:1 endpoint
create
config>service>epipe>spoke-sdp$
config>service>epipe>spoke-sdp$ precedence
precedence primary
primary
config>service>epipe>spoke-sdp$ back
back
spoke-sdp 2:1
2:1 endpoint
create
back
config>service>epipe# exit
exit all
all
Pseudowire redundancy supported on all VPWS

Default spoke SDP precedence is none (4)
Service SAP in a second, implied endpoint
Module 3 |
22
Phase 1 - Configuring Redundant Pseudowires

SROS supports PW redundancy on aPipe, cPipe, ePipe, fPipe, and iPipe VPWS, as well as VPLS.
Endpoint
Endpoint defines the endpoint object; it can have any textual name, up to 32 characters long. This controls the
traffic flow egressing the active and standby pseudowires. The create keyword is required by default.
A:NodeA# configure service epipe 1 endpoint ENET_BTS1_URC1 create
Revert time
In the endpoint, a revert timer can be set to control, in seconds, when the PE moves traffic back to the primary
(precedence 0) spoke SDP.
A:NodeA>config>service>epipe>endpoint# revert-time 90
The default is 0 (immediately), and can be set from 0-600 or infinite (never revert). The revert time has no effect
when no primary spoke SDP exists, as it will not move traffic to other secondary spoke SDPs.
Spoke SDP Binding Creation
Upon the spoke SDPs creation, you must specify the endpoint object to which it belongs. You may not add an
endpoint assignment once youve created the spoke SDP binding. You will have to delete it and recreate it to add
an endpoint object.
A:NodeA>config>service>epipe# spoke-sdp 1:1 endpoint ENET_BTS1_URC1 create
Precedence
Each spoke SDP binding is configured as an endpoint object, and one may be configured with the precedence
primary keywords.
A:NodeA>config>service>epipe>spoke-sdp$ precedence primary
SROS supports five precedence values, 0-4, though 0 is not configurable (0=primary). 1-4 are configurable, with
the lowest numeric precedence preferred. precendence primary sets the precedence to 0. You may
explicitly set the backup spoke precedence with a number value, 1-4. Otherwise, the default is no precedence
(4), and the spoke becomes the backup once you set the precedence on the primary.
Configuration on the Remote PE
The remote PEs, MLS1 and MLS2, require only a single spoke SDP binding and SAP, as required by the VPWS
configuration. The intelligence of the redundant PW resides on the multi-homing peer, the local PE, CSA1.
Syntax:
Syntax:
Phase 1 - Pseudowire Status Flags
Peer PW Status
Description
TLV Flag
0x00000000
Pseudowire forwarding ( clear all failures )
0x00000020
Pseudowire forwarding Standby
0x00000006
Remote pseudowire active, remote SAP is down
0x00000026
Remote pseudowire in standby, remote SAP is down
0x00000001
Pseudowire Not Forwarding (MTU problems, etc)
0x00000021
0x00000018
0x00000038
Remote pseudowire in standby and not forwarding

Remote pseudowire is active but operationally
down
Remote pseudowire is in standby and operationally
down
Priority determines pseudowire selection order

Local PE picks best spoke SDP based on status priority
Local PE will only discard traffic if both local spoke SDPs are down
If PW status tied on both spoke SDPs, local precedence decides
Module 3 |
23
Phase 1- Pseudowire Status Flags

The status flags indicate the local and remote spoke SDP status. The PEs signal the spoke SDP status in T-LDP
Label Mapping and Notification messages.
On each PE, the status bits represent the local SAP forwarding status. If the SAP is part of a MC-LAG or MC-APS
and the service uses Interchassis Backup PW (ICB-PW), the PE can set the SAP status to standby (0x20), otherwise,
it is up (0x0) or down (0x26). We will discuss ICB-PW later in this module.
The local PEs learn the peers spoke SDP status by reading the LDP status bits in the T-LDP PW-Status TLV. These
bits indicate the remote spoke SDPs operational and preferential states.
The local PE determines the active spoke SDP based on its local SAP state and the state signaled by the remote PE.
Redundant PW Status and Spoke SDP Selection
Initially, the local PE signals the remote PEs a status of 0x0 in its label mapping message to establish the spoke
SDPs. It then chooses between them based on the local status, the status signaled from the two remote PEs, and
the precedence, if necessary. Each status value has a priority assigned, and the lowest priority wins.
For example:
Assume that the local PW status bits are clear, 0x0. The local PE receives flag 0x20, pwForwardingStandby, from
remote PE1 and flag 0x6, lacIngressFault/lacEgressFault (SAP failure), from remote PE2. The local PE will choose
its PE1 spoke SDP, as this path has the better status and priority. Even if the local spoke SDP toward PE2 is
assigned precedence primary, the local PE chooses the healthiest spoke SDP, the local PE1 spoke SDP.
If the local and remote flags are equal on both spoke SDPs, then the local PE uses the local precedence value to
choose between them.
The local node will only discard traffic if both spoke SDPs are locally down.
Priority
The local PE chooses the active spoke SDP

It initially tells the remote PE that all SAPs are Up
It reads the local and remote status bits to choose the active spoke SDP
If a tie occurs between the spoke SDPs, it can choose by precedence
(shown)
Module 3 |
24
Phase 1 - Choosing the Active Pseudowire

Initially, for all spoke SDPs associated with an endpoint, the local PE signals the remote PE a status of Pseudowire
Forwarding - this establishes all the spoke SDPs. Then, the local PE determines which of the redundant spoke
SDPs is the healthiest, and chooses it as the active spoke SDP.
Active Selection Criteria
The local PE chooses the active spoke SDP based on the following criteria:
1. It reads each spoke SDPs local and remote status. If it sees one with the status bits all clear, but another
with some set, it chooses the spoke SDP with the bits all cleared.
2. If it sees a tie between available spoke SDPs, it chooses the one with the lowest numeric local precedence
value. The primary spoke SDP has a precedence of 0, and all others have some other value.
3. If it still sees a tie, as might be the case when there is no primary but two or more secondary spoke SDPs, it
chooses the spoke SDP with the lowest sdp-id.
4. If an MC-LAG or MC-APS is used to protect the SAPs, there is no primary pseudowire. The local PE chooses by
local and remote SAP status, which is determined by the MC-LAG or MC-APS status. We will discuss this case
in upcoming slides.
Traffic Flow
As mentioned previously, the endpoint configuration ensures that the local PE transmits traffic only over the
active spoke SDP - in operation, the local PE blocks the backup spoke SDP. However, return traffic can travel
both the active and standby spoke SDPs simultaneously.
The remote PEs will always transmit as long as the service is up. A change in the remote PE state, such as a SAP
going down, may cause the local PE to switch traffic to a secondary spoke SDP.
Phase 1 - Choosing the Active Pseudowire
Phase 1 - View the Local PE Endpoint Status
===============================================================================
===============================================================================
Service 1 endpoints
Service 1 endpoints
===============================================================================
===============================================================================
Endpoint
:: Enet_BTS1_URC1_CSA1
Endpoint name
name
Enet_BTS1_URC1_CSA1
Description
: (Not Specified)
Description
: (Not Specified)
Revert time
: 90
Revert time
: 90
Act Hold Delay
: 0
Act Hold Delay
: 0
Standby Signaling Master
: false
: false
Standby Signaling Slave
: false
Standby Signaling Slave
: false
Tx Active
: 1:1
Tx Active
: 1:1
Tx Active Up Time
: 0d 00:16:20
Tx Active Up Time
: 0d 00:16:20
Revert
:: N/A
Revert Time
Time Count
Count Down
Down
N/A
Tx
:: 44
Tx Active
Active Change
Change Count
Count
Last
:: 08/10/2011
Last Tx
Tx Active
Active Change
Change
08/10/2011 12:38:07
12:38:07
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 1:1
1:1 Prec:0
Prec:0
Oper Status:
Status: Up
Up
Spoke-sdp:
2:1
Prec:4
Oper
Status:
Spoke-sdp: 2:1 Prec:4
Oper Status: Up
Up
===============================================================================
===============================================================================
===============================================================================
===============================================================================
Module 3 |
25
Phase 1 - View the Local PE Endpoint Status

A:NodeA# show service id 1 endpoint
Tx Active: Shows the active spoke SDP. In this example, the primary 1:1 is active.
Tx Active Up Time: - How long the active spoke SDP has been up.
Tx Active Change Count: - How often the active spoke SDP has changed.
Members: - List the spoke SDPs that are members in the endpoint object.
A change in the remote or local pseudowire status can cause a change.
The remote PE withdrawals its label
The remote PE signals a pseudowire status change, such as a remote spoke SDP or SAP failure
The local PEs T-LDP session times out with the remote peer
A network failure affected the SDP operational state
Revert time: - You may set a revert timer value to control when the local PE reverts back to the primary spoke
SDP. The default is 0, which causes immediate reversion. The range is 0 to 600 seconds, and infinite is an option.
A:NodeA>config>service>epipe>endpoint# revert-time infinite
...tells the router to never switch back to the primary spoke SDP.
The local PE will never revert the active spoke SDP to another secondary, only back to the primary.
A:CSA1# show service id 1 endpoint

A:CSA1# show service id 1 endpoint
The local PE sets standby-signaling-master on the endpoint

The local PE sends status 0x20 on the secondary spoke SDP
The remote PE VPLS shows the spoke SDP as Forwarding Standby
The remote PE egress label indicates Status Signaled Down
Module 3 |
26
Phase 1 Signaling the Secondary as Standby

Since CSA1 spoke SDP 1:1 is the primary spoke SDP, traffic flows from CSA1 to MLS1. However, unless otherwise
configured, traffic can return over both MLS1 spoke SDP 1:1 and MLS2 spoke SDP 2:1. This default behavior
does not create a loop, as the local PE service has only one active transmit path.
To ensure the remote PEs only transmit over the active path, you can enable standby signaling from the local PE
to the remote PE:
A:NodeA>config>service>epipe>endpoint# standby-signaling-master
By default, the remote PEs do not know that the connecting SDP is in standby. The default setting is no
standby-signaling-master.
If you want the remote PE to be aware that A/S SDPs are being used, use standby-signaling-master. Then, the
local PE signals status 0x20 for the standby pseudowire. The remote PE changes its spoke SDP state from
forwarding active (0x00) to forwarding standby (0x20), and marks the spoke SDPs egress service label as Status
Signaled Down.
Phase 1 Signaling the Secondary as Standby
Phase 1 - View the Remote PE LDP Bindings
===============================================================================
===============================================================================
LDP
LDP LSR
LSR ID:
ID: 192.0.2.0
192.0.2.0
===============================================================================
===============================================================================
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Type
:: V-Eth
VcId
:: 11
Type
V-Eth
VcId
SvcId
:: 11
SdpId
:: 22
SvcId
SdpId
Peer
Address
:
192.0.2.2
Vc-switching
:: No
Peer Address
: 192.0.2.2
Vc-switching
No
LMTU
:: 1500
RMTU
:: 1500
LMTU
1500
RMTU
1500
Egr.
:: 131064D
Egr.
:: No
Egr. Lbl
Lbl
131064D
Egr. Ctl
Ctl Word
Word
No
Egr.
:: None
Egr.
Egr. Flags
Flags
None
Egr. Status
Status Bits
Bits :: Supported
Supported (0x20)
(0x20)
Egr.
Egr.
Egr. Flow
Flow Label
Label Tx
Tx :: No
No
Egr. Flow
Flow Label
Label Rx:
Rx: No
No
Ing.
:: 131062U
Ing.
:: No
Ing. Lbl
Lbl
131062U
Ing. Ctl
Ctl Word
Word
No
Ing.
:: None
Ing.
Ing. Flags
Flags
None
Ing. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
Ing.
Ing.
Ing. Flow
Flow Label
Label Tx
Tx :: No
No
Ing. Flow
Flow Label
Label Rx:
Rx: No
No
===============================================================================
===============================================================================
No.
No. of
of VC
VC Labels:
Labels: 22
===============================================================================
===============================================================================
...
...
Module 3 |
27
Phase 1 - View the Remote PE LDP Bindings

A:NodeA# show router ldp bindings service-id 1 detail
LDP LSR ID: - Local node system ID
Peer Address: - Remote peer system ID
Egr Label: Shows the label passed by the remote peer PE for this spoke SDP.
A:MLS1# show router ldp bindings service-id 1 detail
===============================================================================
LDP LSR ID: 192.0.2.0
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up,
D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service

A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
BU - Alternate Next-hop for Fast Re-Route, TLV - (Type, Length: Value)
===============================================================================
...
MLS1 indicates Status Signaled Down for this LDP binding. In the service, it shows status pwFwdingStandby.
Egr. Status Bits: - Indicates flag values 0x20, pseudowire forwarding standby.
With the spoke SDP in standby, the remote peer PE (CSA1) only forwards traffic over the active spoke SDP.
A:MLS1#
A:MLS1# show
show router
router ldp
ldp bindings
bindings service-id
service-id 11 detail
detail
Redundant PWs protect

against nodal failures
Can protect against misconfiguration or provisioning
errors, but lost or dropped
packets may occur
Module 3 |
28
Phase 1 CSA1 Spoke SDP Bindings

Failure conditions
Planned and unplanned outages
Physical, routing, and MPLS redundancy make it unlikely that an SDP will fail. However, none of these can protect
a single-homed, distributed service from nodal failure.
Hence, PW redundancy helps provide a path to the destination in the case one of the redundant downstream
routers goes offline, either as a planned outage or as a result of an equipment outage.
System and circuit maintenance
Best practice is to never make routine changes on live systems and circuits unless in a maintenance window.
PW redundancy can also help protect against configuration errors, such as shutting down a protocol or tunnel
inadvertently, but a few lost or dropped packets may occur in these circumstances.
Phase 1 CSA1 Spoke SDP Bindings

Section 1 Phase 2 Outer VPLS Services
MLS1#
MLS1# configure
configure service
service
MLS1>config>service#
MLS1>config>service# vpls
vpls 11 customer
customer 11 create
create
MLS1>config>service>vpls$
MLS1>config>service>vpls$ no
no shutdown
shutdown
The MLS1 and MLS2 local services all use the same customer ID
On each router, the service configuration differs only by the spoke
SDP <sdp-id:vc-id>
Module 3 |
30
Phase 2 VPLS Service Creation

Show above is the service creation command on MLS1; MLS2 mirrors this configuration in all ways but the spoke
SDP sdp-id:vc-id.
Phase 2 - VPLS Service Definition
Phase 2 Creating the Spoke SDP Binding
A:MLS1>config>service>vpls>spoke-sdp$
A:MLS1>config>service>vpls>spoke-sdp$ exit
exit
A:MLS1>config>service>vpls#
A:MLS1>config>service>vpls# info
info
------------------------------------------------------------------------------------------stp
stp
shutdown
shutdown
exit
exit
spoke-sdp
spoke-sdp 1:1
1:1 create
create
spoke-sdp
spoke-sdp 2:1
2:1 create
create
exit
exit
no
no shutdown
shutdown
-------------------------------------------------------------------------------------------
The service has been bound to SDP 1 and 2

For redundancy, CSA1 and 2 each ties into the MLS1 and MLS2 outer
VPLS
Spoke SDP vc-ids must match those configured on the CSA ePipes
facing this router
Module 3 |
31
Phase 2 Creating the Spoke SDP Binding

For redundancy, each CSA1 and CSA2 ePipe has a spoke SDP terminated in each of the two MLS routers outer VPLS
1. Each outer VPLS includes two spoke SDP bindings, one for CSA1 and one for CSA2.
Remember that the vc-ids must match on each end, though they dont have to match within the service.
A:MLS1>config>service>vpls# spoke-sdp
spoke-sdp 1:1
1:1 create
create
A:MLS1>config>service>vpls>spoke-sdp$ back
back
spoke-sdp 2:1
2:1 create
create
A:MLS1>config>service>vpls# split-horizon-group
split-horizon-group group1
group1 create
create
A:MLS1>config>service>vpls>split-horizon-group#
A:MLS1>config>service>vpls>split-horizon-group# back
back
spoke-sdp 1:1
1:1 split-horizon-group
split-horizon-group group1
group1 create
create
A:MLS1>config>service>vpls>spoke-sdp$ exit
exit
info
------------------------------------------------------------------------------------------stp
stp
shutdown
shutdown
exit
exit
spoke-sdp
spoke-sdp 1:1
split-horizon-group "group1"
"group1" create
create
no
no shutdown
shutdown
exit
exit
spoke-sdp
spoke-sdp 2:1
split-horizon-group "group1"
"group1" create
create
no
no shutdown
shutdown
exit
exit
no
no shutdown
shutdown
-------------------------------------------------------------------------------------------
Split horizon groups help prevent L2 loops on the outer VPLS spoke
SDPs
No need for Spanning Tree Protocol (STP) on the spoke SDPs
Traffic entering the VPLS on the split horizon group cannot directly
enter another group spoke SDP
Module 3 |
32
Phase 2 Spoke SDP Split Horizon Groups

Split Horizon Groups
In some instances, you may want to prevent direct BS-BS communications in the VPLS service, which could
potentially cause a L2 loop.
A split horizon group associated with the ePipe spoke SDPs ensures that all traffic received on a spoke SDP within
the split horizon group leaves the VPLS before it is forwarded on to the target network. This means packets
received on the SHG must be forwarded through the VPRN service.
You must create the split horizon group (SHG), then associate the spoke SDPs to the SHG. You must associate the
spoke SDPs with the SHG at the time you create them; you cannot add them later.
Phase 2 Spoke SDP Split Horizon Groups

Section 1 Phase 2 Cross Connected Services
Used to interconnect Ethernet

encapsulated services like a VPLS or
VLL into an IES or VPRN service
The complete 10 Gbps forwarding
path is available to support an
aggregate of up to 10 Gbps halfduplex
Maintains egress and ingress features
of the services to which it is
interconnecting, including the ability
to remap QoS, enforce policing and
shaping and accounting for each
service.
Multiple VSMs incrementally increase
the interconnecting bandwidth and
provide load sharing/fault tolerance
Module 3 |
34
Phase 2 - Versatile Services Module (VSM) for CCAG SAPs

Both the MLS VPLS and VPRN services use CCAG SAPs. These require a VSM installed in the router.
The VSM provides roughly the equivalent connectivity as looping back external ports, but with various
improvements:
The interconnect function is performed internally eliminating the need for the physical port MAC, PHY, cable and
other MDA specific components producing a more reliable adaptor.
Bandwidth is utilized in a more efficient manner than with externally cabled ports. Typically, the offered load
presented to each side of the cross connect port pair is asymmetric in nature. When physical ports are used to
cross connect services, each service is egress bandwidth limited to the link speed of the TX-RX path it is using. If
one TX-RX path is underutilized, egress services on the other path cannot make use of the available bandwidth.
Since the VSM is forwarding all services over the same path, all the available bandwidth may be used up to the 10
Gbps (half duplex) capability.
The MDA is called a vsm-cca in the CLI to tie together the CCAG concepts underlying the VSM. VSM-CCAs may be
placed into CCAGs (Cross Connect Aggregation Groups). A CCAG provides a mechanism to aggregate multiple vsmccas into a single forwarding group. The CCAG uses conversation hashing to dynamically distribute cross connect
traffic to the active CCAs in the aggregation group. In the event that an active CCA fails or is removed from the
group, the conversation hashing function will redistribute the traffic over the remaining active CCAs within the
group.
The VSM can be used to interconnect services with Ethernet encapsulations (e.g. no Frame Relay or ATM
encapsulated SAPs).
Phase 2 - Versatile Services Module (VSM) for CCAG SAPs
Phase 2 - Cross Connect Aggregation Group (CCAG)
Module 3 |
35
Phase 2 - CCAG
The VSMs can be spread across IOMs. Each VSM support 10 Gbps of half-duplex service interconnect traffic.
A Cross Connect Aggregation Group (CCAG) provides a mechanism to aggregate multiple VSM Cross Connect
Adapters (CCAs) into a single forwarding group. The CCAG uses conversation hashing to dynamically distribute
cross connect traffic to the active VSMs in the aggregation group. In the event an active VSM fails or is removed
from the group, the conversation hashing function will redistribute the traffic over the remaining active VSMs
within the group.
CCAG includes one or more VSMs

Up to 8 VSMs per CCAG
CCID is the binding point for services and IP interfaces in a

CCAG
Interconnected services are assigned the same CCID; ex:
ccag-1.a:1 and ccag-1.b:1
Ingress and egress QoS, filtering and accounting policies are
assigned to the CCID
Module 3 |
36
CCID Cross Connect Identifier

Services and IP interfaces are bound to a CCAG through a CCID (Cross Connect Identifier). When two services or a
service and an IP interface are assigned the same CCID, the CCAG will attempt to provide a crosss connection path
between the objects. The CCID enables multiple pairs of cross connected services to share the same CCAG.
From a services perspective, a CCID is an object that not only binds two services together, but also provides the
attachment point for the ingress and egress QoS, filtering and accounting policies. When considered in conjunction
with the CCAG, it allows the actual cross connection path (through the VSMs) to be indirectly associated with the
services using the CCAG and maintain a simplified provisioning model over port level cross connected services.
VSM Virtual Paths
The function of the VSM is to connect an egress forwarding path directly to an ingress forwarding path, allowing a
packet to exit and reenter the system on the same MDA interface. This creates a half duplex forwarding
environment for all cross connected objects using the VSM and differs from the full duplex nature of externally
cross connected ports which support two distinct forwarding paths. VSM provisioning emulates full duplex
provisioning with two logical Path A and Path B constructs which each emulates a TX-RX path for the CCAG.
Although Path A and Path B use the same TX bandwidth at the hardware level (represented by the shared egress
forwarding path for a given VSM), defining these distinct paths within a CCAG allows for optional provisioning of
rate limiting on each path. When enabled, rate limiting on a path is spread across all the VSMs in the CCAG. For
example, you may limit forwarding bandwidth in a CCAG based on limits applied to the Paths (e.g. Path A = 3
Mbps, Path B = 7 Mbps). This allocated more bandwidth to the B path than the A where asymmetric traffic flows
appear.
Objects on Path A must interconnect with objects on Path B
SAPs are assigned to a Path when created on the CCID
IP interfaces are assigned to a Path when bound to a CCAG;
ex: sap ccag-1.a:1 or sap ccag-1.b:1
SAPs are defined as belonging to either Path A or Path B when the SAP is created on the CCID. An IP interface is
assigned to Path A or Path B when it is bound to a CCAG. A Path A object can only be paired with a Path B object
and vice versa.
Phase 2 - Cross Connect Identifier (CCID)
Phase 2 - Provision a CCAG
Syntax:
Syntax:
[no] ccag <ccag-id> create

[no] ccag <ccag-id> create
[no] description
[no] description
[no] member-cca <card-slot/mda-number>
[no] member-cca <card-slot/mda-number>
path <path-id> sap-sap [no] mtu <mtu-bytes>
path <path-id> sap-sap [no] mtu <mtu-bytes>
Example: config>vsm# ccag 1 create

Example: config>vsm# ccag 1 create
config>vsm>ccag# description Service Cross Connect CSA1-MLS1 VPLS
config>vsm>ccag# description Service Cross Connect CSA1-MLS1 VPLS
config>vsm>ccag# member-cca 5/1
config>vsm>ccag# member-cca 5/1
config>vsm>ccag# path a sap-sap mtu 9212
config>vsm>ccag# path a sap-sap mtu 9212
config>vsm>ccag# path b sap-sap mtu 9212
config>vsm>ccag# path b sap-sap mtu 9212
config>vsm>ccag# exit all
config>vsm>ccag# exit all
For resiliency and load balancing, a typical deployment would

assign at least two VSMs as member-ccas
The default path MTU is 1514
You must define both paths a and b
Module 3 |
37
Phase 2 Provision a CCAG

This command creates a Cross Connect Aggregation Group (CCAG). A CCAG represents a group of CCAs as a
common forwarding entity. Objects requiring a CCA cross connect function are mapped to a CCAG, not the
individual CCAs within the CCAG. The CCAG treats each active member CCA as a possible destination when
forwarding packets between the cross connected objects mapped to the CCAG. The system uses both conversation
hashing functions and direct service mappings to determine the load sharing distribution between the active CCAs.
All packets for a given conversation flow through the same CCA to preserve packet order. Packet ordering may be
momentarily affected during convergence events when CCAs are dynamically added or removed from the active
list.
The CCAG context is used to manage the following functions per CCAG instance:
Informational description of the CCAG
Administrative state of the CCAG
Alpha path bandwidth and weight parameters
Beta path bandwidth and weight parameters
CCA total bandwidth limit
CCA membership in the CCAG
ccag-id Identifies the CCAG instance. The system can have up to eight CCAGs.
member-cca identifies the CCAG member VSM CCA. A CCAG can have up to eight member-ccas.
path Each CCA is divided into an alpha and a beta path. Each path can have a relative weight assigned to
distribute bandwidth, including setting a maximum path bandwidth value. The CCAG includes sap-sap, sap-net,
and net-sap paths, and each path context enables MTU size and MAC address assignments and QoS policies.
The default path weight for bandwidth allocation is 50/50, a to b.
Context: config>vsm
Context: config>vsm
Phase 2 Create the Outer VPLS CCAG SAP
info
------------------------------------------------------------------------------------------stp
stp
shutdown
shutdown
exit
exit
sap
sap ccag-1.b:1
ccag-1.b:1 create
create
description
description Outer
Outer VPLS
VPLS 11 to
to VPRN
VPRN 22 crossconnect
crossconnect
exit
exit
no
no shutdown
shutdown
-------------------------------------------------------------------------------------------
Create the b path SAP in the VPLS 1 service

Requires a corresponding a path in the VPRN 2 service
Each CCAG SAP requires a VLAN tag assigned
Module 3 |
38
Phase 2 Create the outer VPLS CCAG SAP

The CCAG SAP components define the following characteristics:
ccag-id Defines the group of CCAs used to forward packets associated with this SAP.
path a or b - Identifies the bandwidth control grouping use to manage CCA egress bandwidth. This pairing helps
the system identify buffering resources it will use to manage egress packet queuing.
cc-id Explicit cross-connects the SAP to another, in this case, one defined on a VPRN interface, configured with
the same cc-id.
A:MLS1>config>service>vpls# sap
sap ccag-1.b:1
ccag-1.b:1 create
create
A:MLS1>config>service>vpls>sap$
A:MLS1>config>service>vpls>sap$ back
back
A:MLS1#
A:MLS1# show
show service
service id
id 11 sap
sap ccag-1.b:1
ccag-1.b:1
===============================================================================
===============================================================================
Service
Service Access
Access Points(SAP)
Points(SAP)
===============================================================================
===============================================================================
Service
:: 11
Service Id
Id
SAP
:: ccag-1.b:1
Encap
:: q-tag
SAP
ccag-1.b:1
Encap
q-tag
Description
:: Outer
Description
Outer VPLS
VPLS 11 to
to VPRN
VPRN 22 crossconnect
crossconnect
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
Flags
:: None
Flags
None
Multi
:: None
Multi Svc
Svc Site
Site
None
Last
Last Status
Status Change
Change :: 08/22/2011
08/22/2011 11:16:38
11:16:38
Last
Mgmt
Change
:
08/22/2011
Last Mgmt Change
: 08/22/2011 11:14:38
11:14:38
===============================================================================
===============================================================================
Default encap-type is q-tag

Loopback (hairpin) cables could also be used, but would tie up
two physical ports
Module 3 |
39
Phase 2 - View the CCAG SAP

A:NodeA# show service id 1 sap ccag-1.a:1
Encap: Always q-tag.
Hairpins in place of CCAG
In the instance where the customer does not use VSMs, an external loopback cable can be used to cross connect
service SAPs.
In the VPLS service, you would create a SAP tied to physical port:
A:NodeA# configure service id 1 sap 1/1/6 create
In the VPRN, you would create an interface, also tied to a physical port. Then, using a jumper, tie transmit to
receive (or set MDI/MDI-X).
Remember, however, that this ties up two physical ports, though you could support multiple physical
crossconnects by setting dot1q or qinq on the ports.
Phase 2 - View the CCAG SAP
An R-VPLS takes the place of the VSM or external cross-connects

Only one R-VPLS interface per L2 service
Set the VPLS service-name to associate it with L3 service interface
Set allow-ip-int-binding in the VPLS service
Module 3 |
40
Phase 2 Routed VPLS

A standard IP interface within an existing IES or VPRN service context may be bound to a service name. Subscriber
and group IP interfaces are not allowed to bind to a VPLS service context. A VPLS service only supports binding for
a single IP interface; however, the routing context to which the VPLS is bound may have more than one bound
VPLS service.
Assigning the Service Name to the R-VPLS
The R-VPLS requires a name.
A:NodeA# configure service vpls 4 service-name <service-name>
The service name can be up to 64 characters long. The name can only be associated with one service.
A:NodeA# configure service vpls 4 allow-ip-int-binding
When the service is configured with a name and the allow-ip-int-binding command, the system scans
existing IES and VPRN services for interfaces bound to the service name. When it finds an interface associated
with the name, it attaches it to the VPLS service.
R-VPLS requires SROS 8 or later and IOM3-XP. 7705 SAR does not support R-VPLS.
Phase 2 Routed VPLS
Phase 2 Routed VPLS (cont)
===============================================================================
===============================================================================
Interface
Interface Table
Table (Service:
(Service: 2)
2)
===============================================================================
===============================================================================
Interface-Name
Adm
Opr(v4/v6)
Port/SapId
Interface-Name
Adm
Opr(v4/v6) Mode
Mode
Port/SapId
IP-Address
PfxState
IP-Address
PfxState
------------------------------------------------------------------------------------------------------------------------------------------------------------toOuterVPLS
Up
Up/-VPRN
rvpls
toOuterVPLS
Up
Up/-VPRN
rvpls
203.0.113.1/30
n/a
203.0.113.1/30
n/a
------------------------------------------------------------------------------------------------------------------------------------------------------------Interfaces
Interfaces :: 11
===============================================================================
===============================================================================
In the VPRN, an interface must be bound to the VPLS service.

A:MLS1>config>service>vprn# interface toOuterVPLS
vpls OuterVPLS
Module 3 |
41
Phase 2 Routed VPLS (cont)

Associating the Interface to the VPLS
In the VPRN, an interface must be bound to the VPLS service.
A:NodeA>config>service>vprn>if# vpls <service-name>
A:MLS1#
A:MLS1# show
show router
router 22 interface
interface "toOuterVPLS"
"toOuterVPLS"

Section 1 Phase 3 Local VPRN Services
A:MLS1>config>service#
A:MLS1>config>service# vprn
vprn
A:MLS1>config>service>vprn$
Traffic"
Traffic"
22 customer
customer 11 create
create
description
description "VPRN
"VPRN Service
Service for
for 3G
3G Voice
Voice
A:MLS2>config>service# vprn
vprn
Traffic"
Traffic"
22 customer
customer 11 create
create
description
description "VPRN
"VPRN Service
Service for
for 3G
3G Voice
Voice
router-id
router-id 198.51.100.1
198.51.100.1
route-distinguisher
route-distinguisher 65000:2
65000:2
no
no shutdown
shutdown
router-id
router-id 198.51.100.2
198.51.100.2
route-distinguisher
65000:2
no
no shutdown
shutdown
Create the local VPRN service on MLS1 and MLS2

No MP-BGP required, as these are local services
Each service needs a unique Router ID for IGP and EGP use
Each PEs service needs a route distinguisher to build its local VRF
Module 3 |
44
Phase 3 Create the MLS router Local VPRN Service

The VPRN service must be defined and associated with the customer ID created in an earlier configuration. A
description for the VPRN should always be included for ease of reference and troubleshooting.
The router-ID is manually configured to establish a predictable identifier for the protocols that require one, such
as OSPF and BGP. This is preferred over leaving the router-ID selection to the default mechanism, which can result
in unpredictable values.
Though this is a local service, it still requires a route distinguisher set in the service instance. Each PE requires a
route distinguisher so that it can build and maintain its local Virtual Routing and Forwarding (VRF) table.
Phase 3 Create the MLS router Local VPRN Service
The MLS routers host multiple local VPRNs, one for voice, data, and OAM traffic
Each traffic types outer VPLS has a CCAG interface
Each traffic type has a inner VPLS for NC traffic
Some interfaces pass traffic to external networks for soft handoff,
Internet, and network management
A:MLS1>config>service>vprn#
A:MLS1>config>service>vprn# interface
interface outer_VPLS1
outer_VPLS1
A:MLS1>config>service>vprn>if$
A:MLS1>config>service>vprn>if$ sap
sap ccag-1.a:1
ccag-1.a:1
A:MLS1>config>service>vprn>if$ ip-address
ip-address 192.0.2.1/27
192.0.2.1/27
mac
A:MLS1>config>service>vprn>if$ mac 00:00:00:00:01:01
00:00:00:00:01:01
A:MLS1>config>service>vprn>if$ static-arp
static-arp 192.0.2.2
192.0.2.2 00:00:00:00:01:02
00:00:00:00:01:02
back
A:MLS1>config>service>vprn>if$ back
interface inner_VPLS3
inner_VPLS3
sap ccag-1.a:2
ccag-1.a:2
ip-address 192.0.2.34/27
192.0.2.34/27
back
A:MLS1>config>service>vprn>if$ back
interface to_MLS2
to_MLS2
ip-address 192.0.2.165/30
192.0.2.165/30
sap lag-1:1
lag-1:1
Module 3 |
45
Phase 3 Create the VPRN Interface

In most cases, the VPRNs on the two MLS routers mirror each other.
The exceptions are the interfaces between the MLS routers, some directly connected NC elements, and the VRRP
protected NC gateway interfaces.
The MLS inter-chassis interfaces must route traffic between the VPRN instances, in the case where the traffic must
flow from a L2 service on one MLS router to the VPRN on the other. This flow characteristic is possible when a
failure occurs on the CSA ePipes active spoke SDP, but the NC gateway interface is active on the opposite router.
The NC gateway interface state does not follow the active spoke SDP state.
We discuss VRRP later in this section.
Phase 3 - Create the VPRN Interfaces
interface to_BTS1_URC1_DO
to_BTS1_URC1_DO
A:MLS1>config>service>vprn>if#
A:MLS1>config>service>vprn>if# dhcp
dhcp
A:MLS1>config>service>vprn>if>dhcp$
A:MLS1>config>service>vprn>if>dhcp$ server
server 192.168.1.1
192.168.1.1 192.168.1.2
192.168.1.2
A:MLS1>config>service>vprn>if>dhcp$ gi-address
gi-address 198.51.100.65
198.51.100.65
A:MLS1>config>service>vprn>if>dhcp$ no
no shutdown
shutdown
A:MLS1>config>service>vprn>if>dhcp$ back
back
DHCP relay is configured on a per interface basis

The interface proxies DHCP requests on behalf of the URC
The URC discovers its IP address via DHCP discover broadcast into
outer VPLS
Once IP configured, the URC establishes signaling link with NC
element
Module 3 |
46
Phase 3 Configure DHCP Relay for Data Only services

DHCP relay configured on DO interfaces allows the DO URC to discover its IP address and IP configuration details.
server Specifies the list of target DHCP server(s) to which the interface will forward requests. The list can
include up to eight servers, and if multiple servers are listed, the request is fowarded to all of them.
gi-address This is the DHCP gateway interface address. Also known as the gi-addr, this address identifies the
interface address to be used for relaying DHCP packets.
A:MLS1#
A:MLS1# show
show router
router 33 interface
interface to_BTS1_URC1_DO
to_BTS1_URC1_DO detail
detail
===============================================================================
===============================================================================
Interface
Interface Table
Table (Service:
(Service: 2)
2)
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Interface
Interface
------------------------------------------------------------------------------------------------------------------------------------------------------------If
:: to_BTS1_URC1_DO
If Name
Name
to_BTS1_URC1_DO
Admin
:: Up
Oper
:: Up/-Admin State
State
Up
Oper (v4/v6)
(v4/v6)
Up/-Protocols
:: OSPFv2
Protocols
OSPFv2
IP
:: 198.51.100.65/27
Address
:: Primary
IP Addr/mask
Addr/mask
198.51.100.65/27
Address Type
Type
Primary
IGP
:: Disabled
Broadcast
IGP Inhibit
Inhibit
Disabled
Broadcast Address
Address :: Host-ones
Host-ones
...
...
DHCP
DHCP Details
Details
Description
Description :: (Not
(Not Specified)
Specified)
Admin
State
:: Up
Lease
:: 00
Admin State
Up
Lease Populate
Populate
Servers
:: 192.168.1.1
Servers
192.168.1.1 192.168.1.2
192.168.1.2
Gi-Addr
:: 198.51.100.65
Gi-Addr
Gi-Addr
198.51.100.65
Gi-Addr as
as Src
Src Ip
Ip :: Disabled
Disabled
** == inferred
inferred gi-address
gi-address from
from interface
interface IP
IP address
address
Module 3 |
47

A:NodeA# show router 2 interface to_BTS1_URC1_DO detail
DHCP relay configured on DO interfaces allows the DO URC to discover its IP address and IP configuration details.
server Specifies the list of target DHCP server(s) to which the interface will forward requests. The list can
include up to eight servers, and if multiple servers are listed, the request is fowarded to all of them.
gi-address This is the DHCP gateway interface address. Also known as the gi-addr, this address identifies the
interface address to be used for relaying DHCP packets.
Phase 3 View DHCP Relay Configuration
interface outer_VPLS1
outer_VPLS1
A:MLS1>config>service>vprn>if# mac
mac 00:00:00:01:00:01
00:00:00:01:00:01
A:MLS1>config>service>vprn>if# static-arp
192.0.2.2 00:00:00:01:00:02
00:00:00:01:00:02
Static ARP protects against packet loss caused by aged out ARP cache
entries
If the BS does not support ARP functions, the service already has
an BS ARP cache entry
The static MACs are unique within the VPRN service
Module 3 |
48
Phase 3 Configure Static ARP Entries
VRRP presents a virtual router to the sub-network

A Virtual Router ID (VRID) represents a virtual router instance
The NC element forwards traffic toward the virtual gateway
address
VRRP instance determines the current master physical interface
Module 3 |
49
Phase 3 VRRP on NC VPRN Interfaces

Consider the diagram above. Both MLS1 and MLS2 have interfaces attached to a common subnet, 192.0.2.32/27.
MLS1s interface IP address is 192.0.2.33/27, while MLS2s interface address is 192.0.2.34/27. When configured for
VRRP, both routers represent a virtual router consisting of the same VRID and the associated IP addresses. The
virtual router presents a single virtual IP interface to the network. In this example, the virtual interface IP address
could be either 192.0.2.33, 192.0.2.34, or another virtual IP address on the same network segment but belonging
to none of the router interfaces, such as 192.0.2.35.
Network hosts use the virtual interface address as their default gateway address, and thus route traffic destined
for external networks via this virtual interface. Either router MLS1 or MLS2 operates as the VRIDs master, and
ultimately routes this traffic through its real IP interface.
VRRP Router Roles
VRRP specifies two router roles; a master and a backup. The master is responsible for forwarding traffic to other
network segments while the backup merely waits to take over if the master becomes unavailable. The master can
operate in two modes, owner or non-owner. In owner mode, the master owns the virtual interface IP address.
This means that the VRIDs virtual interface uses an IP address belonging to the masters real interface. In nonowner mode, the virtual interface address belongs to no real interface, but still represents to network hosts the
default gateway address. VRRP ensures that when hosts route their traffic to this virtual default gateway address,
it actually routes through the masters real network interface.
The backup router does not route traffic unless the master becomes unavailable. While the master is offline, the
backup router responds to ARP requests for the virtual interface IP address, so that any packets sent toward the
default gateway arrive on the backup routers real interface instead of the masters. Once the master recovers,
the VRRP protocol can force an election and route traffic again through the master.
VRRP Router Priorities
VRRP assigns each router a priority, which dictates which router becomes the master. The priorities range from 1255, with 255 the highest priority. When the master operates in owner mode, VRRP automatically assigns its
priority to 255. VRRP assigns all non-owner master and backup routers priority to 100 by default. When configuring
a VRRP router for non-owner mode, assign the master the higher priority, for example, 220. Then assign lower
priorities to the backups as desired. By using progressively lower priorities for a group of backup routers, you can
control the order in which routers become masters. A VRID can have up to 16 backup IP address in non-owner
mode.
Phase 3 VRRP on NC VPRN interfaces
A network can host multiple VRIDs and load-balance traffic

across them
NC element gateway address determines VRID targeted
Owner mode master interface owns backup address
Non-owner mode backup a third address
Module 3 |
50
Phase 3 VRRP Load Balancing

VRRP supports load balancing traffic on the same network segment across VRIDs. In this case, the network is
configured with multiple virtual interfaces, all on the same sub-network. Assume again that Routers MLS1 and
MLS2 present two real IP interfaces to the same Layer 3 network segment. Operating in owner mode, MLS1 is
master for VRID 1 and its real interface IP address 192.0.2.33 becomes VRID 1s virtual interface address. MLS2 is
master for VRID 2 and its real interface IP address 192.0.2.34 becomes VRID 2s virtual interface address.
VRID 1 is configured as follows:
Router MLS1 real interface IP address: 192.0.2.33/27
Virtual interface address (MLS1s interface IP): 192.0.2.33/27
Master router: Router MLS1
Backup router: Router MLS2
VRID 2 is configured as follows:
Virtual interface address (MLS2s interface IP): 192.0.2.34/27
Master router: Router MLS2
Backup router: Router MLS1
The network administrator configures some network hosts to use VRID 1s virtual interface as their default
gateway, while others use VRID 2s virtual interface. If MLS1 fails, VRID 1 traffic routes through backup MLS2. If
MLS2 fails, VRID 2 traffic routes through MLS1.
Phase 3 VRRP Load Balancing
Master advertises itself on the network every 1 second

Advertisement sent to multicast address 224.0.0.18
Backup waits for [(3 * Advertisement Interval) + Skew Time] to
attempt to become master
Skew time partially based on interface priority value
Module 3 |
51
Phase 3 VRRP on NC VPRN Interfaces (cont)

VRRP Advertisements and Elections
VRRP defines an advertisement interval that controls how often a master declares itself on the network; the
default is 1 second. The master advertises its availability on the network with announcement messages sent to the
multicast address 224.0.0.18 every second.
If a backup does not receive the master advertisement message after a protocol calculated master down time
interval, it announces its intention to become the master. A component of this calculated master down interval is
the skew time, a value partly derived from the routers VRRP priority. The higher the priority, the lower the skew
time, so that a higher priority backup router will wait a shorter time period before it asserts itself as the master.
This avoids transition race conditions, where all the backups attempt to become master simultaneously. However,
the backups need significantly different priority assignments to avoid this race condition. In the event of a tie, the
master becomes the router with the highest physical interface IP address.
Since VRRP messages use a local link multicast address, the VRRP instances require Layer 2 connectivity for
successful operation. The inner VPLS provides this connectivity through the inter-chassis LAG SAPs. See Phase 4.
Virtual Router MAC Address Learning
All IP packets the current master delivers into the network source the interfaces physical MAC address, not the
VRID MAC address. Additionally, ARP requests sourced off the master interface use its physical MAC, though the
ARP messages carry the VRID MAC address in the hardware address field. VRRP messages are the only ones that
use the virtual MAC address as the source MAC.
The NC element learns the virtual MAC through ARP requests. The master must only respond with the virtual MAC
address so that the NC element does not have to relearn the virtual router MAC if a master change occurs.
When the virtual router initializes or restarts, it sends a Gratuitous ARP with the virtual MAC address on the virtual
interface.
VRRP Applications
SROS supports VRRP on network, IES, VPRN, and routed VPLS interfaces.
BFD and VRRP
SROS supports BFD in VRRP VRIDs, supporting 30 ms failure detection.
Phase 3 VRRP Advertisements and Elections
inner_VPLS3
A:MLS1>config>service>vprn>if# vrrp
vrrp 11
A:MLS1>config>service>vprn>if>vrrp$
A:MLS1>config>service>vprn>if>vrrp$ backup
backup 192.0.2.35
192.0.2.35
priority
A:MLS1>config>service>vprn>if>vrrp$ priority 230
230
A:MLS1>config>service>vprn>if>vrrp$ no
no preempt
preempt
A:MLS1>config>service>vprn>if>vrrp$ ping-reply
ping-reply
A:MLS1>config>service>vprn>if>vrrp$ back
back
A:MLS1>config>service>vprn>if# exit
exit all
all
inner_VPLS3
A:MLS2>config>service>vprn>if# vrrp
vrrp 11
A:MLS2>config>service>vprn>if>vrrp$ backup
backup 192.0.2.35
192.0.2.35
no
A:MLS2>config>service>vprn>if>vrrp$ no preempt
preempt
A:MLS2>config>service>vprn>if>vrrp$ ping-reply
ping-reply
A:MLS2>config>service>vprn>if>vrrp$ back
back
A:MLS2>config>service>vprn>if# exit
exit all
all
Module 3 |
52
Phase 3 Configure VRRP in the VPRN Service

backup The virtual gateway address the VRID represents
priority In non-owner mode, each interface has the same priority by default, 100. Setting a higher priority
value determines which interface becomes the master.
no preempt If so configured, the VRID will never automatically switch the master away from the current
master. This helps control flapping on the interfaces. If the backup becomes the master, it remains so until
either it fails or an administrator manually switches states. The command:
A:NodeA# clear router 2 vrrp interface inner_VPLS3 vrid 1
...clears and resets the VRRP instance.
ping-reply In non-owner mode, this command enables the master to reply to echo requests directed at the
virtual router interface. Without this command enabled, the master only replies to pings for its own address.
Phase 3 Configure VRRP in the VPRN Service
MLS1 master interface goes offline

MLS2 VRRP Master Down Timer expires
2
3
MLS2 becomes the master interface and sends a gratuitous ARP
for the virtual interface MAC into the network
4
The NC element forwards frames toward the virtual interface
MAC address, which the switch has learned on MLS2 facing port
1
Module 3 |
53
Phase 3 VRRP Recovery

If MLS1 goes offline or the interface goes down, MLS2 will time out the master and itself become the master.
MLS2s interface sends out a VRRP announcement declaring itself as the master. It also sends out a gratuitous ARP
on the subnet containing the virtual MAC address for the virtual interface. It then transitions to the master state.
If no preempt is set, the backup remains the master until an administrator clears the VRRP instance. If preempt is
allowed, a message received with a higher priority will cause the current master to reset its Master_Down_Timer
and transition to backup.
Phase 3 VRRP Recovery
OSPF configured within the VPRN service

MLS1 and MLS2 become neighbors in the same OSPF area
Interfaces to BTS and NC elements configured as passive
Local routes have preference over remotely learned, duplicate
routes
Supports redundancy in the case the router strikes the local route
from the VRF
A:MLS1>config>service>vprn# ospf
ospf area
area 0.0.0.51
0.0.0.51
A:MLS1>config>service>vprn>ospf>area$
A:MLS1>config>service>vprn>ospf>area$ interface
interface to_VPLS2
to_VPLS2
A:MLS1>config>service>vprn>ospf>area>if$
A:MLS1>config>service>vprn>ospf>area>if$ passive
passive
A:MLS1>config>service>vprn>ospf>area>if$ back
back
A:MLS1>config>service>vprn>ospf>area$ interface
interface toMLS2
toMLS2
A:MLS1>config>service>vprn>ospf>area>if$ back
back
A:MLS1>config>service>vprn>ospf>area$ back
back
A:MLS1>config>service>vprn>ospf$
A:MLS1>config>service>vprn>ospf$ back
back
Module 3 |
54
Phase 3 Routing in the VPRN

An IGP is configured within the VPRN 2 instances.
The MLS routers duplicate many addresses between the VPRN instances, but this means that if MLS1 strikes the
local route, it can replace it with the route learned from MLS2. Then, packets targeting the new route entry
travel over the inter-chassis link to MLS2s service.
Phase 3 Routing in the VRPN

Section 1 Phase 4 Inner VPLS Services
VPLS
VPLS44
sap
sap1/1/4:4
1/1/4:4
sap
saplag-1:4
lag-1:4
sap
sapccag-1.b:4
ccag-1.b:4
VPLS
VPLS44
sap
sap1/1/4:4
1/1/4:4
sap
saplag-1:4
lag-1:4
sap
sapccag-1.b:4
ccag-1.b:4
Layer 2 loop can form in the topology shown

Some NC elements (DO-RNC, for example) connect to the VPLS
service through redundant Ethernet switches
The VPLS needs a way to break the loop but still support link
redundancy
Module 3 |
56
Phase 4 Inner VPLS Management VPLS (mVPLS)

By design, certain NC elements connect to the MLS inner VPLS through redundant Ethernet switches. This can
cause a Layer 2 loop, as depicted above.
SROS provides a means to break the loop while maintaining the redundant Ethernet links. Called a management
VPLS (m-VPLS), it is a separate service designed to run Spanning Tree Protocol (STP) on behalf of a set of VPLS
services.
Rapid STP (RSTP) runs among the management VPLS (mVPLS) instances. It detects a loop in the mVPLS domain
and, based on the priority of the mVPLS moves to a blocking state, thus breaks the loop. Note that RSTP
recognizes mVPLS instances as interfaces. To facilitate the transition of traffic to the new SAP, the forwarding
databases of the affected user VPLS (uVPLS) instances are flushed if a topology change occurs.
mVPLS features include:
mVPLS is used to remove loops in the network caused by the implementation of SAP redundancy.
When RSTP in the mVPLS blocks an interface, the uVPLS is also blocked.
mVPLS instances are interconnected in a loop that is identical to the loop within the customer VPLS.
An mVPLS instance does not carry customer traffic.
Load balancing can be achieved with two mVPLS instances, with each instance managing multiple VLANs.
Phase 4 Inner VPLS Management VPLS (mVPLS)
mVPLS
mVPLS3000
3000
stp
stppriority
priority28762
28762
sap
sap1/1/4:3000
1/1/4:3000
managed-vlan-list
managed-vlan-list
range
range4-4
4-4
sap
saplag-1:3000
lag-1:3000
managed-vlan-list
managed-vlan-list
range
range4-4
4-4
mVPLS
mVPLS3000
3000
stp
stppriority
priority28762
28762
sap
sap1/1/4:3000
1/1/4:3000
managed-vlan-list
managed-vlan-list
range
range4-4
4-4
sap
saplag-1:3000
lag-1:3000
managed-vlan-list
managed-vlan-list
range
range4-4
4-4
Create an mVPLS on the MLS routers

Each mVPLS needs a SAP on the managed links; must be dot1q
or qinq
The managed-vlan-list identifies the managed VLANs on that SAP
The switches A and B must run STP
Module 3 |
57
Phase 4 Inner VPLS Management VPLS (mVPLS) (cont)

On each of the MLS routers, an mVPLS identifies the SAPs on which RSTP runs, and the VLANs the mVPLS will
protect against loops.
The STP bridge priority determines which ports forward and which block traffic. The goal is to provide a path to
all destinations on the bridged domain, while blocking potential loops.
The NC switches must be STP enabled.
Phase 4 Inner VPLS Management VPLS (mVPLS) (cont)
A:MLS1#
A:MLS1# show
show service
service service-using
service-using vpls
vpls
==============================================================================
==============================================================================
Services
Services [vpls]
[vpls]
===============================================================================
===============================================================================
ServiceId
Type
Adm
ServiceId
Type
Adm Opr
Opr CustomerId
CustomerId Service
Service Name
Name
------------------------------------------------------------------------------------------------------------------------------------------------------------44
uVPLS
Up
uVPLS
Up Up
Up 11
3000
mVPLS
Up
3000
mVPLS
Up Up
Up 11
------------------------------------------------------------------------------------------------------------------------------------------------------------Matching
Matching Services
Services :: 22
------------------------------------------------------------------------------------------------------------------------------------------------------------===============================================================================
===============================================================================
A:MLS2#
A:MLS2# show
show service
service service-using
service-using vpls
vpls
==============================================================================
==============================================================================
Services
Services [vpls]
[vpls]
===============================================================================
===============================================================================
ServiceId
Type
Adm
ServiceId
Type
Adm Opr
Opr CustomerId
CustomerId Service
Service Name
Name
------------------------------------------------------------------------------------------------------------------------------------------------------------44
uVPLS
Up
uVPLS
Up Up
Up 11
3000
mVPLS
Up
3000
mVPLS
Up Up
Up 11
------------------------------------------------------------------------------------------------------------------------------------------------------------Matching
Matching Services
Services :: 22
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Module 3 |
58
Phase 4 View the mVPLS Status

A:NodeA# show service service-using vpls
VPLS 4 is now being displayed as uVPLS. Both VPLSs have SAPs on the same port within the defined managed VLAN
list in the mVPLS configuration.
type The service type shown. mVPLS is the management VPLS, and uVPLS is a service managed by an mVPLS
instance.
Phase 4 View the mVPLS Status
Phase 4 Verifying the mVPLS MLS1
===============================================================================
===============================================================================
Stp
Stp info,
info, Service
Service 3000
3000
===============================================================================
===============================================================================
Bridge
:: 70:00.62:aa:ff:00:00:00
Bridge Id
Id
70:00.62:aa:ff:00:00:00 Top.
Top. Change
Change Count
Count :: 11
Root
:: 70:00.62:a9:ff:00:00:00
:: Up
Root Bridge
Bridge
70:00.62:a9:ff:00:00:00 Stp
Stp Oper
Oper State
State
Up
Primary
Bridge
:
N/A
Topology
Change
:
Primary Bridge
: N/A
Topology Change
: Inactive
Inactive
Mode
:: Rstp
Last
Mode
Rstp
Last Top.
Top. Change
Change :: 0d
0d 01:00:56
01:00:56
Vcp
Active
Prot.
:
N/A
Vcp Active Prot.
: N/A
Root
:: 2049
External
:: 10
Root Port
Port
2049
External RPC
RPC
10
===============================================================================
===============================================================================
Stp
Stp port
port info
info
===============================================================================
===============================================================================
Sap/Sdp/PIP
OperPortPortPortSap/Sdp/PIP Id
Id
OperPortPortPort- OperOper- LinkLink- Active
Active
State
Role
State
Num
Edge
Type
State
Role
State
Num
Edge
Type Prot.
Prot.
------------------------------------------------------------------------------------------------------------------------------------------------------------1/1/4:3000
Up
Designated
2048
1/1/4:3000
Up
Designated Forward
Forward
2048 True
True Pt-pt
Pt-pt Rstp
Rstp
lag-1:3000
Up
Root
Forward
2049
False
Pt-pt
lag-1:3000
Up
Root
Forward
2049
False Pt-pt Rstp
Rstp
===============================================================================
===============================================================================
Module 3 |
59
Phase 4 Verifying the mVPLS MLS1

A:NodeA# show service id 3000 stp
Port role Either root, designated, alternate, or backup.
Port state Discard, block, listen or forward.
mVPLS
mVPLS
A:MLS1#
A:MLS1# show
show service
service id
id 3000
3000 stp
stp
uVPLS
A:MLS1#
uVPLS
A:MLS1# show
show service
service id
id 44 stp
stp
===============================================================================
===============================================================================
Inherited
Inherited Stp
Stp State
State (from
(from mVPLS),
mVPLS), Service
Service 44
===============================================================================
===============================================================================
Sap/Spoke
OperPruneMngd
Mngd
Mngd
Sap/Spoke Id
Id
OperPrune- PortPortMngd by
by
Mngd by
by
Mngd by
by
State
State
Service
Sap/spoke
MSTI
State
State State
State
Service
Sap/spoke
MSTI
------------------------------------------------------------------------------------------------------------------------------------------------------------1/1/4:4
Up
-Forward
1/1/4:3000
CIST
1/1/4:4
Up
Forward 3000
3000
1/1/4:3000
CIST
lag-1:4
Up
Forward
3000
lag-1:3000
CIST
lag-1:4
Up
Forward 3000
lag-1:3000
CIST
===============================================================================
===============================================================================
The uVPLS port states follow the mVPLS state.

The show service id <service-id> stp command
displays the port state and the service and SAP managing
the port.
Module 3 |
60
Phase 4 Verifying the mVPLS MLS1 (cont)

A:NodeA# show service id 4 stp
Port state Discard, block, listen or forward.
Mngd by Service The service id for the managing mVPLS.
Phase 4 Verifying the mVPLS MLS1 (cont)
Module 3 |
61
Model 1 3G Ethernet Detailed Configuration
Lab 7 : Configure ePipe, VPRN and VPLS for 3G Voice Service
MLS1
CR1
CSA2
1.5 Hour
MLS2
Lab Objectives:
On the CSA routers, provision redundant ePipe spoke SDPs and NodeB/BTS
facing SAPs
On the MLS routers, provision outer and inner VPLS services, local VPRNs,
VRRP, and routing protocols
Verify service operation with SROS OAM tools
Module 3 |
62
CSA1
Section Summary
In this section, we :
Provisioned the 3G Ethernet voice traffic distributed ePipe services

Configured the 3G Ethernet voice traffic outer VPLS
Provisioned the 3G Ethernet voice traffic VPRN service
Configured the 3G Ethernet voice traffic inner VPLS
Explored pseudowire redundancy as deployed in the Model 1 and 2
distributed VPWS
Configured PW redundancy in an ePipe service
Created CCAGs for L2 and L3 service virtual Ethernet cross connects
Configured VRRP on NC element facing interfaces
Evaluated management VPLS for STP application in the inner VPLS
services
Module 3 |
63
Reviewed the Model 1 3G Ethernet voice, data, and control traffic paths
and services

Section 3 Model 1 Detailed Configuration 3G TDM
Section Objectives
Provision the 3G TDM BS packetized voice traffic distributed iPipe
services
Provision the 3G TDM BS packetized voice traffic VPRN service
interfaces
Employ pseudowire redundancy in the iPipe service
Module 3 |
66
Review the Model 1 3G TDM BS traffic paths and services
Model 1 - Ethernet Backhaul (EBH) - iPipes

3G iPipes cross-connect into MLS VPRN interfaces
Carried over the same transport as the ePipes
Module 3 |
67
Model 1 iPipes/VPRN for 3G IP-over-TDM (IPoTDM) Voice Traffic

A TDM-connected BS delivers packetized voice traffic to the CSA router over ML-PPP bundled DS1 or E1 circuits.
The iPipe extracts the IP packets from the IP-over-ML-PPP-over-TDM UNI-BS, and forwards the packets alone
through the VPWS to the far-end L3 interface.
The MLS iPipe SAP or spoke SDP acts on behalf of the BS to accept and deliver Ethernet frames to and from the
MLS L3 interface Ethernet port. In the case where the iPipe cross connects via a CCAG to a VPRN, the iPipe SAP
and VPRN interface are the Ethernet endpoints.
Model 1 iPipes/VPRN for 3G IP-over-TDM (IPoTDM) Voice Traffic
CSA-MLS iPipes for 3G IPoTDM Voice and Control traffic

Distributed iPipes at CSA and MLS routers
iPipes cross connected into MLS VPRN services
MLS VPRNs cross connected into local VPLS
Module 3 |
68
Model 1 TDM over iPipes Overview

The diagram above shows an overview of the Model 1 design services to support 3G CDMA voice traffic.
CSA1 to MLS iPipes
Redundant iPipes transport IP packets to and from BTS ML-PPP bundled DS1 or E1 links. The CSA iPipe passes the
BTS its IP address and target BSC addresses during IPCP negotiations.
At the MLS, the iPipe cross connects into a local VPRN through a Versatile Services Module (VSM) hosted Cross
Connect Aggregate Group (CCAG). The CCAG presents to the iPipe a requisite Ethernet interface acting on behalf
of the BTS.
MLS VPRN
The MLS VPRN provides the BTS gateway interfaces. The CCAG provides bidirectional logical links between the L2
iPipe and the L3 VPRN interfaces. When the VPRN needs to build a frame which will transport a packet destined
for the BTS, it uses the iPipe SAPs proxy MAC address as the destination. The iPipe service then forwards the
packet down the service to the BTS.
In the return direction, the CSA iPipe forwards the packet to the VPRN interface, which forwards it on to its
destination. The iPipe uses the CCAG interfaces MAC address as the frames destination MAC address.
The VPRN also includes interfaces to the various NC elements, including VRRP protected interfaces cross
connecting into an inner, NC-facing VPLS.
MLS VPLS
The MLS inner VPLS provides redundant L2 interfaces to certain NC elements. A management VPLS might run STP
on behalf of some of the inner VPLS VLANs. The inner VPLS supports VRRP running on the VPRN-VPLS cross connect
interface, and includes an inter-chassis SAP.
The MLS routers terminate the iPipes into cross connected VPRN interfaces.
VRRP-protected VPRN interfaces forward traffic into inner VPLS SAPs.
OSPF runs between the local VPRNs.
Model 1 3G IPoTDM over iPipes Overview
Ipipe is a point to point Ethernet interworking VPWS service

that makes it possible to provide connectivity between hosts
that are attached to different point to point access circuits
(ATM,FR, PPP, Ethernet) on either end of a pseudowire.
Only IP traffic can be transported over an iPipe.
Module 3 |
69
Introduction to IP Interworking VPWS (Ipipe)

IPipe is a point to point Ethernet interworking VPWS service which makes it possible to provide connectivity
between hosts that are attached to different point to point access circuits (ATM,FR, PPP, Ethernet) on either end
of a pseudowire. Only IP traffic can be transported over an iPipe.
TDM base stations deliver ML-PPP bundled packets to the CSA router iPipe SAP. A PPP interface makes use of RFC
1332, The PPP Internet Protocol Control Protocol (IPCP), PPP IPCP encapsulation of an IPv4 packet.
Note that the iPipe is a point-to-point Layer 2 service. All packets received on one SAP of the iPipe will be
forwarded to the other SAP. No IP routing of customer packets occurs.
In order to forward IP packets between the BTS and the NC element, MLS1 needs to know the BTS and the VPRN
gateway interface IP addresses.
MLS1 maintains an ARP cache context for each iPipe and responds to ARP request messages received on the
Ethernet SAP, the CCAG interface to VPRN2. MLS1 responds with the Ethernet SAP configured MAC address as a
proxy for any ARP request for the BTS IP address. MLS1 should silently discard any ARP request message received
on the Ethernet SAP for an address other than that of the BTS.
Likewise, MLS1 should silently discard any ARP request message with the source IP address other than that of the
VPRN interface. In all cases, MLS1 keeps track of the association of IP to MAC addresses for ARP requests it receive
over the Ethernet SAP.
Introduction to IP Interworking VPWS (iPipe)
The CSA router sends the BTS an IP address via IPCP

A multilink bundle is configured as the BTS SAP
The MLS1 iPipe SAP acts as an Ethernet interface on the BTS
behalf
Sends and answers BTS ARP requests
The VPRN interface is the BTS gateway L3 interface
Module 3 |
70
Model 1 Distibuted iPipe

Configured on the CSA router are bundled DS1 or E1 links. In the iPipe SAP context, IPCP is configured to pass the
the BTS its IP address and controller information.
Model 1 - Distributed iPipe
The ce-address identifies the destination IP address for traffic

egressing the iPipe service
The iPipe maintains an ARP cache and its Ethernet SAP sends and
replies to ARP requests
The iPipe discards any frames not targeting the iPipe Ethernet SAP MAC
address (00:00:00:00:10:10, as illustrated)
Module 3 |
71
iPipe ce-address and Forwarding Behavior

When two Ethernet devices communicate via IP, they must encapsulate the IP packets in Ethernet frames. The
sender needs a destination MAC address for the frames, so it maintains an ARP cache and sends ARP requests
for unknown MAC addresses.
Since the BTS uses PPP frames to transport its IP packets, it has no assigned MAC address. In the iPipe context, the
MLS1 router acts as an Ethernet interface for the BTS, answering ARP requests on its behalf. The CCAG
becomes a point-to-point link between two L3 interfaces, the iPipe service and the VPRN interface.
Ce-address
In order to forward unicast frames destined for the RNC, the MLS1 iPipe needs to know the VPRN 2 interface MAC
address. When the iPipe SAP is first configured and administratively enabled, MLS1 sends an ARP request
message over the iPipe-VPRN CCAG Ethernet SAP, request the VPRN interface MAC address and using the iPipe
SAP ce-address as the target IP address.
Until it receives an ARP reply, the iPipe discards any unicast IP packets destined for the VPRN interface. The iPipe
forwards IP broadcast and multicast packets using the broadcast or direct mapped multicast MAC address.
Forwarding to the BTS
1. In order to forward unicast frames destined to the BTS, the MLS1 iPipe validates the destination MAC address of
any frames it receives from the VPRN interface. If the VPRN does not have an ARP cache entry for the
destination IP, it sends an ARP request on the CCAG. The iPipe will only respond to requests for the BTS IP
address.
2. If the IP packet is unicast, the destination MAC must match that of the Ethernet SAP. If the IP packet is
multicast or broadcast, the MAC destination address must be an appropriate multicast or broadcast MAC
address.
3. The iPipe removes the Ethernet header and encapsulates the IP packet directly into the PW without a control
word.
4. CSA1 removes the PW encapsulation and forwards the IP packet over the ML-PPP bundle.
A PE does not flush the ARP cache unless the SAP goes admin or operationally down. The PE with the Ethernet SAP
sends unsolicited ARP requests to refresh the ARP cache every T seconds. ARP requests are staggered at an
increasing rate if no reply is received to the first unsolicited ARP request. T is configurable by user through the
mac-refresh CLI command.
iPipe ce-address and Forwarding Behavior
A:CSA1>config>service# ipipe
ipipe 10
10 customer
customer 11 create
create
config>service>ipipe$
description
config>service>ipipe$ description Distributed
Distributed ipipe
ipipe for
for 3G
3G TDM
TDM Services"
Services"
config>service>ipipe#
config>service>ipipe# sap
sap bundle-ppp-1/1.10
bundle-ppp-1/1.10 create
create
config>service>ipipe>sap$
back
config>service>ipipe>sap$ back
config>service>ipipe>sap$ ce-address
ce-address 192.0.2.162
192.0.2.162
config>service>ipipe>sap$ ipcp
ipcp
config>service>ipipe>sap>ipcp$
config>service>ipipe>sap>ipcp$ assign-peer-ce-addr
assign-peer-ce-addr
config>service>ipipe>sap>ipcp$ dns
dns 198.151.100.250
198.151.100.250
config>service>ipipe>sap>ipcp$ back
back
config>service>ipipe#
config>service>ipipe# no
no shutdown
shutdown
Module 3 |
72
Model 1 Configuring an iPipe Service

This command configures an iPipe service instance. No MAC learning or filtering is provided on an Ipipe.
Additionally, we show the BTS SAP configuration.
sap bundle-ppp-1/1.10 An ML-PPP bundle already exists on the CSA router, and it terminates at the BTS.
However, the bundle is not fully operational until it is provisioned in the iPipe service.
ce-address This is the BTSs IP address. Once IPCP is configured and running, this is the address the CSA will
send to the BTS.
ipcp This enables IPCP encapsulation on the bundle.
assign-peer-ce-addr Tells the router to pass the peer IP address during IPCP signaling.
dns Passes additional information, such as the NC address the URC will use for signaling.
Model 1 - Configuring an Ipipe Service
A:MLS1>config>service# ipipe
ipipe 10
10 customer
customer 11 create
create
sap
ccag-1.b:10
config>service>epipe# sap ccag-1.b:10 create
create
config>service>epipe>sap#
config>service>epipe>sap# ce-address
192.0.2.161
Both the CSA and MLS SAPs must be configured for the directly connected
Layer 3 interface address
The MLS SAP ce-address is the directly cross-connected VPRN interface
Module 3 |
73
Model 1 Configuring Distributed iPipe SAPs

A CE address corresponding to the local end CE address needs to be configured under the SAP context before the
SAP will come up operationally.
Model 1 - Configuring Distributed Ipipe SAPs
Example:
Example:
ipipe 10
10
A:CSA1>config>service>ipipe#
A:CSA1>config>service>ipipe# endpoint
endpoint
A:CSA1>config>service>ipipe>endpoint$
ipipe
ipipe
back
back
A:CSA1>config>service>ipipe$
A:CSA1>config>service>ipipe$ spoke-sdp
spoke-sdp 1:10
1:10
spoke-sdp
A:CSA1>config>service>ipipe# spoke-sdp 1:10
1:10
create
create
endpoint
endpoint ipipe
ipipe create
create precedence
precedence primary
primary
ce-address
192.0.2.161
Example:
Example:
ipipe 10
10
A:MLS1>config>service>ipipe#
A:MLS1>config>service>ipipe# spoke-sdp
spoke-sdp 1:10
1:10 create
create
A:MLS1>config>service>ipipe>spoke-sdp$
A:MLS1>config>service>ipipe>spoke-sdp$ ce-address
192.0.2.162
Module 3 |
74
Model 1 Configuring the iPipe Primary SDP Bindings

Note that at this point in our configuration steps, the iPipe service will show as being operationally up even if the
spoke-sdp ce-address is not configured.
However, you will not be able to ping between the CE devices as no data will be transmitted through the iPipe
until the spoke-sdp ce-address is configured on CSA1 and MLS1.
Note that the spoke SDP ce-address is the far-end L3 interface address. The CSA1 spoke SDP defines the VPRN2
CCAG interface address, while the MLS1 spoke SDP defines the BTS IP address.
Model 1 - Configuring the iPipe Primary SDP Bindings
Example:
Example:
ipipe 10
10
A:CSA1>config>service>ipipe# endpoint
endpoint
ipipe
ipipe create
create
back
back
A:CSA1>config>service>ipipe$
A:CSA1>config>service>ipipe$ spoke-sdp
spoke-sdp 2:10
2:10 endpoint
endpoint ipipe
ipipe create
create
A:CSA1>config>service>ipipe>spoke-sdp$
ce-address
192.0.2.161
A:CSA1>config>service>ipipe>spoke-sdp$ ce-address 192.0.2.161
Example:
Example:
ipipe 10
10
A:MLS2>config>service>ipipe#
A:MLS2>config>service>ipipe# spoke-sdp
spoke-sdp 2:10
2:10 create
create
A:MLS2>config>service>ipipe>spoke-sdp$
A:MLS2>config>service>ipipe>spoke-sdp$ ce-address
192.0.2.162
Module 3 |
75
Model 1 Configuring the iPipe Secondary SDP Bindings

Secondary Standby Spoke SDP
To finish the configuration, you would add the redundant pseudowire to MLS2:
A:CSA1>config>service>ipipe# spoke-sdp 2:10 endpoint ipipe create
A:CSA1>config>service>ipipe>spoke-sdp$ ce-address 192.0.2.161
You would also configure the iPipe on MLS2.
Model 1 - Configuring the iPipe Secondary SDP Bindings
Model 1 - Verifying the CSA iPipe Service

===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 10
Service Id
Id
10
Service
:: Ipipe
Service Type
Type
Ipipe
Description
:: MLPPP_BTS10_URC10
Description
MLPPP_BTS10_URC10
Customer
:: 11
Customer Id
Id
Last
Last Status
Status Change:
Change: 08/23/2011
08/23/2011 13:25:52
13:25:52
Last
Last Mgmt
Mgmt Change
Change :: 08/23/2011
08/23/2011 13:26:28
13:26:28
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
MTU
:: 1500
MTU
1500
Vc
:: False
Vc Switching
Switching
False
SAP
:: 11
SDP
:: 22
SAP Count
Count
SDP Bind
Bind Count
Count
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Access && Destination
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:bundle-ppp-1/1.10
ipcp
1526
1526
Up
Up
sap:bundle-ppp-1/1.10
ipcp
1526
1526
Up
Up
sdp:1:10
n/a
00
1546
Up
Up
sdp:1:10 S(192.0.2.0)
S(192.0.2.0)
n/a
1546
Up
Up
sdp:2:10
n/a
00
1546
Up
Up
sdp:2:10 S(192.0.2.1)
S(192.0.2.1)
n/a
1546
Up
Up
===============================================================================
===============================================================================
Module 3 |
76
Model 1 Verifying the CSA iPipe Service

A:NodeA# show service id 10 base
MTU: - Note that the default service MTU of an Ipipe service is 1500 as opposed to the default service MTU of
1514 for an epipe. This value represents just the IP packet size.
A:CSA1#
A:CSA1# show
show service
service id
id 10
10 base
base
Model 1 - Verifying the CSA iPipe Bundle SAP
===============================================================================
===============================================================================
Service
Service Access
Access Points(SAP)
Points(SAP)
===============================================================================
===============================================================================
Service
:: 10
Service Id
Id
10
SAP
:: bundle-ppp-1/1.10
Encap
:: ipcp
SAP
bundle-ppp-1/1.10
Encap
ipcp
Description
:: (Not
Description
(Not Specified)
Specified)
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
Flags
:: None
Flags
None
Multi
:: None
Multi Svc
Svc Site
Site
None
Last
Last Status
Status Change
Change :: 08/23/2011
08/23/2011 13:24:44
13:24:44
Last
:: 08/23/2011
Last Mgmt
Mgmt Change
Change
08/23/2011 13:09:57
13:09:57
------------------------------------------------------------------------------------------------------------------------------------------------------------Ipipe
Ipipe SAP
SAP Configuration
Configuration Information
Information
------------------------------------------------------------------------------------------------------------------------------------------------------------Ce
:: 192.0.2.162
Assign
:: false
Ce IP
IP Address
Address
192.0.2.162
Assign to
to Peer
Peer
false
Peer
Peer Pri
Pri DNS
DNS Addr
Addr :: 198.51.100.250
198.51.100.250
Peer
Peer Sec
Sec DNS
DNS Addr
Addr :: Not
Not configured
configured
Configured
:: 192.0.2.162
Discovered
Configured CE
CE IP
IP
192.0.2.162
Discovered CE
CE IP
IP :: n/a
n/a
...
...
Module 3 |
77
Model 1 - Verifying the CSA iPipe Bundle SAP

A:NodeA# show service id 10 sap bundle-ppp-1/1.10
The CE IP Address of 192.0.2.162 is the CE IP address of the BTS directly attached to the SAP. Since this is PPP
SAP, there is no associated MAC address.
A:CSA1#
A:CSA1# show
show service
service id
id 10
10 sap
sap bundle-ppp-1/1.10
bundle-ppp-1/1.10
Model 1 - Verifying the iPipe MLS1 Ethernet SAP
===============================================================================
===============================================================================
Service
Service Access
Access Points(SAP)
Points(SAP)
===============================================================================
===============================================================================
Service
:: 10
Service Id
Id
10
SAP
:: ccag-1.b:10
Encap
:: q-tag
SAP
ccag-1.b:10
Encap
q-tag
Description
:: MLPPP_BTS10_URC10
Description
MLPPP_BTS10_URC10
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
Flags
:
None
Flags
: None
Multi
:: None
Multi Svc
Svc Site
Site
None
Last
Last Status
Status Change
Change :: 08/23/2011
08/23/2011 14:32:13
14:32:13
Last
:: 08/23/2011
Last Mgmt
Mgmt Change
Change
08/23/2011 14:32:04
14:32:04
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Ipipe
Ipipe SAP
SAP Configuration
Configuration Information
Information
------------------------------------------------------------------------------------------------------------------------------------------------------------Configured
Discovered
Configured CE
CE IPv4
IPv4 :: 192.0.2.161
192.0.2.161
Discovered CE
CE IPv4:
IPv4: n/a
n/a
SAP
:: 00:00:00:10:00:10
Mac
SAP MAC
MAC Address
Address
00:00:00:10:00:10
Mac Refresh
Refresh Inter*:
Inter*: 14400
14400
...
...
Ipipe
Ipipe SAP
SAP IPv4
IPv4 ARP
ARP Entry
Entry Info
Info
------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.161
62:aa:ff:00:02:19
192.0.2.161
62:aa:ff:00:02:19 dynamic
dynamic 03h59m39s
03h59m39s
Module 3 |
78
Model 1 - Verifying the iPipe MLS1 Ethernet SAP

The CE IP Address shown in the figure is the CE IP address belonging to the VPRN 2 CCAG interface.
Since this is an Ethernet SAP, the MAC address was dynamically learned from the VPRN interface.
A:MLS1#
A:MLS1# show
show service
service id
id 10
10 sap
sap ccag-1.b:10
ccag-1.b:10
Module 3 |
79
Model 1 3G IPoTDM iPipes Detailed View

The detail, above, shows the services and service features used to support 3G TDM traffic over an Ethernet
transport.
CSA1 to MLSx iPipe
CSA1 - iPipe 10 transports IP packets delivered from a TDM base station to the MLS routers. The BTS Universal
Radio Controller (URC) terminates an ML-PPP bundle, and delivers packetized voice, data, and control traffic over
load balanced PPP links. The CSA extracts the IP packets and delivers them to the target MLS through the iPipe
service.
Each ce-address entry enables IP forwarding within the iPipe service. On the CSA1 end, the spoke SDP ce address
is the far-end L3 interface address, VPRN 2 interface to_iPipe10. The SAP ce address belongs to the URC, and
supports IPCP signaling between it and the iPipe bundle SAP. The bundles assign-peer-ce-addr command
tells the CSA router to send the URC its IP address, and the DNS entry becomes the URCs target controller
address.
MLSx On the MLS end, the spoke SDP ce address entries belong to the URC. The CCAG SAP ce address belongs to
the VPRN 2 to_iPipe10 interface. The SAP MAC entry determines for which ARP requests the router will respond on
the CCAG virtual Ethernet port. On ingress from the iPipe CCAG SAP, the MLS router will only respond to ARP
requests for the URC MAC address, discarding all others.
VPRN 2
The VPRN 2 interface to_iPipe10 includes a static ARP entry for the URC IP address. This means the router wont
have to send out ARPs for that address.
Once the packets leave the iPipe and entry the VPRN, they are forwarded as they were in the previous example.
Model 1 3G IPoTDM iPipes Detailed View
Section Summary
Reviewed the Model 1 3G TDM traffic paths and services
Provisioned the 3G TDM voice traffic VPRN service interfaces
Employed redundant pseudowires in the iPipe service
Module 3 |
80
Provisioned the 3G TDM voice traffic distributed iPipe services

Section 4 Model 1 Detailed Configuration 4G LTE Voice and

Data Services
Section Objectives
Observe the LTE interfaces flows through the Model 1 network
eNodeB S1-MME
eNodeB S1-U
EPC element flows - S5, s6a, S11, and Gx
eNodeB X2
Configure the IES interfaces for LTE traffic
Module 3 |
82
Review the Model 1 LTE services
Model 1 - 4G LTE
4G ePipes terminate into MLS IES
BS-BS traffic routed through MLS IESs
MME VRRP interface supported through MLS local VPLS
Module 3 |
83

The Backhaul Transport carries LTE user and OAM packets through dedicated redundant ePipes originating and
terminating on the CSA routers. These tie into spoke SDP IES interfaces configured in a single MLS router IES. All
traffic is routed at the MLS routers.
Each eNodeB connects to the CSA router through a gigabit Ethernet link, using dot1q encapsulation. Each VLAN,
one for user and one for OAM traffic, is assigned a /30 or /31 mask address. The MLS IES interfaces become the
eNodeBs gateway.
VRRP for MME Interfaces
Local VPLS support multiple MMEs, and VRRP-protected, cross-connected IES interfaces provide MME routed access.
The eNodeB networks are included in the base routing instance. MPLS is only used on the spoke SDPs.
CSA-MLS ePipes for eNodeB VLANs User and OAM traffic

ePipes spoked into MG IES
VRRP protected IES for MME VPLS traffic
Network interfaces to other EPC elements
Module 3 |
84
Model LTE Services Overview

The diagram above shows an overview of the services and interfaces the Model 1 design uses to transport LTE user
and OAM traffic.
CSA1 to MLS ePipes
The ePipes use pseudowire redundancy, and terminate into MG router IES interfaces. From there, all LTE traffic is
routed to and from the EPC elements.
The MLS routers host cell site-facing IES interfaces.
MME traffic enters a dedicated VPLS through a VRRP-protected IES.
All other EPC traffic enters and exits through a number of network interfaces.
Model 1 LTE Services Overview
LTE S1-MME traffic

The Mobility Management Entity (MME) manages access and mobility
The S1-MME interface is the reference point for the control plane protocol
between the eNodeB and the MME
This traffic is forwarded through a telecom VLAN, IES, and local VPLS
Module 3 |
85
Model 1 LTE S1-MME Traffic

The Backhaul Transport provides a flat, L2 network for transporting LTE packets. Routing occurs at the MLS
routers, reducing processing and nodal delay.
S1-MME Traffic
The MME is the LTE control plane element responsible for high volume mobility management and connection
management.
MME performs the following actions:
Authenticates the user and authorizes the user equipment access to network connections after interacting with
the HSS (Home Subscriber Server)
Selects the appropriate serving and PDN gateways to handle the connection
Establishes, modifies and releases user connections
Selects the Serving GPRS Support Node (SGSN) for handovers to 2G or 3G 3GPP access networks
Allows a law enforcing agency to receive information regarding user signaling activities.
The MME is also responsible for searching for an idle UE to establish a connection to it.
The S1-MME interface controls the UEs interaction with the network. All UE control and tracking information
flows in this interface, including UE signaling, managing eUTRAN resources in the UE context, UE handover via
the X2 and S1 interfaces, and paging.
S1-MME Traffic Flow
UE S1-MME traffic leaves the CSA router as MPLS tunneled ePipe service traffic. It exits the ePipe at an MLS router
IES interface spoke SDP. From there, the MLS router switches the packets through the MME VPLS to the MME in
the EPC. VRRP protects the IES interfaces.
S1-Flex
LTE standards also support pooled MME and S-GW elements via the S1-Flex interface. S1-Flex supports load
balancing of traffic across an NC pool, required a full-mesh topology between a BS and multiple MME and S-GW.
The routed interfaces and the inner VPLS supports this design.
Model 1 LTE S1-MME Traffic
LTE S1-U traffic
The S1-U carries only user traffic (no signaling or OAM)

The S1-U session terminates at the SGW
All user traffic routes through the SGW
This traffic is forwarded through a telecom VLAN and IES
Module 3 |
86
Model 1 LTE S1-U Traffic

The S1-U interface transports only user traffic. The GPRS Tunneling Protocol (GTP)-User plane, GTP-U, tunnels
user traffic between the eNodeB and the Serving Gateway (SGW).
SGW Functions
The Serving Gateway (SGW) terminates the interfaces towards the E-UTRAN. For each Evolved Packet System
(EPS) associated UE there is a single SGW node handling all the UEs connections.
The SGW performs the following actions:
It serves as the mobility anchor (meaning that packets are routed through this node) for the user plane when a
UE moves from one eNodeB to another (inter-eNodeB). It also acts as the anchor for mobility between LTE and
2G/3G 3GPP access networks (inter-3GPP).
It routes and forwards eNodeB user data packets
It buffers downlink data packets sent to an idle UE. An idle UE does not have a user plane connection
established to the EPC. When the SGW receives downlink data destined for a UE, it requests that the MME
search for that UE and ask it to establish a connection with the EPC. During this setup time, the SGW buffer the
data until the UE connection comes up.
It replicates user traffic for law enforcement agency use.
S1-U Traffic Flow
This traffic travels the telecom VLAN data path, exiting at the eNodeB IES interface. In the base routing instance,
the MLS routers route these packets to the target SGW. A single SGW handles all a UEs user traffic.
Model 1 LTE S1-U Traffic
EPC Traffic Flows

All EPC inter-element traffic routes through the MLS routers
The S5/8 interfaces support SGW-PGW communications for user plane tunneling
and tunnel management
The S11 interface carries control traffic between the MME and the SGW
The S6a enables the transfer of subscription and authentication between the
MME and the HSS function.
The Gx interface supports PGW to PCRF QoS and Policy and Charging
Enforcement Functions (PCEF)
Module 3 |
87
Model 1 EPC Element Traffic Flows S5, S6a, S11, and Gx

All traffic between the EPC elements is routed at the MLS routers, either directly or alternately over the interchassis LAG.
The routers form an OSPF adjacency over the inter-chassis LAG, and as we learned earlier, either route to directly
connected or remote interfaces depending on network conditions.
S5/8 Interface
The S5/S8 interface is the reference point between SGW and PGW. The S5 interface is used when the SGW and
PGW are part of the same network. The S8 interface is used in roaming scenarios where the SGW is located in
the visiting network and the PGW is located in the home network.
These interfaces provide support for user plane tunneling and tunnel management between SGW and PGW. They
support the creation of control sessions per UE per PDN connection as well as the creation, modification and
deletion of individual user data tunnels. These interfaces are also used for SGW relocation due to UE mobility,
in the case where the UE moves to an area served by a different SGW.
The S5/S8 interface supports both control plane and user plane functions.
The PGW:
Allocates an IP address per PDN for the UE during initial attachment
Applies the quality of service rules received from PCRF for a given connection
Allows a law enforcing agency to receive information regarding user data
Serves as the mobility anchor during handovers between LTE and non-3GPP access networks (e.g. CDMA/HRPD)
May perform packet filtering on a per-user basis by implementing deep packet inspection for example.
S6a Interface
The S6a interface carries control traffic between the MME and the Home Subscriber Server (HSS). The HSS is the
master database that contains subscriber AAA information, and the MME uses the HSS to validate the
subscribers access to the network and the services they can use. The HSS stored information includes:
Authentication key for the UE allowing it to authenticate the user at registration time.
A list of networks and services that the UE is allowed to access, along with their corresponding QoS parameters
and charging characteristics.
Up-to-date information regarding the users location and IP information which could be needed by various
network entities
(continued on the next page...)
Model 1 EPC Element Traffic Flows S5, S6a, S11, and Gx
The X2 interface supports inter-eNodeB traffic

It supports inter-eNodeB UE handoff and load management
This traffic is routed at the MLS User IES interfaces
Module 3 |
89
Model 1 X2 Interface for eNodeB to eNodeB Traffic

X2 Interface
X2 is the reference point between 2 eNodeBs. When a UE moves from one eNodeB to another and both are served
by the same MME, an X2 handover procedure is performed. This traffic is routed at the MLS IES interfaces.
Model 1 X2 Interface for eNodeB to eNodeB Traffic
Model 1 - Create the MLS eNodeB and MME IES Services

A:MLS1>config>service# ies
ies
A:MLS1>config>service>ies$
2000
2000 customer
customer 11
description
description L3
L3
create
create
MME-1
MME-1 VRRP
VRRP VPLS"
VPLS"
ies 4000
4000 customer
customer 11 create
create
A:MLS1>config>service>ies$ description
description eNodeB
eNodeB IES"
IES"
A:MLS1>config>service>ies$ no
no shutdown
shutdown
ies 2000
2000 customer
customer 11 create
create
description "" L3
L3 MME-1
MME-1 VRRP
VRRP VPLS
VPLS ""
no shutdown
shutdown
ies 4000
4000 customer
customer 11 create
create
description "eNodeB
"eNodeB IES"
IES"
no shutdown
shutdown
Create the eNode and MME VPLS IES on MLS1 and MLS2
One IES for eNodeB telecom (user and control) and OAM traffic
One for MME Pool routed traffic
Module 3 |
90
no shutdown
shutdown
The eNodeB IES includes interfaces for telecom and OAM traffic
Each interface is tied to a return CSA spoke SDP
Each interface defines the interface MAC and eNodeB static ARP
cache entries
A:MLS1>config>service>ies#
A:MLS1>config>service>ies# interface
interface toEnodeB_1_telecom
toEnodeB_1_telecom create
create
A:MLS1>config>service>ies>if$
A:MLS1>config>service>ies>if$ spoke-sdp
spoke-sdp 1:100
1:100 create
create
A:MLS1>config>service>ies>if>spoke-sdp$
A:MLS1>config>service>ies>if>spoke-sdp$ back
back
A:MLS1>config>service>ies>if$ address
address 192.0.2.176/31
192.0.2.176/31
A:MLS1>config>service>ies>if$ mac
mac 00:00:01:00:01:01
00:00:01:00:01:01
A:MLS1>config>service>ies>if$ static-arp
192.0.2.177 00:00:01:00:01:02
00:00:01:00:01:02
A:MLS1>config>service>ies>if$ back
back
interface toEnodeB_1_OAM
toEnodeB_1_OAM
A:MLS1>config>service>ies>if$ spoke-sdp
spoke-sdp 1:101
1:101 create
create
A:MLS1>config>service>ies>if>spoke-sdp$
A:MLS1>config>service>ies>if>spoke-sdp$ back
back
A:MLS1>config>service>ies>if$ ip-address
ip-address 192.0.2.178/31
192.0.2.178/31
mac
mac 00:00:01:00:01:03
00:00:01:00:01:03
static-arp
192.0.2.179 00:00:01:00:01:04
00:00:01:00:01:04
back
Module 3 |
91
Model 1 - Create the MLS eNodeB IES Interfaces

The eNodeB IES includes two spoke SDP interfaces for each eNodeB, one for telecom and one for OAM traffic. The
interfaces statically define the interface MAC addresses and include eNodeB static ARP cache entries.
The IES interfaces are advertised by the IGP via a routing policy, shown later in this section.
The active CSA ePipe spoke SDP forwards traffic toward the MLS routers, and the EPC element-facing interfaces
are IGP advertised. Hence, the MLS can find the destination network, regardless of the active EPC element
interface.
Model 1 - Create the MLS eNodeB IES Interfaces
Model 1 Set the IES Service VC-MTU
or
interface eNodeB_telecom
eNodeB_telecom
A:MLS1>config>service>ies>if#
A:MLS1>config>service>ies>if# ip-mtu
ip-mtu 1500
1500
A:MLS1>config>service>ies>if#
A:MLS1>config>service>ies>if# back
back
The IES signals a VC-MTU for the spoke SDPs; the VC-MTU must be
compatible with the ePipe service MTU
An L3 service has no service MTU; the default signaled VC-MTU is
based on the SDP path MTU (path MTU - 14 bytes)
An L2 service VC-MTU equals the service MTU - 14 bytes (1500
bytes for a default VPLS or ePipe service)
Setting the spoke SDP interface IP-MTU overrides the SDP path
MTU
Module 3 |
92
Model 1 Set the IES Service Interface MTU Size

MTU Concerns
The PEs signal service VC-MTUs when they signal service labels. The VC-MTU is not configurable; on an L2 service.
it is based on the service MTU minus the encapsulation overhead. On an ePipe service, this is 1514-14=1500.
If the L2 and L3 VC-MTUs dont match, the spoke SDPs will remain operationally down. Potentially, the L3 service
could deliver to the spoke SDP a payload larger than the ePipe service MTU, and the ePipe service will not
fragment L2 payloads.
To ensure that the signaled VC-MTUs are compatible at both ends, you can either set on the MLS an SDP path MTU
or an interface IP-MTU. The path MTU applies to all services bound to the SDP, but the IP-MTU only applies on a
per interface basis. The IP-MTU overrides the path MTU.
The choice is up to the designer, and there are pros and cons to each approach.
SDP path MTU Setting the SDP path MTU affects all the services bound to the SPD. Potentially, an L2 services
MTU may exceed the path MTU, which is not allowed by SROS. By default, L2 services set the service MTU to 1514
bytes, but if you plan to carry tagged payloads, you might adjust the service MTU to some greater value. In this
case, you would need another set of SDPs which would support the greater service MTU.
Since setting the SDP path MTU effects all bound services, all L3 spoke SDP bindings inherit this path MTU. Hence,
the interfaces IP-MTU conforms to the ePipe service MTU, and the spoke SDPs can become operational.
IES interface IP-MTU You may set the interface IP-MTU. The IES has no service MTU, but by setting the
appropriate IP-MTU on a per interface basis, you can ensure the MLS router signals a compatible VC-MTU for the
spoke SDP bindings.
For a spoke SDP interface with the default L2 service MTU set, the IP-MTU should equal the IP payload minus the
Ethernet frame header, or 1514-14=1500 bytes. If you adjust the L2 service MTU, the L3 IP MTU must still equal
the L2 service MTU minus the frame header.
Since this is a per interface setting, you must set it individually on each spoke SDP interface.
A:MLS1>config>service>sdp#
A:MLS1>config>service>sdp# path-mtu
path-mtu 1514
1514
The MME IES provides an MME VRRP virtual gateway interface

CCAGs tie the IES to the MME VPLS
All routing is handled by the MLS switch fabric, there are no
physical IES interfaces
interface L3
L3 MME
MME VPLS
VPLS interface
interface
A:MLS1>config>service>ies>if$ sap
sap ccag-1.a:2000
ccag-1.a:2000 create
create
A:MLS1>config>service>ies>if>sap$
A:MLS1>config>service>ies>if>sap$ back
back
A:MLS1>config>service>ies>if$ address
address 192.0.2.97/27
192.0.2.97/27
A:MLS1>config>service>ies>if$ tos-marking-state-trusted
tos-marking-state-trusted
A:MLS1>config>service>ies>if$ vrrp
vrrp 10
10
A:MLS1>config>service>ies>if>vrrp$
A:MLS1>config>service>ies>if>vrrp$ backup
backup 192.0.2.99
192.0.2.99
A:MLS1>config>service>ies>if>vrrp$ no
no preempt
preempt
A:MLS1>config>service>ies>if>vrrp$ ping-reply
ping-reply
A:MLS1>config>service>ies>if>vrrp$ back
back
back
Module 3 |
93
Model 1 - Create the MLS MME VPLS IES Interfaces

The MLS MME VPLS IES provides a VRRP protected interface for the MME.
tos-marking-state trusted An interfaces trust nature determines how the router handles CoS markings as
traffic exits the interface. The default behavior for various interfaces is as follows:
VPLS/VLL SAP Always untrusted. Remark the Layer 2 PDU, leaving Layer 3 markings untouched.
IES SAP Default untrusted. If set to the default, remark the packet according to the Network QoS policies.
VPRN SAP Default trusted. Leave the IP packet markings as they were set on service ingress.
Network port Default trusted. Only remark if so configured.
By default, the router remarks packets as they egress an IES interface. Setting the interface to trusted ensures
that the packets retain their CoS markings as they leave the service toward the next hop.
Model 1 - Create the MLS MME VPLS IES Interfaces
Model 1 - Verifying the MLS IES 2000 Service
===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 2000
Vpn
:: 00
Service Id
Id
2000
Vpn Id
Id
Service
:: IES
Service Type
Type
IES
Name
:: (Not
Name
(Not Specified)
Specified)
Description
:: L3
Description
L3 MME-1
MME-1 VRRP
VRRP VPLS
VPLS
Customer
:: 11
Customer Id
Id
Last
Last Status
Status Change:
Change: 09/28/2011
09/28/2011 09:01:51
09:01:51
Last
Last Mgmt
Mgmt Change
Change :: 09/28/2011
09/28/2011 08:58:35
08:58:35
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
SAP
:: 11
SAP Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:ccag-1.a:2000
q-tag
9212
9212
Up
Up
sap:ccag-1.a:2000
q-tag
9212
9212
Up
Up
===============================================================================
===============================================================================
Module 3 |
94
Model 1 Verifying the MLS IES 2000 Service

A:MLS1#
A:MLS1# show
show service
service id
id 2000
2000 base
base
Model 1 - Verifying the MLS IES 4000 Service
===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 4000
Vpn
:: 00
Service Id
Id
4000
Vpn Id
Id
Service
:: IES
Service Type
Type
IES
Name
:: (Not
Name
(Not Specified)
Specified)
Description
:: eNodeB
Description
eNodeB IES
IES
Customer
:: 11
Customer Id
Id
Last
Last Status
Status Change:
Change: 09/28/2011
09/28/2011 08:59:04
08:59:04
Last
Last Mgmt
Mgmt Change
Change :: 09/28/2011
09/28/2011 08:58:35
08:58:35
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
SAP
:: 00
SAP Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sdp:1:100
Spok
1514
1514
Up
Up
sdp:1:100 S(192.0.2.2)
S(192.0.2.2)
Spok
1514
1514
Up
Up
sdp:1:101
Spok
1514
1514
Up
Up
sdp:1:101 S(192.0.2.2)
S(192.0.2.2)
Spok
1514
1514
Up
Up
===============================================================================
===============================================================================
Module 3 |
95
Model 1 Verifying the MLS IES 4000 Service

AdmMTU: - This represents the SDP path MTU. Without the interface IP-MTU set, MLS1 signals the VC-MTU for
each spoke SDP binding as the SDP path MTU minus 14 bytes.
A:MLS1#
A:MLS1# show
show service
service id
id 4000
4000 base
base
Module 3 |
96
Model 1 LTE Services Detailed View

The detail above, shows the services and service features used to support 4G LTE voice, data, control, and OAM
traffic.
CSA1 to MLS ePipes
For each eNodeB, the CSA hosts two redundant ePipe services, one for user traffic and one for eNodeB OAM
functions.
MLS eNodeB IES
IES 4000 terminates the ePipe spoke SDPs. The MLS routes all eNodeB traffic via the routers base routing instance.
The service includes both telecom and OAM eNodeB interfaces, and each ePipe endpoint is assigned either a /30
or /31 mask. Defined in the service are the interfaces MAC addresses and eNodeB static ARP entries.
MLS MME IES
IES 2000 provides VRRP-protected MME interfaces. This service has just a single CCAG interface, cross connected
to the MME VPLS.
MLS MME VPLS
VPLS 100 supports multiple MMEs connected to the same broadcast domain. Additionally, the inter-chassis SAP
supports the VRRP instance protected the MME IES interfaces.
Network Interfaces
The MLS hosts a number of network interfaces defined all in the base routing context supporting SGW, PGW, PCRF,
MME maintenance and OAM, network management, and distribution network functions.
Model 1 LTE Services Detailed View
Section Review
Observed the LTE interfaces flows through the Model 1 network
eNodeB S1-U and X2 through the distributed ePipe and IES to
the desination EPC elements
eNodeB S1-MME through the ePipe and MME-IES into the MME
VPLS
EPC element flows - S5, s6a, S11, and Gx through the MLS IES
interfaces
Configured the IES interfaces for LTE traffic
Module 3 |
97
Reviewed the Model 1 LTE services

Section 5 Service Resiliency in the Model 2 Network
Section Objectives
Investigate MC-LAG as the feature might be used to protect multihomed Ethernet NC elements
Deploy Interchassis Backup Pseudowires (ICB-PW) to avoid blackholing traffic destined to the standby multi-chassis peer
Provision MC-APS for MLS SONET/SDH protection
Module 3 |
100
Implement pseudowire switching to support traffic engineering

and control FIB sizes across IGP areas
PW switching ties spoke SDPs together across routing areas or protocols and
different MPLS protocols
It improves scalability by removing the need for a full mesh of SDPs
between the CSA and POC1 routers
It is supported on all VPWS services
The Switching PE (S-PE) ties the spoke SDPs together, while the
Terminating PEs (T-PE) terminate the services
Module 3 |
101
Pseudowire Switching across Routing Areas

The Model 2 network divides the access and aggregation rings into different ISIS levels. This helps to limit control
plane traffic and FIB sizes. However, since traffic engineering does not work across routing areas, an approach is
needed to ensure the use of admin groups, FRR, and other TE techniques.
Pseudowire switching uses an intermediate PE router as a switching PE (S-PE), breaking the service into segments.
The S-PE ties two spoke SDPs together in a VPWS service context, swapping the vc-label as traffic enters on one
spoke SDP and exits on another. It has no SAP endpoints, and only two spoke SDPs endpoint objects. The network
can have many S-PEs.
A terminating PE (T-PE) originates and terminates the service. These provide the SAP endpoints, and may use PW
redundancy and ICB-PW, as well. In fact, all of these may be used in the Model 2 network design.
S-PE Function
You create the S-PE function in the VPWS context, using the vc-switching command.
A:NodeA# configure service epipe 3 customer 1 vc-switching create
The vc-switching keyword allows only two endpoint objects, both spoke SDPs, and they should each terminate on
the T-PE routers.
For label mapping, the S-PE:
Acts as a slave to the T-PEs for PW signaling.
Waits for labels from the T-PEs. These messages pass SAP MTUs and other information the S-PE must relay to
the opposite T-PE.
Appends a PW switching point TLV to the FEC TLV, recording its system address.
For status messages, the S-PE:
Can process and relay status messages generated by the T-PE or generate them itself.
Appends the PW switching TLV to messages it originates (Notification and Label Mapping) or to messages it
receives with this TLV (from another S-PE)
Sends status unchanged if both S-PE spoke SDPs are up, sends SDP-binding down if one of the local spoke SDPs
is down
Sends the vc-id of the next PW segment in the PW switching TLV
Model 2 - Pseudowire Switching across Routing Areas
The T-PE routers signal service labels upstream toward the S-PE
The S-PE signals labels towards the next hop only after it receives
a label message from a downstream router (ordered control)
The S-PE includes the previous segments vc-id and its own
system ID as well as the PW status bits
Module 3 |
102
Message Propagation in a Switched PE

The S-PE only propagates service label mapping messages it receives from the T-PE routers. Here, MLS1 is the
originating T-PE, and once the service becomes operational it sends a service label mapping message to the next
upstream router, POC3-1, the S-PE. POC2-1 only acts as an LSR.
POC3-1 generates its own service label mapping message and sends it to the other T-PE, CSA1. It includes the PW
switching TLV, and includes the previous vc-id and its own System ID.
CSA1 receives the label mapping message and, once its end is configured and operational, can forward traffic
toward MLS1.
Label Actions at the S-PE
The S-PE swaps both the MPLS transport labels and the VC labels. POC2 only swaps the MPLS transport label.
PW Status Messages
The S-PE relays T-PE router-generated status messages and generates status messages of its own.
The S-PE must notify the T-PEs and other S-PEs (if part of the service) of the status of its own spoke SDPs.
Assuming one of the S-PE router spoke SDPs were to fail, the S-PE would send a PW status message to its peer
indicating the spoke SDP is down. It appends to this message the PW switching TLV.
The S-PE must forward notification messages it receives from the T-PEs. For example, if the MC T-PE were to
signal a change on the active SAP, it would signal this in a PW status message to the S-PE. Since this status
affects CSA1s choice of redundant spoke SDPs, the S-PE must forward this message to CSA1. Again, the S-PE
appends the PW switching TLV.
As do the T-PEs, the S-PE must compare the local and remote spoke SDP status to determine the local spoke SDP
state.
Switched PW Message Propagation
Configuring PW Switching
Context:
Context: config>service#
config>service#
[no]
[no] epipe
epipe <service-id>
<service-id> customer
customer <customer-id>
<customer-id> vc-switching
vc-switching create
create
Context:
Context: config>service>epipe#
Syntax:
Syntax:
[no]
[no] spoke-sdp
spoke-sdp <sdp-id:vc-id>
<sdp-id:vc-id> create
create
Example:
Example: config>service#
config>service# epipe
epipe 33 customer
customer 11 vc-switching
vc-switching create
create
config>service>epipe$
spoke-sdp
1:1
config>service>epipe$ spoke-sdp 1:1 create
create
back
spoke-sdp 4:2
4:2 create
create
back
config>service>epipe# no
no shutdown
shutdown
The vc-switching keyword configures the S-PE

The service remains down until both spoke SDPs become
operational
No SAPS and only two spoke SDPs allowed
Module 3 |
103
Configuring PW Switching
Configure the PW switching services as follows:
1. Configure an ePipe on the T-PEs.
Configure the ePipe on the T-PEs as you would any VPWS service. If the T-PE is a MC peer and you plan to use
ICB-PWs, configure the service with the MC-APS or MC-LAG SAPs. We discuss MC-LAG, MC-APS, and ICB-PW use
later in this section.
If the T-PE originates redundant PWs, then configure them as we discussed in previous sections.
The spoke SDP targets will be the S-PEs, rather than the opposite T-PE.
2. Configure the S-PE.
Shown above are the configuration commands for the S-PE, POC3-1. The service remains down until the S-PE
receives labels from the T-PEs, or another S-PE.
The S-PE will not distribute labels until both its spoke SDPs are up. That means that though its spoke SDP to TPE1 is up, and it has received and signaled a label to T-PE1, it will not signal a label to T-PE2 until it receives a
label from T-PE2, as well.
Syntax:
Syntax:
A:POC3-1#
A:POC3-1# show
show service
service id
id 33 base
base
===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 33
Vpn
:: 00
Service Id
Id
Vpn Id
Id
Service
:: Epipe
Service Type
Type
Epipe
...
...
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
MTU
:
1514
MTU
: 1514
Vc
:: True
Vc Switching
Switching
True
SAP
Count
:: 00
SDP
:: 22
SAP Count
SDP Bind
Bind Count
Count
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sdp:1:1
Spok
00
1550
Up
sdp:1:1 S(192.0.2.2)
S(192.0.2.2)
Spok
1550
Up Up
Up
sdp:4:2
Spok
00
1550
Up
sdp:4:2 S(192.0.2.128)
S(192.0.2.128)
Spok
1550
Up Up
Up
===============================================================================
===============================================================================
Module 3 |
104
View the S-PE Service Status

Vc Switching: Shows that vc-switching is enabled on the service.
Identifier: - List the spoke SDPs included in the service.
View the S-PE Service Status
Access Redundancy in the Model 2 Network

Multi-chassis-Link Aggregation Group (LAG)
Interchassis Backup-Pseudowire (ICB-PW)
Multi-chassis-Automatic Protection Switching (MC-APS}

SROS supports MC-LAG only on Ethernet MDAs

MC-LAG provides link and node redundancy for CE devices
Supports access redundancy for two PE devices
To the CE device, the MC-LAG member PEs appear as a single
LACP peer
The first MC peer up becomes the active PE
Module 3 |
106
Multi-Chassis LAG (MC-LAG)

Multi-Chassis LAG provides redundant Ethernet access connectivity, beyond physical link level protection, by
extending logical LAG connectivity to redundant PE routers.
From the CEs point of view, the redundant PEs are a single Link Access Control Protocol (LACP) endpoint. The
MC-LAG protocol on the PE routers synchronizes the forwarding planes to and from the CE peer, including
synchronizing the link states between the two PEs to ensure proper LACP messaging across both links.
MC-LAG Characteristics
MC-LAG is an SROS proprietary solution to providing both link and nodal redundancy on Ethernet access links.
It is transparent to the CE device and customer. The MC-LAG configuration and control protocol are only
deployed in the PE routers. No functional changes are required on the CE device LAGs.
No MPLS or service is required on the CE devices. The CE connects to the service through an Ethernet LAG, as
if it was connected to a single chassis.
There is no need to run Spanning Tree Protocol or a management VPLS. The MC-LAG protocol ensures only one
CE-PE link is active at a time.
Inter-chassis signaling
The MC-LAG protocol signals the LAG member status between the two chassis. It is a routed protocol, using UDP
port 1025.
As a routed protocol, it doesnt require the peers to be directly connected. The peer address is either the
peers system ID, interface, or a loopback interface address, and must be IP reachable.
It provides a heartbeat for robustness and failure detection.
It supports operator actions to force an operational change.
It ensures consistent LAG system-ID, administrative-key, and system priority configuration between the peers.
These values must match to avoid signaling incorrect information to the CE device.
It is encrypted with Message Digest 5 (MD5) encryption.
Active PE selection
The first PE up becomes the active PE. You can adjust the port priorities on one PE to make it the preferred
active MC-LAG member. Then, if all active port numbers match, the nodes choose by a calculated weight
value.
Multi-Chassis LAG (MC-LAG)
Based on IEEE 802.3ad

LACP messages are sent over each link every 1 s (fast) or 30 s
(slow).
Uses the OSSP destination MAC (01:80:C2:00:00:02).
Three parameters uniquely identify a LAG instance to the local
node:
LACP key - default 32768 for first LAG. Must be set for MC-LAG
System ID - derived from base MAC address or set specifically for
MC-LAG
System priority - default 32768. Must be set for MC-LAG
Actor (self) and Partner (other side of the link) info is contained in
every LACP packet.
The actor initiates LACP packet exchange
Alcatel-Lucent Virtual Private LAN Services v2.0
Module 3 |
107
LACP Basics
LACP is based on the IEEE 802.3ad standard. LACP messages are carried in IEEE OSSP frames (see Module 2,
SyncE/SSM). Each LAG instance includes:
LACP key The default is 32768. These must match between the MC-LAG peers and the peer CE.
System-ID Derived from the chassis MAC by default, but must be configured on an MC-LAG.
System priority Default is 32768, but must be set on an MC-LAG.
The LACP actor is the active side of the LAG, while the partner is the passive side. The actor initiates LACP packet
transmission.
LACP Basics
A:MLS1>config>lag#
A:MLS1>config>lag# info
info
------------------------------------------------------------------------------------------mode
mode access
access
port
port 1/1/1
1/1/1 priority
priority 100
100
port
port 1/1/2
1/1/2 priority
priority 100
100
lacp
active
lacp active administrative-key
administrative-key 32768
32768
no
no shutdown
shutdown
------------------------------------------------------------------------------------------*A:PE1>config>redundancy>multi-chassis#
*A:PE1>config>redundancy>multi-chassis# info
info
------------------------------------------------------------------------------------------peer
peer 10.0.0.2
10.0.0.2 create
create
mc-lag
mc-lag
lag
lag 11 lacp-key
lacp-key 11 system-id
system-id
00:00:00:00:00:01
00:00:00:00:00:01 system-priority
system-priority 100
100
no
no shutdown
shutdown
exit
exit
exit
exit
-------------------------------------------------------------------------------------------
Create on each MC peer

Key, system ID, and systempriority must match
Can assign port priority to
control active peer
*A:MLS2>config>lag#
*A:MLS2>config>lag# info
info
------------------------------------------------------------------------------------------mode
mode access
access
port
port 1/1/1
1/1/1
port
port 1/1/2
1/1/2
lacp
lacp active
active administrative-key
administrative-key 32768
32768
no
no shutdown
shutdown
------------------------------------------------------------------------------------------*A:PE2>config>redundancy>multi-chassis#
*A:PE2>config>redundancy>multi-chassis# info
info
------------------------------------------------------------------------------------------peer
peer 10.0.0.1
10.0.0.1 create
create
mc-lag
mc-lag
lag
lag 11 lacp-key
lacp-key 11 system-id
system-id
00:00:00:00:00:01
00:00:00:00:00:01 system-priority
system-priority 100
100
no
shutdown
no shutdown
exit
exit
exit
exit
-------------------------------------------------------------------------------------------
Module 3 |
108
MC-LAG on PE Nodes
When configuring an MC-LAG across two PE devices, you must inform the PE devices of their peer using the
multi-chassis peer command. In addition, LACP keys, System ID MAC addresses, and priorities must be
equal.
When configuring MC-LAG on the PEs, you do need to specify matching keys. This differs from setting up standard
LAGs, where the system sets up the LACP keys.
A:NodeA>config>redundancy>multi-chassis# peer 10.10.10.12 create
A:NodeA>config>redundancy>multi-chassis>peer# mc-lag
A:NodeA>config>redundancy>mc>peer>mc-lag# lag 1 lacp-key 1 system-id 00:00:00:00:00:01
system-priority 100
A:NodeA>config>redundancy>mc>peer>mc-lag# no shutdown
A:NodeA>config>redundancy>mc>peer>mc-lag# back
A:NodeA>config>redundancy>multichassis>peer# no shutdown
LAG on the CE Nodes
The CE node configuration is a standard LAG with LACP enabled.
A:CR1>config>lag# info
---------------------------------------------mode access
port 1/1/5
port 1/1/6
port 1/1/7
port 1/1/8
lacp active administrative-key 32768
no shutdown
---------------------------------------------Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0
MC-LAG on the Remote PEs
On the MLS router, the MC-LAG LAG groups become the CE SAPs
The remote PEs signal LAG member status as SAP status
The local PE, CSA1, chooses the spoke SDP associated with the
active remote MC-LAG PE
Module 3 |
109
PW Redundancy and MC-LAG

Pseudowire redundancy combined with MC-LAG protects both the pseudowire and the CE access interfaces. If the
active MC-LAG links become unavailable, the CSA can choose the redundant PE spoke SDP, following the active
SAP state.
LAG SAP states
Shown above, the MC-LAG protocol chooses MLS1 as the active MC-LAG PE. By default, this is the first MC-LAG peer
to become operational. MLS1 signals its service SAP and spoke SDP is up, status 0x0. At the same time, MLS2 is
the standby MC-LAG PE, and it signals its spoke SDP in standby but its SAP is down, 0x26. CSA1 chooses spoke
SDP 1:1 over spoke SDP 2:1 on the merits of the better remote status reported by MLS1.
A:CSA1# show service id 1 sdp detail
...
===============================================================================
Services: Service Destination Points Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 1:1
-(192.0.2.0)
...
Peer Pw Bits
: None
...
------------------------------------------------------------------------------Sdp Id 2:1
-(192.0.2.1)
...
Peer Pw Bits
: lacIngressFault lacEgressFault pwFwdingStandby
If the MC-LAG were to change states and the MLS2 LAG became active, then MLS1 would signal its spoke SDP as
standby and SAP down, and CSA1 would choose the backup spoke SDP to MLS2, assuming a better status.
PW Redundancy and MC-LAG
A:CSA1#
A:CSA1# show
show router
router ldp
ldp bindings
bindings detail
detail
...
...
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Type
:: E-Eth
VcId
:: 11
Type
E-Eth
VcId
SvcId
:
1
SdpId
:: 11
SvcId
: 1
SdpId
Peer
:: 192.0.2.0
Vc-switching
:: No
Peer Address
Address
192.0.2.0
Vc-switching
No
LMTU
:
1500
RMTU
:
LMTU
: 1500
RMTU
: 1500
1500
Egr.
:: 131059S
Egr.
:: No
Egr. Lbl
Lbl
131059S
Egr. Ctl
Ctl Word
Word
No
Egr.
:: None
Egr.
Egr. Flags
Flags
None
Egr. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
Ing.
:: 131070U
Ing.
:: No
Ing. Lbl
Lbl
131070U
Ing. Ctl
Ctl Word
Word
No
Ing.
:: None
Ing.
Ing. Flags
Flags
None
Ing. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
------------------------------------------------------------------------------------------------------------------------------------------------------------Type
:: E-Eth
VcId
:: 11
Type
E-Eth
VcId
SvcId
:
1
SdpId
:: 22
SvcId
: 1
SdpId
Peer
:: 192.0.2.1
Vc-switching
:: No
Peer Address
Address
192.0.2.1
Vc-switching
No
LMTU
:: 1500
RMTU
:: 1500
LMTU
1500
RMTU
1500
Egr.
:: 131058D
Egr.
:: No
Egr. Lbl
Lbl
131058D
Egr. Ctl
Ctl Word
Word
No
Egr.
:: None
Egr.
Egr. Flags
Flags
None
Egr. Status
Status Bits
Bits :: Supported
Supported (0x26)
(0x26)
Ing.
:: 131068U
Ing.
:: No
Ing. Lbl
Lbl
131068U
Ing. Ctl
Ctl Word
Word
No
Ing.
:: None
Ing.
Ing. Flags
Flags
None
Ing. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
...
...
Module 3 |
110
View the Local PE Spoke SDP States

A:NodeA# show router ldp bindings detail
MLS1 signals status 0x0, indicating that both its spoke SDP and SAP are up.
Egr. Lbl: - On the egress label for peer 192.0.2.1, D indicates the peer signaled the spoke SDP status down,
indicating the service SAP is down (standby MC-LAG member) and the service is down.
Egr. Status Bits: - Shows the status signaled by the remote PE.
Ing. Status Bits: - Shows the local SAP status signaled to the remote PE.
View the Local PE Spoke SDP States
MLS1 SDP1 fails

Spoke SDP 1:1 fails and the local PE moves traffic to the
secondary spoke SDP (it will forward as long as the spoke SDP is
up)
MLS2s LAG SAP is still in standby, so MLS2 black-holes packets
SAP state doesnt follow SDP state
Module 3 |
111
PW Redundancy and MC-LAG Spoke SDP 1:1 Failure

Spoke SDP states
The configuration shown ties the MC-LAG SAP state to the spoke SDPs, but does it tie the spoke SDP states to the
SAP? In other words, a change in the LAG state affects the signaled spoke SDP state, but a change in the spoke
SDP state doesnt change the remote SAP state.
What would the traffic flow looks like if MLS1 were the active MC-LAG PE, but the spoke SDPs between CSA1 and
MLS1 were down?
Failure on the MLS1-CE LAG
If a failure occurs on the active MC-LAG, MLS1 signals CSA1 that its spoke SDP is in standby and that its SAP failed
(0x26).
When MLS2 becomes the active MC-LAG PE, it signals CSA1 that both its SAP and its spoke SDP (as a result of the
SAP becoming active) are up.
The local PE chooses the active spoke SDP based on the remote PEs SAP status.
Once the LAG recovers, depending on the LAGs configuration, the MLS1 spoke SDP becomes active again.
Failure on SDP1
If a failure occurs on spoke SDP 1:1, CSA1 will remove all labels for MLS1s FEC.
This causes CSA1 to switch traffic to the backup spoke SDP. However, the active MC-LAG PE is still MLS1. The
MLS2 spoke and SAP have not changed states from those it originally signaled (0x26).
PW Redundancy and MC-LAG Spoke SDP 1:1 Failure
A:CSA1# show router ldp bindings detail

A:CSA1# show router ldp bindings detail
...
...
===============================================================================
===============================================================================
LDP Service FEC 128 Bindings
LDP Service FEC 128 Bindings
===============================================================================
===============================================================================
------------------------------------------------------------------------------------------------------------------------------------------------------------Type
: E-Eth
VcId
: 1
Type
: E-Eth
VcId
: 1
SvcId
: 1
SdpId
: 2
SvcId
: 1
SdpId
: 2
Peer Address
: 192.0.2.1
Vc-switching
: No
Peer Address
: 192.0.2.1
Vc-switching
: No
LMTU
: 1500
RMTU
: 1500
LMTU
: 1500
RMTU
: 1500
Egr. Lbl
: 131058D
Egr. Ctl Word
: No
Egr. Lbl
: 131058D
Egr. Ctl Word
: No
Egr. Flags
: None
Egr. Status Bits : Supported (0x26)
Egr. Flags
: None
Egr. Status Bits : Supported (0x26)
Ing. Lbl
: 131068U
Ing. Ctl Word
: No
Ing. Lbl
: 131068U
Ing. Ctl Word
: No
Ing. Flags
: None
Ing. Status Bits : Supported (0x0)
Ing. Flags
: None
Ing. Status Bits : Supported (0x0)
===============================================================================
===============================================================================
No.
No. of
of VC
VC Labels:
Labels: 11
...
...
The failure on the primary spoke SDP did not cause a signaled
status change on the secondary spoke SDP
MLS2 still indicates its SAP is down (0x26)
Module 3 |
112
PW Redundancy and MC-LAG Spoke SDP 1:1 Failure (cont)

A:NodeA# show router ldp bindings detail
MLS2 signals status 0x26, indicating that both its spoke SDP and SAP are up.
Egr. Lbl: - On the egress label for peer 192.0.2.1, D indicates the peer signaled the spoke SDP status down,
indicating the service SAP is down (standby MC-LAG member) and the service is down.
Egr. Status Bits: - Shows the status signaled by the remote PE.
Ing. Status Bits: - Shows the local SAP status signaled to the remote PE.
===============================================================================
===============================================================================
Service Basic Information
Service Basic Information
===============================================================================
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Service Type
: Epipe
...
...
Admin State
: Up
Oper State
: Down
Admin State
: Up
Oper State
: Down
MTU
: 1514
MTU
: 1514
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
Service Access & Destination Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:lag-2
null
1514
1514
Up
sap:lag-2
null
1514
1514
Up Down
Down
sdp:1:1
Spok
00
1550
Up
sdp:1:1 S(192.0.2.2)
S(192.0.2.2)
Spok
1550
Up Up
Up
===============================================================================
===============================================================================
With the LAG SAP in standby, MLS2 shows its ePipe status down
MLS2 black holes any traffic arriving over the active spoke SDP
Module 3 |
113

The MLS2 ePipe remains operationally down. Though traffic arrives over the active secondary spoke SDP, the MLS1
LAG 2 port is in standby, keeping the SAP down. Since the SAP is down, the service is down, and MLS2 drops any
traffic arriving from CSA1.
A:MLS2# show service id 1 base

Interchassis Backup Pseudowire (ICB-PW)
SAP
SAP icb
icb
SPOKE
SPOKE
SPOKE
SPOKE icb
icb
ePipe
ePipe 11
endpoint
endpoint SAP
SAP
sap
sap lag-2
lag-2 endpoint
endpoint SAP
SAP
spoke-sdp
spoke-sdp 3:1
3:1 endpoint
endpoint SAP
SAP icb
icb
endpoint
SPOKE
endpoint SPOKE
spoke-sdp
spoke-sdp 1:1
1:1 endpoint
endpoint SPOKE
SPOKE
spoke-sdp
spoke-sdp 3:2
3:2 endpoint
endpoint SPOKE
SPOKE icb
icb
Interchassis backup PW ensures last resort path to destination

Used in case all other redundancy fails
Sends traffic between chassis over interchassis spoke SDPs
Each MC peer VPWS includes two endpoints, one for the spoke
SDP to CSA1 and one for the MC-LAG SAP, each with a backup
spoke SDP
Module 3 |
114
Interchassis Backup Pseudowire (ICB-PW)

In the previous example, the MC-LAG protected the CE links, and PW redundancy protected the distributed
service. However, nothing ties the spoke SDP status to the MC-LAG status, and thus a situation can exist where
the local PE chooses to forward traffic to a remote PE which cannot forward it on to the CE. However, SROS
supports a special type of PW called an Interchassis Backup PW (ICB-PW), that is used only on routers with
multi-chassis protected SAPs.
ICB-PW can protect the service and SAPs by providing a path between the MC-LAG PE routers in the case where
traffic enters the service on one PE and exits toward the CE on the opposite MC peer. It may be used in ePipe,
aPipe, iPipe, or cPipe services.
A VPWS has two implicit endpoints, a SAP and a spoke SDP or two SAPs. Forwarding rules state that the switch
fabric will only forward traffic between objects in different endpoints.
An ICB-PW provides a backup to an object associated with the same endpoint. In the ICB-PW, you must explicitly
define the endpoints, as we did on the redundant PWs, but now you must define two.
SAP endpoint
To create an ICB-PW, one endpoint must contain a LAG (or APS) SAP object. The SAP endpoint can contain an ICB
spoke SDP as a backup. Only one endpoint object can be forwarding at a time.
SDP endpoint
The second endpoint contains the remote PE spoke SDP. It can contain an ICB spoke SDP as a backup, as well.
When the service is configured, it contains two endpoints, one for the SAP and its backup, and one for the remote
spoke SDP and its backup. Both backup spoke SDPs terminate on the MC peer PE.
ICB endpoints
An ICB-PW in endpoint SAP on PE1 must cross connect to endpoint SPOKE on PE2, and the ICB-PW on endpoint SAP
on PE2 must cross connect to endpoint SPOKE on PE1.
For example, on PE1 and PE2 you create two spoke-SDPs, 3:1 and 3:2. Knowing that the VC-IDs on the spoke SDPs
must match on each end, you use 3:1 as the ICB-PW for PE1s SPOKE endpoint, and 3:2 for PE1s SAP endpoint.
On PE2, you use 3:1 in the SAP endpoint, and 3:2 in the SPOKE endpoint.
ePipe
ePipe 11
endpoint
endpoint SAP
SAP
sap
sap lag-2
lag-2 endpoint
endpoint SAP
SAP
spoke-sdp
spoke-sdp 3:2
3:2 endpoint
endpoint
endpoint
SPOKE
endpoint SPOKE
spoke-sdp
spoke-sdp 1:1
1:1 endpoint
endpoint
spoke-sdp
spoke-sdp 3:1
3:1 endpoint
endpoint
Both the primary spoke SDP and LAG member are up

Traffic flows over the primary path
Inter-chassis spoke SDPs not used
Traffic only flows from one endpoint to another, never within an
endpoint
Module 3 |
115
ICP-PW Normal operations

Here we see that both the primary spoke SDP and LAG members are up. Traffic only flows from endpoint to
endpoint, and only one endpoint object forwards traffic at a time.
The local PE, CSA1, does not forward traffic down its secondary spoke SDP, and all of MLS2s spoke SDP and SAP
are in standby.
(notes continued on next page...)
ICB-PW Normal operations
A:CSA1#
A:CSA1# show
show router
router ldp
ldp bindings
bindings detail
detail
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Type
:: E-Eth
VcId
:: 11
Type
E-Eth
VcId
SvcId
:
1
SdpId
:: 11
SvcId
: 1
SdpId
Peer
:: 192.0.2.0
Vc-switching
:: No
Peer Address
Address
192.0.2.0
Vc-switching
No
LMTU
:: 1500
RMTU
:: 1500
LMTU
1500
RMTU
1500
Egr.
:: 131054S
Egr.
:: No
Egr. Lbl
Lbl
131054S
Egr. Ctl
Ctl Word
Word
No
Egr.
:: None
Egr.
Egr. Flags
Flags
None
Egr. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
Ing.
:: 131067U
Ing.
:: No
Ing. Lbl
Lbl
131067U
Ing. Ctl
Ctl Word
Word
No
Ing.
:: None
Ing.
Ing. Flags
Flags
None
Ing. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
------------------------------------------------------------------------------------------------------------------------------------------------------------Type
:: E-Eth
VcId
:: 11
Type
E-Eth
VcId
SvcId
:
1
SdpId
:: 22
SvcId
: 1
SdpId
Peer
:: 192.0.2.1
Vc-switching
:: No
Peer Address
Address
192.0.2.1
Vc-switching
No
LMTU
:: 1500
RMTU
:: 1500
LMTU
1500
RMTU
1500
Egr.
:: 131059D
Egr.
:: No
Egr. Lbl
Lbl
131059D
Egr. Ctl
Ctl Word
Word
No
Egr.
:: None
Egr.
Egr. Flags
Flags
None
Egr. Status
Status Bits
Bits :: Supported
Supported (0x20)
(0x20)
Ing.
Lbl
:
131070U
Ing.
Ctl
Word
:
No
Ing. Lbl
: 131070U
Ing. Ctl Word
: No
Ing.
:: None
Ing.
Ing. Flags
Flags
None
Ing. Status
Status Bits
Bits :: Supported
Supported (0x0)
(0x0)
-------------------------------------------------------------------------------------------------------------------------------------------------------------
MLS2 sends status 0x20, Pseudowire Forwarding SAP in Standby,

rather than 0x26
Module 3 |
116
ICB-PW Normal Operations (cont)

...
------------------------------------------------------------------------------Sdp Id 1:1
-(192.0.2.0)
...
Peer Pw Bits
: None
Peer Fault Ip
: None
...
------------------------------------------------------------------------------Sdp Id 2:1
-(192.0.2.1)
...
Peer Pw Bits
: pwFwdingStandby
Peer Fault Ip
: None
ICB-PW - Normal Operations (cont)
A:MLS2#
A:MLS2# show
show service
service id
id 11 base
base
...
...
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:lag-2
null
1514
1514
Up
sap:lag-2
null
1514
1514
Up Down
Down
sdp:1:1
Spok
00
1550
Up
sdp:1:1 S(192.0.2.2)
S(192.0.2.2)
Spok
1550
Up Up
Up
sdp:3:1
Spok
00
1550
Up
sdp:3:1 S(192.0.2.0)
S(192.0.2.0)
Spok
1550
Up Up
Up
sdp:3:2
S(192.0.2.0)
Spok
0
1550
Up
sdp:3:2 S(192.0.2.0)
Spok
0
1550
Up Up
Up
===============================================================================
===============================================================================
Though the SAP is down, the MLS2 ePipe service remains

operationally Up
Note the three spoke SDP bindings, two of which terminate as ICB
PWs on MLS1
Module 3 |
117
ICB-PW Normal Operations (cont)

MLS1 shows the LAG SAP and all three spoke spoke SDPs up.
...
Admin State
: Up
Oper State
: Up
...
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU
OprMTU
Adm
Opr
------------------------------------------------------------------------------sap:lag-2
null
1514
1514
Up
Up
sdp:1:1 S(192.0.2.2)
Spok
1550
Up
Up
sdp:3:1 S(192.0.2.1)
Spok
1550
Up
Up
sdp:3:2 S(192.0.2.1)
Spok
1550
Up
Up
===============================================================================
ICB-PW - Normal Operations (cont)
The Primary Spoke SDP fails

CSA1 moves traffic to the backup spoke SDP
MLS1 is still the active MC-LAG member
Traffic flows from MLS2 endpoint SPOKE to endpoint SAP, across
the SAP ICB-PW, then SPOKE to SAP and on to the CE
Module 3 |
118
ICP-PW Primary Spoke SDP fails, MLS1 LAG active

Previously, a failure on SDP1 resulted in lost data at MLS2. Now, the ICB-PW between MLS2 and MLS1 provides a
last resort path to the CE devices.
...
Sdp Id 1:1 -(192.0.2.0)
...
Flags
: SdpOperDown
NoIngVCLabel NoEgrVCLabel
Peer Pw Bits
: None
...
Sdp Id 2:1 -(192.0.2.1)
...
Flags
: None
Peer Pw Bits
: pwFwdingStandby
...
The MLS2 LAG SAP is still in standby.
...
Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:lag-2
null
1514
1514
Up
Down
sdp:1:1 S(192.0.2.2)
Spok
0
1550
Up
Up
sdp:3:1 S(192.0.2.0)
Spok
0
1550
Up
Up
sdp:3:2 S(192.0.2.0)
Spok
0
1550
Up
Up
===============================================================================
ICB-PW Primary Spoke SDP fails, MLS1 LAG active
ICB-PW Primary Spoke SDP fails, MLS1 LAG active (cont)

===============================================================================
===============================================================================
Service
Service 11 endpoints
endpoints
===============================================================================
===============================================================================
Endpoint
:: SAP
Endpoint name
name
SAP
...
...
Tx
:: lag-2
Tx Active
Active
lag-2
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------SAP
:: lag-2
Oper
SAP
lag-2
Oper Status:
Status: Up
Up
Spoke-sdp:
3:2
Prec:4
(icb)
Oper
Status:
Spoke-sdp: 3:2 Prec:4 (icb)
Oper Status: Up
Up
===============================================================================
===============================================================================
Endpoint
:: SPOKE
Endpoint name
name
SPOKE
...
...
Tx
:: 3:1
Tx Active
Active (SDP)
(SDP)
3:1
...
...
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 1:1
1:1 Prec:4
Prec:4
Oper Status:
Status: Down
Down
Spoke-sdp:
Oper
Spoke-sdp: 3:1
3:1 Prec:4
Prec:4 (icb)
(icb)
Oper Status:
Status: Up
Up
Module 3 |
119
ICB-PW Primary Spoke SDP fails, MLS1 LAG active (cont)

MLS1 SAP endpoint ICB PW, SDP 3:1, becomes active as a result of the primary SDP failure. SAP LAG-2 is still the
active MC-LAG member.
MLS2
MLS2 SAP LAG-2 is down, however, its SAP endpoint ICB-PW, SDP 3:1, is active, providing a path for traffic
entering on the active secondary SDP to the active LAG member SAP on MLS1.
A:MLS2# show service id 1 endpoint
===============================================================================
Service 1 endpoints
===============================================================================
Endpoint name
: SAP
...
Tx Active (SDP)
: 3:1
...
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------SAP
: lag-2
Oper Status: Down

Oper Status: Up
===============================================================================
A:MLS1#
A:MLS1# show
show service
service id
id 11 endpoint
endpoint
Configuring ICB-PW
Syntax:
Syntax:
[no]
[no] endpoint
<endpoint-name>
[no]
[no] spoke-sdp
spoke-sdp <sdp-id:vc-id>
<sdp-id:vc-id> endpoint
<endpoint-name> icb
icb create
create
Example:
Example: config>service>epipe#
endpoint SAP
SAP create
create
back
config>service>epipe# sap
sap lag-2
lag-2 endpoint
endpoint SAP
SAP create
create
config>service>epipe>sap$
config>service>epipe>sap$ back
back
spoke-sdp 3:1
3:1 endpoint
endpoint SAP
SAP icb
icb create
create
back
endpoint SPOKE
SPOKE create
create
back
spoke-sdp 1:1
1:1 endpoint
endpoint SPOKE
SPOKE create
create
back
spoke-sdp 3:2
3:2 endpoint
endpoint SPOKE
SPOKE icb
icb create
create
Create the endpoints with <endpoint-name> as any valid text string

Assign the LAG to one endpoint, the remote PE spoke SDP to the other
Create an ICB backup for each endpoint, terminating on the MC peer PE
Module 3 |
120
Configuring ICB-PW
ICB-PW should only be used with PW redundancy and MC-LAG or MC-APS on the edge PE routers.
Endpoint
Two explicit endpoints must be created, one to protect the SAP and one to protect the remote PE PW. The local
PE only forwards traffic between endpoints, and only one object per endpoint may be forwarding traffic.
ICB Spoke SDP Binding Creation
You must first create the protected SAP or spoke SDP, then create the ICB PW. You use the icb keyword in the
spoke SDP context.
A:NodeA>config>service>epipe# spoke-sdp 3:1 endpoint SPOKE icb create
Precedence
ICB PW have the lowest precedence of all spoke SDPs. This is not configurable.
Configuration on the MC Peer PE
The MC peer PE requires a similar configuration, noting that the spoke SDPs have to terminate in opposite
endpoints than those on which they were created.
Context:
Context: config>service>epipe
config>service>epipe
A:MLS1#
A:MLS1# show
show service
service id
id 11 endpoint
endpoint
...
...
===============================================================================
===============================================================================
Service
endpoints
===============================================================================
===============================================================================
Endpoint
:: SPOKE
Endpoint name
name
SPOKE
Description
:: (Not
Description
(Not Specified)
Specified)
Revert
time
:
0
Revert time
: 0
Act
:: 00
Act Hold
Hold Delay
Delay
Standby
Signaling
Master
:
: false
false
Standby
:: false
Standby Signaling
Signaling Slave
Slave
false
Tx
:: 1:1
Tx Active
Active (SDP)
(SDP)
1:1
Tx
:: 0d
Tx Active
Active Up
Up Time
Time
0d 02:18:24
02:18:24
Revert
:: N/A
Revert Time
Time Count
Count Down
Down
N/A
Tx
:: 12
Tx Active
Active Change
Change Count
Count
12
Last
:: 08/16/2011
Last Tx
Tx Active
Active Change
Change
08/16/2011 10:38:25
10:38:25
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 1:1
1:1 Prec:4
Prec:4
Oper Status:
Status: Up
Up
Spoke-sdp:
Oper
Spoke-sdp: 3:1
3:1 Prec:4
Prec:4 (icb)
(icb)
Oper Status:
Status: Up
Up
===============================================================================
===============================================================================
===============================================================================
===============================================================================
Module 3 |
121
View the MLS1 SPOKE Endpoint Status Normal operations

Tx Active: Shows the active spoke SDP. In this example, the primary 1:1 is active.
Only one endpoint object can be forwarding at a time, and the ICB spoke SDP has the lowest precedence.
View the MLS1 SPOKE endpoint status Normal operations
A:MLS1#
A:MLS1# show
show service
service id
id 11 endpoint
endpoint
...
...
===============================================================================
===============================================================================
Service
endpoints
===============================================================================
===============================================================================
Endpoint
:: SPOKE
Endpoint name
name
SPOKE
Description
:: (Not
Description
(Not Specified)
Specified)
Revert
:: 00
Revert time
time
Act
:: 00
Act Hold
Hold Delay
Delay
Standby
:: false
Standby Signaling
Signaling Master
Master
false
Standby
:: false
Standby Signaling
Signaling Slave
Slave
false
Tx
:: 3:1
Tx Active
Active (SDP)
(SDP)
3:1
Tx
:: 0d
Tx Active
Active Up
Up Time
Time
0d 00:00:01
00:00:01
Revert
:: N/A
Revert Time
Time Count
Count Down
Down
N/A
Tx
:: 13
Tx Active
Active Change
Change Count
Count
13
Last
Tx
Active
Change
:
Last Tx Active Change
: 08/16/2011
08/16/2011 13:12:31
13:12:31
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 1:1
1:1 Prec:4
Prec:4
Oper Status:
Status: Down
Down
Spoke-sdp:
3:1
Prec:4
(icb)
Oper
Status:
Oper Status: Up
Up
Module 3 |
122
View the MLS1 SPOKE Endpoint Status Primary Spoke SDP failed
Tx Active: Shows the active spoke SDP. Since MLS1-CSA1 SDP1 is down, MLS1 forwards traffic over the ICB
spoke SDP 3:1.
MLS2 Endpoint Status
MLS2s endpoints never change states. In normal operations, the SAP ICB PW and the SPOKE remote spoke SDP
were forwarding. When CSA1 moved its traffic over to the backup spoke SDP, this had no effect on MLS2s
endpoint status.
...
Endpoint name
: SAP
...
Tx Active (SDP)
: 3:1
...
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------SAP
: lag-2
Oper Status: Down
Oper Status: Up
===============================================================================
Endpoint name
: SPOKE
...
Tx Active (SDP)
: 1:1
...
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 1:1 Prec:4
Oper Status: Up
Oper Status: Up
===============================================================================
View the MLS1 SPOKE endpoint status Primary Spoke SDP

failed
PW redundancy protects the S-PEs

ICB-PW protects the POC1 T-PEs
MC-LAG or MC-APS protects the NC elements and access ports
PW switching allows TE across areas, and increases scalability
Module 3 |
123
PW Redundancy, PW Switching, and ICB-PW - MC-LAG Access

The Model 2 network may include all the techniques discussed in this section to provide reliability and scalability.
Configured on CSA1 are redundant PWs terminated at the POC3 routers. SDP1 follows the UPPER links, as
configured in the MPLS section in M2, and SDP2 follows the LOWER links.
POC3-1 and POC3-2 are configured as S-PEs for the redundant, switched spoke SDPs. POC3-1 spoke SDP 4:2 follows
the UPPER links on its primary LSP path, and the LOWER links on its standby path. POC3-2 spoke SDP 4:2 follows
the LOWER links, then the UPPER. FRR protects all the LSPs, with manual bypass tunnels configured on the POC3
routers to keep aggregation ring traffic off of the access ring.
POC2-1 and POC2-2 act only as LSRs.
MLS1 and MLS2 (POC1-1 and POC1-2) terminate the VPWS service. They include LSPs and SDPs terminated on the
opposite MLS router to support the ICB-PWs. FRR protects the LSPs, but they include no standby paths. An MC-LAG
is configured to protect the ePipe service access interfaces, with MLS1 configured as the preferred active MC peer.
PW Redundancy, PW Switching and ICB-PW - MC-LAG Access
Automatic Protection
Switching (APS) is designed
to protect SONET/SDH
equipment from ring or
linear unidirectional or
bidirectional failures
The NEs monitor the
network health
Upon failure detection,
the network quickly
switches over live traffic
to a backup, or
protection, facility
SROS facility is the
physical line and line
terminating hardware
Module 3 |
124
Automatic Protection Switching

APS is designed to protect SONET/SDH lines from ring linear uni or bi-directional failures.
The Network Elements (NEs) in a SONET/SDH network constantly monitor the network. They can recognize faults
on the active circuit, called the working facility, by monitoring the bits in the SONET/SDH header K1 and K2
bytes. These bits indicate alarm conditions and switch requests.
When a node detects a failure, the network proceeds through a coordinated, predefined sequence of steps to
transfer (or switchover) live traffic to the backup facility (called protection facility.) This is done very quickly to
minimize lost traffic. Traffic remains on the protection facility until the working facility fault is cleared, at which
time the traffic may optionally be reverted to the working facility.
1+1, 1:n, 1:1
These terms represent the protection scheme employed on a SONET/SDH circuit.
1+1 - Each working circuit has a dedicated protection circuit, and the same traffic travels both. They dont
have to indicate to the other end a switch will occur.
1:n One protection circuit 1 can protect multiple n working circuits. An APS protocol must run between
the nodes.
1:1 One protection circuit for each working circuit. The nodes run an APS protocol, and the receiver must
request that the sender bridge live traffic onto the protection circuit. This is the most significant difference
between 1+1 and 1:1 APS.
Unidirectional v. Bi-directional
Linear (point-to-point) APS defines both unidirectional and bi-directional protection. Unidirectional protection
switches traffic off of a failed fiber, either transmit or receive, leaving the remaining traffic on the remaining
active fiber. No signaling is required.
Bi-directional APS moves both transmit and receive traffic. This requires the use of the K-bytes in the SONET/SDH
overhead. SROS implements bi-directional 1+1 APS by default.
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Section 6 PageModule

124 3 - Page 124 | All rights reserved 2012 Alcatel-Lucent
Automatic Protection Switching (APS)
The SONET line overhead and SDH multiplex section overhead K1 and
K2 bytes carry APS protocol messages
K1 bits 1-4 to request switch
K2 bits 6-8 to indicate status
Sent on protection circuit
Module 3 |
125
Linear APS Signaling

The SONET/SDH K1 and K2 bytes signal APS protocol messages. The table on the next page lists the SONET/SDH
linear APS messages.
Either node can initiate a switch, by sending a request down the protection circuit. A switch can also occur in the
case of Loss of Signal (LOS), Loss of Frame (LOF), detected Alarm Indication Signal (AIS), or a line Bit Error Rate >
10^3. This signaling channel also keeps the two nodes synchronized.
MC-APS Signaling
When running MC-APS, the protect router selects the working circuit. To keep the working and protect routers
synchronized, they maintain a UDP transported Multi-chassis Sync (MCS) session over a routed interface.
MCS ensures consistent configuration between chassis
Group membership and configuration
Ensures one side is configured as working and the other protection
Synchronizes working circuit status between the routers
Ensures the working router knows when the protection router has changed the working circuit selection

Linear APS Signaling
Bidirectional 1+1 APS

One protection link for each working link
APS protects circuits on a port by port basis
APS links may transport IMA or ML-PPP bundled traffic
SROS Default
Module 3 |
127
Bi-Directional APS 1+1

The APS standard, ANSI T1.105.01-2000, mandates that when using the 1+1 architecture, the active OC-N/STM
signal is permanently transmitted to both the working and protection ports so that in the egress direction the
same payloads are transmitted identically on both ports.
For efficiency, SROS does not transmit the same payload on the standby port that we transmit on the active port.
If an ADM measures for quality (and switch-over) purposes, then this measurement will perform equally well on the
idle stream.
In bi-directional mode:
A failure of the signal in either direction causes both near-end and far-end equipment to switch to the
protecting lines
The highest priority local request is compared to the remote request (received from the far-end node using
an APS command), and whichever has the greater priority is selected
The APS priority requests are:
1 Lockout of protect port
2 Forced switch
3 Signal failure low priority
4 Signal degradation low priority
5 Manual switch

Bi-Directional APS 1+1
Module 3 |
128
Single Chassis APS Options

Same IOM/MDA
In this configuration, APS protects the physical port. The working and protection facilities are on different ports.
Same IOM/Different MDA
APS protects both the port and the MDA. The protection facility protects against a failure on the working port or
its host MDA.
Different IOM/Different MDA
APS protects the port, MDA, and IOM. Any combination of the three, including all three, are protected.

Single Chassis APS Options
Multi-Chassis 1+1 APS protects from physical link and node failures
Provides stateful ML-PPP protection, even across two different
physical routers (MC-APS)
Synchronization across two SRs maintained using Multi-Chassis
synchronization (MCS)
Maintains existing ML-PPP signaling sessions
Module 3 |
129
Multichassis APS (MC-APS)

SROS supports MC-APS on 7450, 7750, and 7710/7750srC-12 chassis.
MC-APS reduces the recovery time and enables faster switchover
ML-PPP State is actively maintained across two chassis
MC-APS eliminates the requirement to re-establish the MLPPP Groups
Handles any APS switch-over in less than 5 seconds so NO Calls are dropped
MLPPP State synchronization uses MCS
Significantly reduces recovery time by seconds for a large number of groups (MLPPP)
Enables high-scale for a large number of base stations coming into the MLS
MC-APS may be used with redundancy pseudowires and Interchassis Backup Pseudowires to provide both access
node redundancy and network redundancy.
SROS does not support MC-APS for IMA bundles; only SC-APS is supported.

Multi-Chassis APS (MC-APS)
Configuring MC-APS
Context:
config>port
aps-<group-id>
aps-<group-id>
Context:
Context: config>port>aps
config>port>aps
Syntax:
Syntax:
[no]
[no] neighbor
neighbor <ip-address>
<ip-address>
[no]
protect-circuit
[no] protect-circuit <slot-id>
<slot-id>
[no]
[no] working-circuit
working-circuit <slot-id>
<slot-id>
[no]
[no] revert-time
revert-time <minutes>
<minutes>
[no]
[no] hold-time
hold-time <hold-time>
<hold-time>
Example:
Example: config#
config# port
port aps-1
aps-1
config>port$
config>port$ aps
aps
config>port>aps$
config>port>aps$ neighbor
neighbor 192.0.2.1
192.0.2.1
config>port>aps$
config>port>aps$ revert-time
revert-time 99
config>port>aps$
config>port>aps$ hold-time
hold-time 70
70
config>port>aps$
working-circuit
config>port>aps$ working-circuit 1/2/1
1/2/1
config>port>aps$
config>port>aps$ back
back
config>port$
config>port$ no
no shutdown
shutdown
Module 3 |
130
Configuring MC-APS
First, you create the logical APS group, where the possible range is 1-64:
A:NodeA>config# port aps-1
Then, identify the neighbor. This must be an IP-reachable address:
A:NodeA>config>port$ aps
A:NodeA>config>port>aps$ neighbor 192.0.2.1
Depending on the nodes role, configure either the working or protection circuit:
A:NodeA>config>port>aps$ working-circuit 1/2/1
Or
A:NodeA>config>port>aps$ protect-circuit 1/2/1
You may adjust the revert and hold time values, depending on the design.
revert-time A value, in minutes, that determines how long the router waits to switch traffic back to the
working circuit once it recovers. The default is 5 minutes, and the values are 0-60 minutes.
hold-time Specifies the time, in 100s of milliseconds, the router waits after failing to receive an advertisement
from the neighbor before determining the multi-chassis link is down. The values are 10-650.
The hold time is normally 3 times the advertise interval, which determines how frequently the neighbors tell each
other, in 100s of millseconds, that they are operational. The default advertise interval is 10.
Finally, turn up the APS group.
Syntax:
Syntax:
Verifying MC-APS
===============================================================================
===============================================================================
APS
APS Group
Group Info
Info
===============================================================================
===============================================================================
Interface
Tx/Rx
Interface Admin/Oper
Admin/Oper MC-Ctl
MC-Ctl Work|Work1
Work|Work1 Prot|Work2
Prot|Work2 Active
Active
Tx/Rx
State
State
Circuit
Circuit
Circuit
K1
State
State Circuit
Circuit
Circuit
K1 Byte
Byte
------------------------------------------------------------------------------------------------------------------------------------------------------------aps-1
Up/Up
Up
1/2/1
N/A
1/2/1
N/A
aps-1
Up/Up
Up
1/2/1
N/A
1/2/1
N/A
===============================================================================
===============================================================================
Interface
Interface -- aps-<id>
aps-<id> [<x>]
[<x>]
-- <x>
<x> applies
applies to
to APS
APS Annex
Annex BB only:
only:
LL -- lockout
lockout
Circuit
-- <slot>/<mda>/<port>
Circuit
<slot>/<mda>/<port> [<y>]
[<y>]
-- <y>
<y> applies
applies to
to APS
APS Annex
Annex BB only:
only:
PP -- primary
UU -- up
primary
up
SS -- secondary
DD -- down
secondary
down
===============================================================================
===============================================================================
Active circuit shows port number on active working or protection

node
Active circuit N/A if opposite peers circuit is active
Module 3 |
131
Model 1 Verifying APS

A:NodeA# show aps aps-1
MC-Ctl State: - Indicates the MCS is up.
Work|Work1 Circuit Indicates the working circuit ID.
Prot|Work2 Circuit Indicates the physical port that acts as the protection circuit ID.
Active Circuit Indicates the current active circuit. For MC-APS, shows N/A if the nodes circuit is inactive.
Tx/Rx K1 Byte This is the value of the SONET/SDH K1 byte received or transmitted on the protection circuit.
A:MLS1#
A:MLS1# show
show aps
aps aps-1
aps-1
A:MLS1>config#
A:MLS1>config# port
port aps-1
aps-1
A:MLS1>config>port#
A:MLS1>config>port# info
info
--------------------------------------------------------------------------------------aps
aps
neighbor
neighbor 192.0.2.1
192.0.2.1
hold-time
hold-time 70
70
revert-time
revert-time 99
working-circuit
working-circuit 1/2/1
1/2/1
exit
exit
sonet-sdh
sonet-sdh
path
path
atm
atm
exit
exit
no
no shutdown
shutdown
exit
exit
exit
exit
no
no shutdown
shutdown
Within APS group context

Neighbor is system ID,
loopback, or other IP reachable
address
One chassis hosts the working
circuit and the other the
protect circuit
A:MLS2>config#
A:MLS2>config# port
port aps-1
aps-1
A:MLS2>config>port#
A:MLS2>config>port# info
info
--------------------------------------------------------------------------------------aps
aps
neighbor
neighbor 192.0.2.0
192.0.2.0
hold-time
hold-time 70
70
revert-time
revert-time 99
protect-circuit
protect-circuit 1/2/1
1/2/1
exit
exit
sonet-sdh
sonet-sdh
path
path
atm
atm
exit
exit
no
no shutdown
shutdown
exit
exit
exit
exit
no
no shutdown
shutdown
Module 3 |
132
MC-APS for ATM Ports

You will configure the peer addresses in the APS group. This address must be IP reachable.
One neighbor must specify the working circuit while the other specifies the protect circuit.
MC-APS for ATM Ports
PW redundancy protects the S-PEs

ICB-PW protects the POC1 T-PEs
MC-APS protects the NC elements and access ports
PW switching allows TE across areas, and increases scalability
Module 3 |
133
PW Redundancy, PW Switching and ICB-PW - MC-APS Access

As with the MC-LAG configuration, the MLS routers signal the SAP state, active or standby, in the PW status bits.
POC3-1 forwards the status it receives from the T-PE routers. A change in the MLS signaled PW status will
influence the CSA routers choice of active PW.
PW Redundancy, PW Switching and ICB-PW - MC-APS Access
Section Review
Investigated MC-LAG as the feature might be used to protect

multi-homed Ethernet NC elements
Deployed Interchassis Backup Pseudowires (ICB-PW) to avoid
black-holing traffic destined to the standby multi-chassis peer
Provisioned MC-APS for MLS SONET/SDH protection
Module 3 |
134
Implemented pseudowire switching to support traffic engineering

and control FIB sizes across IGP areas

Section 6 Model 2 ePipe and Distributed VPRN for Ethernet

Services
Section Objectives
Observe the active ePipe pseudowire controlling the POC3 VPRN

interface states
Module 3 |
136
Review the Model 2 ePipe and distributed VPRN configuration for

3 and 4G voice, data, and control

ePipes cross-connect into POC3 VPRNs
BS-BS traffic routed at POC3 interfaces
MC-LAG, pseudowire switching and Interchassis Backup PW (ICB-PW) may be
used for end-to-end ePipe resiliency
Module 3 |
137
Model 2 ePipes and VPRN for 3G and LTE Ethernet Traffic

As we learned, the Model 2 subtended ring Model transported Ethernet backhaul traffic over redundant ePipes
connected to a distributed VPRN via spoke SDP interfaces. The VPRN endpoints are the POC3 and POC1 routers.
At the POC 1 router, interchassis LAG interfaces support VPRN route updates and L3 redundancy. VRRP protects
some NC facing interfaces.
If the NC element includes an L2 switch function, there is no need for separate VRRP-supporting VPLS on the MLS
routers. If necessary, additional VPLS may be provisioned to support VRRP signaling, as we learned in the previous
section.
Model 2 ePipes and VPRN for 3G and LTE Ethernet Traffic
CSA-POC3 ePipes carry 3 and 4G Ethernet traffic to distributed VPRN

PW redundancy on the CSA
POC3 and POC1 (MLS) routers are VPRN PEs
Standby-signaling-master on redundant PW take down redundant
VPRN interface
VRRP on RNC interfaces
Module 3 |
138
Model 2 3G and 4G ePipes and VRPN Services - Overview

The overview above shows the services and service features used to support 3G and 4G voice, data and OAM traffic
in the Model 2 distributed VPRN service design.
CSA1 to POC3 ePipes
On the CSA1 router, the ePipe uses redundant spoke SDPs to tie into the POC3 router VPRN interfaces. Enabled on
the ePipe endpoint is standby-signaling-master, which causes the CSA to signal the standby secondary SDP state to
the POC3 routers. This causes the POC3 router on which the standby spoke SDP terminates to take down the
associated VPRN interface and block traffic destined for the NodeB.
POC1-POC3 VPRN
The distributed VPRN delivers routed traffic to and from the NodeB and the RNC, other NC and EPC elements, and
external networks. The POC2 routers serve only as LSRs, and are not service aware.
A unique route-distinguisher is set within each PEs VPRN instance, so that each iBGP peer will use overlapping
routes received from both POC3 routers. This insures fast convergence in case of a failure toward the NodeB.
The interfaces and addresses are identical in each POC3 VPRN, and the NodeB-facing interface associated with the
active ePipe spoke SDP forwards traffic toward the NodeB. Only one of the NodeB-facing interfaces is active and
forwarding traffic.
Each VPRN PE shares a common route-target value.
The POC3 routers host identical interfaces and addresses for the NodeB-facing interfaces. They also advertise
a blackhole static route to a larger aggregate prefix to help speed convergence if a NodeB-facing interface
failure occurs.
On the POC1 routers, a VRRP instance protects the RNC gateway interface. If the RNC has a built in switching
function, in supports the VRRP messaging. If necessary, a separate set of inner VPLS may be used to support
VRRP signaling.
Model 2 3G and 4G ePipes and VRPN Services - Overview
The POC3 VPRN interfaces are spoke SDPs to the CSA ePipes
The CSA active spoke SDP determines the active VPRN interface,
standby-signaling-master on the endpoint
The VPRN to NodeB interfaces share the same IP address
MP-BGP distributes the active static route so the MLS routers know the
active path to the NodeB loopback interface
Module 3 |
139
Model 2 POC3 VPRN Interfaces

The CSA ePipes terminate into the POC3 router distributed VPRN interfaces. Since only one spoke SDP is active,
only one of the POC3 NodeB interfaces is active.
Routing toward the BS
On each of the two POC3 routers, static routes define the path to the NodeBs loopback interface. Since only one
of the NodeB interfaces is active, only one of the two POC3 routers holds a valid route to the NodeBs loopback
interface. The POC3 router with the active interface advertises this route into the VPRN service.
A:NodeA>config>service>epipe# endpoint epipe standby-signaling-master
By default, the Local PE, the CSA router, advertises both SDPs status as active. By enabling standby signaling
master on the endpoint, you allow the CSA to signal the secondary spoke SDP as standby, status flag 0x20. Since
the POC3-2 BS-facing interface is tied to the secondary spoke SDP, the POC3-2 interface remains down.
A:MLS2# show router 5 interface
===============================================================================
Interface Table (Service: 5)
===============================================================================
Interface-Name
Adm
Opr(v4/v6)
Mode
IP-Address
Port/SapId
PfxState
------------------------------------------------------------------------------toNodeB
Up
192.0.2.182/30
Down/--
VPRN
spoke-2:50
n/a
------------------------------------------------------------------------------Interfaces : 1
===============================================================================
Model 2 POC3 VPRN Interfaces
A:POC3-1>config>service>vprn#
A:POC3-1>config>service>vprn# info
info
------------------------------------------------------------------------------------------route-distinguisher
65100:150
vrf-target
vrf-target target:65100:50
target:65100:50
interface
interface "to
"to NodeB"
NodeB" create
create
address
address 192.0.2.182/30
192.0.2.182/30
spoke-sdp
spoke-sdp 2:50
2:50 create
create
no
no shutdown
shutdown
exit
exit
exit
exit
static-route
static-route 198.51.100.0/29
198.51.100.0/29 black-hole
black-hole
static-route
static-route 198.51.100.3/32
198.51.100.3/32 next-hop
next-hop 192.0.2.181
192.0.2.181
spoke-sdp
spoke-sdp 33 create
create
no
no shutdown
shutdown
exit
exit
spoke-sdp
spoke-sdp 44 create
create
no
no shutdown
shutdown
exit
exit
no
no shutdown
shutdown
-------------------------------------------------------------------------------------------
Module 3 |
140
View the POC3-1 VPRN Configuration

Black hole static routes
The VPRN black hole static routes ensure the VPRN PE routers have an active route to the NodeB loopback
interface during failure transition from the active to the standby pseudowire.
Assumed is that the entire MLS router chassis has gone offline, causing the CSA router to move traffic to the
secondary spoke SDP. While MP-BGP converges, the MLS routers can route traffic based on the POC3 routeradvertised black hole static route.
POC3-2 advertises a more specific black hole route than does POC3-1. Since POC3-2 protects POC3-1, NodeB
traffic should route to POC3-2.
Likewise, if ePipe traffic travels through POC3-2 and POC3-1 SDPs have recovered, once MP-BGP has converged,
NodeB traffic will once again flow to POC3-1.
Avoiding black holed traffic on recovery
To avoid black holed NodeB traffic on recovery, or in the case of rapid, intermittent failures on the primary spoke
SDP, you can set a revert time on the ePipe endpoint.
A:NodeA# configure service epipe 50 endpoint epipe50 revert-time infinite
Additionally, setting a revert time of infinite keeps traffic on the secondary spoke SDP until you force traffic back
to the primary SDP.
A:NodeA# clear service id 50 spoke-sdp 2:50 ingress-vc-label
View the POC3-1 VPRN Configuration
A:POC3-2#
A:POC3-2# show
show service
service id
id 55 interface
interface "toNodeB"
"toNodeB" detail
detail
...output
...output truncated
truncated
------------------------------------------------------------------------------------------------------------------------------------------------------------Interface
Interface
------------------------------------------------------------------------------------------------------------------------------------------------------------If
:: to
If Name
Name
to NodeB
NodeB
Admin
Oper
:: Down/-Admin State
State :: Up
Up
Oper (v4/v6)
(v4/v6)
Down/-Down
Down Reason
Reason Code:
Code: assocObjNotReady
assocObjNotReady
Protocols
:: None
Protocols
None
IP
Address
:: Primary
IP Addr/mask
Addr/mask :: 192.0.2.182/30
192.0.2.182/30
Address Type
Type
Primary
...
...
SDP
:: spoke-2:50
SDP Id
Id
spoke-2:50
Spoke-SDP
Spoke-SDP Details
Details
Admin
Admin State
State :: Up
Up
Hash
:: Disabled
Hash Label
Label
Disabled
Peer
Peer Fault
Fault Ip:
Ip: None
None
Peer
:: pwFwdingStandby
Peer Pw
Pw Bits
Bits
pwFwdingStandby
Peer
Peer Vccv
Vccv CV
CV Bits
Bits :: lspPing
lspPing
Peer
Peer Vccv
Vccv CC
CC Bits
Bits :: mplsRouterAlertLabel
mplsRouterAlertLabel
Flags
:: None
Flags
None
Oper
:: Up
Oper State
State
Up
Hash
Hash Lbl
Lbl Sig
Sig Cap
Cap :: Disabled
Disabled
POC3-2 interface to NodeB is operationally down since the spoke SDP is

in standby
Module 3 |
141
View the POC3-2 NodeB Interface

A:NodeA# show service id 5 interface toNodeB detail
POC3-2 hosts the standby interface.
Down Reason Code: - Indicates the spoke SDP is in standby
Peer Pw Bits: - POC3-2 received pseudowire forwarding standby (0x20) from the CSA peer
View the POC3-2 to NodeB Interface
Active SDP Failure Scenario CSA2 Chooses New Active PW
===============================================================================
===============================================================================
Service
Service 50
50 endpoints
endpoints
===============================================================================
===============================================================================
Endpoint
:: epipe50
Endpoint name
name
epipe50
...
...
Tx
:: 2:50
Tx Active
Active
2:50
Tx
:: 0d
Tx Active
Active Up
Up Time
Time
0d 00:02:10
00:02:10
Revert
:: N/A
Revert Time
Time Count
Count Down
Down
N/A
Tx
:: 30
Tx Active
Active Change
Change Count
Count
30
Last
:: 10/03/2011
Last Tx
Tx Active
Active Change
Change
10/03/2011 07:30:57
07:30:57
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 1:50
1:50 Prec:0
Prec:0
Oper Status:
Status: Down
Down
Spoke-sdp:
Oper
Spoke-sdp: 2:50
2:50 Prec:4
Prec:4
Oper Status:
Status: Up
Up
===============================================================================
===============================================================================
===============================================================================
===============================================================================
CSA2 signals the standby spoke SDP as active

POC3-2 brings up its VPRN interface
POC1-1 replaces the POC3-1 NodeB route with the POC3-2 route
Module 3 |
142
Active SDP Failure Scenario CSA2 Chooses New Active PW

POC3-1 hosts the active interface. The active interface status is tied to the active spoke SDP status.
In the case where the primary SDP were to fail, most likely from a nodal failure, the POC3-2 interface becomes
the active interface. In the series of events below, everything occurs nearly simultaneously except for step 5,
MP-BGP convergence, which depends on the BGP timers.
1. The CSA2-POC3-1 T-LDP session times out and the active SDP goes down.
2. POC1-1 IGP removes the route to POC3-1, which removes the BGP next hop for POC3-1 routes.
3. POC1-1 removes its POC3-1 /32 route; it maintains the POC3-2 /31 aggregate route.
NOTE: POC1-1 learned from POC3-2 the black hole static route to the larger NodeB /31 prefix. While BGP
converges, POC1-1 forwards the NodeB traffic to POC3-2 using this /31 route. This provides a path for NodeB
traffic while POC1-1 waits for the more specific route from POC3-2.
3. CSA2 signals the secondary SDP as active.
4. POC3-2 brings up its NodeB interface and activates its static route.
5. POC3-2 MP-BGP advertises the NodeB /32 route to POC1-1.
6. POC1-1 forwards the NodeB traffic to POC3-2 using the more specific route.
A:CSA2#
A:CSA2# show
show service
service id
id 50
50 endpoint
endpoint
Active SDP Failure Scenario POC3-2 Interface
===============================================================================
===============================================================================
Interface
Interface Table
Table (Service:
(Service: 5)
5)
===============================================================================
===============================================================================
Interface-Name
Adm
Opr(v4/v6)
Port/SapId
Interface-Name
Adm
Opr(v4/v6) Mode
Mode
Port/SapId
IP-Address
PfxState
IP-Address
PfxState
------------------------------------------------------------------------------------------------------------------------------------------------------------to
Up
Up/-VPRN
spoke-2:50
to NodeB
NodeB
Up
Up/-VPRN
spoke-2:50
192.0.2.182/30
n/a
192.0.2.182/30
n/a
------------------------------------------------------------------------------------------------------------------------------------------------------------Interfaces
Interfaces :: 22
===============================================================================
===============================================================================
CSA2 signals the standby SDP as active

Module 3 |
143
A:POC3-2#
A:POC3-2# show
show router
router 55 interface
interface
A:POC1-1#
A:POC1-1# show
show router
router 55 route-table
route-table
===============================================================================
===============================================================================
Route
Route Table
Table (Service:
(Service: 5)
5)
===============================================================================
===============================================================================
Dest
Type
Proto
Age
Pref
Dest Prefix
Prefix
Type
Proto
Age
Pref
Next
Metric
Next Hop[Interface
Hop[Interface Name]
Name]
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.56/29
Local
Local
01h07m04s
00
192.0.2.56/29
Local
Local
01h07m04s
To_RNC
00
To_RNC
192.0.2.180/30
Remote
170
192.0.2.180/30
Remote BGP
BGP VPN
VPN 00h02m02s
00h02m02s
170
192.0.2.1
00
192.0.2.1
198.51.100.0/31
Remote
170
198.51.100.0/31
Remote BGP
BGP VPN
VPN 00h49m56s
00h49m56s
170
192.0.2.1
00
192.0.2.1
198.51.100.3/32
Remote
170
198.51.100.3/32
Remote BGP
BGP VPN
VPN 00h02m02s
00h02m02s
170
192.0.2.1
00
192.0.2.1
------------------------------------------------------------------------------------------------------------------------------------------------------------No.
No. of
of Routes:
Routes: 44
===============================================================================
===============================================================================
CSA2 signals the standby SDP as active

Module 3 |
144
Active SDP Failure Scenario New NodeB Route

A:NodeA# show router 5 route-table
Upon a POC3-1 nodal failure or restart for maintenance, POC1-1 replaces the POC3-1 NodeB route with the new
route learned from POC3-2.
With BGP enable-peer-tracking on, POC1-1 removed the POC3-1 route as soon as the IGP removed its route to the
next hop.
POC1-1 depends on the standard BGP timers to insert the new /32 route:
Minimum Route Advertisement Interval (MRAI) In seconds, range 1-255. This minimum interval, in seconds,
at which a router can advertise a prefix to its peer. Set to the default of 30 seconds.
Keep-alive timer In seconds, range 0-21854. Determines how often a router sends a keepalive to its peer.
Set to the default, 30 seconds.
Hold timer In seconds, range 0 or 3-65535, usually set to 3 times the keep alive timer. Specifies the
maximum time BGP waits between successive keepalive or update messages before closing the peer
connection.
Active SDP Failure Scenario New NodeB Route
Module 3 |
145
Model 1 3G/4G ePipes and Distributed VPRN Detailed View

CSA1 On the ePipe endpoint, standby-signaling-master ensures only one POC3 VPRN interface is active.
POC3 VPRN The POC3 VPRNs include duplicate NodeB interfaces. Only the interface associated with the active
ePipe spoke SDP is active. The router with the active interface advertises a static route to the NodeB loopback
interface.
Static ARP entries may be included for the NodeB MAC address.
Each PE sets a unique route-distinguisher. This ensures that each BGP peer accepts overlapping routes from both
POC3 routers, again aiding convergence.
Static routes route traffic to the NodeB loopback interfaces.
MLS Router VPRN
Auto bind RSVP-TE is used to simplify provisioning. The 7705 SARs do not currently support auto bind RSVP-TE on
VPRN services.
VRRP protects the RNC interface.
Model 2 3G/4G ePipes and Distributed VPRN

Detailed View
Section Objectives
Observed standby-signaling-master controlling the VPRN services

active NodeB interface state
Module 3 |
146
Reviewed the Model 2 ePipe and distributed VPRN configuration

for 3 and 4G voice, data, and control

Section 7 Model 2 Legacy Services for 2G and 3G Voice, Data,

and Control Traffic
Section Objectives
Provision the ATM voice traffic distributed aPipe services

Implement PW redundancy in the aPipe services
Configure PW switching in the aPipe services
Provision MC-APS and ICB-PW on aPipe services
Configure the TDM voice traffic distributed cPipe services
Implement PW redundancy in the cPipe services
Configure PW switching in the cPipe services
Module 3 |
148
Review the Model 2 legacy (ATM and TDM) 2 and 3G voice, data,
and control traffic paths and services

cPipe and aPipes terminate directly into MLS router STM-1 access ports
POC3 routers switch tunneled traffic from access to aggregate rings
Module 3 |
149
Model 2 cPipe and aPipes for 2G and 3G TDM and ATM Traffic
In this section, we focus on building the aPipe and cPipe services the Model 2 network deploys to support TDM and
ATM base stations.
The service endpoints are the CSA and POC1 routers. The POC3 routers switch the traffic from one ISIS level to
another, so we will explore pseudowire switching and its use in these services.
The MLS routers protect the TDM and ATM NC links with MC-APS, so we will discuss MC-APS use in combination with
pseudowire redundancy.
Model 2 cPipe and aPipes for 2G and 3G TDM and ATM Traffic

3G aPipes
CSA-MLS aPipes for NodeB IMA Bundled E1 traffic

ATM VCC N:1 cell mode vc-type
PW switching at POC3 routers
ICB-PW and MC-APS at MLS routers
Module 3 |
152
Model 2 Legacy Services aPipe Overview

The detail above shows the services and service features used to support legacy ATM voice, data, and control
traffic.
CSA1 to MLS aPipes
On the CSA1 router, the aPipe terminates IMA bundles originating at the 3G UMTS ATM NodeB. The NodeB offers
traffic to the CSA over bundled E1 circuits. Each bundle consists of two or more E1 (or optionally, E3) member
ports.
For each ATM NodeB, a separate service carries, voice, data, and control traffic. The service sets the vc-type
atm-vcc to support N:1 cell mode encapsulation. N:1 cell mode encapsulation allows a single aPipe to carry
multiple ATM virtual channels/paths, but may also transport only a single VC, as well. The service supports cell
concatenation, where a single MPLS packet can carry multiple ATM cells, reducing overhead and increasing
efficiency.
The POC3 routers are the switching PEs. They are also configured for vc-type atm-vcc.
MC-APS protects the MLS-NC links, and Interchassis Backup Pseudowires (ICB-PW) ensure a path of last resort
to the NC element. We discuss pseudowire swiching and ICB-PW in detail in upcoming pages.
Model 2 Legacy Services aPipe Overview
ATM uses a fixed size cell consisting of 53 Bytes

First 5 Bytes contains header information such as the connection
identifier
Remaining 48 Bytes contains the data or Payload
Module 3 |
153
ATM Cell Format

What is ATM? ATM was designed for the high-speed transfer of Voice, Video and Data using cell relay technology
Uses small, Fixed-size Cells
Connection-oriented Service
Supports multiple service types
Applicable to LAN and WAN
ATM Cell Format
Module 3 |
154
ATM Header Format
Module 3 |
155
Virtual Path and Virtual Channels
This hop-by-hop forwarding is known as cell relay
Module 3 |
156
Virtual Channels and Virtual Paths
7705 Supported ATM VC-Types
ATM-VCC (Default on the 7705)

Virtual Channel Connection. An ATM connection that is switched based
on the cell headers VCI Requires VPI/VCI identifier to be specified
ATM-VPC
Virtual Path Connection. An ATM connection that is switched based on
the cell headers VPI Requires VPI identifier to be specified
The vc-type must be specified at the time of APIPE service creation

and cannot be changed without deleting the service first.
*A:CSA1#
*A:CSA1# configure
configure service
service apipe
apipe 10
10 vc-type
vc-type atm-vcc
atm-vcc customer
customer 11 create
create
*A:CSA1>config>service>apipe$
*A:CSA1>config>service>apipe$
Module 3 |
157
The VC-type is a 15-bit value that defines the type of VC signalled to

the peer
aPipe Overview
Module 3 |
158
aPipe Overview
Apipe provides a bi-directional layer 2 connection of ATM service between users via IP/MPLS network.
Support both local cross-connect and remote connect.
Standard UNI/NNI cells received on the ATM SAP are encapsulated into PW packet using N:1 cell mode or AAL5
SDU mode.
ATM VPWSs (Apipe) provide a point-to-point ATM service between users connected to SROS nodes on an IP/MPLS
network. Users are either directly connected to an SROS PE or through an ATM access network. In both cases, an
ATM PVC (for example, a virtual channel (VC) or a virtual path (VP)) is configured on the PE router. This feature
supports local cross-connecting when users are attached to the same PE node. VPI/VCI translation is supported in
the ATM VPWS.
ATM VPWS is used to carry ATM cells over an MPLS network.
Cell Mode Encapsulation
Allows a service provider to offer an ATM PVC or SVC based

service across a network
Used to transmit a single ATM cell or multiple ATM cells per
Packet Switch Network (PSN) PDU
Allows multiple ATM VCCs or VPCs to be carried within a single
PSN tunnel
Supports the binding of multiple VCCs/VPCs to a single
pseudowire
7705 SAR currently only supports N=1 cell mode (vc-type atm-vcc)
Module 3 |
159
aPipe Cell Mode Encapsulation

N:1 Cell Mode
In the simplest case, this encapsulation can be used to transmit a single ATM cell per service PDU. However, in
order to more efficiently use the available bandwidth, several ATM cells may optionally be encapsulated in a single
PCU. This process is called cell concatenation.
According to RFC 4717, in N:1 Cell Mode ATM cells are transported individually. The encapsulation of a single ATM
cell is the only REQUIRED encapsulation for ATM. The encapsulation of more than one ATM cell in a PSN frame is
optional and supported by SROS.
N:1 Cell Mode in the Backhaul Transport
Though the 7750 SR can support N:1 cell mode, vc-type atm-vpc, currently supported in the Model 2 network is
N=1 cell mode; the 7705 SAR only supports vc-type atm-vcc. The NodeBs assign unique VPI/VCI combinations to
each NodeB service, thus the NodeBs require separate aPipes for each VPI/VCI combination.
AAL5 SDU Frame Mode
The AAL5 payload VCC service defines a mapping between the payload of an AAL5 VCC and a single pseudowire.
The AAL5 payload VCC service requires ATM segmentation and reassembly support on the PE.
Even the smallest TCP packet requires two ATM cells when sent over AAL5 on a native ATM device. It is desirable
to avoid this padding on the pseudowire. Therefore, once the ingress PE reassembles the AAL5 PDU, the PE
discards the PAD and PDU trailer and then the ingress PE inserts the resulting payload into a pseudowire PDU. The
egress PE MUST regenerate the PAD and trailer before transmitting the AAL5 frame on the egress ATM port.
Alcatel-Lucent backhaul solutions dont currently implement AAL5 SDU Mode.
N:1 Cell Mode
ATM N:1 cell mode supports ATM cell concatenation.

As the cell is being packed, the concatenation can be
terminated by:
Max cells: maximum number of ATM cells to concatenation.
Max delay: maximum delay for ATM cells in hundreds of
microseconds.
Cell Loss Priority (CLP)-change: allow the CLP change to be an
indication to complete the cell concatenation.
Module 3 |
160
ATM Cell Concatenation

Cell concatenation helps the aPipe service make efficient use of the transport bandwidth. ATM delivers a constant
cell stream at the SONET/SDH interfaces by inserted idle cells when there is no data to send. An aPipe configured
for cell concatenation can remove the idle cells at service ingress and insert them at egress.
However, this introduces delay at the service edge as the ingress PE builds the service PDU. A single ATM cell
experiences the least delay, but makes the least efficient use of the aggregate bandwidth.
Concatenation Parameters
A number of parameters and events determine the number of cells/service PDU.
The maximum number of cells to concatenate This depends on the traffic class and interface MTU.
The maximum delay in 100s of milliseconds Based on acceptable network delay for this traffic type.
A change in the CLP bit A change in the CLP bit indicates the end of the concatenated PDU
For UBR traffic, the current recommended settings are:
Max cells 26 tied to the max interface MTU.
Max delay for the service the network delay
Change in the CLP bit enabled
For CBR traffic:
Max cells 1 to 6 This is service dependent
Max delay for the service the network delay
Change in the CLP bit enabled
ATM Cell Concatenation
A:CSA1#
A:CSA1# show
show service
service id
id 200
200 sdp
sdp 1:200
1:200 detail
detail
...output
...output truncated
truncated
------------------------------------------------------------------------------------------------------------------------------------------------------------APIPE
APIPE Service
Service Destination
Destination Point
Point specifics
specifics
------------------------------------------------------------------------------------------------------------------------------------------------------------Admin
Oper
Admin Concat
Concat Limit
Limit :: 11
Oper Concat
Concat Limit
Limit :: 11
Peer
Max
Peer Concat
Concat Limit
Limit :: 11
Max Concat
Concat Delay
Delay :: 400
400
------------------------------------------------------------------------------------------------------------------------------------------------------------Number
Number of
of SDPs
SDPs :: 11
------------------------------------------------------------------------------------------------------------------------------------------------------------===============================================================================
===============================================================================
Default settings
Concatenation limit 1 cell per packet (no max-cells)
Max Concatenation delay 400ms (no max-delay)
No CLP change (no clp-change)
Module 3 |
161
View Cell Concatenation Settings

Configure Cell Concatentation
Configure on the spoke SDP CLP change:
A:NodeA>config>service>apipe# spoke-sdp 1:200 cell-concatenation clp-change
Configure the number of cells per packet:
A:NodeA>config>service>apipe# spoke-sdp 1:200 cell-concatenation max-cells [1..29]
Configure the maximum delay per packet:
A:NodeA>config>service>apipe# spoke-sdp 1:200 cell-concatenation max-delay [1..400]
View Cell Concatenation Settings
Service Category
CBR
RT-VBR
NRT-VBR
ABR*
UBR
Typical Application
Circuit Emulation Services
Interactive Multimedia
Bursty applications File Transfers
Best Effort service with flow control feedback
LAN Traffic
Traffic
Parameters*
PCR
PCR, SCR, MBS
PCR, SCR, MBS
PCR, MCR
(no guarantees)
*ABR is not supported on the 7750 or 7705 Products
ATM Provides five standard service Categories

Commited Bit Rate (CBR)
Real Time Variable Bit Rate (RT-VBR)
Non-Real Time VBR (NRT-VBR)
Available Bit Rate (ABR)
Unspecified Bit Rate (UBR)
Module 3 |
* Peak Cell Rate (PCR)

Sustainable Cell Rate (SCR)
Maximum Burst Size (MBS)
Minimum Cell Rate (MCR)
162
ATM Service Categories

CBR Constant Bit Rate
RT-VBR Variable Bit Rate Real-Time
NRT-VBR Variable Bit Rate Non-Real Time
ABR* Available Bit Rate
UBR Unspecified Bit Rate
Traffic parameters
Peak cell rate (PCR)
Sustainable cell rate (SCR)
Burst tolerance, conveyed through the maximum burst size (MBS)
Cell delay variation tolerance (CDVT)
Minimum cell rate (MCR)
ATM Service Categories
ATM QoS applied per VC (VPI/VCI)

ATM NodeB supports 5 different traffic types
18 DSPs (6 cards x 3 DSPs/card) per NodeB (Vendor specific)
Up to 32 VPI/VCIs required across all traffic types
N:1 (7750 only) requires only 5 aPipes to support all traffic across
all VCs - one QoS profile per VP/one VP per aPipe
Module 3 |
163
ATM N to 1 Cell Mode QoS Application

The diagram above shows a total of 32 VCs carried over a single IMA bundle from the NodeB to the CSA.
Depending on the vendor, the NodeB may have a total of 18 Digital Signal Processors (DSPs) installed. The NodeB
supports several traffic types - some, such as OAM traffic, require only a single VC. However, others, such as user
voice and data, requireup to 18 VCs, one per NodeB DSP.
As shown, the NodeB carries 5 traffic types, each requires a different QoS treatments, for a total of 5 QoS profiles
on the CSA router.
N:1 cell mode allows a single aPipe to carry traffic from multiple VCs. When the aPipe is configured for type atmvcp, all traffic of type UBR, for example, can originate on the same VPI. The service SAP accepts all traffic on the
bundle in VPI 100.
With 5 QoS profiles shown, each carrying a different traffic class and unique cell drop threshold (CDT), N to 1 cell
mode allows just 5 aPipes to carry traffic from 32 individual VCs.
aPipe 100 - carries Unspecified Bit Rate (UBR) AAL5 traffic with a Cell Drop Threshold (CDT) of 24ms, on VPI
100.
aPipe 101 - carries Constant Bit Rate (CBR) traffic with a CDT of 11ms, on VPI 101.
aPipe 102 - carries CBR traffic with a CDT of 20ms on VPI 102.
aPipe 103 - carries CBR traffic with a CDT of 20ms on VPI 103.
aPipe 104 - carries CBR traffic with a CDT of .9ms on VPI 104.
ATM N:1 Cell Mode QoS Application
Control word optional

for cell mode
Required for AAL5 SDU
frame mode
Module 3 |
164
aPipe Packet Format

The metro domain shown deploys MPLS Label Switch Routers. The core LSRs only look at the top label to switch
the labeled frame across the MPLS domain. It is possible that additional labels get pushed along the way. The
egress LER infers from the VC label on how to process the frame and then forwards it to the appropriate outgoing
port. The VC label is not visible until the frame reaches the egress LER due to the MPLS tunneling hierarchy.
LDP or RSVP signaling is required to distribute the outer labels, and LSRs are necessary to determine the routes to
establish the required Label-Switched Paths (LSPs). Martini encapsulation can be used to carry the customers PDU
over any layer-1 network, for example. ATM cells can be transported over MPLS and in turn over HDLC/DS3, or
similarly via PoS/OC-X. As a result, with Martini-encapsulation, ATM cells can be transported over almost any
access/physical network.
Control Word (Optional)
The control word is optional, and is used to reorder cells on egress. Cell mode carries the cell header with the
encapsulated payload, and current design documents state that cell re-ordering is not a requirement.
Nonetheless, a control word may be included. RFC4385 (Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
for Use over an MPLS PSN) states, "If a PW is sensitive to packet misordering and is being carried over an MPLS PSN
that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism which prevents
packet misordering."
This is necessary due to the fact that ECMP implementations may examine the first nibble after the MPLS label
stack to determine whether the labeled packet is IP or not. Thus, if the VPI of an ATM connection carried over the
PW using AAL5 SDU mode encapsulation without a control word present begins with 0x4 or 0x6, it could be
mistaken for an IPv4 or IPv6 packet since an IP packet begins with a version number which is either a 4 or a 6
for IPv4 and IPv6 respectively. This could, depending on the configuration and topology of the MPLS network, lead
to a situation where all packets for a given PW do not follow the same path. This may increase out-of-order frames
on a given PW, or cause OAM packets to follow a different path than actual traffic.
Flags Bits 4-7, AAL5 SDU
Bit 4 Transport type (T): 0=AAL 5, 1=Admin Cell
Bit 5 EFCI (E): middle bit of each cells PTI
Bit 6 CLP (C) : cell loss priority
Bit 7 Command/response field bit (U): 0 or 1
aPipe Packet Format
Creating the CSA aPipe Service
config>service>apipe$
config>service>apipe$ sap
sap bundle-ima-1/1.1:200/10
bundle-ima-1/1.1:200/10 create
create
config>service>apipe>sap$
back
config>service>apipe>sap$ back
config>service>apipe#
config>service>apipe# endpoint
endpoint "ATM_IMA_URC200"
"ATM_IMA_URC200" create
create
config>service>apipe>endpoint#
back
config>service>apipe>endpoint# back
config>service>apipe# spoke-sdp
spoke-sdp 1:200
1:200 endpoint
create
config>service>apipe>spoke-sdp$
config>service>apipe>spoke-sdp$ precedence
precedence primary
primary
config>service>apipe>spoke-sdp$ back
back
config>service>apipe# spoke-sdp
spoke-sdp 2:200
2:200 endpoint
create
back
config>service>apipe# no
no shutdown
shutdown
Use vc-type atm-vcc for N = 1 cell mode

Redundant pseudowires terminate on POC3 routers
SAP is IMA bundle with VPI/VCI for a single VCC
Module 3 |
165
Creating the CSA aPipe Service

According to RFC 4717, the VCC cell transport service is characterized by the mapping of a single ATM VCC
(VPI/VCI) to a Pseudo Wire. This service is fully transparent to the ATM Adaptation Layer.
The VPC service is defined by mapping a single VPC (VPI) to a Pseudo Wire. As such it emulates a Virtual Path
cross-connect across the PSN. All VCCs belonging to the VPC are carried transparently by the VPC service.
The AAL5 SDU encapsulation is more efficient for small AAL5 SDUs than the VCC cell encapsulations. In turn it
presents a more efficient alternative to the cell relay service when carrying RFC 2684 encapsulated IP PDUs across
a PSN. The AAL5-SDU encapsulation requires Segmentation and Reassembly on the PE-CE ATM interface. Once
reassembled, the AAL5-SDU is carried via a Pseudo Wire to the egress PE. And herein lies another advantage of the
AAL5-SDU encapsulation.
The encapsulation allows multiple VCCs/VPCs to be carried within a single pseudo wire. However, a service
provider may wish to provision a single VCC to a pseudo wire in order to satisfy QoS or restoration requirements.
The encapsulation also supports the binding of multiple VCCs/VPCs to a single Pseudo Wire. This capability is
useful in order to make more efficient use of the PW demultiplexing header space as well as to ease provisioning
of the VCC/VPC services.
A:CSA2>config>service# apipe
apipe 200
200 vc-type
vc-type atm-vcc
atm-vcc customer
customer 11 create
create
description
Distributed
config>service>apipe$ description Distributed apipe
apipe for
for 3G
3G ATM
ATM Services"
Services"
A:POC3>config>service#
A:POC3>config>service# apipe
apipe 200
200 vc-type
vc-type atm-vcc
atm-vcc vc-switching
vc-switching customer
customer 11 create
create
config>service>apipe$ description
description Distributed
Distributed apipe
apipe for
for 3G
3G ATM
ATM Services"
Services"
config>service>apipe$ spoke-sdp
spoke-sdp 1:200
1:200 create
create
back
spoke-sdp 2:200
2:200 create
create
back
config>service>apipe$ no
no shutdown
shutdown
POC3 is the S-PE

Use vc-type atm-vcc and vc-switching when creating the service
Module 3 |
166
Creating the S-PE aPipe Service
A:MLS2>config>service# apipe
apipe 200
200 vc-type
vc-type atm-vcc
atm-vcc customer
customer 11 create
create
description
Distributed
config>service>apipe$ description Distributed apipe
apipe for
for 3G
3G ATM
ATM Services"
Services"
endpoint
SAP
create
config>service>apipe$ endpoint SAP create
config>service>apipe>endpoint$
config>service>apipe>endpoint$ back
back
config>service>apipe$ endpoint
endpoint SPOKE
SPOKE create
create
config>service>apipe>endpoint$
config>service>apipe>endpoint$ back
back
config>service>apipe$ sap
sap aps-1:200/10
aps-1:200/10 endpoint
endpoint SAP
SAP create
create
config>service>epipe>sap$
back
config>service>epipe>sap$ back
spoke-sdp 3:200
3:200 endpoint
endpoint SAP
SAP icb
icb create
create
back
spoke-sdp 1:200
1:200 endpoint
endpoint SPOKE
SPOKE create
create
back
config>service>apipe4
config>service>apipe4 spoke-sdp
spoke-sdp 3:201
3:201 endpoint
endpoint SPOKE
SPOKE icb
icb create
create
back
config>service>apipe$ no
no shutdown
shutdown
APS group in SAP

ICB-PW to provide path of last resort to active SONET/SDH link
Module 3 |
167
Creating the MLS router ICB-PW aPipe Service
View the MLS1 aPipe Status

===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 200
Vpn
:: 00
Service Id
Id
200
Vpn Id
Id
Service
:: Apipe
VLL
:: ATMVCC
Service Type
Type
Apipe
VLL Type
Type
ATMVCC
Name
:: (Not
Name
(Not Specified)
Specified)
Description
:: Distributed
Description
Distributed apipe
apipe for
for 3G
3G ATM
ATM Services
Services
Customer
:: 11
Customer Id
Id
...
...
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
MTU
:: 1508
MTU
1508
Vc
:: False
Vc Switching
Switching
False
SAP
:: 11
SDP
:: 33
SAP Count
Count
SDP Bind
Bind Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:aps-1:200/10
atm
1524
1524
Up
Up
sap:aps-1:200/10
atm
1524
1524
Up
Up
sdp:1:200
Spok
00
1550
Up
Up
sdp:1:200 S(192.0.2.2)
S(192.0.2.2)
Spok
1550
Up
Up
sdp:3:200
Spok
00
1550
Up
Up
sdp:3:200 S(192.0.2.1)
S(192.0.2.1)
Spok
1550
Up
Up
sdp:3:201
Spok
00
1550
Up
Up
sdp:3:201 S(192.0.2.1)
S(192.0.2.1)
Spok
1550
Up
Up
===============================================================================
===============================================================================
Module 3 |
168
View the MLS1 aPipe Status

VLL Type: - ATMVCC.
Service Access & Destination Points - Identifier APS SAP and both ICB spoke SDPs are Up
SDP:3:200 ICB endpoint SPOKE
SDP:3:201 ICB endpoint SAP
A:MLS1#
A:MLS1# show
show service
service id
id 200
200 base
base
View the CSA aPipe Status

===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 200
Service Id
Id
200
Service
:: Apipe
VLL
:: ATMVCC
Service Type
Type
Apipe
VLL Type
Type
ATMVCC
Description
:: (Not
Description
(Not Specified)
Specified)
Customer
:: 11
Customer Id
Id
Last
Last Status
Status Change:
Change: 08/31/2011
08/31/2011 13:51:56
13:51:56
Last
Last Mgmt
Mgmt Change
Change :: 08/30/2011
08/30/2011 15:12:28
15:12:28
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
MTU
:: 1508
MTU
1508
Vc
:: False
Vc Switching
Switching
False
SAP
:: 11
SDP
:: 22
SAP Count
Count
SDP Bind
Bind Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:bundle-ima-1/1.1:200/10
atm
1524
1524
Up
Up
sap:bundle-ima-1/1.1:200/10
atm
1524
1524
Up
Up
sdp:1:200
n/a
00
1550
Up
Up
sdp:1:200 S(192.0.2.0)
S(192.0.2.0)
n/a
1550
Up
Up
sdp:2:200
n/a
00
1550
Up
Up
sdp:2:200 S(192.0.2.1)
S(192.0.2.1)
n/a
1550
Up
Up
===============================================================================
===============================================================================
Module 3 |
169
View the CSA2 aPipe Status

VLL Type: - ATMVCC.
Service Access & Destination Points - Identifier APS IMA bundle SAP and both redundant spoke SDPs are Up
SDP:1:200 Primary spoke SDP
SDP:2:200 Secondary spoke SDP
A:CSA1#
A:CSA1# show
show service
service id
id 200
200 base
base
A:MLS1#
A:MLS1# show
show service
service id
id 200
200 endpoint
endpoint
===============================================================================
===============================================================================
Service
Service 200
200 endpoints
endpoints
===============================================================================
===============================================================================
...
...
===============================================================================
===============================================================================
Endpoint
:: SPOKE
Endpoint name
name
SPOKE
Description
:: (Not
Description
(Not Specified)
Specified)
Revert
time
:
0
Revert time
: 0
Act
:: 00
Act Hold
Hold Delay
Delay
Tx
Active
(SDP)
:: 2:200
Tx Active (SDP)
2:200
Tx
:: 0d
Tx Active
Active Up
Up Time
Time
0d 00:53:25
00:53:25
Revert
:: N/A
Revert Time
Time Count
Count Down
Down
N/A
Tx
:: 11
Tx Active
Active Change
Change Count
Count
Last
Tx
Active
Change
:
: 08/31/2011
08/31/2011 12:57:12
12:57:12
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 2:200
2:200 Prec:4
Prec:4
Oper Status:
Status: Up
Up
Spoke-sdp:
3:200
Prec:4
(icb)
Oper
Status:
Oper Status: Up
Up
===============================================================================
===============================================================================
===============================================================================
===============================================================================
Module 3 |
170
View the MLS1 SPOKE Endpoint Status Normal operations

Tx Active (SDP): Shows the active spoke SDP. In this example, the primary 2:200 is active.
Only one endpoint object can be forwarding at a time, and the ICB spoke SDP has the lowest precedence.
View the MLS SPOKE endpoint status Normal operations
A:MLS1#
A:MLS1# show
show service
service id
id 200
200 endpoint
endpoint
===============================================================================
===============================================================================
Service
Service 200
200 endpoints
endpoints
===============================================================================
===============================================================================
...
...
===============================================================================
===============================================================================
Endpoint
:: SPOKE
Endpoint name
name
SPOKE
Description
:: (Not
Description
(Not Specified)
Specified)
Revert
time
:
0
Revert time
: 0
Act
:: 00
Act Hold
Hold Delay
Delay
Tx
Active
(SDP)
:: 3:200
Tx Active (SDP)
3:200
Tx
:: 0d
Tx Active
Active Up
Up Time
Time
0d 00:00:26
00:00:26
Revert
:: N/A
Revert Time
Time Count
Count Down
Down
N/A
Tx
:: 33
Tx Active
Active Change
Change Count
Count
Last
Tx
Active
Change
:
: 08/31/2011
08/31/2011 13:55:54
13:55:54
------------------------------------------------------------------------------------------------------------------------------------------------------------Members
Members
------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp:
Oper
Spoke-sdp: 2:200
2:200 Prec:4
Prec:4
Oper Status:
Status: Down
Down
Spoke-sdp:
3:200
Prec:4
(icb)
Oper
Status:
Oper Status: Up
Up
===============================================================================
===============================================================================
===============================================================================
===============================================================================
Module 3 |
171
View the MLS1 SPOKE Endpoint Status Primary Spoke SDP failed
Tx Active: Shows the active spoke SDP. Since spoke SDP 2:200 shows down, MLS1 receives traffic from MLS2
over the ICB spoke SDP 3:200.
MLS2 Endpoint Status
The CSA2 secondary SDP 2:200 is up, and MLS2 forwards traffic to MLS1 over the ICB spoke SDP 3:200.
...
Endpoint name
: SAP
...
Tx Active (SDP)
: 3:200
...
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------SAP
: aps-1:200/20
Oper Status: Down
Oper Status: Up
===============================================================================
Endpoint name
: SPOKE
...
Tx Active (SDP)
: 2:200
...
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 2:200 Prec:4
Oper Status: Up
Oper Status: Up
===============================================================================
View the MLS SPOKE endpoint status Primary Spoke SDP failed
View MC-APS on MLS1
===============================================================================
===============================================================================
APS
APS Group
Group Info
Info
===============================================================================
===============================================================================
Interface
Tx/Rx
Interface Admin/Oper
Admin/Oper MC-Ctl
MC-Ctl Work|Work1
Work|Work1 Prot|Work2
Prot|Work2 Active
Active
Tx/Rx
State
State
Circuit
Circuit
Circuit
K1
State
State Circuit
Circuit
Circuit
K1 Byte
Byte
------------------------------------------------------------------------------------------------------------------------------------------------------------aps-1
Up/Up
Up
1/2/4
N/A
1/2/4
N/A
aps-1
Up/Up
Up
1/2/4
N/A
1/2/4
N/A
===============================================================================
===============================================================================
Interface
Interface -- aps-<id>
aps-<id> [<x>]
[<x>]
-- <x>
<x> applies
applies to
to APS
APS Annex
Annex BB only:
only:
LL -- lockout
lockout
Circuit
-- <slot>/<mda>/<port>
Circuit
<slot>/<mda>/<port> [<y>]
[<y>]
-- <y>
<y> applies
applies to
to APS
APS Annex
Annex BB only:
only:
PP -- primary
UU -- up
primary
up
SS -- secondary
DD -- down
secondary
down
===============================================================================
===============================================================================
Module 3 |
172
Model 1 Verifying APS

A:NodeA# show aps aps-1
MC-Ctl State: - Indicates the MCS is up.
Work|Work1 Circuit Indicates the working circuit ID.
Prot|Work2 Circuit Indicates the physical port that acts as the protection circuit ID.
Active Circuit Indicates the current active circuit. MLS1 currently hosts the active circuit.
Tx/Rx K1 Byte This is the value of the SONET/SDH K1 byte received or transmitted on the protection circuit.
A:MLS1#
A:MLS1# show
show aps
aps aps-1
aps-1
Module 3 |
173
Model 2 Legacy Services aPipe Detailed View
.5 Hour
Lab Objectives:
On the CSA routers, provision redundant aPipe spoke SDPs and NodeB/BTS
facing SAPs
On the MLS routers, provision PW switching for the aPipe service
On the CR router, provision the aPipe spoke SDPs and NC SAPs
Module 3 |
174
Lab 8 : Configure 3G Voice aPipe Service

2G cPipes
CSA-MLS cPipes for unchannelized BTS E1 traffic

Structure agnostic transport over PSN (SAToP) vc-type
PW Switching at POC3 routers
ICB-PW and MC-APS at MLS routers
Module 3 |
176
Model 2 Legacy Services cPipe Overview

The overview above shows the cPipe terminations on the PE routers.
CSA2 to MLS router cPipe Services
On the CSA2 router, a cPipe service transports an unchannelized E1 circuit between the 2G GSM BTS and the Base
Station Controller (BSC). The circuit vc-type is Structure Agnostic Transport Over PSN (SAToP), which means the
cPipe is not aware of the individual timeslots. An unchannelized E1 uses all 32 timeslots, giving the entire
2.048Mb/s circuit bandwidth to PPP or ATM framed data or voice traffic.
The cPipe SAP is set to unframed, and the service disregards the bit sequence and TDM structure to transport the
entire signal over a Packet Switched Network (PSN) as a pseudowire. The E1 channel group contains all 32
timeslots.
Configured on CSA2 are redundant pseudowires. The service vc-type is satop-e1.
The POC3 routers are the switching PEs. They are also configured for vc-type satop-e1.
The MLS routers use ICB-PW and MC-APS to protect the links to the BSC. Again, we use vc-type satop-e1. The
MLS SAPs are SDH framed, MC-APS protected STM-1 circuits carrying the unchannelized E1 payload to the BSC.
Model 2 Legacy Services cPipe Overview
Synchronous channel based

Each station gets a fixed-length slot
Unused slots are idle transmitted without data
For example: T1, SONET
Module 3 |
177
Review: Time Division Multiplexing

Each host PC sends information to the switch. The switch then transmits a frame to the router at a constant data
rate (for example, 1.5 Mb/s). This frame is then divided into many fixed time slots (24), each containing 64 kbits.
Each host can occupy one or more time slots per frame.
Each host PC is assigned a fixed data rate. If the host uses one time slot, then its transmission is 64 kbits in that
slot. Because the pipe rate is 1.5 Mb/s, the host will have to supply their next 64 kbits in the next frame.
In this slide, each host PC transmits its characteristic frame (grey, yellow, purple). The frames that are
transmitted from the switch contain several timeslots. Within each of these frames three of the timeslots are used
by the respective host PCs.
Review: Time Division Multiplexing
Time Division Multiplexing (TDM) DS1
1.544 Mb/s Framing Rate

24 subchannels (DS0) each 8 bits sampled at 8000 times per second +
1 framing bit
Module 3 |
178
Time Division Multiplexing (TDM) DS1

Time Division Multiplexing (TDM) is a digital technology where individual signals are interleaved into a composite
multiplexed signal. Recurring fixed-length time slots are created such that each individual signal is represented by
one channel or by multiple channels. The total transmission bandwidth is split among the time slots. The total
composite signal includes the payload bits for the composing channels and overhead bits.
The frame structures of the DS1 [ANSI95b] signal is shown above. The DS1 signal consists of 24 payload channels
plus overhead. The basic frame of each of these signals repeats every 125 s, that is, 8000 times per second. With
8 bits carried in each channel, this gives rise to a basic data rate of 64 kb/s for each channel. The requirement for
this data rate stems from the need to sample the analog telephony signal 8000 times per second and encoding
each sample in 8 bits. A DS-1 frame contains 24 channels, each consisting of 8 bits, plus 1 framing/overhead bit,
leading to a total of 193 bits. Because the frame repeats every 125 s (or 8000 times a second), the total bit rate
of the DS1 signal is 1.544 Mb/s. Similarly, the total bit rate of the E1 signal is 2.048 Mb/s (32 channels of 8 bits,
repeating every 125 s).
Widely used signaling examples:
DS1/T1, E1, DS3, E3, OC3/STM-1, OC12/STM-4
Other signaling examples:
DS3 that uses 28 DS1 or 7 DS2 or 1 DS3 = 45 M
OC3 that uses 3 DS3
DS1/T1
E1
2048Kb/s framing rate
32 subchannels each 8 bits sampled at 8000 times per second
Module 3 |
179
Time Division Multiplexing (TDM) E1
SROS cPipe Overview
Support both local cross-connect and remote connect.

Support both structured and unstructured frames
Module 3 |
180
SROS cPipe Overview

CES VPWSs (cPipe) provide a point-to-point TDM service between users connected to 7750 SR nodes on an IP/MPLS
network. Users are either directly connected to a 7750 PE or through an TDM access network. In both cases, the
SROS PE provides a TDM cross connect. This feature supports both distributed services and local cross-connects
where users are attached to the same node. On the 7750 SR, a CES (circuit emulation service) MDA is required, on
the 7705 SAR, a channelized DSx MDA is required. The transport network is Ethernet based.
CES VPWS (Cpipe) is a point-to-point VPN services emulating a TDM leased line. Two PE routers connected to the
customer sites through the local attachment circuit receives native TDM traffic, perform VPN (PW) encapsulation
and transport tunnel encapsulation, then send the traffic through packet switched network (PSN, usually IP/MPLS)
to reach the remote site.
cPipe provides a bi-directional layer 2 TDM service

connection over the IP/MPLS transport
DS1/E1 traffic received on service SAP

Bits read into packetization buffer at BS transmit clock rate
PW control word, VC label, and transport label added
De-jitter buffer emptied at local clock rate
Module 3 |
181
cPipe Data Plane Encapsulation

The illustration above shows the encapsulated TDM traffic carried over the MPLS transport.
Service Ingress
The ingress PE receives the customer traffic on the service SAP. It reads the incoming bit stream at the BS clock
rate into a packetization buffer. The packetization buffer holds the TDM frame octets while the router builds the
payload. The payload size depends on the DS1 or E1 circuit configuration, which influences the services
packetization delay.
Once the ingress PE builds the payload, it adds an optional RTP header, a control word, the service label and the
transport label, and forwards the payload to the next hop.
cPipe services support PW switching, and the S-PE switches the payload from one spoke SDP to the next without
manipulating the payload.
Service Egress
At the egress PE, the target node examines and strips off the transport and service labels. It examines the control
word to determine if any packets were received out of order or lost in transit and to check for alarm conditions.
The egress PE reads the RTP header, if included, though often this is included only for CE compatibility and
ignored at egress. It then feeds the payload into a de-jitter buffer and feeds the frames out at a steady rate
based on the local clock reference. The local and remote clocks must be synchronized in order to avoid buffer
under- and overruns.
cPipe Data Plane Encapsulation
Structured - CESoPSN : Circuit Emulation Service Over PSN.

RFC 5086 The PE is aware of the individual DS1/E1 timeslots
Structured mode is supported for n*64kbps circuits
Allows timeslot selection and suppression to avoid transmitting
unused timeslots
The transported DS1 and E1 circuits specify channel-groups with
timeslots from 1-24 for DS1 or 1-32 for E1
Unstructured - SAToP : Structure Agnostic Transport Over PSN.
RFC 4553 - Transports an unstructured (clear channel) DS1 or E1

frame for ATM or MLPPP traffic
Efficiently transports the full DS1/E1 frame
DS1 and E1 unstructured circuits can be set to unframed, so that
when channel-group 1 is configured it contains all 24 or 32 channels
Module 3 |
182
cPipe Delivery Options

Structured TDM Circuit Emulation over Packet Switched Networks (CESoPSN)
RFC 5086 Structured emulation (also called CESoPSN) makes use of the TDM framing structure, where each frame
comprises a sequence of timeslots. The IWF (Inter-Working Function) strips the framing structure (for example, the
F bit in a DS1) from the data stream. It then places the sequence of timeslots from the first frame into the packet
payload, followed by the same timeslots from the next frame, and so on, until the payload is complete. A packet
header is then added, and the packet is sent through the transport network to the PE at the other end. On the
egress, the PE recreates the TDM data stream.
Unstructured Structure-agnostic TDM over Packet (SAToP)
Unstructured emulation (also called SAToP) disregards the TDM framing structure and treats the TDM data simply
as a stream of consecutive octets. The number of octets that comprise each PSN packet payload is independent of
the number of timeslots in each TDM frame, thus any alignment of these octets with the underlying timeslots is
coincidental and not guaranteed. The payload length is typically chosen to make a packet formation time of
approximately 1msec. For a T1 circuit, this length is 193 octets.
cPipe Delivery Options
Module 3 |
183
cPipe Encapsulation
The pseudowire encapsulation performed on the TDM traffic in Cpipe service with two types of format are similar.
The only difference is the control word field.
For CESoPSN, see RFC 5086, Stucture-aware TDM Circuit Emulation Service over Packet Switched Network
(CESoPSN);
For SAToP, see RFC4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet [SAToP].
cPipe Encapsulation
Bits 0-3 Set to 000 according to RFC 4385

L (Local TDM Failure) set to 1 if the attachment circuit experiences
LOS, LOF, or AIS
R (Remote Loss of Frames) set to 1 if the local CE-bound inter-working
function (IWF) is in packet loss state
M (Modifier) 00 for SAToP. CESoPSN according to RFC 5086, see notes
section
FRG CESoPSN sets to 00
LEN length of CESoPSN packet (header plus payload) if > 64 bytes,
otherwise 0
Sequence number for lost packet detection and resequencing
Module 3 |
184
cPipe Control Word

L (Local TDM Failure) is set to 1 when some abnormal condition of the attachment circuit such as Loss of
Sync (LOS), Loss of Frame (LOF) or Alarm Indication Signal (AIS) has been detected and TDM data carried in
the payload is invalid. L bit is cleared back to 0 when fault is rectified.
R (Remote Loss of Frames indication) Set to 1 if the local CE-bound IWF is in the packet loss state, i.e. has
lost a pre-configured number of consecutive packets and cannot reproduce the TDM stream. The R bit is
cleared once its local CE-bound IWF has exited the packet loss state, i.e. has received a pre-configured
number of consecutive packets.
M - 2-bit modifier field. Set to 00 for SAToP as per RFC4553. For CESoPSN, M is set according to RFC 5086, as
shown below:
When L bit = 0, and
M = 00 Normal conditions
M = 01 Reserved for future use
M = 10 Remote Defect Indicator (RDI) condition for the attachment circuit (AC)
M = 11 Reserved for CESoPSN
When L bit = 1, and
M = 00 TDM data is invalid
FRG Set to 00 in CESoPSN control word.
LEN - The LEN bits (bits 10 to 15) carry the length of the CESoPSN packet (defined as the size of the CESoPSN
header plus the payload size) if it is less than 64 bytes, and set to 0 otherwise.
Sequence number - The sequence number is used to provide the common PW sequencing function as well as
detection of lost packets.
cPipe Control Word
Packet size is user-configurable in bytes. It must be a multiple of the

number of timeslots by T1/E1 frame (N)
Minimum packet size will be based on 8 frames (T1/E1) per
packet
Maximum number for packet size is 1514 bytes
With a smaller packet size, the packetization latency is reduced,
however this results in higher overhead as a percentage of the
traffic
Module 3 |
185
Payload Size vs. Packetization Delay

The payload size is calculated by the formula
S=NxF
where S is the payload size, N is the number of timeslots collected per frame, and F is the number of frames
accumulated in each packet. Each timeslot is 8 bits, or 1 byte.
Assuming a E1 channel group containing all 32 timeslots, and the service collects 8 frames, the payload size is
32 timeslots (bytes) x 8 = 256 octets
Packetization Delay
A DS1 or E1 frame arrives at the SAP 8000 times per second, or every 125us. The packetization delay is calculated
by the formula
D = frame delivery time x the number of frames accumulated
In the example above, D = 125us/frame x 8 frames = 1ms, the packetization delay imposed by this service.
Number of Frames Per Packet, Structured
The SROS sets the default number of frames per packet by the number of timeslots in the received DS1 or E1.
The default values are set by the operating system as follows, where N = the number of timeslots:
for N = 1, the default is 64 frames/packet
for 2 N 4, the default is 32 frames/packet
for 5 N 15, the default is 16 frames/packet
for N 16, the default is 8 frames/packet
Number of Frames per Packet, Unstructured
DS1, 192 bytes
E1, 256 bytes
Minimum and Maximum Payload Sizes
The SROS minimum payload size is 2 bytes and the maximum is 1514 bytes.
Packet Size vs. Packet Latency
Packet jitter is the time difference between a packets actual

arrival time and the expected arrival time caused by network
congestion, timing drift, or route changes
If packets are delayed by the network, some packets arrive in
bursts with inter-packet delays shorter than when they were
transmitted while others are delayed
Module 3 |
186
Jitter Buffer
Several network impairments prevent IP networks from carrying emulated circuit-switched traffic such as a T1
(1.544 Mb/s signal). A T1 line delivers a constant bit rate stream from node A to some node B on the other side of
the network.
As packets travel through the network, delay accumulates at each intermediary node. In order to compensate for
this delay, node B must use a jitter buffer to further delay packets in order to guarantee that there will always be
a packet ready to be transmitted out.
Where problems start to arise, however, is that each packet arrives with a different delay. The range of delay in
which packets arrive is known as time delay variation (TDV) or jitter. Typically, with a large enough jitter buffer,
packets will arrive in time to be useful. In the extreme case, a packet may be discarded if the time delay variation
exceeds the maximum the jitter buffer can accommodate.
Jitter Buffer
Jitter Buffer (cont)
The jitter buffer must be set to a minimum of 3 times the

packetization delay and should be greater than the maximum network
jitter
SROS plays out the buffer once it is 50% full
Module 3 |
187
Jitter Buffer (cont)

The cPipe service uses a jitter buffer to ensure received packets are tolerant of TDV. The buffer size must
consider the payload size, though other values may also affect this value, such as the number of nodes in the
network.
SROS plays out the buffer once it fills to 50%. The nominal default size is 5ms, but the router uses different
default values based on the number of frames, to ensure the buffer holds at least two frames before playing it
out.
The default CES DS1 and E1 jitter buffer sizes are as follows, where N= the number of timeslots:
N=1, 32ms
2 </= N </= 4, 16ms
5 </= N </= 15, 8ms
N >/= 16, 5ms
NOTE: The SROS may adjust the jitter buffer to avoid packet loss. The configured jitter buffer size may not be
what is actually used by the system.
Use the show service id <service_id> sap <sap-id> detail command to view the effective packet
delay variation tolerance.
...
------------------------------------------------------------------------------CEM SAP Configuration Information
------------------------------------------------------------------------------Endpoint Type
: Unstruct. T1
Bit-rate
: 24
Payload Size
: 192
Jitter Buffer (ms)
: 5
Jitter Buffer (packets): 6
Playout Threshold (packets): 4
Use RTP Header
: No
Differential
: No
Timestamp Freq
: 0
CAS Framing
: No CAS
Effective PDVT
: +/-2.984 ms
Cfg Alarm
: stray malformed pktloss overrun underrun
Alarm Status
:
------------------------------------------------------------------------------Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0
The cPipe uses a jitter buffer to adjust for Time Delay Variation
Model 2 cPipe Services

2G BTS traffic delivered to CSA on n x unstructured E1 circuits
E1 port on the 7705 SAR is configured with framing e1-unframed and CEM
encapsulation
7750 delivers BSC traffic on channelized ASAP or CES MDA STM-1 port
Module 3 |
188
Model 2 cPipe for 2G TDM Traffic

A 2G BTS delivers its traffic to the transport network over DS1 or E1 circuits. Though these may be channelized
using x number of 64Kb/s timeslots, with the increasing traffic volumes an unstructured circuit would be most
likely used.
The diagram shows the BTS sending traffic over n times unframed E1 circuits, typically one or two.
At the MTSO, the MLS delivers the traffic to the BSC over APS protected channelized STM-1 interfaces.
Supported MDAs
The 7705 SAR supports both structured and unstructured DS1/E1 on the 16 port DS1/E1 ASAP MDA.
The 7750 SR supports CEM on the ASAP and the channelized CES MDAs.
Model 2 cPipe for 2G TDM Traffic
Configuring the CSA E1 port
config>port#
config>port# tdm
tdm
config>port>tdm#
config>port>tdm# e1
e1
config>port>tdm>e1#
config>port>tdm>e1# framing
framing e1-unframed
e1-unframed
config>port>tdm>e1#
channel-group
config>port>tdm>e1# channel-group 11
config>port>tdm>e1>channel-group#
config>port>tdm>e1>channel-group# encap-type
encap-type cem
cem
config>port>tdm>e1>channel-group# no
no shutdown
shutdown
config>port>tdm>e1>channel-group# back
back
config>port>tdm>e1#
config>port>tdm>e1# no
no shutdown
shutdown
config>port>tdm>e1#
config>port>tdm>e1# back
back
config>port>tdm#
back
config>port#
config>port# no
no shutdown
shutdown
Set the port to e1-unframed

Configure the channel group to CEM encapsulation
The default mode is access and all 32 timeslots are used
Module 3 |
189
Configuring the CSA1 E1 Port

Port timing
Each OC-3/STM-1 port can be independently loop or node timed. Each port can be a timing source for the node.
Each DS-1 or E-1 channel without CAS signaling enabled can be independently configured to be loop-timed, nodetimed, adaptive-timed or differential-timed. Each DS-1 or E-1 channel with CAS signaling enabled can be
independently configured to be loop-timed or node-timed. Adaptive timed and differential-timed are not
supported on DS-1 or E-1 channels with CAS signaling enabled.
A CES circuits adaptive recovered clock can be used a timing reference source for the node (ref1 or ref2). This is
required to distribute network timing to network elements which only have packet connectivity to the network.
One timing source on the CMA/MDA can be monitored for timing integrity. Both timing sources can be monitored if
they are configured on separate CMA/MDAs while respecting the timing subsystem slot requirements. If a CES
circuit is being used for adaptive clock recovery at the remote end (such that the local end is now an adaptive
clock master), it is recommended to set the DS-1/E-1 to be node-timed to prevent potential jitter issues in the
recovered adaptive clock at the remote device.
SAToP Port Framing
When using SAToP to transport DS1 traffic, the framing bit (bit 193) in the DS1 overhead is included, packed in the
payload and sent over the PSN. If the underlying framing is ESF, then the Facility Data Link (FDL) channel is
transported over the cPipe as part of the SAToP service. No matter the case, for SAToP, the framing parameter of
the port must be set to unframed.
A:CSA2>config#
A:CSA2>config# port
port 1/1/1
1/1/1
config>port#
description E1
E1 tdm
tdm link
link towards
towards BTS10
BTS10 port
port 1"
1"
Configuring the MLS Path and Payload STM-1
config>port#
config>port# sonet-sdh
sonet-sdh
path sts3
sts3
config>port>sonet-sdh>path#
config>port>sonet-sdh>path# no
no shutdown
shutdown
config>port>sonet-sdh>path# back
back
config>port>sonet-sdh# group
group tug3-1
tug3-1 payload
payload vt2
vt2
path
vt2-1.1.1
config>port>sonet-sdh# path vt2-1.1.1
config>port>sonet-sdh>path# no
no shutdown
shutdown
back
config>port>sonet-sdh>path# back
vt2-tug3-1.tug2-1.vt2-1
config>port>sonet-sdh# back
back
config>port#
config>port# tdm
tdm
config>port>tdm#
config>port>tdm# e1
e1 1.1.1
1.1.1
config>port>tdm>e1#
config>port>tdm>e1# framing
framing e1-unframed
e1-unframed
config>port>tdm>e1#
config>port>tdm>e1# channel-group
channel-group 11
config>port>tdm>e1>channel-group$
config>port>tdm>e1>channel-group$ no
no shutdown
shutdown
config>port>tdm>e1>channel-group# back
back
config>port>tdm>e1#
config>port>tdm>e1# no
no shutdown
shutdown
config>port>tdm#
back
config>port#
config>port# no
no shutdown
shutdown
Module 3 |
190
Configuring the MLS2 Path and Payload

On the CEM MDAs, the default channel group mode is access and encapsulation type is CEM.
As we learned in Module 2, you must build out the TUGs before you can configure the E1s.
A:MLS1>config#
A:MLS1>config# port
port aps-2
aps-2
config>port#
description To
To BSC1
BSC1 over
over SDH"
SDH"
Creating the CSA cPipe Service
config>service>cpipe$
config>service>cpipe$ sap
sap 1/1/1.1
1/1/1.1 create
create
config>service>cpipe>sap$
cem
config>service>cpipe>sap$ cem
config>service>cpipe>sap>cem$
config>service>cpipe>sap>cem$ back
back
config>service>cpipe>sap$ back
back
config>service>cpipe#
config>service>cpipe# endpoint
endpoint BTS_20_port_1"
BTS_20_port_1" create
create
config>service>cpipe>endpoint#
config>service>cpipe>endpoint# back
back
config>service>cpipe# spoke-sdp
spoke-sdp 1:300
1:300 endpoint
endpoint "BTS_20_port_1"
"BTS_20_port_1" create
create
config>service>cpipe>spoke-sdp$
config>service>cpipe>spoke-sdp$ precedence
precedence primary
primary
config>service>cpipe>spoke-sdp$ back
back
config>service>cpipe# spoke-sdp
spoke-sdp 2:300
2:300 endpoint
endpoint "BTS_20_port_1"
"BTS_20_port_1" create
create
back
config>service>cpipe# no
no shutdown
shutdown
Use vc-type satop-e1 for unstructured E1, cem on the SAP

Redundant pseudowires terminate on POC3 routers
Uses default jitter buffer and payload size if not specified on SAP
Module 3 |
191
Creating the CSA cPipe Service

You must specify when you create the service the type of service, structured or unstructured, it will provide.
A:NodeA>config# service cpipe <service-id> vc-type {satop-e1|satopt1|cesopsn|cesopsn-cas} customer <customer-id> create
vc-type
satop-e1 Unstructured E1 CES
satop-t1 Unstructured DS1 CES
Unstructured CES is configured by choosing vc-type satop-t1 or satop-e1 as the when creating a Cpipe
service. For DS1 and E1 unstructured circuit emulation, the framing parameter of the port must be set to ds1unframed or e1-unframed (respectively) because SAToP service ignores the underlying framing. Additionally,
channel group 1 must contain all 24 or 32 timeslots, which is configured automatically when channel group 1
is created.
cesopsn Basic structured n*64 kb/s CES
Structured CES without CAS is configured by choosing vc-type cesopsn when creating a Cpipe service. For n
64 kb/s structured circuit emulation operation, the framing parameter of the port must be set to a framed
setting (such as ESF for DS1). Each channel group contains n DS0s (timeslots), where n is between 1 and 24
timeslots for DS1 and between 1 and 31 timeslots for E1.
cesopsn-cas Structured n*64 kb/s CES with signaling
Structured CES with CAS service is configured by choosing vc-type cesopsn-cas when creating a Cpipe
service. The DS1 or E1 service on the port associated with the Cpipe SAP should be configured to support CAS
(via the signal-mode {cas} command) before configuring the Cpipe service to support DS1 or E1 with CAS.
Refer to the 7705 SAR OS Interface Configuration Guide for information on configuring signal mode.
CEM
On the SAP you must set the cem context. This allows you to set the jitter buffer and payload size. If not set,
the router uses for the number of timeslots defined on the E1 circuit to set the jitter buffer size.
A:CSA2>config>service# cpipe
cpipe 300
300 vc-type
vc-type satop-e1
satop-e1 customer
customer 11 create
create
description
Distributed
config>service>cpipe$ description Distributed cpipe
cpipe for
for 2G
2G BTS
BTS Services"
Services"
A:POC3>config>service#
A:POC3>config>service# cpipe
cpipe 300
300 vc-type
vc-type satop-e1
satop-e1 vc-switching
vc-switching customer
customer 11 create
create
config>service>cpipe$ description
description Distributed
Distributed cpipe
cpipe for
for for
for 2G
2G BTS
BTS Services"
Services"
config>service>cpipe$ spoke-sdp
spoke-sdp 2:300
2:300 create
create
back
spoke-sdp 4:300
4:300 create
create
back
config>service>cpipe$ no
no shutdown
shutdown
POC3 is the S-PE

Use vc-type satop-e1 and vc-switching when creating the service
Module 3 |
192
Creating the S-PE cPipe Service
A:MLS1>config>service# cpipe
cpipe 300
300 vc-type
vc-type satop-e1
satop-e1 customer
customer 11 create
create
description
Distributed
config>service>cpipe$ description Distributed for
for 2G
2G BTS
BTS Services
Services ""
config>service>cpipe$ endpoint
endpoint SAP
SAP create
create
config>service>cpipe>endpoint$
config>service>cpipe>endpoint$ back
back
config>service>cpipe$ endpoint
endpoint SPOKE
SPOKE create
create
config>service>cpipe>endpoint$
config>service>cpipe>endpoint$ back
back
config>service>cpipe$ sap
sap aps-2.1.1.1.1
aps-2.1.1.1.1 endpoint
endpoint SAP
SAP create
create
cem
config>service>cpipe>sap$ cem
aps-2.tug3-1.tug2-1.vt2-1.channel-group 1
config>service>cpipe>sap>cem$
config>service>cpipe>sap>cem$ back
back
config>service>cpipe>sap$ back
back
spoke-sdp 3:300
3:300 endpoint
endpoint SAP
SAP icb
icb create
create
back
spoke-sdp 1:300
1:300 endpoint
endpoint SPOKE
SPOKE create
create
back
spoke-sdp 3:301
3:301 endpoint
endpoint SPOKE
SPOKE icb
icb create
create
back
config>service>cpipe$ no
no shutdown
shutdown
APS group in SAP, aps-2.tug3-1.tug1-1.vt2-1.channel-group 1

ICB-PW to provide path of last resort to active SONET/SDH link
If not specified on the SAP, the service uses default jitter buffer and payload
Module 3 |
193
Creating the MLS router ICB-PW cPipe Service

Configure Jitter Buffer and Payload Size
Under the sap>cem context, set the jitter buffer and payload size. Below are the defaults for an E1 SAP:
A:NodeA>config>service>cpipe>sap>cem# info detail
---------------------------------------------packet jitter-buffer 5 payload-size 256
report-alarm stray malformed pktloss overrun underrun
no report-alarm rpktloss rfault rrdi
no rtp-header
----------------------------------------------
Creating the MLS router ICB-PW cPipe Service
View the CSA cPipe Status

===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 300
Service Id
Id
300
Service
:: Cpipe
VLL
:: SAToPE1
Service Type
Type
Cpipe
VLL Type
Type
SAToPE1
Description
:: Distributed
Description
Distributed cpipe
cpipe for
for for
for 2G
2G BTS
BTS Services
Services
Customer
:: 11
Customer Id
Id
Last
Last Status
Status Change:
Change: 09/02/2011
09/02/2011 10:06:46
10:06:46
Last
Last Mgmt
Mgmt Change
Change :: 09/02/2011
09/02/2011 09:54:53
09:54:53
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
MTU
:: 1514
MTU
1514
Vc
:: False
Vc Switching
Switching
False
SAP
:: 11
SDP
:: 22
SAP Count
Count
SDP Bind
Bind Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:1/1/1.1
cem
1514
1514
Up
Up
sap:1/1/1.1
cem
1514
1514
Up
Up
sdp:1:300
n/a
00
1550
Up
Up
sdp:1:300 S(192.0.2.0)
S(192.0.2.0)
n/a
1550
Up
Up
sdp:2:300
n/a
00
1550
Up
Up
sdp:2:300 S(192.0.2.1)
S(192.0.2.1)
n/a
1550
Up
Up
===============================================================================
===============================================================================
Module 3 |
194
View the CSA aPipe Status

VLL Type: - SAToPE1 Structure agnostic E1 service
A:CSA2#
A:CSA2# show
show service
service id
id 300
300 base
base
View the MLS cPipe Status

===============================================================================
===============================================================================
Service
Service Basic
Basic Information
Information
===============================================================================
===============================================================================
Service
:: 300
Vpn
:: 00
Service Id
Id
300
Vpn Id
Id
Service
:: Cpipe
VLL
:: SAToPE1
Service Type
Type
Cpipe
VLL Type
Type
SAToPE1
Name
:: (Not
Name
(Not Specified)
Specified)
Description
:: (Not
Description
(Not Specified)
Specified)
Customer
:: 11
Customer Id
Id
Last
Last Status
Status Change:
Change: 09/02/2011
09/02/2011 13:51:05
13:51:05
Last
Last Mgmt
Mgmt Change
Change :: 09/02/2011
09/02/2011 13:51:12
13:51:12
Admin
:: Up
Oper
:: Up
Admin State
State
Up
Oper State
State
Up
MTU
:: 1514
MTU
1514
Vc
:: False
Vc Switching
Switching
False
SAP
:: 11
SDP
:: 33
SAP Count
Count
SDP Bind
Bind Count
Count
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Service Access
Destination Points
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
AdmMTU
Identifier
Type
AdmMTU OprMTU
OprMTU Adm
Adm Opr
Opr
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:aps-2.1.1.1.1
cem
1578
1578
Up
Up
sap:aps-2.1.1.1.1
cem
1578
1578
Up
Up
sdp:1:300
Spok
00
1550
Up
Up
sdp:1:300 S(192.0.2.3)
S(192.0.2.3)
Spok
1550
Up
Up
sdp:3:300
Spok
00
1550
Up
Up
sdp:3:300 S(192.0.2.1)
S(192.0.2.1)
Spok
1550
Up
Up
sdp:3:301
Spok
00
1550
Up
Up
sdp:3:301 S(192.0.2.1)
S(192.0.2.1)
Spok
1550
Up
Up
Module 3 | 195
===============================================================================
===============================================================================
View the MLS aPipe Status

VLL Type: - satop-e1.
Service Access & Destination Points - Identifier APS SAP and both ICB spoke SDPs are Up
SDP:3:300 ICB endpoint SPOKE
SDP:3:301 ICB endpoint SAP
A:MLS1#
A:MLS1# show
show service
service id
id 300
300 base
base
CES Packet Loss
Re-ordering is corrected in the jitter buffer on egress

Lost packet data (L bit=1) must be replaced to ensure proper TDM
operation and prevent underruns
Typically the egress router inserts all ones, but any defined byte
pattern may be used
Alternatively, the last frame received can be inserted
Module 3 |
196
cPipe Packet Loss

The CE-bound interworking function (IWF) uses the sequence numbers in the control word to detect lost and
incorrectly ordered packets. Incorrectly ordered packets that cannot be reordered are discarded.
For unstructured CES, the payload of received packets with the L bit set is replaced with an all-ones pattern. For
structured CES, the payload of received packets with the L bit set is replaced with an all-ones or a userconfigurable bit pattern. This is configured using the idle-payload-fill command. For structured CES with
CAS, the signaling bits are replaced with an all-ones or a user-configurable bit pattern. This is configured using the
idle-signal-fill command.
All circuit emulation services can have a status of up, loss of packets (LOP) or admin down, and any jitter buffer
overruns or underruns are logged.
Packet loss or re-ordering is detected through packet sequence

numbers in control word
Module 3 |
197
Model 2 Legacy Services cPipe Detailed View
.5 Hour
Lab Objectives:
On the CSA routers, provision redundant cPipe spoke SDPs and BTS facing
SAPs
On the MLS routers, provision PW switching for the cPipe service
On the CR router, provision the cPipe spoke SDPs and NC SAPs
Module 3 |
198
Lab 9 : Configure 2G Voice cPipe Service
Section Review
Provisioned the ATM voice traffic distributed aPipe services

Implemented PW redundancy in the aPipe services
Provisioned MC-APS and ICB-PW on aPipe services
Configured the TDM voice traffic distributed cPipe services
Module 3 |
199
Reviewed the Model 2 Legacy (ATM and TDM) 2 and 3G voice,

data, and control traffic paths and services
Module Summary
The components needed to build local and distributed Model 1

and Model 2 network services
Pseudowire redundancy protects the distributed VPWS services
from the CSA to the POC3 and POC1 routers
Duplicated services at the POC3 and POC1 routers ensure that the
BS has a path for traffic to and from the NC elements
A CCAG configured on a set of VSMs provides bidirectional logical
links between L2 and L3 services on a local router
VRRP protects the NC element gateway interface with a virtual
router instance
A management VPLS runs RSTP on behalf of a set of VLANs
identified in a SAPs managed-vlan-list
Module 3 |
200
An iPipe provides a VPWS to transport IP packets between

dissimilar L2 interfaces
For LTE traffic, the Model 1 network uses a flat routed
architecture consisting of ePipes spoke-terminated into MLS IES
services
LTE EPC inter-element traffic is routed at the MLS router IES and
network interfaces
An inner VPLS may be used to support multiple MMEs on the same
broadcast domain, and to support VRRP signaling
Pseudowire switching allows inter-area VPWS without additional
overhead
MC-LAG and MC-APS can work with PW redundancy to protect the
service and the NC elements physical links
Module 3 |
201
Interchassis Backup PW ensure a path of last resort between the

MLS routers with MC-LAG or MC-APS protect NC element links
aPipes carry 3G ATM BS traffic between the CSA and the MLS
routers
An aPipe supports cell concatenation to reduce overhead and
more efficiently use the available transport bandwidth
cPipe VPWS carry either channelized or unchannelized DS1 or E1
circuits over the IP/MPLS transport
Timing, packetization delay, jitter, and packet loss are important
considerations when deploying cPipe services
Module 3 |
202
a) The local PW status

b) The remote PW precedence
c) The local spoke ce-address
d) The remote PW status
2. What is the default precedence on a spoke SDP not configured with
precedence primary?
a) 0
b) 2
c) 4
d) 7
Module 3 |
203
Answers:
1. A, D
2. c
1. A PE router is configured with an iPipe service and a primary and

secondary spoke SDP. Which two of the following criteria does the node
use to choose the active spoke SDP? (Choose two.)
a) 1
b) 2
c) 3
d) 4
4. What is the maximum number of VSMs that can be associated with
a CCAG?
a) 1
b) 4
c) 6
d) 8
Module 3 |
204
Answers:
3. D
4. D
3. How many spoke SDP objects can be associated with a single

explicit endpoint?
a) An external hairpin
b) A routed VPLS
c) A routed ePipe
d) A CCAG
6. Which statement is true concerning the configuration of a local
VPRN service?
a) It requires a route target
b) It requires a route distinguisher
c) It requires Multiprotocol-BGP
d) It requires an IGP
Module 3 |
205
Answers:
5. A, B, D
6. B
5. What three options are available in the SROS for cross connecting
a local L2 service to a local L3 service? (Choose three.)
_________________________________________________________
8. On a VPWS endpoint, what command tells the local PE to keep
traffic on the secondary spoke SDP even if the primary recovers?
_________________________________________________________
9. On an L2 service spoked into an L3 interface, what must match
between the two services in order for the spoke SDPs to become
operational? (choose two.)
a) vc-mtu
b) vc-id
c) vc-type
d) vrid
Module 3 |
206
Answers:
7. A:NodeA>config>service>epipe>endpoint# standby-signaling-master
8. A:NodeA>config>service>epipe>endpoint# revert-time infinite
9. a, b
7. What command would you use on a VPWS endpoint to control the

far-end PEs active interface choice?

10.How might the NC element learn the VRRP virtual router MAC
address?
b) ARP request
c) Master announcement message
d) VRRP initialization message
11.What command in a management VPLS context identifies the
VLANs the service protects?
_________________________________________________________
12.In an iPipe service, how does the service verify which ARP requests
to answer and which to ignore?
_________________________________________________________
Module 3 |
207
Answers:
10. b
11. managed-vlan-list range <range>
12. It ignores requests for any but the far-end ce-address MAC, and answers only those with the local SAP ceaddress as the source IP address
a) Forwarding database update
_________________________________________________________
14.An iPipe spoke SDP binding ce-address entry belongs to which
service component?
_________________________________________________________
15. In the Model 1 network model, where does eNodeB-eNodeB traffic
route?
_________________________________________________________
16.In the Model 2 network, where does BS-BS traffic route?
_________________________________________________________
17.In the Backhaul Transport, where does EPC element traffic route?
_________________________________________________________
Module 3 |
208
Answers:
13. IPCP
14. The far-end PE L3 interface
15. The MLS IES
16. The POC3 router VPRN services
17. At the MLS router IES or VPRN interfaces
13.On an iPipe SAP configured for PPP, what protocol passes the BTS
IP address?
a) It initiates label signaling toward the T-PE routers

b) It replaces the received PW status TLV with its own PW status
c) It signals its own service SAP status in its PW status TLV
d) It forwards the received PW status to the upstream T-PE
19.In a switched PW service, what command configures a node as the
S-PE?
_________________________________________________________
20.On a VPWS without ICB-PW, a PE will signal what status for the
MC-APS standby SAP?
_________________________________________________________
Module 3 |
209
Answers:
18. d.
19. configure service epipe 1 customer 1 vc-switching create
20. 0x26, pseudowire in standby, remote SAP down
18.Which statement best describes the S-PE function in a PW

switched VPWS?
a) Explicit endpoints in each MC peer service

b) ICB spoke SDPs in each MC peer service
c) ICB SAPs in each MC peer service
d) Two SAPs per MC peer service
22.When used with ICB-PW, what status will the MC peer signal for
the standby SAP?
_________________________________________________________
23.A SONET link configured for Automatic Protection Switching (APS)
signals APS status with what part of the frame overhead and on
which facility?
_________________________________________________________
Module 3 |
210
Answers:
21. a, b
22. 0x20, PW forwarding standby
23. K1 and K2 bytes, on the protection facility
21.ICB-PW protected services require what configuration components

to provide a last-resort path to the MC-protected SAP? (choose
two.)
24. On a node configured as the MC-APS working chassisg, what command

shows the active circuit information?
25. What vc-type value would you set on an aPipe service to implement ATM
N=1 mode?
________________________________________________________
26. A 7750 SR configured with N:1 aPipes would require a minimum of how
many services to transport 4 different ATM service profiles?
________________________________________________________
27. With what vc-type would you configure a cPipe to carry a clear-channel
DS1 or E1 circuit?
_________________________________________________________
28. How large is a unstructured cPipe payload carrying 8 DS1 frames of 24
timeslots each?
____________________________________________________________
Module 3 |
211
Answers:
24. show aps aps-1
25. atm-vcc
26. 4, one per profile
27.satop-e1 or satop-t1
28.8x24=192 bytes
_______________________________________________________
a) 1ms
b) 3ms
c) 5ms
d) 10ms
30.To carry a unchannelized E1 circuit in a structure agonostic cPipe
service, how must the 7705 SAR TDM port be configured?
a) framing cem
b) framing e1-framed
c) framing e1-unframed
d) framing satop-e1
Module 3 |
212
Answers:
29. b, 3 x the packetization delay, d = 125us/frame x 8 frames = 1ms
30. c
29.A cPipe builds a payload consisting of 8 clear-channel E1 circuits of

32 timeslots each. At a minimum, how large must the jitter buffer
be set to ensure proper playout?
Module 3 |
TTP36002 Edition 1
214

Transport
Appendix A References
Appendix A Page 1| All rights reserved 2012 Alcatel-Lucent
[1] Scott Larrigan, Alcatel-Lucent Product Marketing Manager. (2011, March). Faster, Smarter, Better:
Converged All-IP Backhaul, Mobile World Congress 2011, Barcelona. Available: https://all1.us.alcatellucent.com/projects/SolutionDemos/Wiki%20Pages/Home.aspx
[2] 3GPPTM home page. (2011, March 21). Available: www.3gpp.org
[3] 3GPP2 home page. (2011, March 21). Available: www.3gpp2.org
[4] About ITU. (2011, March 22). Available: www.itu.int/net/about/index.aspx
[5] The Internet Engineering Task Force (IETF). (2011, March 22). Available: www.ietf.org
[6] MEF home page. (2011, March 22). Available: metroethernetforum.org/index.php
[7] IEEE home page. (2011, March 22). Available: www.ieee.org/index.html
[8] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect IP/MPLS MBH. (2010, November 16). LTE Solutions
Key Topics MBH1-MBH3 (Mobile Backhaul for IP/MPLS oriented MSP and BTP R1.0) MBH1&3 R1.0. Available:
TBD
[9] Kevin English and Robert Castellano, Alcatel-Lucent Mobile Backhaul Solutions. (2009, November). Mobile
Backhaul Blueprint Solution Customer Requirements Document, Baseline Version 1.0. Available: TBD
[10] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2011, February 17). InterRegional Line Up on MBH. Available: https://sps.eu.alcatel-lucent.com/sites/Wireline.bell/default.aspx
[11] Joseph Veltri, Alcatel-Lucent. (2009, March 13) APXLIB d50989, EBH Transport Design Document for EV-DO
and 3G1x EBH.R33.3.0. Available: TBD
[12] Jorge Rabadan, Alcatel-Lucent. (2011, Q2) Vodafone Global IMATE Architecture, High Level Design Version
0.4. Draft. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe
ll%2fShared%20Documents%2fCustomer%20Project%20Information%2fVodafone%2fVF%20Global%2fBEP1%2dIMATE%
2dFMC&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d
[13] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2009, September). Solution
Blueprint MBH 1/3: IP Mobile Backhaul High Level Design R1.0 Architect document part 1a. Available:
http://ct.web.alcatel-lucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100ABAA&root=ALU2010&selector=custom&custom_section=sol_collateral_view
[14] Alcatel-Lucent white paper Transforming to a Sustainable Wireless Business Model.
[15] D. Chislow, Alcatel-Lucent. (2008, July 11) SR/ESS PRD Synchronization PRD Revision: 1.3. Alcatel-Lucent
Internal Use only.
[16] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. Mobile Backhaul
Challenges/Solutions R0.1. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe
ll%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul%2fMBH%20Pr
esentations%20%2d%20technology%20independent&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA
3%7d
[17] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2010, April 12). MBH1/3 R1.0
HLD Documentation. Concepts, structure, and how to use. Available: http://ct.web.alcatel-lucent.com/prp/cgibin/public/ProductPortal.cgi?number=3MM-001010001&root=ALU2010&selector=custom&custom_section=sol_collateral_view
[18] Alcatel-Lucent. Technology White Paper. IP/MPLS Transport in the Evolving GSM/UMTS Mobile Radio Access
Network. Available: http://all.alcatellucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLt4x39A7QL8h2VAQAT8ihFw!!?LMSG_CA
BINET=Solution_Product_Catalog&LMSG_CONTENT_FILE=Products/Product_Detail_000426.xml#tabAnchor4
[19] Alcatel-Lucent University. (2008) TER 36035 - 7705 SAR 3.0 IP/Ethernet Backhaul. Available:
https://all1.us.alcatel-lucent.com/teams/ALUUOTTAWA/My%20Wiki%20Library/IPD_Lead_House.aspx
[20] Adam Kasim. (2008) Delivering Carrier Ethernet: Extending Ethernet Beyond the LAN. Available:
http://books.google.com/books?id=cznVxJ4QSnUC&pg=PA306&lpg=PA306&dq=sonet+vcg&source=bl&ots=K72f06G
Z2b&sig=eVhE7j56ucLwBau0CXOJyrFPfaA&hl=en&ei=XeSxTa6HA8jx0gGsheXfBA&sa=X&oi=book_result&ct=result&r
esnum=4&ved=0CDQQ6AEwAw#v=onepage&q=sonet%20vcg&f=false
[21] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2009, September). MBH1/3 R1.0
HLD Documentation. Architecture document part 2a v1.0. Available: http://ct.web.alcatellucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-001010001&root=ALU2010&selector=custom&custom_section=sol_collateral_view
References
[22] Alcatel-Lucent University. (2008) IPBH w/VPRN and 7705. Available: https://all1.us.alcatellucent.com/teams/ALUUOTTAWA/My%20Wiki%20Library/IPD_Lead_House.aspx
[23] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2010, November 16). LTE
Solutions Key Topics MBH1-MBH3 (Mobile Backhaul for IP/MPLS oriented MSP and BTP R1.0) MBH1&3 R1.0
Available: http://___ KeyTopicsMBH1-3-LTE-20101115FINAL.ppt
[24] ITU-T Recommendation G.824. (2000, March). Series G: Transmissions Systems and Media, Digital Systems
and Networks, Digital transmission systems Digital networks Quality and availability targets. The control of
jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy. Available:
http://www.itu.int
[25] Anthony Magee, ADVA Optical Networking. (2010, October). IEEE Communications Magazine. Carrier Scale
Ethernet, Synchronization in Next-Generation Mobile Backhaul Networks. Available:
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05594685&tp=?ALU=LU1024572&tag=1
[26] Juniper Networks. (2011). White Paper. Synchronization Deployment Considerations for IP RAN Backhaul
Operators. Juniper Networks TCA Series Timing Appliances Address the Complex Timing and Synchronization
Requirements of Todays Networking Environments. Available:
http://www.juniper.net/us/en/local/pdf/whitepapers/2000400-en.pdf
[27] Patrick Diamond, PhD, Semtech Corporation. (2008, October). Semtech White Paper. Packet Synchronization
in Cellular Backhaul Networks. Available: http://www.semtech.com/images/promo/Packet-Synchronization-inCellular-Backhaul-Networks.pdf
[28] Fred Davant, Alcatel-Lucent PLM LTE. (2007) LTE Transport, Synchronization and Security. Available: http://
[29] Pierre El-Haddad, Alcatel-Lucent. (2010, November) LTE Mobile Backhaul Reference Architectures.
Available: http://
[30] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2010, May). Solution Blueprint
MBH 1/3: IP Mobile Backhaul High Level Design R1.0 TDM service delivery. Available: http://ct.web.alcatellucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100ABAA&root=ALU2010&selector=custom&custom_section=sol_collateral_view
[31] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH. (2009, September). Solution
Blueprint MBH 1/3: IP Mobile Backhaul High Level Design v1.0 Synchronization. Available: http://ct.web.alcatellucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100ABAA&root=ALU2010&selector=custom&custom_section=sol_collateral_view
[32] D. Chislow, Alcatel-Lucent IPD Division. (2008, July 11) SR/ESS PRD Synchronization PRD.
[33] US Government. Emerging Wireless Technologies. Enhanced 911 Enhanced Wireless Emergency
Communications. Available: http://www.safecomprogram.gov/NR/rdonlyres/D8BFF5A9-47A7-4496-AB93611DD043C3E0/0/emerging_wireless_technologies_enhanced_911.pdf
[34] ITU-T Recommendation G.813. (1996, August). Series G: Transmissions Systems and Media, Digital
transmission systems Digital networks Design objectives for digital networks. Timing characteristics of SDH
equipment slave clocks (SEC). Available: http://www.itu.int
[35] ITU-T Recommendation G.8262/Y.1362. (2010, July). Series G: Transmissions Systems and Media, Digital
systems and networks Quality and availability targets. Series Y: Global information infrastructure, Internet
protocol aspects and next-generation networks. Internet protocol aspects - Transport. Timing characteristics of
Synchronous Ethernet equipment slave clock (EEC). Available: http://www.itu.int
[36] ITU-T Recommendation G.8262/Y.1362. (2008, October). Series G: Transmissions Systems and Media, Digital
systems and networks Quality and availability targets. Series Y: Global information infrastructure, Internet
protocol aspects and next-generation networks. Internet protocol aspects - Transport. Distribution of timing
information through packet networks. Available: http://www.itu.int
[37] ITU-T Recommendation G.781. (2008, September). Series G: Transmissions Systems and Media, Digital
systems and networks Digital terminal equipments Principle characteristics of multiplexing equipment for the
synchronous digital hierarchy. Synchronization layer functions. Available: http://www.itu.int
[38] IEEE 802.3-2008. (2008, December 26) IEEE Standard for Information technology Telecommunications and
information exchange between systems Local and metropolitan area networks Specific requirements. Part 3:
Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and Physical Layer
specifications. Annex 57A. Available: http:// www.ieee.org/index.html
[39] Alcatel-Lucent. (2010, February). 2.2. 7705 SAR Synchronization Status Messages. Issued v1.0. Available:
https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%
2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d1
91A%2d473D%2d9199%2dD03A1C45808C%7d
[40] P. Roberts. Alcatel-Lucent. (2011, April 6). PTPv2_Freq_PRD, 7x50_PRD_ptp1588_Freq_v1.4.doc. Alcatel
Lucent Internal Use Only.
References
References
[42] IEEE Instrumentation and Measurement Society. (2008, July 24) IEEE Std 1588-2008. IEEE Standard for a
Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. Available: http://
www.ieee.org/index.html
[43] Andre Ethier, Alcatel-Lucent Wireless Division. (2011, March 18). LTE Synchronization Solutions for Claro
Brazil. Available: http://www.alcatel-lucent.com
[44] Jean-Loup Ferrant, et al. (2010, October). Development of the First IEEE 1588 Telecom Profile to Address
Mobile Backhaul Needs. IEEE Communications Magazine, October 2010. available: http://ieee.org.
[45] A. Vainshtein, et al. (2007, December). Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
Service over Packet Switched Network (CESoPSN). IETF Network Working Group Informational RFC. Available:
http://tools.ietf.org/html/rfc5086
[46] Alcatel-Lucent University. (2005). Alcatel 3600+ MainStreet Bandwidth
Manager Core Functions R9.0 Ver 1
[47] Tektonix, Inc. SDH Telecommunications Standard Primer. Available:
http://www.tek.com/Measurement/App_Notes/sdhprimer/2RX_11694_2.pdf
[48] Havard University. An Introduction to SDH and SONET. Available:
http://people.seas.harvard.edu/~jones/cscie129/nu_lectures/lecture12/sonet/sonet.html
[49] Cisco, Inc. A Brief Overview of SONET Technology. Available:
http://www.cisco.com/en/US/tech/tk482/tk607/technologies_tech_note09186a0080094313.shtml
[50] Wayne Jones Jnr. Chapter 17. SONET/SDH. Available: http://www.slideshare.net/WayneJonesJnr/ch173361668
[51] Alcatel-Lucent University. (2001, July). 1631 SX LMC Operations and Maintenance Student Guide. 1631LM310250. Issue 3.00. Available: http://www.alcatel-lucent.com
[52] Alcatel-Lucent. (2008, May). 3.4 7705 SAR Synchronization R1.0 v1.0. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%
91A%2d473D%2d9199%2dD03A1C45808C%
[53] TechFest.com. SONET/SDH Technical Summary. Available:
http://www.techfest.com/networking/wan/sonet.htm
[54] Telecommunication Research Associates. (2000) The Pocket Network Guide. Alcatel. Version 1.0. Available:
http://www.tra.com
[55] Silvana Rodriques, IDT. Sebastian Jobert, France Telecom. IDT. (2009, November) IEEE-1588 Profiles.
Presentation to ITSF-09, Rome, November 3 to 5, 2009. Available: http://www.telecomsync.com/pdf/2009/Day1/IDT%20IEEE-1588%20Profiles.pdf
[56] Craig Preuss, PE. Engineering Manager, Black & Veatch Corp. (Date unknown) Perfect Timing How IEEE
Standard PC37.238 Impacts Substation Automation. Available:
http://ewh.ieee.org/cmte/substations/scm0/Chicago%20Meeting/Conference%20PDFs/tutorial%20handouts/Coll
oquium/Impact%20of%20Time%20Synch%20on%20Sub%20Automation%20-%20Preuss.pdf
[41] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - IP/MPLS MBH./Peter Roberts. Alcatel-Lucent.
(2011, April) Alcatel-Lucent PTP Design Guidelines (Draft), Issue 1. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%
91A%2d473D%2d9199%2dD03A1C45808C%7d
References
MBH 1/3: IP Mobile Backhaul High Level Design v1.0 IP/MPLS infrastructure. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe
ll%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul&View=%7bE7
F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d
[59] Alcatel-Lucent. (2011, March). 7750 SR OS Router Configuration Guide. Software Version: 7750 SR OS 9.0R1.
Document Part Number: 93-0073-08-01. Available: https://market.alcatellucent.com/release/jsp/sso/login.jsp?TYPE=33554433&REALMOID=06-3cffeb57-8088-001e-00006f4900006f49&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$Vs%2fCwDSWZ8BOHkVOoewB7IvXS
BgFCYcdLKauGuwzsJHsPRgrWps%2f0Exm%2fL%2bHbAmU&TARGET=$SM$https%3a%2f%2fwww1%2ealcatellucent%2ecom%2fosds%2f%3f_requestid%3d23167
[60] Walter Goralski. (2002). SONET/SDH. Third Edition. ISBN 0-07-222524-6. McGraw-Hill/Osborne. 2600 Tenth
Street, Berkely, California, 94710.
[61] William Pacino. (Date unknown.) Telecommunications Standards Primer. What is SDH? Available:
http://users.rcn.com/wpacino/sdh_2pri.htm
[61] Juniper Networks. (Date unknown). Configuring Multilink PPP Overview. Available:
http://www.juniper.net/techpubs/software/erx/junose72/swconfig-link/html/mlppp-config2.html
[62] Paul Reid, Alcatel-Lucent. (2009, November). 7705 Service Aggregation Router. Available:
https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%
91A%2d473D%2d9199%2dD03A1C45808C%
[63] Dr. Yaakov Stein, Chief Scientist, RAD Communications. (2006, August) RAD Data Communications White
Paper. TDM Timing. Available: http://www.dspcsp.com/RAD/tdm_timing_wp.pdf
[64] Alcatel-Lucent. (2011, March). 7750 SR OS Services Guide. Software Version: 7750 SR OS 9.0 r1. Available:
http://www.alcatel-lucent.com.
[65] Alcatel-Lucent. (2011, April). Alcatel-Lucent Services Architecture. Version 3.1. Student Guide. Available:
http://www.alcatel-lucent.com/src.
[66] Zhuo (Frank) Xu, Alcatel-Lucent. (2010). Designing and Implementing IP/MPLS-Based Ethernet Layer 2 VPN
Services An Advanced Guide for VPLS and VLL. Available: http://www.alcatel-lucent.com/src.
[67] L. Martini, Cisco Systems, Inc. (2006, April). Network Working Group. Request for Comments: 4446. IANA
Allocations for Pseudowire Edge to Edge Emulation (PWE3). Available: http://ietf.org
[68] Praveen Muley and Mustapha Aissaoui, ed. (2011, March 11). Network Working Group. Internet Draft. draftietf-pwe3-redundancy-bit-04.txt. Pseudowire Preferential Forwarding Status Bit. Available: http://ietf.org.
[69] Alcatel-Lucent. (2010). Alcatel-Lucent Virtual Private LAN Services. Version 2.0. Student Guide. Available:
http://www.alcatel-lucent.com/src.
[70] Alcatel-Lucent. (2009) Alcatel LIghtspeed TAC Overview. 3FL30501. Edition 4. Available:
http://www.alcatel-lucent.com
[71] Lyn Rees, EMEA Qual Assur and Cust Care. Alcatel-Lucent. (February 24, 2009). Mobile Backhaul MCAPS/PWE3 Redundancy. MC-APS/PWE3 Redundancy Configuration. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe
ll%2fShared%20Documents%2fSolution%20info%2fCDMA&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F72
3DA3%7d
[57] Microsoft. (Date unknown) TechNet Library, IPv6 Identifiers. Available: http://technet.microsoft.com/enus/library/cc736439%28WS.10%29.aspx.
References
MBH 1/3: IP Mobile Backhaul High Level Design ATM Service Delivery. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe
ll%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul&View=%7bE7
F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d
[73] Alcatel-Lucent. (2011, March). 7750 SR OS Interfaces Guide. Software Version: 7750 SR OS 9.0 r1. Available:
http://www.alcatel-lucent.com.
[74] Anthony Peres, Keith Allan, PLM. (2003) 7x50 Product Briefing for Release 3.0. Available:
http://www.alcatel-lucent.com
[75] Gerwyn Frowen, Alcatel-Lucent EMEA QA and Customer Care. (2009, October 19). 7705 SAR 2.1 1588v2
Client. Issued 1.1. (Split from r2.1 Update Presentation) Available: http://www.alcatel-lucent.com.
[76] NGMN Alliance. (2011, July). ngmn LTE backhauling deployment scenarios by NGMN Alliance. v1.4.2. FINAL.
Editor/Submitter: Miguel Angel Alvarez, Frederic Jounay, Tamas Major, Paolo Volpato. Avaible: www.ngmn.org
TTP36002 Edition 1

Alcatel Lucent IP MPLS Mobile Backhaul Transport Student Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alcatel Lucent IP MPLS Mobile Backhaul Transport Student Guide PDF

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent IP/MPLS Mobile Backhaul

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 0 Course Introduction

Alcatel-Lucent Career Certification Flow

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

All rights reserved 2012 Alcatel-Lucent