Alcatel-Lucent IP MPLS Mobile Backhaul Transport Student Guide

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

Module 0 – Course Introduction

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Module 0 - Page 2 | All rights reserved © 2012 Alcatel-Lucent

Module 0 | 2 All rights reserved © 2012 Alcatel-LucentAlcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module Overview

Alcatel-Lucent Career Certification Flow

General Course Information

Timeline

Objectives

Prerequisites

Follow On

Introduction

Goal

Administration

Alcatel-Lucent IP/MPLS Mobile Backhaul TransportThis 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.alcatel-lucent.com/support

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



The Alcatel-Lucent SRC Program – Five Certifications

ALCATEL-LUCENT NETWORK ROUTING SPECIALIST I4 DAYS / 1 COURSE / 1 WRITTEN EXAM

ALCATEL-LUCENT TRIPLE PLAY ROUTING PROFESSIONAL36 DAYS / 8 COURSES / 8 WRITTEN EXAMS / 1 PRACTICAL LAB EXAM

ALCATEL-LUCENT SERVICE ROUTING ARCHITECT49 DAYS / 11 COURSES / 11 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS

ALCATEL-LUCENT NETWORK ROUTING SPECIALIST II18 DAYS / 4 COURSES / 4 WRITTEN EXAMS / 1 PRACTICAL LAB EXAM

ALCATEL-LUCENT MOBILE ROUTING PROFESSIONAL32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SRC Courses and Exams

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SRC Program Exam Profile

Exam Name 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

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 ASRA4A0100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,

NRSII4A0

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Exam Delivery

Written Exams

Delivered by Prometric

Global provider of testing services

5000+ test sites worldwide

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

• On-site delivery at your business location anywhere in the world• Delivery from any of the following Alcatel-Lucent University locations

globally

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Your Own Service Router Lab – Now you can have one

Need access to a lab to help you: Prepare for your NRS II and SRA exams?

Practice and build your service routing knowledge and configuration skills?

The Alcatel-Lucent Exam Preparation service provides: Remote, private access (7×24) 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Credit for other IP Certifications

Cisco or Juniper certified?

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.alcatel-

lucent.com/src/exemptions

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent IP/MPLS Mobile Backhaul Transport — Timeline

Day 1 Module 0 — Course Introduction Module 1 — IP/MPLS Mobile Backhaul Transport Network

ArchitecturesDay 2 Module 2 — Implementing the Mobile Backhaul

Transport NetworkDay 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)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

After successful completion of this course, you will understand:

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

After successful completion of this course, you will understand:

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Prerequisites

Suggested 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Follow On

Suggested Follow-on Courses

• 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Introduction

With the rising demands for mobile broadband services, operatorsrealize a sharp increase in bandwidth requirements. Hence, theymust 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 viaService 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Course Goal

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Typical graphic symbols found in this courseware.


Presentation Graphics

Generic routers

Network Cloud

Pipe serviceor tunnel

Generic L2 Switch

PE whenblock diagram used

SAPSAP

SDP

Generic NC Element

PRC

MSCGeneric EPC Element

Generic Base Station

EthernetMPLS Label

Service LabelPayload

Service Packet PE

Optical Transport UNI/NNI

7750 SR 7705 SAR

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Administration

Registration

Facility Information

Restrooms

Communications

Materials

Schedule

Introductions

• Name and Company• Experience• Familiarity with MPLS and Services

Questions ?

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te

www.alcatel-lucent.com/src

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module 1 — IP/MPLS Mobile Backhaul Transport Network Architectures

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Module 1 | 2 All rights reserved © 2012 Alcatel-Lucent

Module Objectives

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

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.





Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Module 1 — IP/MPLS Mobile BackhaulTransport Network Architectures

Section 1 — Mobile Backhaul Standards Bodies and Terminology

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives

In this section, we will introduce:

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 consumer’s needs for increased mobile service features and bandwidth

Industry standards bodies defining the transport architecture and its operation

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



What is the IP/MPLS Mobile Backhaul Transport?

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

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Mobile Backhaul Transport Components

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

Mobile Backhaul Transport ComponentsThe 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) NodeB’s, and 4G/Long Term Evolution (LTE) eNodeB’s

•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 100’s 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 CSA’s 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...

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Mobile Backhaul Transport Components (cont)

The Mobile Backhaul Network:• Aggregates at the Mobile Telephone Switching Office (MTSO) traffic for

1000’s of cell service users• Delivers user voice, data, and BS OAM and control traffic to and from

the NC elements and external networks

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 1000’s 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 100’s 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).

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Mobile Service Provider (MSP)

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

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 MSP’s 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.

•Mobile Service Provider (MSP)

The MSP owns the cell site and MTSO, operating all the network elements that compose the Base Station, the MGsand 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Backhaul Transport Provider (BTP)

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

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 MSP’s 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 it’s interfaces, including the BTP Aggregation Gateway (BG) and the BTP Termination Device (BT). The MSP’s demarcation points are the MT and the MG ingress/egress interfaces, the UNI-MT and the UNI-MG.

The MSP may access the BTP’s 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 BTPprovisions 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 MSP’s facility, but belongs to the BTP. The BG terminates the BTP’s 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 BTP’s MSP-facing 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Course Note: Terminology - MLS versus MG

• 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Course Note: Addressing

• To avoid copying any part of a customer’s 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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 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

Mobile Backhaul Transport Standards BodiesSeveral 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 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

• The Next Generation Mobile Networks (NGMN) Alliance – www.ngmn.org

The following pages introduce these organizations.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: 3GPP

The 3GPP – www.3gpp.org

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)

Standard Bodies: 3GPPIn 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 ITU’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: 3GPP2

The 3GPP2 – www.3gpp2.org

Produces Code Division Multiple Access (CDMA) network specifications

3G standards

cdma2000®

EV-DO Revision A

Describes QoS and synchronization requirements for CDMA networks

Standard Bodies: 3GPP2The 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 createtechnical 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: ITU-T

The ITU-T – www.itu.int/ITU-T, develops recommendations which define:

Core network functionality

Broadband service delivery

Next-generation services

Transport connectivity requirements, Operations, Administration and Maintenace (OAM) functions, and synchronization

Standard Bodies: ITU-TThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: IETF

The IETF – www.ietf.org

“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)

Standard Bodies: IETFTo 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: MEF

The MEF – www.mef.org

“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

Standard Bodies: MEFFormed 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 today’s 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 Ethernet-based 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 UNI-NC 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: IEEE

The IEEE – www.ieee.org

“The world’s largest professional organization for the advancement of technology”

Defines many Ethernet network standards

Example: IEEE 1588v2/Precision Time Protocol (PTP) v2, 802.3 Ethernet

Standard Bodies: IEEEThe IEEE is “The world’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Standards Bodies: NGMN Alliance

The NGMN Alliance – www.ngmn.org

“the engine of broadband wireless innovation”

Aims to direct mobile broadband services to a single, integratednetwork

Example: Whitepapers and use cases focused on defining terms and functions as components of a mobile broadband deployment

Standard Bodies: NGMN AllianceThe 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 cost-effect 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 technology’s 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Evolution to all-IP Wireless Broadband Services – 3GPP

Evolution to all-IP Wireless Broadband Services – 3GPPThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Evolution to all-IP Wireless Broadband Services – 3GPP2

Evolution to all-IP Wireless Broadband Services - 3GPP2In 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



3GPP Releases Towards LTE – Key Milestones

3GPP Releases Towards LTE – Key Milestones3GPP 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 R9’s focus on enhancements.

• R10 introduces LTE Advanced

Significant enhancements to LTE/EPC to comply with the aggressive ITU IMT-Advanced requirements.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary

In this section, we learned:

The purpose and use of the Mobile Backhaul Transport Network

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 2 — Backhaul Service Architectures


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives

In this section, we will introduce two Mobile Backhaul Transportmodel architectures:

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 andservices that create the Mobile Backhaul Transport Network.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Backhaul Network Physical Topologies – Hub and Spoke

• 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

Backhaul Network Physical Topologies – Hub and SpokeA backhaul topology can take many forms and incorporate many different physical layer technologies. The topology used depends on the customer’s 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 UNI-MT 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Backhaul Network Physical Topologies – Ring/Subtended Ring

• 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

Backhaul Network Physical Topologies – Ring/Subtended RingRing 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 UNI-NC is ATM over SONET or Ethernet.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Points of Concentration (POC)

• 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

Points of ConcentrationThe 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. TheMLS 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 CSA’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Cell Site Average Downlink Data Rates

• One-sector cell site average downlink bandwidth requirements• Common three-sector site – multiply the one-sector bandwidth

requirement by 1.5-2.0

Cell Site Average Downlink Data RatesFor 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 site’s 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 aren’t 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 don’t 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 sector’s 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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Model 1 – Hub and Spoke Topology

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

Model 1 – Hub and Spoke TopologyVLL 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet Traffic

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

Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet TrafficEthernet 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 100’s 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 station’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ePipe Spoke to MLS Service – VPLS Termination

ePipes “spoked” into VPLS • Each NodeB interface has /27 address• Only one VPRN interface per subnet• Smaller VRF size, but added complexity of VPLS

ePipe Spoke to VPRN Service InterfaceThe 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 router’s MDA slots. The VSM provides no physical ports. Address AllocationEach 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 TablesThe 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 ePipe-VPRN approach.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ePipe Spoke to MLS Service – VPRN Termination

ePipes “spoked” into VPRN interfaces• Each NodeB interface has /30 address• Each ePipe-VPRN spoke requires /30 address• VPRN VRF hosts separate entry for each NodeB

ePipe Spoke to VPRN Service InterfaceA 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 AllocationEach 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 NodeB’s default gateway.In the Routing TablesThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



R-VPLS for VPLS to VPRN Service cross connect

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

R-VPLS for VPLS-VPRN Service Cross-connectRouted 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

EPC

Model 1 – Hub and Spoke Topology - iPipesEthernet 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



iPipe to MLS Service – Cross-connect Termination

iPipes cross-connected to VPRN interfaces• Each NodeB interface has /30 address• Each iPipe endpoint gets /30 address• iPipe context at CSA and MLS routers

iPipe to MLS Service – Cross-connect TerminationAn 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 AllocationEach 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 ApplicationsiPipes 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



iPipe to MLS Service – Spoke VPRN Termination

iPipes “spoked” into VPRN interfaces• Each NodeB interface has /30 address• Each iPipe-VPRN spoke requires /30 address• Supported in SROS 8 and later

iPipe to MLS Service – Spoke VPRN TerminationSROS 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 AllocationEach 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 NodeB’s default gateway.In the VPRN Routing TablesThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Hub and Spoke Topology - IPBH

Model 1 - IP Backhaul (IPBH)• 2G IPBH traffic transported over bundled DS1s• Bundled DS1s terminate into VPRN interfaces

Model 1 – Hub and Spoke Topology - IPBHIP 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 OC’s 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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Model 1 – 4G/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

Model 1 – ePipes, IES, and Local VPLS for LTE Traffic4G/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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Model 2 – Subtended Ring Topology

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

Model 2 – Subtended Ring TopologyVPWS 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – Subtended Ring Topology – Logical Connectivity

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

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 LSPsconfigured with admin groups and standby paths provide efficient, redundant traffic paths between the LERs. BFD insures timely failure recovery.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – Subtended Ring Topology – EBH Services

Model 2 - Backhaul Services• ePipes cross-connect into POC3 VPRNs• BS-BS traffic routed at POC3 interfaces

Model 2 – Subtended Ring Topology – EBH ServicesBackhaul Services

Each cell site’s 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...)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – Subtended Ring Topology – Legacy Services

Model 2 - Backhaul Services• cPipe and aPipes terminate directly into MLS router STM-1 access ports• POC3 routers switch tunneled traffic from access to aggregate rings

Model 2 – Subtended Ring Topology – Legacy ServicesBackhaul 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 channel’s complete cells to the far end ATM switch.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Pseudowire Switching on VPWS

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

BTS

Pseudowire Switching on VPWSThe 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) nodesEach 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) nodesThe 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 BindingsAs 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 100’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – Subtended Ring Topology (cont)

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

Model 2 – Subtended Ring Topology (cont)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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 Network Key Design Points

Resilient hub and spoke topology

Support for 2, 3 and 4G services

Overlay services possible over same infrastructure

Scalable to thousands of base stations

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 SDP’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 Network Key Design Points

Efficient, resilient 2, 3 and 4G connectivity

Scalable - Dynamic cell site learning

Efficient eNodeB to eNodeB routing

Model 2 Network Key Design Points 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 site’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary (cont)


The Model 1 architecture – Hub and Spoke to provide:

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





The Model 2 architecture – Subtended Ring 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 3 — Mobile Backhaul Transport Network Components


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives

In this section, we will:

Position Alcatel-Lucent network elements in the IP/MPLS Mobile Backhaul Transport network

Learn each network element’s functional role supporting 2 and 3G traffic

Learn each network element’s functional role supporting 4G/LTE traffic

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent’s service router portfolio ideally implements an end-to-end Mobile Backhaul Transport solution:

Suitable to either MSP or BTP customer

Leverage existing physical network

Supports array of access technologies

Support for 2, 3, and 4G backhaul

Alcatel-Lucent’s Mobile Backhaul Solution

7750 SR Family7450 ESS Family

7705 SAR Family 7210 SAS Family

Alcatel-Lucent’s Mobile Backhaul Solution• Alcatel-Lucent’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent Product Placement

Alcatel-Lucent supports the Backhaul Transport Network end-to-end with a wide range of service router products

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 MSP’s 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 BS’s, 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... Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent Product Placement (cont)

Alcatel-Lucent supports the Backhaul Transport Network end-to-end with a wide range of service router products

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent 7750 SR-7 and SR-12

7750 SR-127750 SR-7

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

250 Gb/s FD capacity 500 Gb/s FD capacity

Alcatel-Lucent 7750 SR-7 and SR-12At 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

58

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent 7750 SR-c12

7750 SR-c12

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

45 Gb/s FD capacity

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 SR-12 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, pseudowireswitching, 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

•IP, MPLS and Ethernet OAM and service assurance toolsA

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Alcatel-Lucent 7450 ESS-6, ESS-7, and ESS-12

7450 ESS-6/6V 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

80 Gb/s FD capacity 250 Gb/s FD capacity 500 Gb/s FD capacity

Alcatel-Lucent 7450 ESS-6, ESS-7 and ESS-12At 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 (R-VPLS)

•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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent 7705 SAR Family

7705 SAR-8 7705 SAR-18

• The 7705 SAR-F is ideal for CSA role

• The 7705 SAR-8 is ideal for POC3 and CSA roles

• The 7705 SAR–18 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

6 Gb/s FD capacity70 Gb/s FD capacity

7705 SAR-F

1 Gb/s FD capacity

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, pseudowireswitching

•Media conversion supporting multiple access technologies: TDM, ATM, Ethernet, ML-PPP

•IP, MPLS and Ethernet OAM and service assurance tools

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 Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Alcatel-Lucent 7210 SAS-E, M, and D

7210 SAS-M

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

Up to 64 Gb/s FD capacity

7210 SAS-E7210 SAS-D

Up to 24 Gb/s FD capacityUp to 10 Gb/s FD capacity

Alcatel-Lucent 7210 SAS-E, M, and D7210 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 1: Verify the Model 1 Ethernet Transport

.5 Hour

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary


Each node’s role in transporting 2, 3 and 4G traffic through the backhaul transport

Where the Alcatel-Lucent SROS products best fit in the Backhaul Network

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Summary

In this module, we learned:

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Summary (cont)

In this module, we learned:

The service types used to transport cell site traffic to the MTSO routers – ePipes, iPipes, aPipes and cPipes

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 RFtiming

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Review Questions

1. Which two of the following are considered Global Systems for Mobile (GSM) Network Control (NC) elements? (choose two)

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)

Answers:

1. a, b

2. a, d

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Review Questions (cont)

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 Terminationdevices

c) The BTP’s 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)

Answers:

3. B

4. a, b

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




5. Which standards body developed the current LTE network specifications?

a) ITU-T

b) 3GPP2

c) MEF

d) 3GPP

6. Which standards body’s work included developing standards for cdma2000 and EV-DO Rev A?

a) IEEE

b) 3GPP

c) 3GPP2

d) IETF

Answers:

5. D

6. c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




7. The ITU-T develops and maintains recommendations for what three network functions? (choose three)

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

Answers:

7. a, c, d

8. a, d.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




9. In a hub and spoke Backhaul topology, which nodes aggregate the greatest amount of cell site traffic?

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

Answers:

9. a.

10. a.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




11. In a subtended ring topology, how might the carrier overcome the need for a full mesh between the CSA and the POC1 routers?

a) Terminate all cell site tunnels on only one of the MLS 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 theBackhaul 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

Answers:

11. b.

12. c.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




13. In the hub and spoke model mentioned in this module, how does eNodeB-to-eNodeB traffic route?

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

Answers:

13. c.

14. b.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


www.alcatel-lucent.com

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module 2 — Implementing the Mobile Backhaul Transport Network

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Objectives

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

Describe Backhaul Ethernet access port components and configuration

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

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.





Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Objectives (cont)


Describe the PTPv2 message format and trace IEEE 1588v2/PTPv2 message flow in the Model 2 network

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 — Mobile Backhaul Service Access Interfaces

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives

In this section, we will: 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



7x50 Ethernet Port Configuration

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 v2Part number 3HE02776AB

7750 SR 20-Port 10/100/1000 Mb/s RJ45 MDA XPPart number 3HE03613AA

7x50 Ethernet Port ConfigurationThe 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 customer’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Ethernet Port Encapsulation

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

Ethernet Port EncapsulationNot all devices set or expect VLAN tags. For example, a customer’s eNodeB may set no tag on egress and expects no tag on ingress. Thus, the connected router’s 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 NodeB’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Ethernet Port MTU Size

Access Network

Eth. Frame Bytes Null Dot1q Null Dot1q

IFG 12

Preamble 8

DA 6 6 6 6 6

SA 6 6 6 6 6

Type 2 2 2 2 2

VLAN 4 4 4

Tunnel 4 4 4

PW Header 4 4 4

CW (opt) 4 4 4

RTP Header (opt) 12 12

Payload 1500 1500 1500 1514 1518

FCS 4

Total: 1514 1518 1552 1560

Ethernet Port MTU SizeMTU

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring an Ethernet Access Port

Context: config>port>ethernet

Syntax: [no] mode {access|network|hybrid}

[no] encap-type {dot1q|null|qinq}

[no] autonegotiate [limited]

speed {10|100|1000}

duplex {full|half}

[no] mtu mtu-bytes

Example: config# port 1/1/3

config>port# ethernet

config>port>ethernet# mode access

config>port>ethernet# encap-type dot1q

config>port>ethernet# autonegotiate limited

config>port>ethernet# speed 100

config>port>ethernet# duplex half

config>port>ethernet# mtu 1518

config>port>ethernet# back

config>port# no shutdown

Context: config>port>ethernet

Syntax: [no] mode {access|network|hybrid}

[no] encap-type {dot1q|null|qinq}

[no] autonegotiate [limited]

speed {10|100|1000}

duplex {full|half}

[no] mtu mtu-bytes

Example: config# port 1/1/3


config>port>ethernet# mode access

config>port>ethernet# encap-type dot1q

config>port>ethernet# autonegotiate limited

config>port>ethernet# speed 100

config>port>ethernet# duplex half

config>port>ethernet# mtu 1518



Configuring an Ethernet Access PortPort ModeThe 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 encapsulationDot1q 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 AutonegotiationSome 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 duplexSet 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 MTUAdjust to suit the connected network and services. A:NodeA# configure port 1/1/3 ethernet mtu 1518

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Ethernet Network Port Hold Time

The port hold time holds down ports connected to flapping links• Allow network to stabilize before transitioning a port’s operational

state • Example: On all network ports:

A:NodeA>config>port>ethernet# hold-time up 5

Ethernet Network Port Hold TimeLink 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.A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



7x50 TDM Port Configuration

A base station, an NC element, or the transport network may require the following TDM port configurations: 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

7750 SR 4-Port OC3/STM1 Channelized ASAP MDAPart number 3HE01364AA

7705 SAR 2-Port Channelized OC3/STM1 MDAPart number 3HE03127AA

7x50 TDM Port ConfigurationIn 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SONET and SDH in the Backhaul Transport

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

SONET and SDH Data Transmission Rates and StructuresSynchronous 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 BTP’s network often uses a SONET transport. Additionally, SONET/SDH efficiently bundles and transports traffic between IPBH base stations

and the MLS routers.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SONET and SDH Signal Levels and Line Rates

SONET and SDH Signal Levels and Line RatesThe 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SONET/SDH Overview

STS-1 Frame Bandwidth is 51.84 Mb/s Frame consists of 9 rows by 90 columns (9 x 90 bytes)

SONET/SDH OverviewBasic 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 payload’s assembly and disassembly.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SONET/SDH Overview (cont)

Basic STM-1 Frame STM-1 bandwidth 155.52 Mb/s Frame consists of 9 rows by 270 columns (2430 bytes)

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 circuit’s 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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute




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

SONET/SDH Overview (cont)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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




STM-1 payload may be sub-divided 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

SONET/SDH Overview (cont)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. VC’s 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 AU-4.

•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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



OC-12/OC-3 VT Group Circuits

A:MLS1>config>port>tdm# ds1 1.2.3.4 no shutdownA:MLS1>config>port>tdm# ds1 1.2.3.4 no shutdown

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



OC-12 VT Group Circuits – SONET Framing

OC12 VT Group Circuits – SONET FramingVTG 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.

. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



OC12 VT Group Circuits – SDH Framing

OC12 VT Group Circuits – SDH FramingTUG 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 port’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring OC-3/STM-1 ASAP Port Characteristics

Context: config>port>sonet-sdh

Syntax: framing {sonet|sdh}

path {sonet-sdh-index}

vt15-[sonet-sdh-index].[sonet-sdh-index].[sonet-sdh-index]

Context: config>port>sonet-sdh>path

Syntax: payload {sts3|tug3|ds3|e3|vt2|vt15|ds1|e1}]

Example: config# port 1/2/1 sonet-sdh

config>port>sonet-sdh# framing sonet

config>port>sonet-sdh# path sts1-1

config>port>sonet-sdh>path$ payload vt15

config>port>sonet-sdh>path$ no shutdown

config>port>sonet-sdh>path$ back

config>port>sonet-sdh# path vt15-1.1.1



config>port>sonet-sdh# back


Context: config>port>sonet-sdh

Syntax: framing {sonet|sdh}

path {sonet-sdh-index}

vt15-[sonet-sdh-index].[sonet-sdh-index].[sonet-sdh-index]

Context: config>port>sonet-sdh>path

Syntax: payload {sts3|tug3|ds3|e3|vt2|vt15|ds1|e1}]

Example: config# port 1/2/1 sonet-sdh

config>port>sonet-sdh# framing sonet

config>port>sonet-sdh# path sts1-1

config>port>sonet-sdh>path$ payload vt15








Configuring OC-3/STM-1 ASAP Port CharacteristicsShown 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring DS1 ATM Access Ports

Context: config>port>tdm

Syntax: [no] ds1 ds1-idclock-source node-timed

Context: config>port>tdm>channel-group

Syntax: channel-group channel-group-idencap-type {atm|bcp-null|ipcp|ppp-auto|frame-relay|wan-mirror|cisco-hdlc|cem}

Example: config# port 1/2/1config>port# description “ATM delivery IMA 2x DS1”config>port# tdmconfig>port>tdm# ds1 1.1.1config>port>tdm>ds1$ clock-source node-timedconfig>port>tdm>ds1$ channel-group 1config>port>tdm>ds1>channel-group$ encap-type atm

config>port>tdm>ds1>channel-group$ no shutdown

config>port>tdm>ds1>channel-group$ back

config>port>tdm>ds1# no shutdown

config>port>tdm>ds1# back

config>port>tdm# back

config>port># back





Example: config# port 1/2/1config>port# description “ATM delivery IMA 2x DS1”config>port# tdmconfig>port>tdm# ds1 1.1.1config>port>tdm>ds1$ clock-source node-timedconfig>port>tdm>ds1$ channel-group 1config>port>tdm>ds1>channel-group$ encap-type atm

config>port>tdm>ds1>channel-group$ no shutdown





config>port># back

Configuring DS1 ATM Access PortsConfigure the ports according to the connected equipment. In our example, we configure the DS1’s 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 Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the STS-1 – show port 1/2/1.1

A:NodeA# show port 1/2/1.1

===============================================================================Path Info===============================================================================Description : STS1Admin Status : up Oper Status : upMode : N/A CRC : N/AEncap Type : N/A Configured MTU : N/AOperational MTU : N/A Operational MRU : N/ALast State Change : 05/16/2011 23:03:34 Path IfIndex : 574652477Scramble : N/A Payload : vt15Accounting Policy : N/A Collect-Stats : N/ANet. Egress Que Pol: N/ASignal Label : 0x02 Rx Signal Label : 0x01Trace String : Alcatel 7750 SRRx Trace Str(Hex) : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...output truncatedCfg Alarm : plop pplm puneqAlarm Status :...output truncated

A:NodeA# show port 1/2/1.1

===============================================================================Path Info===============================================================================Description : STS1Admin Status : up Oper Status : upMode : N/A CRC : N/AEncap Type : N/A Configured MTU : N/AOperational MTU : N/A Operational MRU : N/ALast State Change : 05/16/2011 23:03:34 Path IfIndex : 574652477Scramble : N/A Payload : vt15Accounting Policy : N/A Collect-Stats : N/ANet. Egress Que Pol: N/ASignal Label : 0x02 Rx Signal Label : 0x01Trace String : Alcatel 7750 SRRx Trace Str(Hex) : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...output truncatedCfg Alarm : plop pplm puneqAlarm Status :...output truncated

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 Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the DS-1 – show port 1/2/1.1.1.1

A:NodeA# show port 1/2/1.1.1.1

===============================================================================TDM DS1 Interface===============================================================================Description : DS1Interface : 1/2/1.1.1.1Type : ds1 Framing : esfAdmin Status : up Oper Status : upPhysical Link : yes Clock Source : node-timedLast State Change : 05/16/2011 23:34:29 Channel IfIndex : 574653943Loopback : none Invert Data : falseRemote Loop respond: false In Remote Loop : falseLoad-balance-algo : default Egr. Sched. Pol : N/ABERT Duration : N/A BERT Pattern : noneBERT Synched : 00h00m00s Err Insertion Rate : 0BERT Errors : 0 BERT Status : idleBERT Total Bits : 0Cfg Alarm : ais losAlarm Status :BER SD Threshold : 5 BER SF Threshold : 50===============================================================================... output truncated

A:NodeA# show port 1/2/1.1.1.1

===============================================================================TDM DS1 Interface===============================================================================Description : DS1Interface : 1/2/1.1.1.1Type : ds1 Framing : esfAdmin Status : up Oper Status : upPhysical Link : yes Clock Source : node-timedLast State Change : 05/16/2011 23:34:29 Channel IfIndex : 574653943Loopback : none Invert Data : falseRemote Loop respond: false In Remote Loop : falseLoad-balance-algo : default Egr. Sched. Pol : N/ABERT Duration : N/A BERT Pattern : noneBERT Synched : 00h00m00s Err Insertion Rate : 0BERT Errors : 0 BERT Status : idleBERT Total Bits : 0Cfg Alarm : ais losAlarm Status :BER SD Threshold : 5 BER SF Threshold : 50===============================================================================... output truncated

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Channel Group – show port 1/2/1.1.1.1.1

A:NodeA# show port 1/2/1.1.1.1.1

===============================================================================TDM DS0 Chan Group===============================================================================Description : DS0GRPInterface : 1/2/1.1.1.1.1TimeSlots : 1-24Speed : 64 CRC : 32Admin Status : up Oper Status : upBER SF Link Down : disabledLast State Change : 05/17/2011 00:10:20 Chan-Grp IfIndex : 574653944

Configured mode : access Encap Type : atmAdmin MTU : 1524 Oper MTU : 1524Scramble : truePhysical Link : yes Bundle Number : 1Idle Cycle Flags : n/a Load-balance-algo : defaultPayload Fill Type : n/a Payload Pattern : N/ASignal Fill Type : n/a Signal Pattern : N/AIng. Pool % Rate : 100 Egr. Pool % Rate : 100Egr. Sched. Pol : N/A

... output truncated


===============================================================================TDM DS0 Chan Group===============================================================================Description : DS0GRPInterface : 1/2/1.1.1.1.1TimeSlots : 1-24Speed : 64 CRC : 32Admin Status : up Oper Status : upBER SF Link Down : disabledLast State Change : 05/17/2011 00:10:20 Chan-Grp IfIndex : 574653944

Configured mode : access Encap Type : atmAdmin MTU : 1524 Oper MTU : 1524Scramble : truePhysical Link : yes Bundle Number : 1Idle Cycle Flags : n/a Load-balance-algo : defaultPayload Fill Type : n/a Payload Pattern : N/ASignal Fill Type : n/a Signal Pattern : N/AIng. Pool % Rate : 100 Egr. Pool % Rate : 100Egr. Sched. Pol : N/A


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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Inverse Multiplexing over ATM (IMA)

• An IMA bundle inverse multiplexes, or splits, an ATM cell streamover 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

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 doesn’t 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 doesn’t 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IMA Bundle Configuration Commands

A:MLS1>config>port>ml-bundle# member iom/mda/port.sts1-1.vtg-1.vt-1.channel-group1

Context: config>port

Syntax: [no] bundle-ima-slot/mda.bundle-nummultilink-bundle

Context: config>port>ml-bundle

Syntax: ima atmmember port-id

Example: config# port bundle-ima-1/2.1config>port# multilink-bundleconfig>port>ml-bundle# ima atmconfig>port>ml-bundle# member 1/2/1.1.1.1.1 config>port>ml-bundle# member 1/2/1.1.1.2.1config>port>ml-bundle# back



Syntax: [no] bundle-ima-slot/mda.bundle-nummultilink-bundle


Syntax: ima atmmember port-id

Example: config# port bundle-ima-1/2.1config>port# multilink-bundleconfig>port>ml-bundle# ima atmconfig>port>ml-bundle# member 1/2/1.1.1.1.1 config>port>ml-bundle# member 1/2/1.1.1.2.1config>port>ml-bundle# back


IMA Bundle Configuration CommandsCreate 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)

A:NodeA>config>port>ml-bundle# member 1/2/1.1.1.2.1

Turn up the bundle

A:NodeA>config>port# no shutdown A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



View the Completed IMA Bundle

show multilink-bundle bundle-ima-1/2.1

The bundle is Admin Up, Port State Up

Operation state remains Down until other end becomes operational

A:NodeA# show multilink-bundle bundle-ima-1/2.1

===============================================================================

Bundle Summary

===============================================================================

Bundle Type Admin Oper Port Min Total/

Id State State State Links Active Links

-------------------------------------------------------------------------------

bundle-ima-1/2.1 ima-grp Up Up Up 1 2/2

-------------------------------------------------------------------------------

Bundles : 1

===============================================================================

A:NodeA# show multilink-bundle bundle-ima-1/2.1

===============================================================================

Bundle Summary

===============================================================================



-------------------------------------------------------------------------------

bundle-ima-1/2.1 ima-grp Up Up Up 1 2/2

-------------------------------------------------------------------------------

Bundles : 1

===============================================================================

View the Completed IMA BundleThe show multilink-bundle bundle-ima-1/2.1 command shows the bundle’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Point to Point Protocol (PPP)/MultiLink-PPP

ML-PPP is a method of splitting, recombing, and sequencing PPP frames across multiple datalinks

PPP signals the Multilink Protocol (MP) option during individuallink 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

Point to Point Protocol (PPP) / MultiLink-PPPRFC1990 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 session’s 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 link’s the maximum receive unit (MRU). MRU is the link’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Point-to-Point Protocol (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

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 frame’s 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 0xc021LCP negotiates the physical link characteristics. When two endpoints negotiate the link’s 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 link’s 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 protocol’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Link Negotiation/Bundle Negotiation

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 bundle’s Layer 3

characteristics

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 link’s 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 usea 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 endpoint’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Multilink Protocol (MP) Frame

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 Multi-Link PPP through two bit Class (CLS) field

Multilink Protocol (MP) FrameThe 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 frame’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Bundle Creation and Maintenance

Bundle Creation and MaintenanceEstablish 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring DS1 PPP Access Ports





Example: config# port 1/2/1config>port# description “MLPPP bundle 2”config>port# tdmconfig>port>tdm# ds1 1.1.1config>port>tdm>ds1$ clock-source node-timedconfig>port>tdm>ds1$ channel-group 1config>port>tdm>ds1>channel-group$ encap-type ipcpconfig>port>tdm>ds1>channel-group$ timeslots 1-24 config>port>tdm>ds1>channel-group$ no shutdown





config>port># back





Example: config# port 1/2/1config>port# description “MLPPP bundle 2”config>port# tdmconfig>port>tdm# ds1 1.1.1config>port>tdm>ds1$ clock-source node-timedconfig>port>tdm>ds1$ channel-group 1config>port>tdm>ds1>channel-group$ encap-type ipcpconfig>port>tdm>ds1>channel-group$ timeslots 1-24 config>port>tdm>ds1>channel-group$ no shutdown





config>port># back

Configuring DS1 PPP Access PortsConfigure the ports according to the connected equipment. In our example, we configure the DS1’s 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 bundle’s 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Channel Group – show port 1/2/1.1.1.1.1


===============================================================================

TDM DS0 Chan Group

===============================================================================

Description : DS0GRP

Interface : 1/2/1.1.1.1.1

TimeSlots : 1-24

Speed : 64 CRC : 16

Admin Status : up Oper Status : up

BER SF Link Down : disabled

Last State Change : 07/28/2011 10:42:57 Chan-Grp IfIndex : 574652503

Configured mode : access Encap Type : ipcp

Admin MTU : 1502 Oper MTU : 1502

Scramble : false

Physical Link : yes Bundle Number : 1

Idle Cycle Flags : flags Load-balance-algo : Default

Payload Fill Type : n/a Payload Pattern : N/A

Signal Fill Type : n/a Signal Pattern : N/A

Ing. Pool % Rate : 100 Egr. Pool % Rate : 100

Egr. Sched. Pol : N/A



===============================================================================

TDM DS0 Chan Group

===============================================================================

Description : DS0GRP

Interface : 1/2/1.1.1.1.1

TimeSlots : 1-24

Speed : 64 CRC : 16


BER SF Link Down : disabled

Last State Change : 07/28/2011 10:42:57 Chan-Grp IfIndex : 574652503

Configured mode : access Encap Type : ipcp

Admin MTU : 1502 Oper MTU : 1502

Scramble : false

Physical Link : yes Bundle Number : 1

Idle Cycle Flags : flags Load-balance-algo : Default

Payload Fill Type : n/a Payload Pattern : N/A

Signal Fill Type : n/a Signal Pattern : N/A

Ing. Pool % Rate : 100 Egr. Pool % Rate : 100

Egr. Sched. Pol : N/A


View the Channel Group – show port 1/2/1.1.1.1.1This 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ML-PPP Bundle Configuration Commands


Syntax: [no] bundle-ppp-slot/mda.bundle-nummultilink-bundle


Syntax: member port-idshort-sequencemrru <mrru>mlppp

Context: config>port>ml-bundle>mlppp

Syntax: endport-discriminator class {ip-address|global-mac-address|null} discriminator-id<discrimator-id>

Example: config# port bundle-ppp-1/2.1config>port# multilink-bundleconfig>port>ml-bundle# short sequenceconfig>port>ml-bundle# member 1/2/1.1.1.1.1 config>port>ml-bundle# member 1/2/1.1.1.2.1config>port>ml-bundle# mlpppconfig>port>ml-bundle>mlppp# endpoint-discriminator class ip-address

discriminator-id 10.10.10.10config>port>ml-bundle>mlppp# backconfig>port# no shutdown


Syntax: [no] bundle-ppp-slot/mda.bundle-nummultilink-bundle


Syntax: member port-idshort-sequencemrru <mrru>mlppp

Context: config>port>ml-bundle>mlppp

Syntax: endport-discriminator class {ip-address|global-mac-address|null} discriminator-id<discrimator-id>

Example: config# port bundle-ppp-1/2.1config>port# multilink-bundleconfig>port>ml-bundle# short sequenceconfig>port>ml-bundle# member 1/2/1.1.1.1.1 config>port>ml-bundle# member 1/2/1.1.1.2.1config>port>ml-bundle# mlpppconfig>port>ml-bundle>mlppp# endpoint-discriminator class ip-address

discriminator-id 10.10.10.10config>port>ml-bundle>mlppp# backconfig>port# no shutdown

ML-PPP Bundle Configuration CommandsCreate 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

A:NodeA>config>port# no shutdown

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>

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



MLPPP

Multi-class MLPPP

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 (MC) MLPPP Overview

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

MC MLPPP OverviewIf 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 QoSprofiles 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 Default egress multi-class profile 2.3 Default egress multi-class profile 3.===============================================================================

A:MLS1# show qos mlppp-profile-ingress===============================================================================Multi-class MLPPP Ingress Profiles===============================================================================Profile-Id Description-------------------------------------------------------------------------------1 Default ingress multi-class profile 1.===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Completed ML-PPP Bundle – No IPCP

show multilink-bundle bundle-ppp-1/2.1

The bundle is Admin Up, Port State Link Up

Operation state remains down until the bundle is associated with an IP interface

A:NodeA# show multilink-bundle bundle-ppp-1/2.1

===============================================================================

Bundle Summary

===============================================================================



-------------------------------------------------------------------------------

bundle-ppp-1/2.1 mlppp Up Down Link Up 1 2/2

-------------------------------------------------------------------------------

Bundles : 1

===============================================================================

A:NodeA# show multilink-bundle bundle-ppp-1/2.1

===============================================================================

Bundle Summary

===============================================================================



-------------------------------------------------------------------------------

bundle-ppp-1/2.1 mlppp Up Down Link Up 1 2/2

-------------------------------------------------------------------------------

Bundles : 1

===============================================================================

View the Completed ML-PPP Bundle – No IPCPThe show multilink-bundle bundle-ppp-1/2.1 command shows the bundle’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Completed ML-PPP Bundle – IPCP Complete

A:NodeA# show multilink-bundle bundle-ppp-1/2.1 detail

===============================================================================

Bundle bundle-ppp-1/2.1 Detail

===============================================================================

Description : MultiLink Bundle

Bundle Id : bundle-ppp-1/2.1 Type : mlppp


Minimum Links : 1 Bundle IfIndex : 574619649

Total Links : 2 Active Links : 2

Red Diff Delay : 0 Yellow Diff Delay : 0

Red Diff Delay Act : none MRRU : 1524

Short Sequence : true Oper MRRU : 1524

Oper MTU : 1526 Fragment Threshold : 128 bytes

Up Time : 0d 00:01:56 Bandwidth : 3968 KBit

PPP Input Discards : 0 Primary Member Port: 1/2/1.1.1.1.1

Mode : access

Interleave-Frag : false

-------------------------------------------------------------------------------

Member Port Id #TS Admin Oper Act Down Reason Up Time

-------------------------------------------------------------------------------

1/2/1.1.1.1.1 31 up up yes N/A 0d 00:04:56

1/2/1.1.1.2.1 31 up up yes N/A 0d 00:04:57

===============================================================================... output truncated

A:NodeA# show multilink-bundle bundle-ppp-1/2.1 detail

===============================================================================

Bundle bundle-ppp-1/2.1 Detail

===============================================================================

Description : MultiLink Bundle

Bundle Id : bundle-ppp-1/2.1 Type : mlppp


Minimum Links : 1 Bundle IfIndex : 574619649

Total Links : 2 Active Links : 2

Red Diff Delay : 0 Yellow Diff Delay : 0

Red Diff Delay Act : none MRRU : 1524

Short Sequence : true Oper MRRU : 1524

Oper MTU : 1526 Fragment Threshold : 128 bytes

Up Time : 0d 00:01:56 Bandwidth : 3968 KBit

PPP Input Discards : 0 Primary Member Port: 1/2/1.1.1.1.1

Mode : access

Interleave-Frag : false

-------------------------------------------------------------------------------

Member Port Id #TS Admin Oper Act Down Reason Up Time

-------------------------------------------------------------------------------

1/2/1.1.1.1.1 31 up up yes N/A 0d 00:04:56

1/2/1.1.1.2.1 31 up up yes N/A 0d 00:04:57

===============================================================================... output truncated

View the Completed ML-PPP Bundle – IPCP CompleteOnce 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 bundle’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Completed ML-PPP Bundle – IPCP Complete (cont)

A:NodeA# show multilink-bundle bundle-ppp-1/2.1 ppp

===============================================================================

Bundle bundle-ppp-1/2.1 Multilink PPP Information

===============================================================================

Local EpId Class : IP Address

Local Discriminator: 10.10.10.10

Yellow Diff Delay : 0 Short Sequence : true

MRRU : 1524 Oper MRRU : 1524

Interleave-Frag : false PPP Input Discards : 0

Multiclass Classes : 4

Ing QoS Profile Id : 0 Egr QoS Profile Id : 0

Magic Number : Disabled

===============================================================================

===============================================================================

PPP Protocols for bundle-ppp-1/2.1

===============================================================================

Protocol State Last Change Restart Count Last Cleared

-------------------------------------------------------------------------------

ipcp opened 11/16/2011 12:17:56 3 11/15/2011 12:05:10


===============================================================================

Local Mac address : 60:39:01:02:00:05 Remote Mac address :

Local IPv4 address : 203.0.113.9 Remote IPv4 address: 203.0.113.10


A:NodeA# show multilink-bundle bundle-ppp-1/2.1 ppp

===============================================================================

Bundle bundle-ppp-1/2.1 Multilink PPP Information

===============================================================================

Local EpId Class : IP Address

Local Discriminator: 10.10.10.10

Yellow Diff Delay : 0 Short Sequence : true

MRRU : 1524 Oper MRRU : 1524

Interleave-Frag : false PPP Input Discards : 0

Multiclass Classes : 4

Ing QoS Profile Id : 0 Egr QoS Profile Id : 0

Magic Number : Disabled

===============================================================================

===============================================================================

PPP Protocols for bundle-ppp-1/2.1

===============================================================================

Protocol State Last Change Restart Count Last Cleared

-------------------------------------------------------------------------------

ipcp opened 11/16/2011 12:17:56 3 11/15/2011 12:05:10


===============================================================================

Local Mac address : 60:39:01:02:00:05 Remote Mac address :

Local IPv4 address : 203.0.113.9 Remote IPv4 address: 203.0.113.10


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 bundle’s 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

Other states: initial, starting, closed, stopped, closing, stopping, requestSent, askReceived, ackSent

Restart Count – The number of times IPCP has reached the opened state

•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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 2: Configure TDM ATM IMA Interfaces

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

1 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 2 — Timing and Synchronization in the Backhaul Transport Network


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronous Network Timing Requirements

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

Synchronous Network Timing RequirementsWhat 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



North American Network Timing Hierarchy

• 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

North American Network Timing HierarchyThis hierarchy, described in ANSI/T1.101-1998, specifies network timing level sources. The Stratum valuedescribes the source’s distance from the reference clock. An important factor is that each clock can trace timing to a single reference source.Stratum 1T1.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 2Tracks 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 3Provides 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 4No 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 SlipFrame slips occur because of timing problems on a circuit. A device sends a frame timed to a reference that differs from the receiver’s reference. This causes the frame to start in a different position in the clock pulse on either end, resulting in lost data.HoldoverIf 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Building Integrated Timing Supply (BITS)

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

Building Integrated Timing Supply (BITS)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 CO’s 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 SSU’s 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 intervalsof 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ITU-T SDH Equipment Clock (SEC)

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.)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronization – Frequency v. Phase and Time

• Frequency synchronization Clock frequencies match within 50 parts per billion, x = y

• Phase/time synchronization Clock frames start simultaneously across all nodes, tA=tB

Synchronization – Frequency v. Phase and TimeAll 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 don’t 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 Node’s 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 runsan 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.A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Physical versus Adaptive Timing Techniques

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

Physical versus Adaptive Timing TechniquesPhysical 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Physical versus Adaptive Timing Techniques (cont)

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)

Physical versus Adaptive Timing Techniques (cont)Adaptive Timing

Adaptive timing techniques delivery the timing reference information in a series of packets delivered by a well-known 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 PDV’s influence, taking a long term sample to calculate an average offset value.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Packet Network Synchronization Techniques

Synchronization techniques• Physical – External GPS,

Synchronous Ethernet, Line Timing

• Packet-based – IEEE 1588v2, Adaptive Clock Recovery

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 master’s 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 clock’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronization Requirements

Application Frequency Relative Phase Solutions

GSMW-CDMA FDDMBMS*

50 ppb 10 to 100 ms

• Timing over Packet (ACR, 1588v2)

• SyncE• E1/T1 Line timing

LTE FDDLTE MBMS 50 ppb 10 to 100 ms

• Timing over Packet• SyncE

CDMA2000 50 ppb6 us(20 us worst case)

• GPS

W-CDMA TDDLTE TDD

50 ppb over one timeslot

2.5 us• GPS• 1588v2 and SyncE

e911 LBS** N/A 200 ns• GPS• 1588v2 and SyncE

Synchronization RequirementsThis 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 PTP’s 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 caller’s location. This requires phase accuracy for reliable operation.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronization Source Locations

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

Synchronizaton Source Locations This slide illustrates where to apply our various timing source options. The actual design depends on the

customer’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 3 — Timing and Synchronization – Synchronous Ethernet


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Explain Synchronous Ethernet (SyncE) operation

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronous Ethernet

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 signal’s physical layer

clock Each node in the path is Sync-E capable and enabled A node can be both a slave and a master

Synchronous EthernetNodes 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.)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronous Ethernet (cont)

Each SyncE capable node maintains a Synchronous Ethernet Equipment Slave Clock (EEC) EEC should be accurate to </= 4.6 part per million (.0001%) per

yearTwo 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

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.A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Synchronization Status Message (SSM) and SyncE

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

Synchronization Status Messages (SSM) and SyncEThough 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 circuit’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Synchronization Status Messages (SSM) and SyncE (cont)

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

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 – Sender’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Events, G.781 Option 1- SDH Mode

SSM Code

Name Quality Level

Description

0010 Quality PRC Best Trail source is PRC clock (Stratum 1)

0100 Quality SSU-A Trail source is type I* or V* slave clock

1000 Quality SSU-B Trail source is type VI* slave clock

1011 Quality SEC/EEC1

Trail transports a timing quality generated by a synchronous equipment clock (SEC)

1111 Quality DNU Lowest Do not use for synchronization

• 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

* 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

SSM Events, G.781 Option 1 – SDH ModeITU-T G.781 defines the SSM QL event codes. SDH networks use the Option 1 codes to indicate the SDH 2048 khzclock 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 source’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Events, G.781 Option 2- SONET Mode

SSM Code

Name Quality Level

Description

0001 Quality PRS Best Trail source is PRS clock (Stratum 1)

0000 Quality STU Does not carry source QL TLV

0111 Quality ST2 Trail source is stratum 2 clock

0100 Quality TNC Trail source is transit node clock

1101 Quality ST3E Trail source is stratum 3E clock

1010 Quality ST3/EEC2

Trail source is stratum 3 clock

1100 Quality SMC Trail source is SONET/Ethernet self-timed node

1110 Quality PROV Network operator provisioned

1111 Quality DUS Lowest 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

SSM Events, G.781 Option 2 – SONET ModeSONET 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Internal Events, Both Options 1 and 2

Name Quality Level

Description

Quality INVx InternalUse

Generated when a node receives an unallocated SSM value, x= the value

Quality NSUPP InternalUse

Generated when the node doesn’t support SSM processing

Quality FAILED InternalUse

Generated if the synchronization trail is in signal fail

Quality UNC InternalUse

Generated when node clock is in holdover

Quality UNKNOWN

SROS Only

SSM port received no message

G.781 Internal Events• For internal use only, never passed to physical interface• SROS also defines QL-UNKNOWN

SSM Internal Events, Both Options 1 and 2Internal 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).

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring Synchronous Ethernet

Configure Synchronous Ethernet Support1.Set router timing reference order 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 Enabled by default on SAR MDAs

5.Enable SSM on ring ports

config>system>sync-if-timing# ref-order bits ref1 ref2config>system>sync-if-timing# ref-order bits ref1 ref2

config>system>sync-if-timing# ql-selectionconfig>system>sync-if-timing# ql-selection

config# card 1 mda 1 sync-econfig# card 1 mda 1 sync-e

config>port# ethernet ssm no shutdownconfig>port# ethernet ssm no shutdown

config>system>sync-if-timing# bits ql-override prcconfig>system>sync-if-timing# bits ql-override prc

Configuring Synchronous EthernetSROS 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 source’s 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. Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Operation – Model 2 Subtended Ring

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

SSM Operation – Model 2 Subtended RingSSM Normal Operation Reference ClocksIn this section, we use the SROS CLI term “SSM” to describe ESMC configuration and management. POC1 MLS1 – Network SSUThe 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 MLS2MLS1 falls back from BITS to STM, then to SyncE/SSM at priority 3 if the BITS and STM loop timing become

unavailable.POC1 MLS2MLS2 reference order: – ref1 bits ref2:1. Priority 1 – Reference 1, SyncE-timed on Ethernet port facing MLS12. Priority 2 – BITS – From Stratum 1 source3. Priority 3 – Reference 2, loop-timed from SONET/STM mux interface (not shown)POC2-1, POC3-1, and CSA1 routersReference order: ref1 ref2 external (external shut down). ql-selection is enabled.1. Priority 1 – Reference 1, SyncE-timed on Ethernet MLS1-facing port 2. Priority 2 – Reference 2, SyncE-timed on Ethernet MLS2-facing port 3. Priority 3 – shutdown POC2-2, POC3-2, and CSA2 routersThese reverse the POC2-1, POC3-1, and CSA1 reference order. ql-selection is enabled.1. Priority 1 – Reference 1, SyncE-timed on Ethernet MLS2-facing port 2. Priority 2 – Reference 2, SyncE-timed on Ethernet MLS1-facing port 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 SAR-

F); if SRs, the ports must be on different IOMs, as well.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Operation – Model 2 Normal Operations

• MLS1 sends QL-PRC out of its SSM-enabled ports• Other ring nodes choose their reference source by timing reference

priority, advertised quality, or both• Each node returns QL-DNU towards selected source, MLS1

1

2

3

SSM Operation – Model 2 Normal OperationsSSM Normal Operation Message Flow – SDH ModeThe SROS sets the SSM port operation modes to SDH (Option 1) by default. This determines the SSM messages sent in the network.POC1 MLS1POC1 MLS1 sends a QL-PRC out on all SyncE/SSM enabled ports. MLS1’s advertised QL value depends on that node’s 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 portsIn 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-DNUFor source traceability, each node returns to the chosen source a QL-DNU message.POC1 MLS2MLS2’s primary timing reference is its MLS1 facing port. MLS2 receives MLS1’s QL-PRC and returns QL-DNU. As configured, POC2-2 chooses MLS2 as its reference and returns QL-DNU toward MLS2. Clock TraceabilityFrom 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Operation – Failure On MLS1 Link

Break in MLS1 to POC2-1 link• POC2-1 no longer qualifies link to MLS1 • POC2-1 sends QL-EEC1 towards POC3-1• Remaining nodes remain on priority 1 reference

1

2

3

SSM Operation – Failure on MLS1 LinkPrior 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SSM Operation – Failure On MLS1 Link (cont)

At time of break, other nodes are unaware that MLS1 is unavailable

• POC3-1 receives QL-EEC1 on its primary reference• With ql-selection enabled, POC3-1 chooses its

qualified reference 2 source, POC3-2• All other nodes except POC2-1 remain on reference 1; POC2-1 chooses

POC3-1 as its primary reference

4

5

6

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Set the MLS1 router Timing References

Context: config>system>sync-if-timing

Syntax: beginbits interface-type {ds1 [{esf|sf}] | e1 [{pcm30crc|pcm31crc}]}ref1 source-port slot/mda/port[.channel]ref2 source-port slot/mda/port[.channel][no] ref-order <first> <second> [<third>][no] revert[no] ql-selectioncommitabort

Example: config# system sync-if-timingconfig>system>sync-if-timing# beginconfig>system>sync-if-timing# ref1 source-port 1/2/1config>system>sync-if-timing# ref1 no shutdownconfig>system>sync-if-timing# ref2 source-port 5/1/1*config>system>sync-if-timing# ref2 no shutdownconfig>system>sync-if-timing# bits interface-type ds1 sfconfig>system>sync-if-timing# bits no shutdownconfig>system>sync-if-timing# ref-order bits ref1 ref2config>system>sync-if-timing# revertconfig>system>sync-if-timing# ql-selectionconfig>system>sync-if-timing# commitconfig>system>sync-if-timing# backconfig>system# back


Syntax: beginbits interface-type {ds1 [{esf|sf}] | e1 [{pcm30crc|pcm31crc}]}ref1 source-port slot/mda/port[.channel]ref2 source-port slot/mda/port[.channel][no] ref-order <first> <second> [<third>][no] revert[no] ql-selectioncommitabort

Example: config# system sync-if-timingconfig>system>sync-if-timing# beginconfig>system>sync-if-timing# ref1 source-port 1/2/1config>system>sync-if-timing# ref1 no shutdownconfig>system>sync-if-timing# ref2 source-port 5/1/1*config>system>sync-if-timing# ref2 no shutdownconfig>system>sync-if-timing# bits interface-type ds1 sfconfig>system>sync-if-timing# bits no shutdownconfig>system>sync-if-timing# ref-order bits ref1 ref2config>system>sync-if-timing# revertconfig>system>sync-if-timing# ql-selectionconfig>system>sync-if-timing# commitconfig>system>sync-if-timing# backconfig>system# back

* Reference 2 must be on last IOM set and SyncE and SSM must be enabled on Ethernet MDAs and ports

Set the Node Timing ReferencesConfigure the node timing references and reference order in the configure system sync-if-timingcontext.

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the timing configuration – show system sync-if-timing

A:MLS1# show system sync-if-timing

===============================================================================

System Interface Timing Operational Info

===============================================================================

System Status CPM A : Master Locked

Reference Input Mode : Revertive

Quality Level Selection : Enabled

Reference Selected : BITS A

System Quality Level : stu

Current Frequency Offset (ppm) : +0

Reference Order : bits ref1 ref2

...output truncatedReference BITS A

Input Admin Status : up

Rx Quality Level : stu

Quality Level Override : prs

Qualified For Use : Yes

Selected For Use : Yes

Interface Type : DS1

Framing : SF

Line Coding : B8ZS...output truncated


===============================================================================


===============================================================================


Reference Input Mode : Revertive


Reference Selected : BITS A

System Quality Level : stu


Reference Order : bits ref1 ref2

...output truncatedReference BITS A

Input Admin Status : up

Rx Quality Level : stu

Quality Level Override : prs



Interface Type : DS1

Framing : SF

Line Coding : B8ZS...output truncated

View the timing configuration – show system sync-if-timingThe 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.

Quality Level Override

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

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Configuring MLS1 for SyncE Support

Context: config>card>mda

Syntax: [no] sync-e

Context: config>port>ethernet>ssm

Syntax: ssm[no] code-type {sonet|sdh}

Example: config# card 5 mda 1 sync-e

config>card>mda# back

config>card# back

config# port 5/1/1


config>port>ethernet# ssm

config>port>ethernet>ssm# code-type sonet

config>port>ethernet>ssm# no shutdown

config>port>ethernet>ssm# back


config>port# back

Context: config>card>mda

Syntax: [no] sync-e

Context: config>port>ethernet>ssm

Syntax: ssm[no] code-type {sonet|sdh}

Example: config# card 5 mda 1 sync-e

config>card>mda# back

config>card# back

config# port 5/1/1


config>port>ethernet# ssm

config>port>ethernet>ssm# code-type sonet

config>port>ethernet>ssm# no shutdown

config>port>ethernet>ssm# back


config>port# back

Configuring MLS1 for SyncE SupportMDA 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View MLS1 Port SSM Configuration – show port 5/1/1

A:MLS1# show port 5/1/1

===============================================================================

Ethernet Interface

===============================================================================Description : 10/100/Gig Ethernet SFP

Interface : 5/1/1 Oper Speed : 1 Gbps

Link-level : Ethernet Config Speed : 1 Gbps

Admin State : up Oper Duplex : full

Oper State : up Config Duplex : full

Physical Link : Yes MTU : 9212

Single Fiber Mode : No

...output truncated

Sync. Status Msg. : Enabled Rx Quality Level : 0xf(dus)

Tx DUS/DNU : Disabled Tx Quality Level : 0x1(prs)

SSM Code Type : sonet

...output truncated

A:MLS1# show port 5/1/1

===============================================================================

Ethernet Interface

===============================================================================Description : 10/100/Gig Ethernet SFP

Interface : 5/1/1 Oper Speed : 1 Gbps

Link-level : Ethernet Config Speed : 1 Gbps

Admin State : up Oper Duplex : full

Oper State : up Config Duplex : full

Physical Link : Yes MTU : 9212

Single Fiber Mode : No

...output truncated

Sync. Status Msg. : Enabled Rx Quality Level : 0xf(dus)

Tx DUS/DNU : Disabled Tx Quality Level : 0x1(prs)

SSM Code Type : sonet

...output truncated

View MLS1 SSM configuration – show port 5/1/1The 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View POC2-1 timing configuration

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

A:POC2-1# show system sync-if-timing

===============================================================================


===============================================================================

System Status CSM A : Master Locked

Reference Input Mode : Non-revertive


Reference Order : ref1 ref2 external

Reference Input 1

Admin Status : up

Configured Quality Level : none

Rx Quality Level : prs



Source Port : 1/2/7

...output truncated

A:POC2-1# show system sync-if-timing

===============================================================================


===============================================================================





Reference Input 1

Admin Status : up





Source Port : 1/2/7

...output truncated

View POC2-1 timing configurationPOC2-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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View MLS1 timing configuration – SyncE/SSM port not selected

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


===============================================================================


===============================================================================

...Reference Input 2

Admin Status : up

Rx Quality Level : dus

Quality Level Override : none


Selected For Use : No

Not Selected Due To : ssm quality

Source Port : 5/1/1...output truncated


===============================================================================


===============================================================================

...Reference Input 2

Admin Status : up

Rx Quality Level : dus



Selected For Use : No

Not Selected Due To : ssm quality

Source Port : 5/1/1...output truncated

View MLS1 timing configuration – SyncE/SSM port not selectedThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 3 : Configure SyncE and SSM

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

.75 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 4 — Timing and Synchronization – IEEE 1588v2 and Precision Time Protocol (PTP) v2


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Explain how IEEE 1588v2 and the Precision Time Protocol (PTP) v2provide 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588v2 and PTPv2

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)

IEEE 1588v2 and PTPv2IEEE 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 domain’s time source, a PTP master delivers a series of time stamped packets to a set of slave nodes. The slave(s) compare the master’s 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 master’s. 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 slave’s frequency calculation accuracy.

General messages – Convey information for the protocol’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588v2 and PTPv2 Operation Modes

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

IEEE 1588v2 Operating ModesIEEE 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 master’s best estimate of the actual time the packet left the master clock’s 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 Delay-Resp(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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588v2 Clock 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

IEEE 1588v2 Clock Operation ModesIEEE 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 secondmessage, 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 master’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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.

IEEE 1588v2 Clock Types

IEEE 1588v2 ClocksIEEE 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.

TC’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SROS Supported PTP Message 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 calculationGeneral 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.

SROS Supported PTP Message TypesSROS supports ordinary master or slave clocks, and so supports the messages necessary to synchronize and maintain the domain’s clocks.Event MessagesCarry time critical information. These are:•Sync – Carries the master’s 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 master’s direction by comparing the time the master received the request to the time the slave sent the Delay_Req message.General MessagesThe 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 master’s 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 clock’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTPv2 Message Header

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

PTP Message HeaderIEEE 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 message’s 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 sender’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTPv2 Signaling Message

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)

PTPv2 Signaling MessageSignaling messages indicate a PTP device’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTPv2 Announce Message

PTP General Message used to establish the synchronization hierarchy

Indicates the quality of the sender’s signaled clock

Master sends periodically based on the slave requested announce interval

Contents used by the slave BMCA to select the best clock

PTPv2 Announce MessageIEEE 1588 describes the PTP Announce message format.

Origin Timestamp – Set within +/- 1 sec of originator’s 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 Earth’s rotation.

Grandmaster Priority1 – Used by the BMCA to choose the best clock, ranges from 0-255.

Grandmaster Clock Quality – Represents the Grandmaster’s 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 sender’s 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.A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



PTPv2 Sync and Delay Messages

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

PTP Sync and Delay MessagesThe 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 slave’s requesting PTP port ID and the time the master received the Delay_Request.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588 PTP Unicast Negotiation Sequence

Slave Unicast Negotiation: Slave sends signaling Announce Request

Unicast message-type to the configured master 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. Slave sends signaling Sync Request

Unicast message-type to the master Master responds to the slave with Sync

Granted message

1

2

3

4

IEEE 1588 PTP Unicast Negotiation SequenceAnnouncement

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 message’s Target Port Identifier field.

This TLV sets the slave’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588 PTP Two-Way, One-Step Time Transfer Sequence

Synchronization in two-way, one-step operation The master sends periodic Announce

messages at rate set by slave The master timestamps each Sync

packet (t1), in hardware, at egress The slave takes a timestamp (t2) when

the message arrives The slave sends a Delay_Req(uest)

message to the configured master and sets a timestamp (t3) The master responds to the slave with

Delay_Resp(onse) message (t4) The slave calculates the mean* one-way

delay and the clock offset, and adjusts its clock accordingly

1

2

3

4

5

6

IEEE 1588 Two-Way, One-Step Time Transfer SequenceThe 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 master’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



1588v2 Best Master Clock Selection

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

master’s information to select the best master

1588v2 Best Master Clock SelectionA 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



1588v2 Alternate BMCA

IEEE 1588v2 is designed to support many applications• Profiles define a specific application’s 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

1588v2 Alternate BMCA1588v2 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 master’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTP Slave Logical PTP Port State Machine

Once configured and turned up, the PTP slave port goes through the following states:

PTP Slave Logical PTP Port State MachinePTP 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 clock’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTP in the Model 2 Ring Architecture

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

*Note: SROS 9R4 only supports master or slave

PTP in the Model 2 Ring ArchitectureWithin the configure system ptp context, the node’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Resulting Model 2 Timing Distribution Tree

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

Resulting Model 2 Timing Distribution TreeBased 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 port’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Offset Calculation with no Path Delay

CSA1 receives the packet with no delay CSA1 adjusts its clock by the difference, -20 KHz

The PTP Master, MLS1, sets a timestamp in the Sync message; at the same time, t1, CSA1 clock is fast by 20KHz

Receive message at:

CSA1t2 = 1278.663375s

1

3

1

2

3

Send message at:

MLS1t1=1278.663325s

Adjust to:

MLS1t1 1278.663325s

- CSA1t2 1278.663375s

MLS1t1-CSA1t2 = -50us

2

1/-50us = -20KHz

Offset Calculation with no Path DelayWith 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Path Delay Effect on Received Timestamp

The intermediate nodes impose residence delay of 1us each as the packet travels to the slave node

CSA1 receives the message 2us after MLS1 sent it CSA1 adjusts its clock by the difference plus the delay,

1/-52 us = -19.3KHz

The Master, MLS1, sets a timestamp in the Sync message; at the same time, t1, the CSA1 clock is fast by 20KHz

Receive message at CSA1t2: 1278.663377s

1

2

3

1 Send message at:

MLS1t1=1278.663325sAdjust to:

MLS1t1 1278.663325s

- CSA1t2 1278.663377s

MLS1t1-CSA1t2 = -52us1/-52us = -19.3KHz

3

4

4

Path Delay Effect on Received TimestampCSA1 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588 PTP Offset Calculations

• 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

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 Delay’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTP Message Flow - Model 2 Unicast Negotiations

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

PTP Message Flow – Model 2 Unicast NegotiationsThe 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 router’s 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-by-link 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 node’s timing reference configuration ultimately determines which source becomes the node’s 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 node’s chassis MAC address. Once you associate a clock with a timing reference, for that reference the node will choose its master only from potential master’s advertising themselves on a particular clock’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTP Message Flow - Model 2 Synchronization

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

PTP Message Flow - Model 2 SynchronizationOnce the master grants the slave’s 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 peer’s 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 master’s. It can then propagate this adjusted clock value downstream to its slave peer(s).

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PTP Message Flow – Failure on MLS1 Link

Link failure between MLS1 and POC2-1 POC2-1 goes into holdover after 5 minutes of missing MLS1 messages POC2-1 sends QL-EEC toward POC3-1 POC3-1 receives QL-PRC from direction of MLS2 Nodes choose better reference according to their configurations

1

2

3

4

PTP Message Flow – Failure on MLS1 LinkPOC2-1 must find another timing source in the case it loses sync with MLS1. The network’s behavior depends on

each node’s 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-1’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring for PTP Master – 7750 SR

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

Context: config>system

Syntax: ptp

Context: config>system>ptp

Syntax: clock-type ordinary {master|slave}

[no] domain <domain-value>

network-type {sdh|sonet}

[no] shutdown

Example: config>system# ptp

config>system>ptp# clock-type ordinary master

config>system>ptp# domain 4

config>system>ptp# network-type sonet

config>system>ptp# no shutdown

Context: config>system

Syntax: ptp

Context: config>system>ptp

Syntax: clock-type ordinary {master|slave}

[no] domain <domain-value>

network-type {sdh|sonet}

[no] shutdown

Example: config>system# ptp

config>system>ptp# clock-type ordinary master

config>system>ptp# domain 4

config>system>ptp# network-type sonet

config>system>ptp# no shutdown

Configuring for PTP Master – 7750 SRThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring for PTP Slave – 7705 SAR

Context: config>system>ptp>clock

Syntax: clock-type {{ordinary {master|slave} | boundary}

source-interface <ip-if-name>

clock-mda <mda-id>

domain <domain-value>

priority1 [0-255]

priority2 [0-255]

profile {ieee1588-2008|itu-telecom-freq}

ptp-port [1-10]

Example: config>system>ptp>clock# clock-type ordinary slave

config>system>ptp>clock# source-interface loop_ptp

config>system>ptp>clock# clock-mda 1/2

config>system>ptp>clock# domain 4

config>system>ptp>clock# profile itu-telecom-freq

config>system>ptp>clock# ptp-port 1




clock-mda <mda-id>


priority1 [0-255]

priority2 [0-255]


ptp-port [1-10]







Configuring for PTP Slave – 7705 SARUnder the configure system ptp clock context, several options determine the node’s 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 clock’s 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 interface’s IP address becomes the peer node’s 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...

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring for PTP Slave – 7705 SAR (cont)




clock-mda <mda-id>


priority1 [0-255]

priority2 [0-255]


ptp-port [1-10]










clock-mda <mda-id>


priority1 [0-255]

priority2 [0-255]


ptp-port [1-10]







Configuring for PTP Slave – 7705 SAR (cont)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 master’s 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...

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring for PTP Slave – 7705 SAR (cont)

Context: config>system>ptp>clock>ptp-port

Syntax: [no] shutdown

peer [1..10]

Context: config>system>ptp>clock>ptp-port>peer

Syntax: description description

ip-address <ip-address>

Example: config>system>ptp>clock>ptp-port# peer 1

config>system>ptp>clock>ptp-port>peer# ip-address 192.0.2.0

config>system>ptp>clock>ptp-port>peer# description peer_MLS1

config>system>ptp>clock>ptp-port>peer# back

config>system>ptp>clock>ptp-port# no shutdown

config>system>ptp>clock>ptp-port# back

config>system>ptp>clock# no shutdown

config>system>ptp>clock# exit all

Context: config>system>ptp>clock>ptp-port

Syntax: [no] shutdown

peer [1..10]

Context: config>system>ptp>clock>ptp-port>peer

Syntax: description description

ip-address <ip-address>

Example: config>system>ptp>clock>ptp-port# peer 1

config>system>ptp>clock>ptp-port>peer# ip-address 192.0.2.0

config>system>ptp>clock>ptp-port>peer# description peer_MLS1

config>system>ptp>clock>ptp-port>peer# back

config>system>ptp>clock>ptp-port# no shutdown

config>system>ptp>clock>ptp-port# back

config>system>ptp>clock# no shutdown

config>system>ptp>clock# exit all

Configuring for PTP Slave – 7705 SAR (cont)peer – Configures a remote PTP peer. The peer IP address is the peer’s 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 slave’s 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 slave’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Set the Node Timing References – 7705 SAR

Enable PTP as a timing reference

Modify reference order to specify PTP source as required

Configure the PTP reference source


Syntax: begin[no] ref-order <first> <second> [<third>]commitabort

Example: config# system sync-if-timing

config>system>sync-if-timing# begin

config>system>sync-if-timing# ref-order ref1 ref2 external

config>system>sync-if-timing# ref1 source-ptp-clock 1

config>system>sync-if-timing# ref1 no shutdown

config>system>sync-if-timing# commit

config>system>sync-if-timing# back

config>system# back


Syntax: begin[no] ref-order <first> <second> [<third>]commitabort

Example: config# system sync-if-timing

config>system>sync-if-timing# begin

config>system>sync-if-timing# ref-order ref1 ref2 external

config>system>sync-if-timing# ref1 source-ptp-clock 1

config>system>sync-if-timing# ref1 no shutdown

config>system>sync-if-timing# commit

config>system>sync-if-timing# back

config>system# back

Set the Node Timing ReferencesConfigure 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Master Configuration – 7750 SR

• 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

A:MLS1# show system ptp

===============================================================================

IEEE 1588/PTP Clock Information

===============================================================================

-------------------------------------------------------------------------------

Local Clock

-------------------------------------------------------------------------------

Clock Type : ordinary,master PTP Profile : ITU-T G.8265.1

Domain : 4 Network Type : sonet

Admin State : up Oper State : up

Clock Id : 0003fafffe688fc0 Clock Class : 80 (prs)

Clock Accuracy : unknown Clock Variance : ffff (not computed)

Clock Priority1 : 128 Clock Priority2 : 128

PTP Port State : master Last Changed : 10/21/2011 16:12:45

===============================================================================


===============================================================================


===============================================================================

-------------------------------------------------------------------------------

Local Clock

-------------------------------------------------------------------------------

Clock Type : ordinary,master PTP Profile : ITU-T G.8265.1



Clock Id : 0003fafffe688fc0 Clock Class : 80 (prs)



PTP Port State : master Last Changed : 10/21/2011 16:12:45

===============================================================================

View the Master PTP Configuration – 7750 SRA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Master Peers – 7750 SR

• 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

A:MLS1# show system ptp peers detail

===============================================================================

IEEE 1588/PTP Peer Information

===============================================================================

IP Address : 192.0.2.1 Announce Direction : tx

Clock Id : 0003fafffe6bd7c0 Remote PTP Port : 1

-------------------------------------------------------------------------------


Clock Id : 7c2064fffec348b8 Remote PTP Port : 1

-------------------------------------------------------------------------------


Clock Id : 7c2064fffec3040e Remote PTP Port : 1

===============================================================================

A:MLS1# show system ptp peers detail

===============================================================================


===============================================================================


Clock Id : 0003fafffe6bd7c0 Remote PTP Port : 1

-------------------------------------------------------------------------------


Clock Id : 7c2064fffec348b8 Remote PTP Port : 1

-------------------------------------------------------------------------------


Clock Id : 7c2064fffec3040e Remote PTP Port : 1

===============================================================================

View the PTP Master Peers – 7750 SRA:NodeA# show system ptp peers detail

IP Address: – Lists the peer’s IP address.

Announce direction: - tx for master, rx for slaveClock ID: - 8 bytes based on the chassis MAC addressRemote PTP Port: - The logical PTP port number for this peer.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Master Peer Details – 7750 SR

A:MLS1# show system ptp peer 192.0.2.227 detail

===============================================================================


===============================================================================


Clock Id : 143e60fffe7eada6 Remote PTP Port : 1

===============================================================================

===============================================================================

IEEE 1588/PTP Unicast Negotiation Information

===============================================================================

IP Address Dir Type Rate Duration State Time

-------------------------------------------------------------------------------

192.0.2.227 Tx Announce 1 pkt/2 s 300 Granted 11/22/2011 14:48:37

192.0.2.227 Tx Sync 64 pkt/s 300 Granted 11/22/2011 14:46:12

192.0.2.227 Tx Delay Resp 64 pkt/s 300 Granted 11/22/2011 14:46:12

===============================================================================...continued on the next slide


===============================================================================


===============================================================================


Clock Id : 143e60fffe7eada6 Remote PTP Port : 1

===============================================================================

===============================================================================

IEEE 1588/PTP Unicast Negotiation Information

===============================================================================

IP Address Dir Type Rate Duration State Time

-------------------------------------------------------------------------------

192.0.2.227 Tx Announce 1 pkt/2 s 300 Granted 11/22/2011 14:48:37

192.0.2.227 Tx Sync 64 pkt/s 300 Granted 11/22/2011 14:46:12

192.0.2.227 Tx Delay Resp 64 pkt/s 300 Granted 11/22/2011 14:46:12

===============================================================================...continued on the next slide

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 network’s performance when transporting synchronization messages.IEEE 1588/PTP Unicast Negotiation Information IP Address: - Peer’s 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 node’s 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. Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Master Peer Details – 7750 SR (cont)


...

===============================================================================

IEEE 1588/PTP Packet Statistics

===============================================================================

Input Output

-------------------------------------------------------------------------------

PTP Packets 4946482 9930069

Announce 0 38635

Sync 0 4944952

Follow Up 0 0

Delay Request 4944951 0

Delay Response 0 4944951

Signaling 1531 1531

Request Unicast Transmission TLVs 1531 0

Announce 511 0

Sync 510 0


Grant Unicast Transmission (Accepted) TLVs 0 1531

Announce 0 511

Sync 0 510


... Continued on next slide


...

===============================================================================


===============================================================================

Input Output

-------------------------------------------------------------------------------

PTP Packets 4946482 9930069

Announce 0 38635

Sync 0 4944952

Follow Up 0 0

Delay Request 4944951 0


Signaling 1531 1531

Request Unicast Transmission TLVs 1531 0

Announce 511 0

Sync 510 0


Grant Unicast Transmission (Accepted) TLVs 0 1531

Announce 0 511

Sync 0 510


... Continued on next slide

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 network’s performance when transporting synchronization messages.


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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Master Peer Details – 7750 SR (cont)


...

Grant Unicast Transmission (Denied) TLVs 0 0

Announce 0 0

Sync 0 0

Delay Response 0 0

Cancel Unicast Transmission TLVs 0 0

Announce 0 0

Sync 0 0

Delay Response 0 0

Ack Cancel Unicast Transmission TLVs 0 0

Announce 0 0

Sync 0 0

Delay Response 0 0

Other TLVs 0 0

Other 0 0

Discards 0 0

Bad PTP domain 0 0

Alternate Master 0 0

Other 0 0

===============================================================================


...

Grant Unicast Transmission (Denied) TLVs 0 0

Announce 0 0

Sync 0 0

Delay Response 0 0

Cancel Unicast Transmission TLVs 0 0

Announce 0 0

Sync 0 0

Delay Response 0 0

Ack Cancel Unicast Transmission TLVs 0 0

Announce 0 0

Sync 0 0

Delay Response 0 0

Other TLVs 0 0

Other 0 0

Discards 0 0

Bad PTP domain 0 0

Alternate Master 0 0

Other 0 0

===============================================================================

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View The PTP Slave Configuration – 7750 SRA:MLS2# show system ptp

===============================================================================


===============================================================================

-------------------------------------------------------------------------------

Local Clock

-------------------------------------------------------------------------------

Clock Type : ordinary,slave PTP Profile : ITU-T G.8265.1



Clock Id : 0003fafffe6bd7c0 Clock Class : 255 (slave-only)



PTP Port State : slave 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

-------------------------------------------------------------------------------

Parent Clock

-------------------------------------------------------------------------------

IP Address : 192.0.2.0

Parent Clock Id : 0003fafffe688fc0 Remote PTP Port : 1

GM Clock Id : 0003fafffe688fc0 GM Clock Class : 80 (prs)

GM Clock Accuracy : unknown GM Clock Variance : ffff (not computed)

GM Clock Priority1: 128 GM Clock Priority2 : 128

===============================================================================


===============================================================================


===============================================================================

-------------------------------------------------------------------------------

Local Clock

-------------------------------------------------------------------------------

Clock Type : ordinary,slave PTP Profile : ITU-T G.8265.1



Clock Id : 0003fafffe6bd7c0 Clock Class : 255 (slave-only)



PTP Port State : slave 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

-------------------------------------------------------------------------------

Parent Clock

-------------------------------------------------------------------------------

IP Address : 192.0.2.0

Parent Clock Id : 0003fafffe688fc0 Remote PTP Port : 1

GM Clock Id : 0003fafffe688fc0 GM Clock Class : 80 (prs)

GM Clock Accuracy : unknown GM Clock Variance : ffff (not computed)

GM Clock Priority1: 128 GM Clock Priority2 : 128

===============================================================================

View the PTP Slave Configuration – 7750 SRA: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 clock’s calculated offset from the master.IP Address: – The master peer’s IP address.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View The PTP Slave Configuration – 7705 SARA:CSA1# show system ptp clock 1

===============================================================================

IEEE1588 PTP Clock Information

===============================================================================

-------------------------------------------------------------------------------

Local Clock

-------------------------------------------------------------------------------

Clock Type : ordinary,slave Admin State : up

Source I/F : loop_ptp Clock MDA : 1/2

PTP Profile : ituTelecomFreq Dynamic Peers : not allowed

Clock ID : 7c2064fffec348b8 Clock Class : 255

Clock Accuracy : unknown(254) Clock Variance : not computed


Domain : 4 Two-Step : unknown

-------------------------------------------------------------------------------

Operational Data

-------------------------------------------------------------------------------

Parent Clock ID : 0003fafffe688fc0 Parent Port Number : 1

GM Clock Id : 0003fafffe688fc0 GM Clock Class : 80

GM Clock Accuracy : unknown(254) GM Clock Variance : not computed

GM Clock Priority1 : 128 GM Clock Priority2 : 128

-------------------------------------------------------------------------------

Slave Port Index : 1 Slave Port State : slave

Slave Peer Index : 1 Slave Peer IP : 192.0.2.0

Forward Weight : 100 Reverse Weight : 0

Recovery State : locked

===============================================================================

A:CSA1# show system ptp clock 1

===============================================================================

IEEE1588 PTP Clock Information

===============================================================================

-------------------------------------------------------------------------------

Local Clock

-------------------------------------------------------------------------------

Clock Type : ordinary,slave Admin State : up

Source I/F : loop_ptp Clock MDA : 1/2

PTP Profile : ituTelecomFreq Dynamic Peers : not allowed

Clock ID : 7c2064fffec348b8 Clock Class : 255

Clock Accuracy : unknown(254) Clock Variance : not computed


Domain : 4 Two-Step : unknown

-------------------------------------------------------------------------------

Operational Data

-------------------------------------------------------------------------------

Parent Clock ID : 0003fafffe688fc0 Parent Port Number : 1




-------------------------------------------------------------------------------

Slave Port Index : 1 Slave Port State : slave

Slave Peer Index : 1 Slave Peer IP : 192.0.2.0

Forward Weight : 100 Reverse Weight : 0

Recovery State : locked

===============================================================================

View the PTP Slave Configuration – 7705 SARA: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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View The PTP Slave PTP Port Peer – 7705 SAR

A:CSA1# show system ptp clock 1 ptp-port 1 peer 1 detail

===============================================================================

Peer-1

===============================================================================

IP Address : 192.0.2.0 static/dynamic : static

Current Master : TRUE

Description : peer_MLS1

Clock Id : 0003fafffe688fc0 Port Number : 1




Step Type : one-step

Last Rx Anno Msg : 11/22/2011 14:54:36

---------------------------------------------------------------------------

Unicast Info

---------------------------------------------------------------------------

Dir Type Rate Dur Result Time Remain

---------------------------------------------------------------------------

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

DelayResp 64 pkts/s 300 granted 11/21/2011 14:53:41 249

---------------------------------------------------------------------------

===============================================================================

...continued on next page


===============================================================================

Peer-1

===============================================================================

IP Address : 192.0.2.0 static/dynamic : static

Current Master : TRUE

Description : peer_MLS1

Clock Id : 0003fafffe688fc0 Port Number : 1




Step Type : one-step

Last Rx Anno Msg : 11/22/2011 14:54:36

---------------------------------------------------------------------------

Unicast Info

---------------------------------------------------------------------------

Dir Type Rate Dur Result Time Remain

---------------------------------------------------------------------------

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

DelayResp 64 pkts/s 300 granted 11/21/2011 14:53:41 249

---------------------------------------------------------------------------

===============================================================================


View the PTP Slave PTP Port Peer – 7705 SARA:NodeA# show system ptp clock 1 ptp-port 1 peer 1 detail

Peer-1 IP Address: – Lists the peer’s 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 GM’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Slave Configuration – 7705 SAR (cont)


...continued from previous page

...output truncated===============================================================================

PTP Peer 1 Algorithm State Statistics (in seconds)

===============================================================================

Free-run : 604

Acquiring : 120

Phase-Tracking : 1440

Hold-over : 0

Locked : 75504

===============================================================================




...output truncated===============================================================================

PTP Peer 1 Algorithm State Statistics (in seconds)

===============================================================================

Free-run : 604

Acquiring : 120

Phase-Tracking : 1440

Hold-over : 0

Locked : 75504

===============================================================================


View the PTP Slave Configuration – 7705 SAR (cont)PTP Peer 1 Algorithm State Statistics (in seconds)Displays how long the slave clock has been in each of the listed states.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the PTP Slave Configuration – 7705 SAR (cont)



...output truncated

===============================================================================

PTP Peer-1 Clock Recovery

- Internal Digital Phase Locked Loop (DPLL) Statistics

===============================================================================

sync delay-req phase phase

pkt delay pkt delay error error

stddev stddev stddev

time (ns) (ns) (ns) (ns)

-------------------------------------------------------------------------------

11/22/2011 14:55:51 7 233 -327 21

11/22/2011 14:53:51 7 225 -376 12

11/22/2011 14:51:50 6 206 -445 25

11/22/2011 14:49:50 10 223 -513 16

11/22/2011 14:47:50 19 236 -551 9

11/22/2011 14:45:50 4 223 -563 7

11/22/2011 14:43:50 0 249 -589 13

11/22/2011 14:41:50 3 233 -599 7

11/22/2011 14:39:50 3 230 -609 8

...output truncated



...output truncated

===============================================================================

PTP Peer-1 Clock Recovery

- Internal Digital Phase Locked Loop (DPLL) Statistics

===============================================================================

sync delay-req phase phase

pkt delay pkt delay error error

stddev stddev stddev

time (ns) (ns) (ns) (ns)

-------------------------------------------------------------------------------

11/22/2011 14:55:51 7 233 -327 21

11/22/2011 14:53:51 7 225 -376 12

11/22/2011 14:51:50 6 206 -445 25

11/22/2011 14:49:50 10 223 -513 16

11/22/2011 14:47:50 19 236 -551 9

11/22/2011 14:45:50 4 223 -563 7

11/22/2011 14:43:50 0 249 -589 13

11/22/2011 14:41:50 3 233 -599 7

11/22/2011 14:39:50 3 230 -609 8

...output truncated

View the PTP Slave Configuration – 7705 SAR (cont)PTP Peer-1 Clock Recovery – Internal Digital Phase Locked Loop (DPLL) StatisticsThese statistics, refreshed by the node every 2 minutes, shows the peer clock phase and delay error values.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Slave Timing References – 7750 SR


===============================================================================


===============================================================================



Quality Level Selection : Disabled

Reference Selected : ptp

System Quality Level : prs


Reference Order : ptp ref1 ref2 bits

...output truncated

Reference PTP

Admin Status : up





===============================================================================


===============================================================================


===============================================================================




Reference Selected : ptp

System Quality Level : prs


Reference Order : ptp ref1 ref2 bits

...output truncated

Reference PTP

Admin Status : up





===============================================================================

View the Slave Timing References – 7750 SARThe 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: – Slave’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Slave Timing References – 7705 SAR

A:CSA2# show system sync-if-timing

===============================================================================


===============================================================================





Reference Input 1

Admin Status : up





Source Port : None

Source PTP Clock : 1

...output truncated

A:CSA2# show system sync-if-timing

===============================================================================


===============================================================================





Reference Input 1

Admin Status : up





Source Port : None

Source PTP Clock : 1

...output truncated

View the Slave Timing References – 7705 SARThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



IEEE 1588v2/PTPv2 Design Considerations

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 4 : Configure IEEE 1588v2 and PTP

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 masterNOTE: 7750 will not operate as PTP slave without SF/CPM-3 installed

.5 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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 thePTP 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 5 — Routing and Routing Protocols


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Explore the unique routing challenges offered by the Mobile Backhaul Transport Network

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives (cont)


Describe routing in the Model 2 network

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Routing in the Mobile Backhaul Transport 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

Routing in the Mobile Backhaul Transport NetworkIn 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 network’s performance. The network must recover quickly enough to prevent dropped calls and subsequent resignalingbursts in the case of an outage. Control traffic must flow reliably as well. The network must provide hot-redundant paths between the cell sites and the MTSO.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Routing in the Model 1 Hub and Spoke Topology

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

Routing in Model 1 Hub and Spoke TopologyThe 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

1000’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Routing in the Model 1 Hub and Spoke Topology (cont)

CSA to MTSO floating static routes

Two paths to each MLS router Set higher preference on backup path

Routing in the Model 1 Hub and Spoke Topology (cont)Floating static routes in the Model 1 topology provide redundant routes to each node’s 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 CSA’s 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 CSA’s system IP. Additionally, the MLS routers have static routes defined to each other’s system IP, and additional static routes to the EPC elements.

BFD on Static Routes

Configured on both static routes is BFD. Since the routers won’t 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 MEN’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

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 abackup static route in the event the router detects a failure along the path used by the primary static route.

Floating Static Routes in the Model 1 NetworkIn the example above, CSA1 has two static routes configured. The top static route points all traffic destined for MLS1’s 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 route’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



BFD on the Model 1 Network Static Routes

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

BFD on the Model 1 Network Static RoutesBFD 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 RoutesBFD 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 customer’s design.BFD on the InterfacesYou 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 messagesreceive-interval – Sets the interval, in milliseconds, at which the node expects to receive BFD messagesmultiplier – Sets the number of packets the node can miss before declaring the BFD session, and thus the

interface, downA: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).

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



LDP-Sync on the 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

LDP-Sync on the Static RoutesLDP 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 route’s 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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



LDP-sync on Primary Static Route

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

A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.5 bfd-enable ldp-sync


LDP-Sync on Primary Static RouteOn 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 ldp-sync



A:MLS2>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.14 bfd-enable ldp-sync


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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the CSA Primary Static Route

A:CSA1# show router static-route detail

===============================================================================

Static Route Table (Router: Base) Family: IPv4

===============================================================================

...

-------------------------------------------------------------------------------

Prefix : 192.0.2.0/32

Nexthop : 192.0.2.5

Type : Nexthop Nexthop Type : IP

Interface : CSA1_MLS1 Active : Y

Prefix List : n/a Prefix List Type : n/a

Metric : 1 Preference : 5

Admin State : Up Tag : 0

BFD : enabled

CPE-check : disabled

LDP Sync : enabled

LDP Sync : enabled


-------------------------------------------------------------------------------No. of Static Routes: 4

===============================================================================

A:CSA1# show router static-route detail

===============================================================================


===============================================================================

...

-------------------------------------------------------------------------------

Prefix : 192.0.2.0/32

Nexthop : 192.0.2.5

Type : Nexthop Nexthop Type : IP

Interface : CSA1_MLS1 Active : Y

Prefix List : n/a Prefix List Type : n/a

Metric : 1 Preference : 5

Admin State : Up Tag : 0

BFD : enabled

CPE-check : disabled

LDP Sync : enabled

LDP Sync : enabled


-------------------------------------------------------------------------------No. of Static Routes: 4

===============================================================================

View the CSA Primary Static RouteA:NodeA# show router static-route detail

BFD: – Enabled on all CSA interfaces and static routes.

LDP Sync: - Enabled on primary route onlyPreference: - The default preference is used for the primary route.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the CSA BFD Sessions

A:CSA1# show router bfd session

===============================================================================

BFD Session

===============================================================================

Interface State Tx Intvl Rx Intvl Multipl

Remote Address Protocol Tx Pkts Rx Pkts Type

-------------------------------------------------------------------------------

CSA1_MLS1 Up (3) 500 500 3

192.0.2.5 static 8709 7477 iom

CSA1_MLS2 Up (3) 500 500 3

192.0.2.13 static 9719 9719 iom

-------------------------------------------------------------------------------

No. of BFD sessions: 2

===============================================================================

A:CSA1# show router bfd session

===============================================================================

BFD Session

===============================================================================


Remote Address Protocol Tx Pkts Rx Pkts Type

-------------------------------------------------------------------------------

CSA1_MLS1 Up (3) 500 500 3

192.0.2.5 static 8709 7477 iom

CSA1_MLS2 Up (3) 500 500 3

192.0.2.13 static 9719 9719 iom

-------------------------------------------------------------------------------


===============================================================================

View the CSA BFD SessionsA: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

===============================================================================


Remote Address Protocols Tx Pkts Rx Pkts Type

-------------------------------------------------------------------------------

MLS1_CSA1 Up (3) 500 500 3

192.0.2.6 static 2753 2751 iom

-------------------------------------------------------------------------------


=============================================================================== Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View LDP Sync Status

A:MLS1# tools dump router static-route ldp-sync-status

===============================================================================

Sync Status of LDP interfaces

===============================================================================

If Ind* If Name Timer Running? Timeout Time

Yes/No used Left

-------------------------------------------------------------------------------

2 MLS1_CSA1 Yes 180 174

4 MLS1_MLS2 No 0 0

===============================================================================

• indicates that the corresponding row element may have been truncated.

A:MLS1# tools dump router static-route ldp-sync-status

===============================================================================

Sync Status of LDP interfaces

===============================================================================

If Ind* If Name Timer Running? Timeout Time

Yes/No used Left

-------------------------------------------------------------------------------

2 MLS1_CSA1 Yes 180 174

4 MLS1_MLS2 No 0 0

===============================================================================

• indicates that the corresponding row element may have been truncated.

View LDP Sync StatusA: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

===============================================================================


===============================================================================

Prefix Tag Met Pref Type Act

Next Hop Interface

-------------------------------------------------------------------------------

192.0.2.1/32 0 1 5 NH Y

192.0.2.22 MLS1_MLS2

192.0.2.2/32 0 1 5 NH N

192.0.2.6 n/a

192.0.2.2/32 0 1 10 NH Y

192.0.2.22 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



OSPF in Model 1

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# timers spf-wait 2000 50 100A:MLS1>config>router>ospf# timers spf-wait 2000 50 100

1st run = 50ms

2nd run = 100ms

200ms

400ms

800ms

1600ms

max wait = 2000ms

Event

SPF Event Timeline

OSPF in Model 1To 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 TimersYou 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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Routing Protocol Convergence Factors

Routing protocol convergence is affected by the following conditions:1. Link failure detection2. Time to generate and send a Link State Advertisement (LSA)/Link

State Packet (LSP) after a topology change occurs3. Time to flood the LSAs/LSPs throughout the network4. SPF timers5. Time to update the Routing Information Base (RIB) and FIB

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Routing in the Model 2 Subtended Ring Topology

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

Routing in Model 2 Subtended Ring TopologyThe 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. Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Routing in the Model 2 Subtended Ring Topology (cont)

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

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 LSPspropagated 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



iBGP in the Model 2 Topology

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

iBGP in the Model 2 TopologyInternal 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 ReflectorsBGP 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 RR’s is called a cluster. MLS1 and MLS2 use different Cluster IDs to provide RR redundancy. This ensures the RRs accept each other’s 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 TrackingSROS 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



iBGP in the Model 2 Topology (cont)

A:MLS1# show router bgp neighbor

===============================================================================

BGP Neighbor

===============================================================================

-------------------------------------------------------------------------------

Peer : 192.0.2.2

Group : Aggregate

-------------------------------------------------------------------------------

Peer AS : 65100 Peer Port : 0

Peer Address : 192.0.2.2

Local AS : 65100 Local Port : 0

Local Address : 0.0.0.0

Peer Type : Internal

State : Connect Last State : Idle

...


===============================================================================

BGP Neighbor

===============================================================================

-------------------------------------------------------------------------------

Peer : 192.0.2.2

Group : Aggregate

-------------------------------------------------------------------------------






State : Connect Last State : Idle

...

BGP peer tracking enabled

Router drops peer connection immediately

iBGP in the Model 2 Topology (cont)BGP Peer TrackingThe 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 MLS1’s IGP removes its POC3 route. Upon notification of this change, MLS1’s 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 trackingA

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Configure the BGP Route Reflectors

Context: config>router

Syntax: autonomous-system as-number

Context: config>router>bgp

Syntax: group name

Context: config>router>bgp>group

Syntax: [no] cluster cluster-id (0.0.0.1-255.255.255.255) [no] enable-peer-tracking[no] neighbor ip-address [no] next-hop-self {[ipv4][vpn-ipv4][ipv6][mcast-ipv4][l2-vpn]} [no] peer-as as-number [no] type {internal|external}

Example: configure router autonomous-system 65100

configure router bgp group Aggregate

config>router>bgp>group$ cluster 10.10.10.10

config>router>bgp>group$ enable-peer-tracking

config>router>bgp>group$ next-hop-self

config>router>bgp>group$ peer-as 65100

config>router>bgp>group$ type internal

config>router>bgp>group$ neighbor 192.0.2.2

config>router>bgp>group>neighbor$ back

config>router>bgp>group$

Context: config>router

Syntax: autonomous-system as-number

Context: config>router>bgp

Syntax: group name

Context: config>router>bgp>group

Syntax: [no] cluster cluster-id (0.0.0.1-255.255.255.255) [no] enable-peer-tracking[no] neighbor ip-address [no] next-hop-self {[ipv4][vpn-ipv4][ipv6][mcast-ipv4][l2-vpn]} [no] peer-as as-number [no] type {internal|external}

Example: configure router autonomous-system 65100

configure router bgp group Aggregate

config>router>bgp>group$ cluster 10.10.10.10

config>router>bgp>group$ enable-peer-tracking

config>router>bgp>group$ next-hop-self

config>router>bgp>group$ peer-as 65100

config>router>bgp>group$ type internal

config>router>bgp>group$ neighbor 192.0.2.2

config>router>bgp>group>neighbor$ back

config>router>bgp>group$

Configure the BGP Route ReflectorsOn 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 neighbor’s address. For iBGP, this is the neighbor’s system ID. The peers must have IGP routes to the neighbor’s system ID for the peering to succeed.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the BGP RR Status


===============================================================================

BGP Neighbor

===============================================================================

-------------------------------------------------------------------------------

Peer : 192.0.2.2

Group : Aggregate

-------------------------------------------------------------------------------






State : Established Last State : Active

Last Event : recvKeepAlive

Last Error : Hold Timer Expire

Local Family : IPv4

Remote Family : IPv4

Hold Time : 90 Keep Alive : 30

Active Hold Time : 90 Active Keep Alive : 30

Cluster Id : 10.10.10.10

Preference : 170 Num of Update Flaps : 0

...


===============================================================================

BGP Neighbor

===============================================================================

-------------------------------------------------------------------------------

Peer : 192.0.2.2

Group : Aggregate

-------------------------------------------------------------------------------






State : Established Last State : Active

Last Event : recvKeepAlive

Last Error : Hold Timer Expire

Local Family : IPv4

Remote Family : IPv4

Hold Time : 90 Keep Alive : 30

Active Hold Time : 90 Active Keep Alive : 30

Cluster Id : 10.10.10.10

Preference : 170 Num of Update Flaps : 0

...

View the BGP RR StatusA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the BGP RR Status (cont)


===============================================================================

BGP Neighbor

===============================================================================

-------------------------------------------------------------------------------

Peer : 192.0.2.2

Group : Aggregate

-------------------------------------------------------------------------------

...

Graceful Restart : Disabled Stale Routes Time : n/a

Advertise Inactive : Disabled Peer Tracking : Enabled

Advertise Label : None

Auth key chain : n/a

Disable Cap Nego : Disabled Peer Tracking : Enabled


...

-------------------------------------------------------------------------------

Neighbors : 1

===============================================================================

* indicates that the corresponding row element may have been truncated.


===============================================================================

BGP Neighbor

===============================================================================

-------------------------------------------------------------------------------

Peer : 192.0.2.2

Group : Aggregate

-------------------------------------------------------------------------------

...

Graceful Restart : Disabled Stale Routes Time : n/a

Advertise Inactive : Disabled Peer Tracking : Enabled

Advertise Label : None


Disable Cap Nego : Disabled Peer Tracking : Enabled


...

-------------------------------------------------------------------------------

Neighbors : 1

===============================================================================

* indicates that the corresponding row element may have been truncated.

View the BGP RR Status (cont)A:NodeA# show router neighbor 192.0.2.2

Peer Tracking: – Enabled for the peer.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



eBGP in the Backhaul Transport Network

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

eBGP in the Backhaul Transport NetworkeBGP 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 5 : Configure ISIS and BFD in the Model 1 Topology

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

.5 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary


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 runfrequency on identical events

A hierarchical routed domain reduces the number of LSPs/LSAsflooding the network when a topology change occurs

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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 timeto 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Section 6 — MPLS in the Backhaul Transport Network


Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Describe the Model 1 network’s use of LDP tunnels between the CSA routers and the MLS routers

Explain the Model 2 network’s 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Why MPLS in the Backhaul Transport?

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-to-end 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

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 LSP’s 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



MPLS in the Mobile Backhaul Transport Network

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

MPLS in the Mobile Backhaul Transport NetworkMPLS 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)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Example 1: LDP in Model 1

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

Example 1: LDP in Model 1Though 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Example 2: RSVP in Model 2

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

Example 2: RSVP in Model 2Model 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



LSPs in the Access Ring

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# info

-----------------------------------

admin-group "LOWER" 2

admin-group "UPPER" 1

...

lsp "CSA1 to POC3-1“

to 192.0.2.0

primary "POC3-1-1"

include "UPPER"

exit

secondary "POC3-1-2“

standby

include "LOWER"

exit

no shutdown

exit

A:CSA1>config>router>mpls# info

-----------------------------------

admin-group "LOWER" 2

admin-group "UPPER" 1

...

lsp "CSA1 to POC3-1“

to 192.0.2.0

primary "POC3-1-1"

include "UPPER"

exit

secondary "POC3-1-2“

standby

include "LOWER"

exit

no shutdown

exit

LSPs in the Access RingAs 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



LSPs in the Aggregation 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 ringA:POC3-1>config>router>mpls# info

-----------------------------------

...

path "bypass_POC3-2“

hop 1 192.0.2.4 strict

...


no shutdown

...

lsp "bypass_POC3-2" bypass-only

to 192.0.2.3

primary "bypass_POC3-2“

exit

no shutdown

exit

A:POC3-1>config>router>mpls# info

-----------------------------------

...

path "bypass_POC3-2“


...


no shutdown

...

lsp "bypass_POC3-2" bypass-only

to 192.0.2.3

primary "bypass_POC3-2“

exit

no shutdown

exit

LSPs in the Aggregation RingAs 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 can’t 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 tail-end of the protected LSP.

(notes continue on the next page...)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configure the POC3 Manual Bypass Tunnels

Context: config>router>mpls

Syntax: path <path-name>

lsp <lsp-name> [bypass-only]

Context: config>router>mpls>path

Syntax: hop <hop-index> <ip-address> {strict|loose}

[no] shutdown

Context: config>router>mpls>lsp

Syntax: [no] to <ip-address>

[no] primary <path-name>

[no] shutdown

Example: configure router mpls

config>router>mpls# path “bypass_POC_3-2”

config>router>mpls>path$ hop 1 192.0.2.4 strict





config>router>mpls>path$ no shutdown

config>router>mpls>path$ back

config>router>mpls# lsp “bypass_POC3-2” bypass-only

config>router>mpls>lsp$ to 192.0.2.3

config>router>mpls>lsp$ primary “bypass_POC3-2”

config>router>mpls>lsp>primary$ exit

config>router>mpls>lsp# no shutdown

Context: config>router>mpls

Syntax: path <path-name>

lsp <lsp-name> [bypass-only]

Context: config>router>mpls>path

Syntax: hop <hop-index> <ip-address> {strict|loose}

[no] shutdown

Context: config>router>mpls>lsp

Syntax: [no] to <ip-address>

[no] primary <path-name>

[no] shutdown

Example: configure router mpls

config>router>mpls# path “bypass_POC_3-2”






config>router>mpls>path$ no shutdown

config>router>mpls>path$ back

config>router>mpls# lsp “bypass_POC3-2” bypass-only

config>router>mpls>lsp$ to 192.0.2.3

config>router>mpls>lsp$ primary “bypass_POC3-2”

config>router>mpls>lsp>primary$ exit

config>router>mpls>lsp# no shutdown

Configure the POC3 Manual Bypass TunnelsBy 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Choosing the Manual Bypass Tunnel

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

Choosing the Manual Bypass TunnelWhen 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Link Failure Example, Manual Bypass Tunnel in Model 2

LSP between POC3-1 and POC3-2 link failure example• BFD detects the link failure between POC3-1 and POC3-2• POC3-1 moves the LSP’s 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

1

2

Link Failure Example, Model 2This slide illustrates a manual bypass tunnel used to reroute traffic from a link failure between POC3-1 and POC3-

2.

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 POC2-1 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Manual Bypass Tunnel Status

The manual bypass tunnel terminating on POC3-2 via POC2-1 protects LSP POC3-1_POC3-2

A:POC3-1# show router mpls bypass-tunnel protected-lsp

===============================================================================

MPLS Bypass Tunnels

===============================================================================

Legend : m - Manual d - Dynamic p - P2mp

===============================================================================

To State Out I/F Out Label Reserved Protected Type

BW (Kbps) LSP Count

-------------------------------------------------------------------------------

192.0.2.3 Up 1/2/7 131069 0 1 m

Protected LSPs -

POC3-1_POC3-2::POC3-1_POC3-2 From: 192.0.2.2 To: 192.0.2.3

-------------------------------------------------------------------------------

Bypass Tunnels : 1

===============================================================================

A:POC3-1# show router mpls bypass-tunnel protected-lsp

===============================================================================

MPLS Bypass Tunnels

===============================================================================

Legend : m - Manual d - Dynamic p - P2mp

===============================================================================

To State Out I/F Out Label Reserved Protected Type

BW (Kbps) LSP Count

-------------------------------------------------------------------------------

192.0.2.3 Up 1/2/7 131069 0 1 m

Protected LSPs -

POC3-1_POC3-2::POC3-1_POC3-2 From: 192.0.2.2 To: 192.0.2.3

-------------------------------------------------------------------------------

Bypass Tunnels : 1

===============================================================================

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 6 : Configure RSVP LSPs in Model 1 Topology

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

.5 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary


The Model 1 LDP tunnels follow the static route paths, preferredand 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 LSP’s primary and secondary paths

Fast reroute facility and manual bypass tunnels provide predictable behavior bypass tunnel behavior

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Summary

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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 LSP’s primary and secondary paths

Fast reroute facility and manual bypass tunnels provide predictable bypass tunnel behavior

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




1. SROS routers support which two encapsulation types on Ethernet access ports? (Choose two.)

a) null

b) bcp-null

c) ipcp

d) dot1q

2. Which three characteristics influence a port’s MTU size setting? (Choose three.)

a) Frame Check Sequence

b) Layer 3 payload size

c) Layer 2 header size

d) Pseudowire header

Answers:

1. a, d

2. b, c, d

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




3. Ethernet auto-negotiate determines what two Ethernet port characteristics? (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 tothe routing process that a port has recovered. What feature would you configure?

a) Turn up BFD on the port

b) Enable auto-negotiate on the port

c) Set a port up hold-time

d) Set an LDP-Sync timer on the port

Answers:

3. c, d

4. c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




5. On a DS1 channel group, what characteristic determines the type of payload the link will transport?

a) The encapsulation type

b) The clock source

c) The port’s 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

Answers:

5. a

6. a

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




7. A node signals its desire to implement ML-PPP during what phase of the circuit’s initialization?

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

Answers:

7. b

8. 4, 1, 2, 3

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




9. Which two synchronization techniques sets the node’s SEC/EEC by the received bit stream? (Choose two.)

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

Answers:

9. a, c

10. c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




11.A SyncE reference’s SEC goes into holdover. On SDH mode, whatSSM quality level will it advertise to its peers?

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

Answers:

11. d

12. a, c, d

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




13.An SROS node configured for SyncE SDH mode might receive which three advertised quality levels? (Choose three.)

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

Answers:

13. a, b, d

14. b

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




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) 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 reference’s 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 slave’s clock profile

Answers:

15. C

16. c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




17.The SROS IEEE 1588v2/PTPv2 slave implementation uses which three messages’ contents to calculate the clock offset? (Choose three.)

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

Answers:

17. b, c, d

18. a, b, c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




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 network’s 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

Answers:

19. c

20. a, b, d

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




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

Answers:

21. b

22. a

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


TTP36002 Edition 1

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module 3 — Implementing Mobile Backhaul Transport Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Module Objectives

Upon successful completion of this module, you will be able to: 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 — Mobile Backhaul Service Fundamentals

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Review the SROS service components: Customer, Service, SAP, SDP

Review SAP and SDP characteristics

Determine the type of service required to transport 2G, 3G, or 4G traffic

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Service Components

Service ComponentsThe 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Service Access Point (SAP)

SAP Identifiers Physical Ethernet port, SONET/SDH port or channel, TDM

port or channel Encapsulation identifier (ID) (eg. VLAN ID, Q-tag) Can only be created on Access interfaces

SAP Identifiers Physical Ethernet port, SONET/SDH port or channel, TDM

port or channel Encapsulation identifier (ID) (eg. VLAN ID, Q-tag) Can only be created on Access interfaces

Service Access Point (SAP)A SAP is a logical entity that serves as the customer’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Service Distribution Point (SDP) Characteristics

A service distribution point (SDP) acts as a logical way to direct traffic from one router to another.

SDPs are locally unique; the same SDP ID can be used on another router

SDPs use the System IP address to identify far end destinations

SDP is not specific to one service; many services can use the same SDP

All services bound to an SDP use the same encapsulation as defined by that SDP (GRE or MPLS)

Operations on an SDP will affect all services that are bound to that SDP

A service distribution point (SDP) acts as a logical way to direct traffic from one router to another.

SDPs are locally unique; the same SDP ID can be used on another router

SDPs use the System IP address to identify far end destinations

SDP is not specific to one service; many services can use the same SDP

All services bound to an SDP use the same encapsulation as defined by that SDP (GRE or MPLS)

Operations on an SDP will affect all services that are bound to that SDP

Service Distribution Point (SDP) CharacteristicsA service distribution point (SDP) acts in a logical way to direct traffic from one router to another through a uni-directional (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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Module 3 | 8 All rights reserved © [year] Alcatel-Lucent

Using an SDP within a Service

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.

Using an SDP within a ServiceWhen 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Logical Service Level View

Transport TunnelA 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Service Connectivity by Technology

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

XCDMA 1x Data

Transport type

Connectivity

XXXCDMA 1x Voice

XXGSM

XXLTE

XXUMTS

IP/Ethernet(ePipe/VPLS/VPRN/IES)

IP/Ethernet(ePipe/VPLS/

VPRN/IES)

ATM(aPipe)

TDM(cPipe/iPipe)

Wireless Technology

BS-BSBS/NodeB to Network Controller (NC)

Service Connectivity by TechnologyIn 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 aPipeor 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 customer’s needs.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary

In this section, we:

Reviewed the SROS service components: Customer, Service, SAP, SDP

Reviewed SAP and SDP characteristics

Determined the service types required to transport 2G, 3G, or 4Gtraffic

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 2 — Model 1 Detailed Configuration – 3G Voice and Data

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet Traffic

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

Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet TrafficThis 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 customer’s 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 loopsA

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Model 1 3G Ethernet Services - Overview

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

Model 1 3G Ethernet Services - OverviewThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 3G Ethernet Services Configuration Phases

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

Model 1 3G Ethernet Services Configuration PhasesPhase 1 - CSA1 to MLS ePipeePipe 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 VPLSVPLS 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 VPRNThe 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 service’s 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 NodeB’s 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_MLSxThe 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 VPLSThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 – Phase 1 – Distributed ePipes with PW Redundancy

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 – Model 1 3G Distributed ePipe SAPs

A:CSA1>config>service# epipe 1 customer 1 create

config>service>epipe$ description “Distributed epipe for 3G Voice"

config>service>epipe# sap 1/1/1:100 create

config>service>epipe>sap# back

config>service>epipe# no shutdown

A:CSA1>config>service# epipe 1 customer 1 create

config>service>epipe$ description “Distributed epipe for 3G Voice"

config>service>epipe# sap 1/1/1:100 create

config>service>epipe>sap# back


• SAPs are only configured on the CSA router• Spoke SDPs terminate the ePipe into the MLS router “outer” VPLS

Phase 1 – Model 1 3G Distributed ePipe SAPsTo 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-sdpsdp-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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 - Pseudowire (PW) Redundancy

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

Phase 1 - Pseudowire (PW) RedundancyAlready 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 PE’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 - Configuring Redundant Pseudowires

Pseudowire redundancy supported on all VPWS Default spoke SDP precedence is none (4) Service SAP in a second, implied endpoint

Context: config>service>epipe

Syntax: [no] endpoint <endpoint-name> create revert-time [revert-time|infinite]

[no] spoke-sdp <sdp-id:vc-id> endpoint <endpoint-name> create

Context: config>service>epipe>spoke-sdp

Syntax: [no] precedence <precedence-value>| primary

Example: config>service>epipe# endpoint ENET_BTS1_URC1 create

config>service>epipe>endpoint$ revert-time 90

config>service>epipe>endpoint$ back

config>service>epipe# spoke-sdp 1:1 endpoint ENET_BTS1_URC1 create

config>service>epipe>spoke-sdp$ precedence primary

config>service>epipe>spoke-sdp$ back



config>service>epipe# exit all


Syntax: [no] endpoint <endpoint-name> create revert-time [revert-time|infinite]

[no] spoke-sdp <sdp-id:vc-id> endpoint <endpoint-name> create

Context: config>service>epipe>spoke-sdp

Syntax: [no] precedence <precedence-value>| primary

Example: config>service>epipe# endpoint ENET_BTS1_URC1 create

config>service>epipe>endpoint$ revert-time 90



config>service>epipe>spoke-sdp$ precedence primary




config>service>epipe# exit all

Phase 1 - Configuring Redundant PseudowiresSROS supports PW redundancy on aPipe, cPipe, ePipe, fPipe, and iPipe VPWS, as well as VPLS.EndpointEndpoint 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 timeIn 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 CreationUpon the spoke SDP’s creation, you must specify the endpoint object to which it belongs. You may not add an endpoint assignment once you’ve 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 PEThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 - Pseudowire Status Flags

Pseudowire Not Forwarding (MTU problems, etc)0x000000015

Remote pseudowire active, remote SAP is down0x000000063

8

7

6

4

2

1

Priority DescriptionPeer PW Status TLV Flag

Remote pseudowire in standby and not forwarding0x00000021

Remote pseudowire is active but operationally down0x00000018

Remote pseudowire is in standby and operationally down0x00000038

Remote pseudowire in standby, remote SAP is down0x00000026

Pseudowire forwarding ( clear all failures )0x00000000

Pseudowire forwarding Standby0x00000020

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

Phase 1- Pseudowire Status FlagsThe 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 peer’s spoke SDP status by reading the LDP status bits in the T-LDP PW-Status TLV. These bits indicate the remote spoke SDP’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 - Choosing the Active Pseudowire

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)

Phase 1 - Choosing the Active PseudowireInitially, 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 SDP’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 - View the Local PE Endpoint Status

A:CSA1# show service id 1 endpoint

===============================================================================

Service 1 endpoints

===============================================================================

Endpoint name : Enet_BTS1_URC1_CSA1

Description : (Not Specified)

Revert time : 90

Act Hold Delay : 0

Standby Signaling Master : false

Standby Signaling Slave : false

Tx Active : 1:1

Tx Active Up Time : 0d 00:16:20

Revert Time Count Down : N/A

Tx Active Change Count : 4

Last Tx Active Change : 08/10/2011 12:38:07

-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------

Spoke-sdp: 1:1 Prec:0 Oper Status: Up


===============================================================================

===============================================================================


===============================================================================

Service 1 endpoints

===============================================================================

Endpoint name : Enet_BTS1_URC1_CSA1


Revert time : 90

Act Hold Delay : 0



Tx Active : 1:1





-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================

Phase 1 - View the Local PE Endpoint StatusA: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 PE’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 – Signaling the Secondary as Standby

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

Phase 1 – Signaling the Secondary as StandbySince 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 PE’s 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 SDP’s egress service label as Status Signaled Down.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 - View the Remote PE LDP Bindings

A:MLS1# show router ldp bindings service-id 1 detail

===============================================================================

LDP LSR ID: 192.0.2.0

===============================================================================

...

-------------------------------------------------------------------------------

Type : V-Eth VcId : 1

SvcId : 1 SdpId : 2

Peer Address : 192.0.2.2 Vc-switching : No

LMTU : 1500 RMTU : 1500

Egr. Lbl : 131064D Egr. Ctl Word : No

Egr. Flags : None Egr. Status Bits : Supported (0x20)

Egr. Flow Label Tx : No Egr. Flow Label Rx: No

Ing. Lbl : 131062U Ing. Ctl Word : No

Ing. Flags : None Ing. Status Bits : Supported (0x0)

Ing. Flow Label Tx : No Ing. Flow Label Rx: No

===============================================================================

No. of VC Labels: 2

===============================================================================

...


===============================================================================

LDP LSR ID: 192.0.2.0

===============================================================================

...

-------------------------------------------------------------------------------

Type : V-Eth VcId : 1

SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500



Egr. Flow Label Tx : No Egr. Flow Label Rx: No



Ing. Flow Label Tx : No Ing. Flow Label Rx: No

===============================================================================

No. of VC Labels: 2

===============================================================================

...

Phase 1 - View the Remote PE LDP BindingsA: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.


===============================================================================

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 1 – CSA1 Spoke SDP Bindings

Redundant PWs protect against nodal failures

Can protect against mis-configuration or provisioning errors, but lost or dropped packets may occur

Phase 1 – CSA1 Spoke SDP BindingsFailure 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 – Phase 2 – Outer VPLS Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 - VPLS Service Definition

MLS1# configure service MLS1>config>service# vpls 1 customer 1 createMLS1>config>service>vpls$ no shutdown

MLS1# configure service MLS1>config>service# vpls 1 customer 1 createMLS1>config>service>vpls$ no 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>

Phase 2 – VPLS Service CreationShow above is the service creation command on MLS1; MLS2 mirrors this configuration in all ways but the spoke SDP sdp-id:vc-id.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 – Creating the Spoke SDP Binding

A:MLS1>config>service>vpls# spoke-sdp 1:1 create

A:MLS1>config>service>vpls>spoke-sdp$ back


A:MLS1>config>service>vpls>spoke-sdp$ exit

A:MLS1>config>service>vpls# info

----------------------------------------------

stp

shutdown

exit

spoke-sdp 1:1 create


exit

no shutdown

----------------------------------------------


A:MLS1>config>service>vpls>spoke-sdp$ back




----------------------------------------------

stp

shutdown

exit



exit

no 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

Phase 2 – Creating the Spoke SDP BindingFor 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 don’t have to match within the service.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 – Spoke SDP Split Horizon GroupsA:MLS1>config>service>vpls# split-horizon-group “group1” create

A:MLS1>config>service>vpls>split-horizon-group# back

A:MLS1>config>service>vpls# spoke-sdp 1:1 split-horizon-group group1 create



----------------------------------------------

stp

shutdown

exit

spoke-sdp 1:1 split-horizon-group "group1" create

no shutdown

exit


no shutdown

exit

no shutdown

----------------------------------------------

A:MLS1>config>service>vpls# split-horizon-group “group1” create

A:MLS1>config>service>vpls>split-horizon-group# back

A:MLS1>config>service>vpls# spoke-sdp 1:1 split-horizon-group group1 create



----------------------------------------------

stp

shutdown

exit


no shutdown

exit


no shutdown

exit

no 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

Phase 2 – Spoke SDP Split Horizon GroupsSplit 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 – Phase 2 – Cross Connected Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 - Versatile Services Module (VSM) for CCAG SAPs

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 half-duplex

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

Phase 2 - Versatile Services Module (VSM) for CCAG SAPsBoth 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 vsm-cca’s 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). A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Phase 2 - Cross Connect Aggregation Group (CCAG)

CCAG includes one or more VSMs Up to 8 VSMs per CCAG

Phase 2 - CCAGThe 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 VSMswithin the group.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 - Cross Connect Identifier (CCID)

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

CCID – Cross Connect IdentifierServices 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 PathsThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 - Provision a CCAG

For resiliency and load balancing, a typical deployment would assign at least two VSMs as member-cca’s

The default path MTU is 1514 You must define both paths a and b

Context: config>vsm

Syntax: [no] ccag <ccag-id> create

[no] description

[no] member-cca <card-slot/mda-number>

path <path-id> sap-sap [no] mtu <mtu-bytes>

Example: config>vsm# ccag 1 create

config>vsm>ccag# description “Service Cross Connect CSA1-MLS1 VPLS”

config>vsm>ccag# member-cca 5/1

config>vsm>ccag# path a sap-sap mtu 9212config>vsm>ccag# path b sap-sap mtu 9212

config>vsm>ccag# exit all

Context: config>vsm

Syntax: [no] ccag <ccag-id> create

[no] description

[no] member-cca <card-slot/mda-number>

path <path-id> sap-sap [no] mtu <mtu-bytes>

Example: config>vsm# ccag 1 create

config>vsm>ccag# description “Service Cross Connect CSA1-MLS1 VPLS”

config>vsm>ccag# member-cca 5/1

config>vsm>ccag# path a sap-sap mtu 9212config>vsm>ccag# path b sap-sap mtu 9212

config>vsm>ccag# exit all

Phase 2 – Provision a CCAGThis 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 CCAGccag-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-cca’s.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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 – Create the Outer VPLS CCAG SAP

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

A:MLS1>config>service>vpls# sap ccag-1.b:1 create

A:MLS1>config>service>vpls>sap$ back


----------------------------------------------

stp

shutdown

exit

sap ccag-1.b:1 create

description “Outer VPLS 1 to VPRN 2 crossconnect”

exit

no shutdown

----------------------------------------------

A:MLS1>config>service>vpls# sap ccag-1.b:1 create

A:MLS1>config>service>vpls>sap$ back


----------------------------------------------

stp

shutdown

exit

sap ccag-1.b:1 create

description “Outer VPLS 1 to VPRN 2 crossconnect”

exit

no shutdown

----------------------------------------------

Phase 2 – Create the outer VPLS CCAG SAPThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 - View the CCAG SAP

Default encap-type is q-tag Loopback (hairpin) cables could also be used, but would tie up

two physical ports

A:MLS1# show service id 1 sap ccag-1.b:1

===============================================================================

Service Access Points(SAP)

===============================================================================

Service Id : 1

SAP : ccag-1.b:1 Encap : q-tag

Description : Outer VPLS 1 to VPRN 2 crossconnect

Admin State : Up Oper State : Up

Flags : None

Multi Svc Site : None

Last Status Change : 08/22/2011 11:16:38

Last Mgmt Change : 08/22/2011 11:14:38

===============================================================================


===============================================================================


===============================================================================

Service Id : 1


Description : Outer VPLS 1 to VPRN 2 crossconnect


Flags : None



Last Mgmt Change : 08/22/2011 11:14:38

===============================================================================

Phase 2 - View the CCAG SAPA:NodeA# show service id 1 sap ccag-1.a:1

Encap: – Always q-tag.

Hairpins in place of CCAGIn 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 – Routed VPLS

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

Phase 2 – Routed VPLSA 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-VPLSThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 2 – Routed VPLS (cont)

In the VPRN, an interface must be bound to the VPLS service.A:MLS1>config>service>vprn# interface toOuterVPLS vpls OuterVPLS

A:MLS1# show router 2 interface "toOuterVPLS"

===============================================================================

Interface Table (Service: 2)

===============================================================================

Interface-Name Adm Opr(v4/v6) Mode Port/SapId

IP-Address PfxState

-------------------------------------------------------------------------------

toOuterVPLS Up Up/-- VPRN rvpls

203.0.113.1/30 n/a

-------------------------------------------------------------------------------

Interfaces : 1

===============================================================================

A:MLS1# show router 2 interface "toOuterVPLS"

===============================================================================


===============================================================================


IP-Address PfxState

-------------------------------------------------------------------------------

toOuterVPLS Up Up/-- VPRN rvpls

203.0.113.1/30 n/a

-------------------------------------------------------------------------------

Interfaces : 1

===============================================================================

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>

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 – Phase 3 – Local VPRN Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – Create the MLS router Local VPRN Service

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 PE’s service needs a route distinguisher to build its local VRF

A:MLS1>config>service# vprn 2 customer 1 create

A:MLS1>config>service>vprn$ description "VPRN Service for 3G Voice Traffic"

A:MLS1>config>service>vprn$ router-id 198.51.100.1

A:MLS1>config>service>vprn$ route-distinguisher 65000:2

A:MLS1>config>service>vprn$ no shutdown
















Phase 3 – Create the MLS router Local VPRN ServiceThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 - Create the VPRN Interfaces

The MLS routers host multiple local VPRNs, one for voice, data, and OAM traffic Each traffic type’s 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# interface outer_VPLS1

A:MLS1>config>service>vprn>if$ sap ccag-1.a:1

A:MLS1>config>service>vprn>if$ ip-address 192.0.2.1/27

A:MLS1>config>service>vprn>if$ mac 00:00:00:00:01:01

A:MLS1>config>service>vprn>if$ static-arp 192.0.2.2 00:00:00:00:01:02

A:MLS1>config>service>vprn>if$ back

A:MLS1>config>service>vprn# interface inner_VPLS3




A:MLS1>config>service>vprn# interface to_MLS2


A:MLS1>config>service>vprn>if$ sap lag-1:1




A:MLS1>config>service>vprn>if$ mac 00:00:00:00:01:01

A:MLS1>config>service>vprn>if$ static-arp 192.0.2.2 00:00:00:00:01:02






A:MLS1>config>service>vprn# interface to_MLS2


A:MLS1>config>service>vprn>if$ sap lag-1:1

Phase 3 – Create the VPRN InterfaceIn 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 ePipe’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – Configure DHCP Relay for Data Only services

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

A:MLS1>config>service>vprn# interface to_BTS1_URC1_DO

A:MLS1>config>service>vprn>if# dhcp

A:MLS1>config>service>vprn>if>dhcp$ server 192.168.1.1 192.168.1.2

A:MLS1>config>service>vprn>if>dhcp$ gi-address 198.51.100.65

A:MLS1>config>service>vprn>if>dhcp$ no shutdown

A:MLS1>config>service>vprn>if>dhcp$ back

A:MLS1>config>service>vprn# interface to_BTS1_URC1_DO

A:MLS1>config>service>vprn>if# dhcp

A:MLS1>config>service>vprn>if>dhcp$ server 192.168.1.1 192.168.1.2

A:MLS1>config>service>vprn>if>dhcp$ gi-address 198.51.100.65

A:MLS1>config>service>vprn>if>dhcp$ no shutdown

A:MLS1>config>service>vprn>if>dhcp$ back

Phase 3 – Configure DHCP Relay for Data Only servicesDHCP 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – View DHCP Relay Configuration

A:MLS1# show router 3 interface to_BTS1_URC1_DO detail

===============================================================================


===============================================================================

-------------------------------------------------------------------------------

Interface

-------------------------------------------------------------------------------

If Name : to_BTS1_URC1_DO

Admin State : Up Oper (v4/v6) : Up/--

Protocols : OSPFv2

IP Addr/mask : 198.51.100.65/27 Address Type : Primary

IGP Inhibit : Disabled Broadcast Address : Host-ones

...

DHCP Details


Admin State : Up Lease Populate : 0

Servers : 192.168.1.1 192.168.1.2

Gi-Addr : 198.51.100.65 Gi-Addr as Src Ip : Disabled

* = inferred gi-address from interface IP address

A:MLS1# show router 3 interface to_BTS1_URC1_DO detail

===============================================================================


===============================================================================

-------------------------------------------------------------------------------

Interface

-------------------------------------------------------------------------------

If Name : to_BTS1_URC1_DO

Admin State : Up Oper (v4/v6) : Up/--

Protocols : OSPFv2

IP Addr/mask : 198.51.100.65/27 Address Type : Primary

IGP Inhibit : Disabled Broadcast Address : Host-ones

...

DHCP Details


Admin State : Up Lease Populate : 0

Servers : 192.168.1.1 192.168.1.2

Gi-Addr : 198.51.100.65 Gi-Addr as Src Ip : Disabled

* = inferred gi-address from interface IP address

Phase 3 – Configure DHCP Relay for Data Only servicesA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – Configure Static ARP Entries

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 MAC’s are unique within the VPRN service


A:MLS1>config>service>vprn>if# mac 00:00:00:01:00:01

A:MLS1>config>service>vprn>if# static-arp 192.0.2.2 00:00:00:01:00:02

A:MLS1>config>service>vprn>if#


A:MLS1>config>service>vprn>if# mac 00:00:00:01:00:01

A:MLS1>config>service>vprn>if# static-arp 192.0.2.2 00:00:00:01:00:02

A:MLS1>config>service>vprn>if#

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – VRRP on NC VPRN interfaces

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

Phase 3 – VRRP on NC VPRN InterfacesConsider the diagram above. Both MLS1 and MLS2 have interfaces attached to a common subnet, 192.0.2.32/27. MLS1’s interface IP address is 192.0.2.33/27, while MLS2’s 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 VRID’s 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 VRID’s virtual interface uses an IP address belonging to the master’s real interface. In non-owner 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 master’s 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 router’s real interface instead of the master’s. 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 1-255, 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – VRRP Load Balancing

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

Phase 3 – VRRP Load BalancingVRRP 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 1’s virtual interface address. MLS2 is master for VRID 2 and its real interface IP address 192.0.2.34 becomes VRID 2’s virtual interface address.

VRID 1 is configured as follows:

Router MLS1 real interface IP address: 192.0.2.33/27


Virtual interface address (MLS1’s interface IP): 192.0.2.33/27

Master router: Router MLS1

Backup router: Router MLS2

VRID 2 is configured as follows:



Virtual interface address (MLS2’s 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 1’s virtual interface as their default gateway, while others use VRID 2’s virtual interface. If MLS1 fails, VRID 1 traffic routes through backup MLS2. If MLS2 fails, VRID 2 traffic routes through MLS1.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – VRRP Advertisements and Elections

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

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 router’s 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 interface’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – Configure VRRP in the VPRN Service


A:MLS1>config>service>vprn>if# vrrp 1

A:MLS1>config>service>vprn>if>vrrp$ backup 192.0.2.35

A:MLS1>config>service>vprn>if>vrrp$ priority 230

A:MLS1>config>service>vprn>if>vrrp$ no preempt

A:MLS1>config>service>vprn>if>vrrp$ ping-reply

A:MLS1>config>service>vprn>if>vrrp$ back

A:MLS1>config>service>vprn>if# exit all




A:MLS1>config>service>vprn>if>vrrp$ priority 230



















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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – VRRP Recovery

MLS1 master interface goes offline MLS2 VRRP Master Down Timer expires MLS2 becomes the master interface and sends a gratuitous ARP

for the virtual interface MAC into the network The NC element forwards frames toward the virtual interface

MAC address, which the switch has learned on MLS2 facing port

1

2

3

4

Phase 3 – VRRP RecoveryIf MLS1 goes offline or the interface goes down, MLS2 will time out the master and itself become the master.

MLS2’s 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_Timerand transition to backup.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 3 – Routing in the VRPN

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 area 0.0.0.51

A:MLS1>config>service>vprn>ospf>area$ interface to_VPLS2

A:MLS1>config>service>vprn>ospf>area>if$ passive

A:MLS1>config>service>vprn>ospf>area>if$ back

A:MLS1>config>service>vprn>ospf>area$ interface toMLS2


A:MLS1>config>service>vprn>ospf>area$ back

A:MLS1>config>service>vprn>ospf$ back

A:MLS1>config>service>vprn# ospf area 0.0.0.51

A:MLS1>config>service>vprn>ospf>area$ interface to_VPLS2

A:MLS1>config>service>vprn>ospf>area>if$ passive


A:MLS1>config>service>vprn>ospf>area$ interface toMLS2


A:MLS1>config>service>vprn>ospf>area$ back

A:MLS1>config>service>vprn>ospf$ back

Phase 3 – Routing in the VPRNAn 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 MLS2’s service.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 1 – Phase 4 – Inner VPLS Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 4 – Inner VPLS Management VPLS (mVPLS)

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

VPLS 4sap 1/1/4:4sap lag-1:4sap ccag-1.b:4




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 RSTPrecognizes 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 4 – Inner VPLS Management VPLS (mVPLS) (cont)

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

mVPLS 3000stp priority 28762sap 1/1/4:3000

managed-vlan-list range 4-4

sap lag-1:3000managed-vlan-list range 4-4










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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 4 – View the mVPLS Status

A:MLS1# show service service-using vpls==============================================================================

Services [vpls]

===============================================================================

ServiceId Type Adm Opr CustomerId Service Name

-------------------------------------------------------------------------------

4 uVPLS Up Up 1

3000 mVPLS Up Up 1

-------------------------------------------------------------------------------

Matching Services : 2

-------------------------------------------------------------------------------

===============================================================================


Services [vpls]

===============================================================================


-------------------------------------------------------------------------------

4 uVPLS Up Up 1

3000 mVPLS Up Up 1

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

===============================================================================A:MLS2# show service service-using vpls==============================================================================

Services [vpls]

===============================================================================


-------------------------------------------------------------------------------

4 uVPLS Up Up 1

3000 mVPLS Up Up 1

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


Services [vpls]

===============================================================================


-------------------------------------------------------------------------------

4 uVPLS Up Up 1

3000 mVPLS Up Up 1

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

Phase 4 – View the mVPLS StatusA: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 mVPLSinstance.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 4 – Verifying the mVPLS – MLS1

A:MLS1# show service id 3000 stp

===============================================================================

Stp info, Service 3000

===============================================================================

Bridge Id : 70:00.62:aa:ff:00:00:00 Top. Change Count : 1

Root Bridge : 70:00.62:a9:ff:00:00:00 Stp Oper State : Up

Primary Bridge : N/A Topology Change : Inactive

Mode : Rstp Last Top. Change : 0d 01:00:56

Vcp Active Prot. : N/A

Root Port : 2049 External RPC : 10

===============================================================================

Stp port info

===============================================================================

Sap/Sdp/PIP Id Oper- Port- Port- Port- Oper- Link- Active

State Role State Num Edge Type Prot.

-------------------------------------------------------------------------------

1/1/4:3000 Up Designated Forward 2048 True Pt-pt Rstp

lag-1:3000 Up Root Forward 2049 False Pt-pt Rstp

===============================================================================

A:MLS1# show service id 3000 stp

===============================================================================

Stp info, Service 3000

===============================================================================

Bridge Id : 70:00.62:aa:ff:00:00:00 Top. Change Count : 1

Root Bridge : 70:00.62:a9:ff:00:00:00 Stp Oper State : Up

Primary Bridge : N/A Topology Change : Inactive

Mode : Rstp Last Top. Change : 0d 01:00:56

Vcp Active Prot. : N/A

Root Port : 2049 External RPC : 10

===============================================================================

Stp port info

===============================================================================

Sap/Sdp/PIP Id Oper- Port- Port- Port- Oper- Link- Active

State Role State Num Edge Type Prot.

-------------------------------------------------------------------------------

1/1/4:3000 Up Designated Forward 2048 True Pt-pt Rstp

lag-1:3000 Up Root Forward 2049 False Pt-pt Rstp

===============================================================================

mVPLSmVPLS

Phase 4 – Verifying the mVPLS – MLS1A:NodeA# show service id 3000 stp

•Port role – Either root, designated, alternate, or backup.

•Port state – Discard, block, listen or forward.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Phase 4 – Verifying the mVPLS – MLS1 (cont)

A:MLS1# show service id 4 stp===============================================================================

Inherited Stp State (from mVPLS), Service 4

===============================================================================

Sap/Spoke Id Oper- Prune- Port- Mngd by Mngd by Mngd by

State State State Service Sap/spoke MSTI

-------------------------------------------------------------------------------

1/1/4:4 Up - Forward 3000 1/1/4:3000 CIST

lag-1:4 Up - Forward 3000 lag-1:3000 CIST

===============================================================================

A:MLS1# show service id 4 stp===============================================================================

Inherited Stp State (from mVPLS), Service 4

===============================================================================

Sap/Spoke Id Oper- Prune- Port- Mngd by Mngd by Mngd by

State State State Service Sap/spoke MSTI

-------------------------------------------------------------------------------

1/1/4:4 Up - Forward 3000 1/1/4:3000 CIST

lag-1:4 Up - Forward 3000 lag-1:3000 CIST

===============================================================================

uVPLSuVPLS

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.

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 3G Ethernet – Detailed Configuration

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 7 : Configure ePipe, VPRN and VPLS for 3G Voice Service

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

1.5 HourMLS2

MLS1

CSA1

CSA2

CR1

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary

In this section, we :

Reviewed the Model 1 3G Ethernet voice, data, and control traffic paths and services

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 3 — Model 1 Detailed Configuration – 3G TDM

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Review the Model 1 3G TDM BS traffic paths and services

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – iPipes/VPRN for 3G IP-over-TDM (IPoTDM) Voice Traffic

Model 1 - Ethernet Backhaul (EBH) - iPipes• 3G iPipes cross-connect into MLS VPRN interfaces• Carried over the same transport as the ePipes

Model 1 – iPipes/VPRN for 3G IP-over-TDM (IPoTDM) Voice TrafficA 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 3G IPoTDM over iPipes Overview

CSA-MLS iPipes for 3G IPoTDM Voice and Control traffic PW redundancy on the CSAs Distributed iPipes at CSA and MLS routers iPipes cross connected into MLS VPRN services MLS VPRNs cross connected into local VPLS

Model 1 TDM over iPipes OverviewThe diagram above shows an overview of the Model 1 design services to support 3G CDMA voice traffic.CSA1 to MLS iPipesRedundant 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 VPRNThe 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 SAP’s 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 interface’s MAC address as the frame’s 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 VPLSThe 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 iPipes into cross connected VPRN interfaces. VRRP-protected VPRN interfaces forward traffic into inner VPLS SAPs. OSPF runs between the local VPRNs.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Introduction to IP Interworking VPWS (iPipe)

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.

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Distributed 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

Model 1 – Distibuted iPipeConfigured 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



iPipe ce-address and Forwarding Behavior

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)

iPipe ce-address and Forwarding BehaviorWhen 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 iPipeSAP 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Configuring an Ipipe Service

A:CSA1>config>service# ipipe 10 customer 1 create

config>service>ipipe$ description “Distributed ipipe for 3G TDM Services"

config>service>ipipe# sap bundle-ppp-1/1.10 create

config>service>ipipe>sap$ back

config>service>ipipe>sap$ ce-address 192.0.2.162

config>service>ipipe>sap$ ipcp

config>service>ipipe>sap>ipcp$ assign-peer-ce-addr

config>service>ipipe>sap>ipcp$ dns 198.151.100.250

config>service>ipipe>sap>ipcp$ back

config>service>ipipe# no shutdown

A:CSA1>config>service# ipipe 10 customer 1 create

config>service>ipipe$ description “Distributed ipipe for 3G TDM Services"

config>service>ipipe# sap bundle-ppp-1/1.10 create

config>service>ipipe>sap$ back

config>service>ipipe>sap$ ce-address 192.0.2.162

config>service>ipipe>sap$ ipcp

config>service>ipipe>sap>ipcp$ assign-peer-ce-addr

config>service>ipipe>sap>ipcp$ dns 198.151.100.250

config>service>ipipe>sap>ipcp$ back

config>service>ipipe# no shutdown

Model 1 – Configuring an iPipe ServiceThis 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 BTS’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Configuring Distributed Ipipe SAPs

A:MLS1>config>service# ipipe 10 customer 1 create

config>service>epipe# sap ccag-1.b:10 create

config>service>epipe>sap# ce-address 192.0.2.161

A:MLS1>config>service# ipipe 10 customer 1 create

config>service>epipe# sap ccag-1.b:10 create

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

Model 1 – Configuring Distributed iPipe SAPsA CE address corresponding to the local end CE address needs to be configured under the SAP context before the SAP will come up operationally.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Configuring the iPipe Primary SDP Bindings

Example:

A:CSA1>config>service# ipipe 10

A:CSA1>config>service>ipipe# endpoint ipipe create

A:CSA1>config>service>ipipe>endpoint$ back

A:CSA1>config>service>ipipe$ spoke-sdp 1:10 endpoint ipipe create precedence primary

A:CSA1>config>service>ipipe# spoke-sdp 1:10 ce-address 192.0.2.161

Example:

A:MLS1>config>service# ipipe 10

A:MLS1>config>service>ipipe# spoke-sdp 1:10 create

A:MLS1>config>service>ipipe>spoke-sdp$ ce-address 192.0.2.162

Example:




A:CSA1>config>service>ipipe$ spoke-sdp 1:10 endpoint ipipe create precedence primary

A:CSA1>config>service>ipipe# spoke-sdp 1:10 ce-address 192.0.2.161

Example:




Model 1 – Configuring the iPipe Primary SDP BindingsNote 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Configuring the iPipe Secondary SDP Bindings

Example:




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

Example:




Example:




A:CSA1>config>service>ipipe$ spoke-sdp 2:10 endpoint ipipe create


Example:




Model 1 – Configuring the iPipe Secondary SDP BindingsSecondary 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


You would also configure the iPipe on MLS2.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Verifying the CSA iPipe Service

A:CSA1# show service id 10 base

===============================================================================

Service Basic Information

===============================================================================

Service Id : 10

Service Type : Ipipe

Description : MLPPP_BTS10_URC10

Customer Id : 1

Last Status Change: 08/23/2011 13:25:52

Last Mgmt Change : 08/23/2011 13:26:28


MTU : 1500

Vc Switching : False

SAP Count : 1 SDP Bind Count : 2

...

-------------------------------------------------------------------------------

Service Access & Destination Points

-------------------------------------------------------------------------------

Identifier Type AdmMTU OprMTU Adm Opr

-------------------------------------------------------------------------------

sap:bundle-ppp-1/1.10 ipcp 1526 1526 Up Up

sdp:1:10 S(192.0.2.0) n/a 0 1546 Up Up

sdp:2:10 S(192.0.2.1) n/a 0 1546 Up Up

===============================================================================


===============================================================================


===============================================================================

Service Id : 10

Service Type : Ipipe


Customer Id : 1


Last Mgmt Change : 08/23/2011 13:26:28


MTU : 1500



...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:bundle-ppp-1/1.10 ipcp 1526 1526 Up Up

sdp:1:10 S(192.0.2.0) n/a 0 1546 Up Up

sdp:2:10 S(192.0.2.1) n/a 0 1546 Up Up

===============================================================================

Model 1 – Verifying the CSA iPipe ServiceA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Verifying the CSA iPipe Bundle SAP

A:CSA1# show service id 10 sap bundle-ppp-1/1.10

===============================================================================


===============================================================================

Service Id : 10

SAP : bundle-ppp-1/1.10 Encap : ipcp



Flags : None



Last Mgmt Change : 08/23/2011 13:09:57

-------------------------------------------------------------------------------

Ipipe SAP Configuration Information

-------------------------------------------------------------------------------

Ce IP Address : 192.0.2.162 Assign to Peer : false

Peer Pri DNS Addr : 198.51.100.250

Peer Sec DNS Addr : Not configured

Configured CE IP : 192.0.2.162 Discovered CE IP : n/a

...

A:CSA1# show service id 10 sap bundle-ppp-1/1.10

===============================================================================


===============================================================================

Service Id : 10

SAP : bundle-ppp-1/1.10 Encap : ipcp



Flags : None



Last Mgmt Change : 08/23/2011 13:09:57

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

Ce IP Address : 192.0.2.162 Assign to Peer : false

Peer Pri DNS Addr : 198.51.100.250

Peer Sec DNS Addr : Not configured

Configured CE IP : 192.0.2.162 Discovered CE IP : n/a

...

Model 1 - Verifying the CSA iPipe Bundle SAPA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Verifying the iPipe MLS1 Ethernet SAP


===============================================================================


===============================================================================

Service Id : 10




Flags : None



Last Mgmt Change : 08/23/2011 14:32:04

...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

Configured CE IPv4 : 192.0.2.161 Discovered CE IPv4: n/a

SAP MAC Address : 00:00:00:10:00:10 Mac Refresh Inter*: 14400

...

Ipipe SAP IPv4 ARP Entry Info

-------------------------------------------------------------------------------

192.0.2.161 62:aa:ff:00:02:19 dynamic 03h59m39s


===============================================================================


===============================================================================

Service Id : 10




Flags : None



Last Mgmt Change : 08/23/2011 14:32:04

...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

Configured CE IPv4 : 192.0.2.161 Discovered CE IPv4: n/a

SAP MAC Address : 00:00:00:10:00:10 Mac Refresh Inter*: 14400

...

Ipipe SAP IPv4 ARP Entry Info

-------------------------------------------------------------------------------

192.0.2.161 62:aa:ff:00:02:19 dynamic 03h59m39s

Model 1 - Verifying the iPipe MLS1 Ethernet SAPThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 3G IPoTDM iPipes – Detailed View

Model 1 3G IPoTDM iPipes – Detailed ViewThe 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 bundle’s assign-peer-ce-addr command tells the CSA router to send the URC its IP address, and the DNS entry becomes the URC’s 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 won’t 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Summary


Reviewed the Model 1 3G TDM traffic paths and services

Provisioned the 3G TDM voice traffic distributed iPipe services

Provisioned the 3G TDM voice traffic VPRN service interfaces

Employed redundant pseudowires in the iPipe service

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 4 — Model 1 Detailed Configuration – 4G LTE Voice and Data Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Review the Model 1 LTE services

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – ePipes, IES, and Local VPLS for LTE Traffic

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

Model 1 – ePipes, IES, and Local VPLS for LTE TrafficThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 LTE Services Overview

CSA-MLS ePipes for eNodeB VLANs – User and OAM traffic PW redundancy on the CSAs ePipes spoked into MG IES VRRP protected IES for MME VPLS traffic Network interfaces to other EPC elements

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – LTE S1-MME Traffic

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

Model 1 – LTE S1-MME TrafficThe 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 UE’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 –LTE S1-U 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

Model 1 –LTE S1-U TrafficThe 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 UE’s 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 UE’s user traffic. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Model 1 – EPC Element Traffic Flows – S5, S6a, S11, and Gx

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)

Model 1 – EPC Element Traffic Flows – S5, S6a, S11, and GxAll traffic between the EPC elements is routed at the MLS routers, either directly or alternately over the inter-

chassis 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 InterfaceThe 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 InterfaceThe 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 subscriber’s 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 user’s location and IP information which could be needed by various

network entities(continued on the next page...)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – X2 Interface for eNodeB to eNodeB Traffic

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

Model 1 – X2 Interface for eNodeB to eNodeB TrafficX2 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Create the MLS eNodeB and MME IES Services

A:MLS1>config>service# ies 2000 customer 1 create

A:MLS1>config>service>ies$ description “L3 MME-1 VRRP VPLS"

A:MLS1>config>service>ies$ no shutdown


A:MLS1>config>service>ies$ description “L3 MME-1 VRRP VPLS"



A:MLS2>config>service>ies$ description " L3 MME-1 VRRP VPLS "



A:MLS2>config>service>ies$ description " L3 MME-1 VRRP VPLS "



A:MLS2>config>service>ies$ description "eNodeB IES"



A:MLS2>config>service>ies$ description "eNodeB IES"



A:MLS1>config>service>ies$ description “eNodeB IES"



A:MLS1>config>service>ies$ description “eNodeB IES"


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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Create the MLS eNodeB IES Interfaces

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# interface “toEnodeB_1_telecom” create

A:MLS1>config>service>ies>if$ spoke-sdp 1:100 create

A:MLS1>config>service>ies>if>spoke-sdp$ back

A:MLS1>config>service>ies>if$ address 192.0.2.176/31

A:MLS1>config>service>ies>if$ mac 00:00:01:00:01:01

A:MLS1>config>service>ies>if$ static-arp 192.0.2.177 00:00:01:00:01:02

A:MLS1>config>service>ies>if$ back

A:MLS1>config>service>ies# interface “toEnodeB_1_OAM”



A:MLS1>config>service>ies>if$ ip-address 192.0.2.178/31



A:MLS1>config>service>ies>if$ backA:MLS1>config>service>ies#

A:MLS1>config>service>ies# interface “toEnodeB_1_telecom” create







A:MLS1>config>service>ies# interface “toEnodeB_1_OAM”



A:MLS1>config>service>ies>if$ ip-address 192.0.2.178/31



A:MLS1>config>service>ies>if$ backA:MLS1>config>service>ies#

Model 1 - Create the MLS eNodeB IES InterfacesThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 – Set the IES Service VC-MTU

A:MLS1>config>service>sdp# path-mtu 1514A:MLS1>config>service>sdp# path-mtu 1514

A:MLS1>config>service>ies# interface eNodeB_telecom

A:MLS1>config>service>ies>if# ip-mtu 1500

A:MLS1>config>service>ies>if# back

A:MLS1>config>service>ies# interface eNodeB_telecom

A:MLS1>config>service>ies>if# ip-mtu 1500

A:MLS1>config>service>ies>if# 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

or

Model 1 – Set the IES Service Interface MTU SizeMTU 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 don’t 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 service’s 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 interface’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Create the MLS MME VPLS IES Interfaces

The MME IES provides an MME VRRP virtual gateway interface CCAG’s tie the IES to the MME VPLS All routing is handled by the MLS switch fabric, there are no

physical IES interfaces

A:MLS1>config>service>ies# interface “L3 MME VPLS interface”

A:MLS1>config>service>ies>if$ sap ccag-1.a:2000 create

A:MLS1>config>service>ies>if>sap$ back


A:MLS1>config>service>ies>if$ tos-marking-state-trusted

A:MLS1>config>service>ies>if$ vrrp 10

A:MLS1>config>service>ies>if>vrrp$ backup 192.0.2.99

A:MLS1>config>service>ies>if>vrrp$ no preempt

A:MLS1>config>service>ies>if>vrrp$ ping-reply

A:MLS1>config>service>ies>if>vrrp$ back


A:MLS1>config>service>ies#

A:MLS1>config>service>ies# interface “L3 MME VPLS interface”

A:MLS1>config>service>ies>if$ sap ccag-1.a:2000 create

A:MLS1>config>service>ies>if>sap$ back


A:MLS1>config>service>ies>if$ tos-marking-state-trusted

A:MLS1>config>service>ies>if$ vrrp 10

A:MLS1>config>service>ies>if>vrrp$ backup 192.0.2.99

A:MLS1>config>service>ies>if>vrrp$ no preempt

A:MLS1>config>service>ies>if>vrrp$ ping-reply

A:MLS1>config>service>ies>if>vrrp$ back


A:MLS1>config>service>ies#

Model 1 - Create the MLS MME VPLS IES InterfacesThe MLS MME VPLS IES provides a VRRP protected interface for the MME.

•tos-marking-state trusted – An interface’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Verifying the MLS IES 2000 Service

A:MLS1# show service id 2000 base

===============================================================================


===============================================================================

Service Id : 2000 Vpn Id : 0

Service Type : IES

Name : (Not Specified)

Description : L3 MME-1 VRRP VPLS

Customer Id : 1


Last Mgmt Change : 09/28/2011 08:58:35


SAP Count : 1

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:ccag-1.a:2000 q-tag 9212 9212 Up Up

===============================================================================


===============================================================================


===============================================================================


Service Type : IES


Description : L3 MME-1 VRRP VPLS

Customer Id : 1


Last Mgmt Change : 09/28/2011 08:58:35


SAP Count : 1

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:ccag-1.a:2000 q-tag 9212 9212 Up Up

===============================================================================

Model 1 – Verifying the MLS IES 2000 ServiceA:NodeA# show service id 2000 base

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 - Verifying the MLS IES 4000 Service


===============================================================================


===============================================================================


Service Type : IES


Description : eNodeB IES

Customer Id : 1


Last Mgmt Change : 09/28/2011 08:58:35


SAP Count : 0

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sdp:1:100 S(192.0.2.2) Spok 1514 1514 Up Up

sdp:1:101 S(192.0.2.2) Spok 1514 1514 Up Up

===============================================================================


===============================================================================


===============================================================================


Service Type : IES


Description : eNodeB IES

Customer Id : 1


Last Mgmt Change : 09/28/2011 08:58:35


SAP Count : 0

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sdp:1:100 S(192.0.2.2) Spok 1514 1514 Up Up

sdp:1:101 S(192.0.2.2) Spok 1514 1514 Up Up

===============================================================================

Model 1 – Verifying the MLS IES 4000 ServiceA:NodeA# show service id 4000 base

•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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 1 LTE Services – Detailed View

Model 1 LTE Services – Detailed ViewThe 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 router’s 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 MME’s 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. A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Section Review


Reviewed the Model 1 LTE services

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 5 — Service Resiliency in the Model 2 Network

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Implement pseudowire switching to support traffic engineering and control FIB sizes across IGP areas

Investigate MC-LAG as the feature might be used to protect multi-homed Ethernet NC elements

Deploy Interchassis Backup Pseudowires (ICB-PW) to avoid black-holing traffic destined to the standby multi-chassis peer

Provision MC-APS for MLS SONET/SDH protection

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 - Pseudowire Switching across Routing 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

Pseudowire Switching across Routing AreasThe 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 SDP’s 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 FunctionYou 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Switched PW Message Propagation

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 segment’s vc-id and its own

system ID as well as the PW status bits

Message Propagation in a Switched PEThe 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 MessagesThe 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 CSA1’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring PW Switching

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

Context: config>service#

Syntax: [no] epipe <service-id> customer <customer-id> vc-switching create

Context: config>service>epipe#

Syntax: [no] spoke-sdp <sdp-id:vc-id> create

Example: config>service# epipe 3 customer 1 vc-switching create

config>service>epipe$ spoke-sdp 1:1 create


config>service>epipe# spoke-sdp 4:2 create



Context: config>service#

Syntax: [no] epipe <service-id> customer <customer-id> vc-switching create

Context: config>service>epipe#

Syntax: [no] spoke-sdp <sdp-id:vc-id> create

Example: config>service# epipe 3 customer 1 vc-switching create

config>service>epipe$ spoke-sdp 1:1 create


config>service>epipe# spoke-sdp 4:2 create



Configuring PW SwitchingConfigure 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 T-PE1 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the S-PE Service Status

A:POC3-1# show service id 3 base

===============================================================================


===============================================================================


Service Type : Epipe

...


MTU : 1514

Vc Switching : True


...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sdp:1:1 S(192.0.2.2) Spok 0 1550 Up Up

sdp:4:2 S(192.0.2.128) Spok 0 1550 Up Up

===============================================================================

A:POC3-1# show service id 3 base

===============================================================================


===============================================================================



...


MTU : 1514

Vc Switching : True


...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sdp:1:1 S(192.0.2.2) Spok 0 1550 Up Up

sdp:4:2 S(192.0.2.128) Spok 0 1550 Up Up

===============================================================================

View the S-PE Service StatusA:NodeA# show service id 3 base

Vc Switching: – Shows that vc-switching is enabled on the service.

Identifier: - List the spoke SDPs included in the service.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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}

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Multi-Chassis LAG (MC-LAG)

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

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 CE’s 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 CharacteristicsMC-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 signalingThe 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 doesn’t require the peers to be directly connected. The peer address is either the

peer’s 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 selectionThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Module 3 | 107 All rights reserved © 2012 Alcatel-LucentAlcatel-Lucent Virtual Private LAN Services v2.0

LACP Basics

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

LACP BasicsLACP 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



MC-LAG on the Remote PEs

A:MLS1>config>lag# info ----------------------------------------------mode accessport 1/1/1 priority 100port 1/1/2 priority 100lacp active administrative-key 32768 no shutdown

----------------------------------------------*A:PE1>config>redundancy>multi-chassis# info ----------------------------------------------

peer 10.0.0.2 createmc-lag

lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100no shutdown

exitexit

----------------------------------------------

A:MLS1>config>lag# info ----------------------------------------------mode accessport 1/1/1 priority 100port 1/1/2 priority 100lacp active administrative-key 32768 no shutdown




exitexit

----------------------------------------------

*A:MLS2>config>lag# info ----------------------------------------------mode accessport 1/1/1 port 1/1/2 lacp active administrative-key 32768 no shutdown




exitexit

----------------------------------------------

*A:MLS2>config>lag# info ----------------------------------------------mode accessport 1/1/1 port 1/1/2 lacp active administrative-key 32768 no shutdown




exitexit

----------------------------------------------

Create on each MC peer Key, system ID, and system-

priority must match Can assign port priority to

control active peer

MC-LAG on PE NodesWhen 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 NodesThe 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

----------------------------------------------

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PW Redundancy and MC-LAG

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

PW Redundancy and MC-LAGPseudowire 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the Local PE Spoke SDP States

A:CSA1# show router ldp bindings detail

...

===============================================================================

-------------------------------------------------------------------------------

Type : E-Eth VcId : 1

SvcId : 1 SdpId : 1


LMTU : 1500 RMTU : 1500

Egr. Lbl : 131059S Egr. Ctl Word : No




-------------------------------------------------------------------------------


SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500





...


...

===============================================================================

-------------------------------------------------------------------------------


SvcId : 1 SdpId : 1


LMTU : 1500 RMTU : 1500





-------------------------------------------------------------------------------


SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500





...

View the Local PE Spoke SDP StatesA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure

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 isup)

MLS2’s LAG SAP is still in standby, so MLS2 black-holes packets SAP state doesn’t follow SDP state

PW Redundancy and MC-LAG – Spoke SDP 1:1 FailureSpoke 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 doesn’t 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 PE’s SAP status.

Once the LAG recovers, depending on the LAG’s 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 MLS1’s 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). A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure (cont)

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)


...

===============================================================================

LDP Service FEC 128 Bindings

===============================================================================

-------------------------------------------------------------------------------


SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500





===============================================================================

No. of VC Labels: 1

...


...

===============================================================================

LDP Service FEC 128 Bindings

===============================================================================

-------------------------------------------------------------------------------


SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500





===============================================================================

No. of VC Labels: 1

...

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure (cont)

With the LAG SAP in standby, MLS2 shows its ePipe status down MLS2 black holes any traffic arriving over the active spoke SDP


===============================================================================


===============================================================================



...

Admin State : Up Oper State : Down

MTU : 1514

...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:lag-2 null 1514 1514 Up Down

sdp:1:1 S(192.0.2.2) Spok 0 1550 Up Up

===============================================================================


===============================================================================


===============================================================================



...

Admin State : Up Oper State : Down

MTU : 1514

...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


sdp:1:1 S(192.0.2.2) Spok 0 1550 Up Up

===============================================================================

PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure (cont)A:NodeA# show service id 1 base

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Interchassis Backup Pseudowire (ICB-PW)

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

ePipe 1endpoint SAPsap lag-2 endpoint SAPspoke-sdp 3:2 endpoint SAP icbendpoint SPOKEspoke-sdp 1:1 endpoint SPOKEspoke-sdp 3:1 endpoint SPOKE icb




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 SDPsmust match on each end, you use 3:1 as the ICB-PW for PE1’s SPOKE endpoint, and 3:2 for PE1’s SAP endpoint. On PE2, you use 3:1 in the SAP endpoint, and 3:2 in the SPOKE endpoint.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ICB-PW – Normal operations

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

ICP-PW – Normal operationsHere 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 MLS2’s spoke SDP and SAP are in standby.

(notes continued on next page...)

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ICB-PW - Normal Operations (cont)

MLS2 sends status 0x20, Pseudowire Forwarding SAP in Standby, rather than 0x26


...

-------------------------------------------------------------------------------


SvcId : 1 SdpId : 1


LMTU : 1500 RMTU : 1500





-------------------------------------------------------------------------------


SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500





-------------------------------------------------------------------------------


...

-------------------------------------------------------------------------------


SvcId : 1 SdpId : 1


LMTU : 1500 RMTU : 1500





-------------------------------------------------------------------------------


SvcId : 1 SdpId : 2


LMTU : 1500 RMTU : 1500





-------------------------------------------------------------------------------

ICB-PW Normal Operations (cont)A:CSA1# show service id 1 sdp detail

...

-------------------------------------------------------------------------------

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 : NoneA

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



ICB-PW - Normal Operations (cont)

Though the SAP is down, the MLS2 ePipe service remains operationally Up

Note the three spoke SDP bindings, two of which terminate as ICBPWs on MLS1


...


...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


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

===============================================================================


...


...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


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 Normal Operations (cont)MLS1 shows the LAG SAP and all three spoke spoke SDPs up.


...


...

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:lag-2 null 1514 1514 Up Up

sdp:1:1 S(192.0.2.2) Spok 0 1550 Up Up

sdp:3:1 S(192.0.2.1) Spok 0 1550 Up Up

sdp:3:2 S(192.0.2.1) Spok 0 1550 Up Up

===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ICB-PW – Primary Spoke SDP fails, MLS1 LAG active

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

ICP-PW – Primary Spoke SDP fails, MLS1 LAG activePreviously, 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.A:CSA1# show service id 1 sdp detail...Sdp Id 1:1 -(192.0.2.0)...Flags : SdpOperDown

NoIngVCLabel NoEgrVCLabelPeer Pw Bits : None...Sdp Id 2:1 -(192.0.2.1)...Flags : NonePeer Pw Bits : pwFwdingStandby...• The MLS2 LAG SAP is still in standby.A:MLS2# show service id 1 base...Service Access & Destination Points-------------------------------------------------------------------------------Identifier Type AdmMTU OprMTU Adm Opr-------------------------------------------------------------------------------sap:lag-2 null 1514 1514 Up Downsdp:1:1 S(192.0.2.2) Spok 0 1550 Up Upsdp:3:1 S(192.0.2.0) Spok 0 1550 Up Upsdp:3:2 S(192.0.2.0) Spok 0 1550 Up Up===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ICB-PW – Primary Spoke SDP fails, MLS1 LAG active (cont)

A:MLS1# show service id 1 endpoint

===============================================================================

Service 1 endpoints

===============================================================================

Endpoint name : SAP

...

Tx Active : lag-2

...

-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------

SAP : lag-2 Oper Status: Up

Spoke-sdp: 3:2 Prec:4 (icb) Oper Status: Up

===============================================================================

Endpoint name : SPOKE

...

Tx Active (SDP) : 3:1

...

-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------

Spoke-sdp: 1:1 Prec:4 Oper Status: Down



===============================================================================

Service 1 endpoints

===============================================================================

Endpoint name : SAP

...

Tx Active : lag-2

...

-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------

SAP : lag-2 Oper Status: Up


===============================================================================


...


...

-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



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.


===============================================================================

Service 1 endpoints

===============================================================================

Endpoint name : SAP

...


...

-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------

SAP : lag-2 Oper Status: Down


===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring ICB-PW

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


Syntax: [no] endpoint <endpoint-name>

[no] spoke-sdp <sdp-id:vc-id> endpoint <endpoint-name> icb create

Example: config>service>epipe# endpoint SAP create

config>service>epipe>endpoint$ back config>service>epipe# sap lag-2 endpoint SAP createconfig>service>epipe>sap$ backconfig>service>epipe# spoke-sdp 3:1 endpoint SAP icb create


config>service>epipe# endpoint SPOKE create


config>service>epipe# spoke-sdp 1:1 endpoint SPOKE create


config>service>epipe# spoke-sdp 3:2 endpoint SPOKE icb create


Syntax: [no] endpoint <endpoint-name>

[no] spoke-sdp <sdp-id:vc-id> endpoint <endpoint-name> icb create

Example: config>service>epipe# endpoint SAP create

config>service>epipe>endpoint$ back config>service>epipe# sap lag-2 endpoint SAP createconfig>service>epipe>sap$ backconfig>service>epipe# spoke-sdp 3:1 endpoint SAP icb create


config>service>epipe# endpoint SPOKE create


config>service>epipe# spoke-sdp 1:1 endpoint SPOKE create


config>service>epipe# spoke-sdp 3:2 endpoint SPOKE icb create

Configuring ICB-PWICB-PW should only be used with PW redundancy and MC-LAG or MC-APS on the edge PE routers.EndpointTwo 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 CreationYou 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

PrecedenceICB PW have the lowest precedence of all spoke SDPs. This is not configurable.

Configuration on the MC Peer PEThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the MLS1 SPOKE endpoint status – Normal operations


...

===============================================================================

Service 1 endpoints

===============================================================================



Revert time : 0

Act Hold Delay : 0








-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================


...

===============================================================================

Service 1 endpoints

===============================================================================



Revert time : 0

Act Hold Delay : 0








-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================

View the MLS1 SPOKE Endpoint Status – Normal operationsA: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.Only one endpoint object can be forwarding at a time, and the ICB spoke SDP has the lowest precedence.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the MLS1 SPOKE endpoint status – Primary Spoke SDP failed


...

===============================================================================

Service 1 endpoints

===============================================================================



Revert time : 0

Act Hold Delay : 0








-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------




...

===============================================================================

Service 1 endpoints

===============================================================================



Revert time : 0

Act Hold Delay : 0








-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



View the MLS1 SPOKE Endpoint Status – Primary Spoke SDP failedA:NodeA# show service id 1 endpoint

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 StatusMLS2’s 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 MLS2’s endpoint status. A:MLS2# show service id 1 endpoint...Endpoint name : SAP...Tx Active (SDP) : 3:1...-------------------------------------------------------------------------------Members-------------------------------------------------------------------------------SAP : lag-2 Oper Status: DownSpoke-sdp: 3:1 Prec:4 (icb) Oper Status: Up===============================================================================Endpoint name : SPOKE...Tx Active (SDP) : 1:1...-------------------------------------------------------------------------------Members-------------------------------------------------------------------------------Spoke-sdp: 1:1 Prec:4 Oper Status: UpSpoke-sdp: 3:2 Prec:4 (icb) Oper Status: Up===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PW Redundancy, PW Switching and ICB-PW - MC-LAG Access

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

PW Redundancy, PW Switching, and ICB-PW - MC-LAG AccessThe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Module 3 - Page 124 | All rights reserved © 2012 Alcatel-LucentSection 6 · Page 124


Automatic Protection Switching (APS)

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

Automatic Protection SwitchingAPS 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 don’t 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Linear APS Signaling

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

Linear APS SignalingThe 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 selectionA

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



Bi-Directional APS 1+1

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

Bi-Directional APS 1+1The 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 Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Single Chassis APS Options

Single Chassis APS OptionsSame IOM/MDA

In this configuration, APS protects the physical port. The working and protection facilities are on different ports.

Same IOM/Different MDAAPS 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Multi-Chassis APS (MC-APS)

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

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring MC-APS


Syntax: aps-<group-id>

Context: config>port>aps

Syntax: [no] neighbor <ip-address>

[no] protect-circuit <slot-id>

[no] working-circuit <slot-id>

[no] revert-time <minutes>

[no] hold-time <hold-time>

Example: config# port aps-1

config>port$ aps

config>port>aps$ neighbor 192.0.2.1

config>port>aps$ revert-time 9

config>port>aps$ hold-time 70

config>port>aps$ working-circuit 1/2/1

config>port>aps$ back

config>port$ no shutdown


Syntax: aps-<group-id>

Context: config>port>aps

Syntax: [no] neighbor <ip-address>

[no] protect-circuit <slot-id>

[no] working-circuit <slot-id>

[no] revert-time <minutes>

[no] hold-time <hold-time>

Example: config# port aps-1

config>port$ aps

config>port>aps$ neighbor 192.0.2.1

config>port>aps$ revert-time 9

config>port>aps$ hold-time 70

config>port>aps$ working-circuit 1/2/1

config>port>aps$ back

config>port$ no shutdown

Configuring MC-APSFirst, 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 node’s role, configure either the working or protection circuit:A:NodeA>config>port>aps$ working-circuit 1/2/1

OrA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Verifying MC-APS

Active circuit shows port number on active working or protectionnode

Active circuit N/A if opposite peer’s circuit is active

A:MLS1# show aps aps-1

===============================================================================

APS Group Info

===============================================================================

Interface Admin/Oper MC-Ctl Work|Work1 Prot|Work2 Active Tx/Rx

State State Circuit Circuit Circuit K1 Byte

-------------------------------------------------------------------------------

aps-1 Up/Up Up 1/2/1 N/A 1/2/1 N/A

===============================================================================

Interface - aps-<id> [<x>]

- <x> applies to APS Annex B only:

L - lockout

Circuit - <slot>/<mda>/<port> [<y>]

- <y> applies to APS Annex B only:

P - primary U - up

S - secondary D - down

===============================================================================


===============================================================================

APS Group Info

===============================================================================



-------------------------------------------------------------------------------

aps-1 Up/Up Up 1/2/1 N/A 1/2/1 N/A

===============================================================================



L - lockout



P - primary U - up


===============================================================================

Model 1 – Verifying APSA: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 node’s circuit is inactive.

•Tx/Rx K1 Byte – This is the value of the SONET/SDH K1 byte received or transmitted on the protection circuit.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



MC-APS for ATM Ports

A:MLS1>config# port aps-1

A:MLS1>config>port# info--------------------------------------------

apsneighbor 192.0.2.1hold-time 70revert-time 9working-circuit 1/2/1

exitsonet-sdh

path atmexitno shutdown

exitexitno shutdown


A:MLS1>config>port# info--------------------------------------------

apsneighbor 192.0.2.1hold-time 70revert-time 9working-circuit 1/2/1

exitsonet-sdh


exitexitno shutdown

A:MLS2>config# port aps-1A:MLS2>config>port# info --------------------------------------------

apsneighbor 192.0.2.0hold-time 70revert-time 9protect-circuit 1/2/1

exitsonet-sdh


exitexitno shutdown

A:MLS2>config# port aps-1A:MLS2>config>port# info --------------------------------------------

apsneighbor 192.0.2.0hold-time 70revert-time 9protect-circuit 1/2/1

exitsonet-sdh


exitexitno 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

MC-APS for ATM PortsYou 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



PW Redundancy, PW Switching and ICB-PW - MC-APS Access

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

PW Redundancy, PW Switching and ICB-PW - MC-APS AccessAs 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Review


Implemented pseudowire switching to support traffic engineering and control FIB sizes across IGP areas

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section 6 — Model 2 ePipe and Distributed VPRN for Ethernet Services

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Review the Model 2 ePipe and distributed VPRN configuration for 3 and 4G voice, data, and control

Observe the active ePipe pseudowire controlling the POC3 VPRN interface states

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – ePipes and VPRN for 3G and LTE Ethernet Traffic

Model 2 - Backhaul Services• 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

Model 2 – ePipes and VPRN for 3G and LTE Ethernet TrafficAs we learned, the Model 2 subtended ring Model transported Ethernet backhaul traffic over redundant ePipesconnected 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 3G and 4G ePipes and VRPN Services - Overview

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

Model 2 3G and 4G ePipes and VRPN Services - OverviewThe 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 PE’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – POC3 VPRN Interfaces

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

Model 2 – POC3 VPRN InterfacesThe 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 BSOn each of the two POC3 routers, static routes define the path to the NodeB’s loopback interface. Since only one of the NodeB interfaces is active, only one of the two POC3 routers holds a valid route to the NodeB’s loopback interface. The POC3 router with the active interface advertises this route into the VPRN service.Standby Signaling Master

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

===============================================================================


===============================================================================


IP-Address PfxState

-------------------------------------------------------------------------------

toNodeB Up Down/-- VPRN spoke-2:50

192.0.2.182/30 n/a

-------------------------------------------------------------------------------

Interfaces : 1

===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the POC3-1 VPRN Configuration

A:POC3-1>config>service>vprn# info

----------------------------------------------

route-distinguisher 65100:150

vrf-target target:65100:50

interface "to NodeB" create

address 192.0.2.182/30


no shutdown

exit

exit

static-route 198.51.100.0/29 black-hole

static-route 198.51.100.3/32 next-hop 192.0.2.181

spoke-sdp 3 create

no shutdown

exit

spoke-sdp 4 create

no shutdown

exit

no shutdown----------------------------------------------

A:POC3-1>config>service>vprn# info

----------------------------------------------

route-distinguisher 65100:150

vrf-target target:65100:50

interface "to NodeB" create

address 192.0.2.182/30


no shutdown

exit

exit

static-route 198.51.100.0/29 black-hole

static-route 198.51.100.3/32 next-hop 192.0.2.181

spoke-sdp 3 create

no shutdown

exit

spoke-sdp 4 create

no shutdown

exit

no shutdown----------------------------------------------

View the POC3-1 VPRN ConfigurationBlack 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 router-advertised black hole static route.

POC3-2 advertises a more specific black hole route than does POC3-1. Since POC3-2 protects POC3-1, NodeBtraffic 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the POC3-2 “to NodeB” Interface

POC3-2 interface “to NodeB” is operationally down since the spoke SDP is in standby

A:POC3-2# show service id 5 interface "toNodeB" detail

...output truncated

-------------------------------------------------------------------------------

Interface

-------------------------------------------------------------------------------

If Name : to NodeB

Admin State : Up Oper (v4/v6) : Down/--

Down Reason Code: assocObjNotReady

Protocols : None

IP Addr/mask : 192.0.2.182/30 Address Type : Primary...

SDP Id : spoke-2:50

Spoke-SDP Details


Hash Label : Disabled Hash Lbl Sig Cap : Disabled

Peer Fault Ip: None


Peer Vccv CV Bits : lspPing

Peer Vccv CC Bits : mplsRouterAlertLabel

Flags : None

A:POC3-2# show service id 5 interface "toNodeB" detail

...output truncated

-------------------------------------------------------------------------------

Interface

-------------------------------------------------------------------------------

If Name : to NodeB

Admin State : Up Oper (v4/v6) : Down/--

Down Reason Code: assocObjNotReady

Protocols : None

IP Addr/mask : 192.0.2.182/30 Address Type : Primary...

SDP Id : spoke-2:50

Spoke-SDP Details


Hash Label : Disabled Hash Lbl Sig Cap : Disabled

Peer Fault Ip: None


Peer Vccv CV Bits : lspPing

Peer Vccv CC Bits : mplsRouterAlertLabel

Flags : None

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Active SDP Failure Scenario – CSA2 Chooses New Active PW

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


===============================================================================

Service 50 endpoints

===============================================================================

Endpoint name : epipe50

...

Tx Active : 2:50





-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================


===============================================================================


===============================================================================

Endpoint name : epipe50

...

Tx Active : 2:50





-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================

Active SDP Failure Scenario – CSA2 Chooses New Active PWPOC3-1 hosts the active interface. The active interface status is tied to the active spoke SDP status.

A:NodeA# show service id 50 endpoint

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 NodeBtraffic 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Active SDP Failure Scenario – POC3-2 Interface

A:POC3-2# show router 5 interface

===============================================================================


===============================================================================


IP-Address PfxState

-------------------------------------------------------------------------------

to NodeB Up Up/-- VPRN spoke-2:50

192.0.2.182/30 n/a

-------------------------------------------------------------------------------

Interfaces : 2

===============================================================================

A:POC3-2# show router 5 interface

===============================================================================


===============================================================================


IP-Address PfxState

-------------------------------------------------------------------------------

to NodeB Up Up/-- VPRN spoke-2:50

192.0.2.182/30 n/a

-------------------------------------------------------------------------------

Interfaces : 2

===============================================================================

CSA2 signals the standby SDP as active POC3-2 brings up its VPRN interface POC1-1 replaces the POC3-1 NodeB route with the POC3-2 route

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Active SDP Failure Scenario – New NodeB Route

CSA2 signals the standby SDP as active POC3-2 brings up its VPRN interface POC1-1 replaces the POC3-1 NodeB route with the POC3-2 route

A:POC1-1# show router 5 route-table===============================================================================Route Table (Service: 5)===============================================================================Dest Prefix Type Proto Age Pref

Next Hop[Interface Name] Metric-------------------------------------------------------------------------------192.0.2.56/29 Local Local 01h07m04s 0

To_RNC 0192.0.2.180/30 Remote BGP VPN 00h02m02s 170

192.0.2.1 0198.51.100.0/31 Remote BGP VPN 00h49m56s 170


192.0.2.1 0-------------------------------------------------------------------------------No. of Routes: 4===============================================================================

A:POC1-1# show router 5 route-table===============================================================================Route Table (Service: 5)===============================================================================Dest Prefix Type Proto Age Pref

Next Hop[Interface Name] Metric-------------------------------------------------------------------------------192.0.2.56/29 Local Local 01h07m04s 0

To_RNC 0192.0.2.180/30 Remote BGP VPN 00h02m02s 170



192.0.2.1 0-------------------------------------------------------------------------------No. of Routes: 4===============================================================================

Active SDP Failure Scenario – New NodeB RouteA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 3G/4G ePipes and Distributed VPRN –Detailed View

Model 1 3G/4G ePipes and Distributed VPRN – Detailed ViewCSA1 – 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Reviewed the Model 2 ePipe and distributed VPRN configuration for 3 and 4G voice, data, and control

Observed standby-signaling-master controlling the VPRN services’active NodeB interface state

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Objectives


Review the Model 2 legacy (ATM and TDM) 2 and 3G voice, data, and control traffic paths and services

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – cPipe and aPipes for 2G and 3G TDM and ATM Traffic

Model 2 - Backhaul Services• cPipe and aPipes terminate directly into MLS router STM-1 access ports• POC3 routers switch tunneled traffic from access to aggregate rings

Model 2 – cPipe and aPipes for 2G and 3G TDM and ATM TrafficIn 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



3G aPipes

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 Legacy Services – aPipe Overview

CSA-MLS aPipes for NodeB IMA Bundled E1 traffic PW redundancy on the CSA ATM VCC N:1 cell mode vc-type PW switching at POC3 routers ICB-PW and MC-APS at MLS routers

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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

ATM Cell Format

ATM Cell FormatWhat 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ATM Header Format

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Virtual Path and Virtual Channels

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Virtual Channels and Virtual Paths

This hop-by-hop forwarding is known as cell relay

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



7705 Supported ATM VC-Types

The VC-type is a 15-bit value that defines the type of VC signalled to the peer ATM-VCC (Default on the 7705) Virtual Channel Connection. An ATM connection that is switched based

on the cell header’s VCI – Requires VPI/VCI identifier to be specified ATM-VPC Virtual Path Connection. An ATM connection that is switched based on

the cell header’s 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# configure service apipe 10 vc-type atm-vcc customer 1 create *A:CSA1>config>service>apipe$

*A:CSA1# configure service apipe 10 vc-type atm-vcc customer 1 create *A:CSA1>config>service>apipe$

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



aPipe Overview

ATM VPWS is used to carry ATM cells over an MPLS network.

aPipe OverviewApipe 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Cell Mode Encapsulation

N:1 Cell Mode

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)

aPipe Cell Mode EncapsulationN: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 don’t currently implement AAL5 SDU Mode.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ATM Cell Concatenation

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.

ATM Cell ConcatenationCell 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View Cell Concatenation Settings

Default settings Concatenation limit – 1 cell per packet (no max-cells)Max Concatenation delay – 400ms (no max-delay) No CLP change (no clp-change)

A:CSA1# show service id 200 sdp 1:200 detail

...output truncated

-------------------------------------------------------------------------------

APIPE Service Destination Point specifics

-------------------------------------------------------------------------------

Admin Concat Limit : 1 Oper Concat Limit : 1

Peer Concat Limit : 1 Max Concat Delay : 400

-------------------------------------------------------------------------------

Number of SDPs : 1

-------------------------------------------------------------------------------

===============================================================================

A:CSA1# show service id 200 sdp 1:200 detail

...output truncated

-------------------------------------------------------------------------------

APIPE Service Destination Point specifics

-------------------------------------------------------------------------------

Admin Concat Limit : 1 Oper Concat Limit : 1

Peer Concat Limit : 1 Max Concat Delay : 400

-------------------------------------------------------------------------------

Number of SDPs : 1

-------------------------------------------------------------------------------

===============================================================================

View Cell Concatenation SettingsConfigure 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]

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



ATM Service Categories

LAN Traffic

Best Effort service with flow control feedback

Bursty applications – File Transfers

Interactive Multimedia

Circuit Emulation Services

Typical Application

(no guarantees)UBR

PCR, MCRABR*

PCR, SCR, MBSNRT-VBR

PCR, SCR, MBSRT-VBR

PCRCBR

Traffic Parameters*

Service Category

• *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)

* Peak Cell Rate (PCR)Sustainable Cell Rate (SCR)Maximum Burst Size (MBS)Minimum Cell Rate (MCR)

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) A

lcat

el-L

ucen

t Con

fiden

tial f

or In

tern

al U

se O

NLY

- D

o N

ot D

istri

bute



ATM N:1 Cell Mode QoS Application

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

ATM N to 1 Cell Mode QoS ApplicationThe 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 NodeBsupports 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 atm-vcp, 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



aPipe Packet Format

• Control word optional for cell mode

• Required for AAL5 SDU frame mode

aPipe Packet FormatThe 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 customer’s 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 cell’s PTI•Bit 6 – CLP (C) : cell loss priority•Bit 7 – Command/response field bit (U): 0 or 1

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Creating the CSA aPipe Service

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

A:CSA2>config>service# apipe 200 vc-type atm-vcc customer 1 create

config>service>apipe$ description “Distributed apipe for 3G ATM Services"

config>service>apipe$ sap bundle-ima-1/1.1:200/10 create

config>service>apipe>sap$ back

config>service>apipe# endpoint "ATM_IMA_URC200" create

config>service>apipe>endpoint# back

config>service>apipe# spoke-sdp 1:200 endpoint "ATM_IMA_URC101" create

config>service>apipe>spoke-sdp$ precedence primary

config>service>apipe>spoke-sdp$ back



config>service>apipe# no shutdown

A:CSA2>config>service# apipe 200 vc-type atm-vcc customer 1 create


config>service>apipe$ sap bundle-ima-1/1.1:200/10 create

config>service>apipe>sap$ back

config>service>apipe# endpoint "ATM_IMA_URC200" create

config>service>apipe>endpoint# back


config>service>apipe>spoke-sdp$ precedence primary




config>service>apipe# no shutdown

Creating the CSA aPipe ServiceAccording 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Creating the S-PE aPipe Service

A:POC3>config>service# apipe 200 vc-type atm-vcc vc-switching customer 1 create


config>service>apipe$ spoke-sdp 1:200 create




config>service>apipe$ no shutdown

A:POC3>config>service# apipe 200 vc-type atm-vcc vc-switching customer 1 create







POC3 is the S-PE Use vc-type atm-vcc and vc-switching when creating the service

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Creating the MLS router ICB-PW aPipe Service

A:MLS2>config>service# apipe 200 vc-type atm-vcc customer 1 create


config>service>apipe$ endpoint SAP create

config>service>apipe>endpoint$ back

config>service>apipe$ endpoint SPOKE create


config>service>apipe$ sap aps-1:200/10 endpoint SAP create

config>service>epipe>sap$ back

config>service>apipe$ spoke-sdp 3:200 endpoint SAP icb create


config>service>apipe$ spoke-sdp 1:200 endpoint SPOKE create


config>service>apipe4 spoke-sdp 3:201 endpoint SPOKE icb create



A:MLS2>config>service# apipe 200 vc-type atm-vcc customer 1 create


config>service>apipe$ endpoint SAP create


config>service>apipe$ endpoint SPOKE create


config>service>apipe$ sap aps-1:200/10 endpoint SAP create

config>service>epipe>sap$ back

config>service>apipe$ spoke-sdp 3:200 endpoint SAP icb create


config>service>apipe$ spoke-sdp 1:200 endpoint SPOKE create


config>service>apipe4 spoke-sdp 3:201 endpoint SPOKE icb create



APS group in SAP ICB-PW to provide path of last resort to active SONET/SDH link

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the MLS1 aPipe Status


===============================================================================


===============================================================================


Service Type : Apipe VLL Type : ATMVCC


Description : Distributed apipe for 3G ATM Services

Customer Id : 1

...


MTU : 1508



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:aps-1:200/10 atm 1524 1524 Up Up

sdp:1:200 S(192.0.2.2) Spok 0 1550 Up Up

sdp:3:200 S(192.0.2.1) Spok 0 1550 Up Up

sdp:3:201 S(192.0.2.1) Spok 0 1550 Up Up

===============================================================================


===============================================================================


===============================================================================




Description : Distributed apipe for 3G ATM Services

Customer Id : 1

...


MTU : 1508



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:aps-1:200/10 atm 1524 1524 Up Up

sdp:1:200 S(192.0.2.2) Spok 0 1550 Up Up

sdp:3:200 S(192.0.2.1) Spok 0 1550 Up Up

sdp:3:201 S(192.0.2.1) Spok 0 1550 Up Up

===============================================================================

View the MLS1 aPipe StatusA:NodeA# show service id 200 base

•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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the CSA aPipe Status


===============================================================================


===============================================================================

Service Id : 200



Customer Id : 1


Last Mgmt Change : 08/30/2011 15:12:28


MTU : 1508



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:bundle-ima-1/1.1:200/10 atm 1524 1524 Up Up

sdp:1:200 S(192.0.2.0) n/a 0 1550 Up Up

sdp:2:200 S(192.0.2.1) n/a 0 1550 Up Up

===============================================================================


===============================================================================


===============================================================================

Service Id : 200



Customer Id : 1


Last Mgmt Change : 08/30/2011 15:12:28


MTU : 1508



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:bundle-ima-1/1.1:200/10 atm 1524 1524 Up Up

sdp:1:200 S(192.0.2.0) n/a 0 1550 Up Up

sdp:2:200 S(192.0.2.1) n/a 0 1550 Up Up

===============================================================================

View the CSA2 aPipe StatusA:NodeA# show service id 200 base

•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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the MLS SPOKE endpoint status – Normal operations


===============================================================================


===============================================================================

...

===============================================================================



Revert time : 0

Act Hold Delay : 0






-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================


===============================================================================


===============================================================================

...

===============================================================================



Revert time : 0

Act Hold Delay : 0






-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================

View the MLS1 SPOKE Endpoint Status – Normal operationsA:NodeA# show service id 200 endpoint

Tx Active (SDP): – Shows the active spoke SDP. In this example, the primary 2:200 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.Only one endpoint object can be forwarding at a time, and the ICB spoke SDP has the lowest precedence.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the MLS SPOKE endpoint status – Primary Spoke SDP failed


===============================================================================


===============================================================================

...

===============================================================================



Revert time : 0

Act Hold Delay : 0






-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================


===============================================================================


===============================================================================

...

===============================================================================



Revert time : 0

Act Hold Delay : 0






-------------------------------------------------------------------------------

Members

-------------------------------------------------------------------------------



===============================================================================

===============================================================================

View the MLS1 SPOKE Endpoint Status – Primary Spoke SDP failedA:NodeA# show service id 1 endpoint

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 StatusThe CSA2 secondary SDP 2:200 is up, and MLS2 forwards traffic to MLS1 over the ICB spoke SDP 3:200.A:MLS2# show service id 200 endpoint...Endpoint name : SAP...Tx Active (SDP) : 3:200...-------------------------------------------------------------------------------Members-------------------------------------------------------------------------------SAP : aps-1:200/20 Oper Status: DownSpoke-sdp: 3:200 Prec:4 (icb) Oper Status: Up===============================================================================Endpoint name : SPOKE...Tx Active (SDP) : 2:200...-------------------------------------------------------------------------------Members-------------------------------------------------------------------------------Spoke-sdp: 2:200 Prec:4 Oper Status: UpSpoke-sdp: 3:201 Prec:4 (icb) Oper Status: Up===============================================================================

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View MC-APS on MLS1


===============================================================================

APS Group Info

===============================================================================



-------------------------------------------------------------------------------

aps-1 Up/Up Up 1/2/4 N/A 1/2/4 N/A

===============================================================================



L - lockout



P - primary U - up


===============================================================================


===============================================================================

APS Group Info

===============================================================================



-------------------------------------------------------------------------------

aps-1 Up/Up Up 1/2/4 N/A 1/2/4 N/A

===============================================================================



L - lockout



P - primary U - up


===============================================================================

Model 1 – Verifying APSA: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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 Legacy Services – aPipe Detailed View

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 8 : Configure 3G Voice aPipe Service

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 Verify service operation with SROS OAM tools

.5 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



2G cPipes

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 Legacy Services – cPipe Overview

CSA-MLS cPipes for unchannelized BTS E1 traffic• PW redundancy on the CSA• Structure agnostic transport over PSN (SAToP) vc-type• PW Switching at POC3 routers• ICB-PW and MC-APS at MLS routers

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Review: Time Division Multiplexing

Synchronous channel based

Each station gets a fixed-length slot

Unused slots are idle – transmitted without data

For example: T1, SONET

Review: Time Division MultiplexingEach 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



DS1/T1

1.544 Mb/s Framing Rate

24 subchannels (DS0) each 8 bits sampled at 8000 times per second + 1 framing bit

Time Division Multiplexing (TDM) – DS1

Time Division Multiplexing (TDM) – DS1Time 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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Time Division Multiplexing (TDM) – E1

E1 2048Kb/s framing rate 32 subchannels each 8 bits sampled at 8000 times per second

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



SROS cPipe Overview

cPipe provides a bi-directional layer 2 TDM service connection over the IP/MPLS transport

Support both local cross-connect and remote connect.

Support both structured and unstructured frames

SROS cPipe OverviewCES 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



cPipe Data Plane Encapsulation

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

cPipe Data Plane EncapsulationThe 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 service’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



cPipe – Delivery Options

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 E1Unstructured - 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 thatwhen channel-group 1 is configured it contains all 24 or 32 channels

cPipe Delivery OptionsStructured – 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, theF 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



cPipe Encapsulation

cPipe EncapsulationThe 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].

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



cPipe Control Word

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

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, andM = 00 – Normal conditionsM = 01 – Reserved for future useM = 10 – Remote Defect Indicator (RDI) condition for the attachment circuit (AC)M = 11 – Reserved for CESoPSN

• When L bit = 1, andM = 00 – TDM data is invalidM = 01 – Reserved for future useM = 10 – Reserved for future useM = 11 – Reserved for future use

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Packet Size vs. Packet Latency

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

Payload Size vs. Packetization Delay The payload size is calculated by the formula

S = N x F

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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Jitter Buffer

Packet jitter is the time difference between a packet’s 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

Jitter BufferSeveral 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Jitter Buffer (cont)

The cPipe uses a jitter buffer to adjust for Time Delay Variation

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

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 : 24Payload Size : 192 Jitter Buffer (ms) : 5Jitter Buffer (packets): 6 Playout Threshold (packets): 4Use RTP Header : No Differential : NoTimestamp Freq : 0 CAS Framing : No CASEffective PDVT : +/-2.984 ms

Cfg Alarm : stray malformed pktloss overrun underrunAlarm Status :-------------------------------------------------------------------------------

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 – cPipe for 2G TDM Traffic

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

Model 2 – cPipe for 2G TDM TrafficA 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring the CSA E1 port

Set the port to e1-unframed Configure the channel group to CEM encapsulation The default mode is access and all 32 timeslots are used

A:CSA2>config# port 1/1/1

config>port# description “E1 tdm link towards BTS10 port 1"

config>port# tdm

config>port>tdm# e1

config>port>tdm>e1# framing e1-unframed

config>port>tdm>e1# channel-group 1

config>port>tdm>e1>channel-group# encap-type cem

config>port>tdm>e1>channel-group# no shutdown

config>port>tdm>e1>channel-group# back

config>port>tdm>e1# no shutdown

config>port>tdm>e1# back



A:CSA2>config# port 1/1/1

config>port# description “E1 tdm link towards BTS10 port 1"

config>port# tdm

config>port>tdm# e1



config>port>tdm>e1>channel-group# encap-type cem

config>port>tdm>e1>channel-group# no shutdown



config>port>tdm>e1# back



Configuring the CSA1 E1 PortPort 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, node-timed, 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 circuit’s 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Configuring the MLS Path and Payload – STM-1


config>port# description “To BSC1 over SDH"

config>port# sonet-sdh

config>port>sonet-sdh# path sts3

config>port>sonet-sdh>path# no shutdown

config>port>sonet-sdh>path# back

config>port>sonet-sdh# group tug3-1 payload vt2





config>port# tdm

config>port>tdm# e1 1.1.1



config>port>tdm>e1>channel-group$ no shutdown






config>port# description “To BSC1 over SDH"

config>port# sonet-sdh

config>port>sonet-sdh# path sts3



config>port>sonet-sdh# group tug3-1 payload vt2





config>port# tdm

config>port>tdm# e1 1.1.1



config>port>tdm>e1>channel-group$ no shutdown





vt2-tug3-1.tug2-1.vt2-1

Configuring the MLS2 Path and PayloadOn 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Creating the CSA cPipe Service

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

A:CSA2>config>service# cpipe 300 vc-type satop-e1 customer 1 create

config>service>cpipe$ description “Distributed cpipe for 2G BTS Services"

config>service>cpipe$ sap 1/1/1.1 create

config>service>cpipe>sap$ cem

config>service>cpipe>sap>cem$ back

config>service>cpipe>sap$ back

config>service>cpipe# endpoint “BTS_20_port_1" create

config>service>cpipe>endpoint# back

config>service>cpipe# spoke-sdp 1:300 endpoint "BTS_20_port_1" create

config>service>cpipe>spoke-sdp$ precedence primary

config>service>cpipe>spoke-sdp$ back



config>service>cpipe# no shutdown

A:CSA2>config>service# cpipe 300 vc-type satop-e1 customer 1 create

config>service>cpipe$ description “Distributed cpipe for 2G BTS Services"

config>service>cpipe$ sap 1/1/1.1 create




config>service>cpipe# endpoint “BTS_20_port_1" create

config>service>cpipe>endpoint# back


config>service>cpipe>spoke-sdp$ precedence primary




config>service>cpipe# no shutdown

Creating the CSA cPipe ServiceYou 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|satop-t1|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 ds1-unframed 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 CESStructured 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 signalingStructured 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.

CEMOn 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Creating the S-PE cPipe Service

A:POC3>config>service# cpipe 300 vc-type satop-e1 vc-switching customer 1 create

config>service>cpipe$ description “Distributed cpipe for for 2G BTS Services"

config>service>cpipe$ spoke-sdp 2:300 create




config>service>cpipe$ no shutdown

A:POC3>config>service# cpipe 300 vc-type satop-e1 vc-switching customer 1 create

config>service>cpipe$ description “Distributed cpipe for for 2G BTS Services"






POC3 is the S-PE Use vc-type satop-e1 and vc-switching when creating the service

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Creating the MLS router ICB-PW cPipe Service

A:MLS1>config>service# cpipe 300 vc-type satop-e1 customer 1 create

config>service>cpipe$ description “Distributed for 2G BTS Services "

config>service>cpipe$ endpoint SAP create

config>service>cpipe>endpoint$ back

config>service>cpipe$ endpoint SPOKE create


config>service>cpipe$ sap aps-2.1.1.1.1 endpoint SAP create




config>service>cpipe$ spoke-sdp 3:300 endpoint SAP icb create


config>service>cpipe$ spoke-sdp 1:300 endpoint SPOKE create


config>service>cpipe$ spoke-sdp 3:301 endpoint SPOKE icb create



A:MLS1>config>service# cpipe 300 vc-type satop-e1 customer 1 create

config>service>cpipe$ description “Distributed for 2G BTS Services "

config>service>cpipe$ endpoint SAP create


config>service>cpipe$ endpoint SPOKE create


config>service>cpipe$ sap aps-2.1.1.1.1 endpoint SAP create




config>service>cpipe$ spoke-sdp 3:300 endpoint SAP icb create


config>service>cpipe$ spoke-sdp 1:300 endpoint SPOKE create


config>service>cpipe$ spoke-sdp 3:301 endpoint SPOKE icb create



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

aps-2.tug3-1.tug2-1.vt2-1.channel-group 1

Creating the MLS router ICB-PW cPipe ServiceConfigure 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

----------------------------------------------

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the CSA cPipe Status


===============================================================================


===============================================================================

Service Id : 300

Service Type : Cpipe VLL Type : SAToPE1

Description : Distributed cpipe for for 2G BTS Services

Customer Id : 1


Last Mgmt Change : 09/02/2011 09:54:53


MTU : 1514



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:1/1/1.1 cem 1514 1514 Up Up

sdp:1:300 S(192.0.2.0) n/a 0 1550 Up Up

sdp:2:300 S(192.0.2.1) n/a 0 1550 Up Up

===============================================================================


===============================================================================


===============================================================================

Service Id : 300


Description : Distributed cpipe for for 2G BTS Services

Customer Id : 1


Last Mgmt Change : 09/02/2011 09:54:53


MTU : 1514



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:1/1/1.1 cem 1514 1514 Up Up

sdp:1:300 S(192.0.2.0) n/a 0 1550 Up Up

sdp:2:300 S(192.0.2.1) n/a 0 1550 Up Up

===============================================================================

View the CSA aPipe StatusA:NodeA# show service id 300 base

•VLL Type: - SAToPE1 – Structure agnostic E1 service

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



View the MLS cPipe Status


===============================================================================


===============================================================================





Customer Id : 1


Last Mgmt Change : 09/02/2011 13:51:12


MTU : 1514



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:aps-2.1.1.1.1 cem 1578 1578 Up Up

sdp:1:300 S(192.0.2.3) Spok 0 1550 Up Up

sdp:3:300 S(192.0.2.1) Spok 0 1550 Up Up

sdp:3:301 S(192.0.2.1) Spok 0 1550 Up Up

===============================================================================


===============================================================================


===============================================================================





Customer Id : 1


Last Mgmt Change : 09/02/2011 13:51:12


MTU : 1514



-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

sap:aps-2.1.1.1.1 cem 1578 1578 Up Up

sdp:1:300 S(192.0.2.3) Spok 0 1550 Up Up

sdp:3:300 S(192.0.2.1) Spok 0 1550 Up Up

sdp:3:301 S(192.0.2.1) Spok 0 1550 Up Up

===============================================================================

View the MLS aPipe StatusA:NodeA# show service id 300 base

•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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



CES Packet Loss

Packet loss or re-ordering is detected through packet sequence numbers in control word

Re-ordering is corrected in the jitter buffer on egress

Lost packet data (L bit=1) must be replaced to ensure proper TDMoperation 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

cPipe Packet LossThe 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 user-configurable 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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Model 2 Legacy Services – cPipe Detailed View

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Lab 9 : Configure 2G Voice cPipe Service

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 Verify service operation with SROS OAM tools

.5 Hour

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



Section Review


Reviewed the Model 2 Legacy (ATM and TDM) 2 and 3G voice, data, and control traffic paths and services

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



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 theBS 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 VLANsidentified in a SAP’s managed-vlan-list

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te





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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




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) 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

Answers:

1. A, D

2. c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




3. How many spoke SDP objects can be associated with a single explicit endpoint?

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

Answers:

3. D

4. D

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




5. What three options are available in the SROS for cross connecting a local L2 service to a local L3 service? (Choose three.)

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

Answers:

5. A, B, D

6. B

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




7. What command would you use on a VPWS endpoint to control the far-end PE’s active interface choice?

_________________________________________________________

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

Answers:

7. A:NodeA>config>service>epipe>endpoint# standby-signaling-master

8. A:NodeA>config>service>epipe>endpoint# revert-time infinite

9. a, b

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




10.How might the NC element learn the VRRP virtual router MAC address?

a) Forwarding database update

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?

_________________________________________________________

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 ce-address as the source IP address

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




13.On an iPipe SAP configured for PPP, what protocol passes the BTS IP address?

_________________________________________________________

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?

_________________________________________________________

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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




18.Which statement best describes the S-PE function in a PW switched VPWS?

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?

_________________________________________________________

Answers:

18. d.

19. configure service epipe 1 customer 1 vc-switching create

20. 0x26, pseudowire in standby, remote SAP down

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




21.ICB-PW protected services require what configuration components to provide a last-resort path to the MC-protected SAP? (choose two.)

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?

_________________________________________________________

Answers:

21. a, b

22. 0x20, PW forwarding standby

23. K1 and K2 bytes, on the protection facility

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




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?

____________________________________________________________

Answers:

24. show aps aps-1

25. atm-vcc

26. 4, one per profile

27.satop-e1 or satop-t1

28.8x24=192 bytes

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te




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?

a) 1ms

b) 3ms

c) 5ms

d) 10ms

30.To carry a unchannelized E1 circuit in a structure agonostic cPipeservice, how must the 7705 SAR TDM port be configured?

a) framing cem

b) framing e1-framed

c) framing e1-unframed

d) framing satop-e1

Answers:

29. b, 3 x the packetization delay, d = 125us/frame x 8 frames = 1ms

30. c

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te



TTP36002 Edition 1

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Appendix A – Page 1| All rights reserved © 2012 Alcatel-Lucent


Appendix A — References

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


References

[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.alcatel-lucent.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). Inter-Regional 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.alcatel-lucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%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-00100-ABAA&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.alcatel-lucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul%2fMBH%20Presentations%20%2d%20technology%20independent&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%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/cgi-bin/public/ProductPortal.cgi?number=3MM-00101-0001&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.alcatel-lucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLt4x39A7QL8h2VAQAT8ihFw!!?LMSG_CABINET=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=K72f06GZ2b&sig=eVhE7j56ucLwBau0CXOJyrFPfaA&hl=en&ei=XeSxTa6HA8jx0gGsheXfBA&sa=X&oi=book_result&ct=result&resnum=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.alcatel-lucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00101-0001&root=ALU2010&selector=custom&custom_section=sol_collateral_view

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


References

[22] Alcatel-Lucent University. (2008) IPBH w/VPRN and 7705. Available: https://all1.us.alcatel-lucent.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 Today’s 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-in-Cellular-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.alcatel-lucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100-ABAA&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.alcatel-lucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100-ABAA&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-AB93-611DD043C3E0/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.alcatel-lucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d191A%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.

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


References

[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.alcatel-lucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d191A%2d473D%2d9199%2dD03A1C45808C%7d

[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/ch17-3361668

[51] Alcatel-Lucent University. (2001, July). 1631 SX LMC Operations and Maintenance Student Guide. 1631LM-310250. 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.alcatel-lucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d191A%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.telecom-sync.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/Colloquium/Impact%20of%20Time%20Synch%20on%20Sub%20Automation%20-%20Preuss.pdf

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


References[57] Microsoft. (Date unknown) TechNet Library, IPv6 Identifiers. Available: http://technet.microsoft.com/en-us/library/cc736439%28WS.10%29.aspx.

[58] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2010, May). Solution Blueprint MBH 1/3: IP Mobile Backhaul High Level Design v1.0 IP/MPLS infrastructure. Available: https://sps.eu.alcatel-lucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul&View=%7bE7F1A86E%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.alcatel-lucent.com/release/jsp/sso/login.jsp?TYPE=33554433&REALMOID=06-3cffeb57-8088-001e-0000-6f4900006f49&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$Vs%2fCwDSWZ8BOHkVOoewB7IvXSBgFCYcdLKauGuwzsJHsPRgrWps%2f0Exm%2fL%2bHbAmU&TARGET=$SM$https%3a%2f%2fwww1%2ealcatel-lucent%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.alcatel-lucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d191A%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. draft-ietf-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 MC-APS/PWE3 Redundancy. MC-APS/PWE3 Redundancy – Configuration. Available: https://sps.eu.alcatel-lucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fShared%20Documents%2fSolution%20info%2fCDMA&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


References

.

[72] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2010, May). Solution Blueprint MBH 1/3: IP Mobile Backhaul High Level Design ATM Service Delivery. Available: https://sps.eu.alcatel-lucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebell%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul&View=%7bE7F1A86E%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

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te


TTP36002 Edition 1

Alc

atel

-Luc

ent C

onfid

entia

l for

Inte

rnal

Use

ON

LY -

Do

Not

Dis

tribu

te