Alcatel-Lucent IP MPLS Mobile Backhaul Transport Student Guide

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

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

Module 0 – Course Introduction

Module Overview

 Alcatel-Lucent Career Certification Flow  Timeline  Objectives  Prerequisites  Follow On  Introduction  Goal  Administration

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

Module 0 |

2

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. For more information on the SRC program, see www.alcatel-lucent.com/src To locate additional information relating to the topics presented in this manual, refer to the following: 

Technical Practices for the specific product



Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts



Technical support pages of the Alcatel-Lucent website located at: http://www.alcatellucent.com/support

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

Module 0 - Page 2 | All rights reserved © 2012 Alcatel-Lucent

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

 General Course Information

ALCATEL-LUCENT NETWORK ROUTING SPECIALIST I

ALCATEL-LUCENT NETWORK ROUTING SPECIALIST II

4 DAYS / 1 COURSE / 1 WRITTEN EXAM

18 DAYS / 4 COURSES / 4 WRITTEN EXAMS / 1 PRACTICAL LAB EXAM

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

32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS

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

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

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

Module 0 |

3

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 3 | All rights reserved © 2012 Alcatel-Lucent

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

The Alcatel-Lucent SRC Program – Five Certifications

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

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

Module 0 |

4

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 4 | All rights reserved © 2012 Alcatel-Lucent

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

SRC Courses and Exams

Exam Number

Exam Pre-requisites (4A0-XXX)

Alcatel-Lucent Scalable IP Networks

4A0-100

NA

Alcatel-Lucent Interior Routing Protocols

4A0-101

NA

Alcatel-Lucent Border Gateway Protocol

4A0-102

NA

Alcatel-Lucent Multiprotocol Label Switching

4A0-103

NA

Alcatel-Lucent Services Architecture

4A0-104

NA

Exam Name

Alcatel-Lucent Virtual Private LAN Services

4A0-105

NA

Alcatel-Lucent Virtual Private Routed Networks

4A0-106

NA

Alcatel-Lucent Quality of Service

4A0-107

NA

Alcatel-Lucent Multicast Protocols

4A0-108

NA

Alcatel-Lucent Triple Play Services

4A0-109

NA

Alcatel-Lucent Advanced Troubleshooting

4A0-110

NA

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

4A0-M01

NA

Alcatel-Lucent Mobile Gateways for the LTE Evolved Packet Core

4A0-M02

NA

Alcatel-Lucent Network Routing Specialist II Lab Exam

NRSII4A0

100, 101, 103, 104

Alcatel-Lucent Mobile Routing Professional Lab Exam

MRP4A0

100, 101, 103, 104, 107, M01, M02, NRSII4A0

Alcatel-Lucent Service Routing Architect Lab Exam

ASRA4A0

100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, NRSII4A0

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

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

Module 0 |

5

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 5 | All rights reserved © 2012 Alcatel-Lucent

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

SRC Program Exam Profile

Exam Delivery Written Exams  Delivered by Prometric  Global provider of testing services  Register at: www.prometric.com/alcatel-lucent Lab Exams  Written at Alcatel-Lucent sites  NRS II Certification • Half-day lab exam • MRP Certification • Half-day lab exam  SRA Certification • Full-day lab exam • Register at: www.alcatel-lucent.com/src/examreg

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

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

Module 0 |

6

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 6 | All rights reserved © 2012 Alcatel-Lucent

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

 5000+ test sites worldwide

SRC Program Global Reach, Flexible Delivery Options

 APAC ― Shanghai, China ― Sydney, Australia ― Melbourne, Australia ― Wellington, New Zealand ― Bangalore, India ― Chennai, India ― Gurgaon, India ― Mumbai, India

 Europe ―Antwerp, Belgium ―Newport, UK ―Paris, France  Americas ―Plano, USA ―Ottawa, Canada ―Mexico City, Mexico ―Sao Paulo, Brazil

 Class schedules posted @ www.alcatel-lucent.com/src  Registration online @ www.alcatel-lucent.com/src/coursereg

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

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

Module 0 |

7

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 7 | All rights reserved © 2012 Alcatel-Lucent

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

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

Your Own Service Router Lab – Now you can have one

Need access to a lab to help you:  Practice and build your service routing knowledge and configuration skills?

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

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

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

Module 0 |

8

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 8 | All rights reserved © 2012 Alcatel-Lucent

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

 Prepare for your NRS II and SRA exams?

Credit for other IP Certifications

 You can receive exemptions from some of the SRC exams, if you hold any one of the Cisco or Juniper certifications identified  Certifications must be valid to receive exemptions  Submit your request for exemptions at: http://www.alcatellucent.com/src/exemptions

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

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

Module 0 |

9

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 9 | All rights reserved © 2012 Alcatel-Lucent

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

Cisco or Juniper certified?

Day 1  Module 0 — Course Introduction  Module 1 — IP/MPLS Mobile Backhaul Transport Network Architectures Day 2  Module 2 — Implementing the Mobile Backhaul Transport Network Day 3  Module 2 — Implementing the Mobile Backhaul Transport Network (cont)  Module 3 — Mobile Backhaul Transport Services Day 4  Module 3 — Mobile Backhaul Transport Services (cont)

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

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

Module 0 |

10

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 10 | All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport — Timeline

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Objectives

 Mobile Backhaul Transport Network (2/3/4G) standards bodies and terminology  Mobile Backhaul Transport Network physical topology options  How Alcatel-Lucent SROS-based products are used in the backhaul transport network  Backhaul Transport Network timing and synchronization requirements, protocols, and their configuration  Cell Site and Mobile Telephone Switching Office (MTSO) router TDM and Ethernet access interface configurations  Routing protocol use and configuration in the Backhaul Transport Network

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

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

Module 0 |

11

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 11 | All rights reserved © 2012 Alcatel-Lucent

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

After successful completion of this course, you will understand:

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport– Objectives (cont.)

 Mobile Backhaul Transport service deployment and configuration (VPWS, VPLS, VPRN)  Network resiliency requirements and configuration (VRRP, pseudowire redundancy, MC-LAG, MC-APS, BFD)  CLI OAM tools to verify network configuration and operation

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

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

Module 0 |

12

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 12 | All rights reserved © 2012 Alcatel-Lucent

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

After successful completion of this course, you will understand:

Prerequisites

• In order to fully appreciate the concepts to be discussed in this course, we strongly recommended that you successfully complete the following courses and certifications: • Alcatel-Lucent Scalable IP Networks • Alcatel-Lucent Interior Routing Protocols and High Availability • Alcatel-Lucent Multiprotocol Label Switching • Alcatel-Lucent Services Architecture • Alcatel-Lucent Network Routing Specialist II (NRS II) hands-on lab exam • Alcatel-Lucent Quality of Service

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

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

Module 0 |

13

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 13 | All rights reserved © 2012 Alcatel-Lucent

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

 Suggested Prerequisites

Follow On

• Based in the material covered in this course, we recommend that you follow this course with: • Alcatel-Lucent Mobile Gateways for the LTE Evolved Packet Core  Additionally, we encourage you to continue your efforts towards the Service Router Architect (SRA) certification status.

 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport Exam • Following successful completion of this course, and to ensure that you fully comprehend the material it covers, we recommend that you register for and take the Alcatel-Lucent IP/MPLS Mobile Backhaul Transport certification exam.

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

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

Module 0 |

14

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 14 | All rights reserved © 2012 Alcatel-Lucent

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

 Suggested Follow-on Courses

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

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

Module 0 |

15

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 15 | All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport - Introduction

Describe and implement the transport and services used in two current solutions to IP/MPLS Mobile Backhaul Transport bandwidth and service quality requirements, as major wireless service providers have deployed them.

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

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

Module 0 |

16

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 16 | All rights reserved © 2012 Alcatel-Lucent

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

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

Presentation Graphics

Service Packet

PE when block diagram used

PE

Payload Service Label MPLS Label Ethernet

Generic L2 Switch

SDP SAP SAP

Generic routers

Optical Transport UNI/NNI

7750 SR

Generic Base Station

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

7705 SAR

PRC

Pipe service or tunnel

Generic NC Element

Generic EPC Element

Module 0 |

17

MSC

All rights reserved © 2012 Alcatel-Lucent

Typical graphic symbols found in this courseware.

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

Module 0 - Page 17 | All rights reserved © 2012 Alcatel-Lucent

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

Network Cloud

Administration

 Registration  Restrooms  Communications  Materials  Schedule  Introductions • Name and Company • Experience • Familiarity with MPLS and Services

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

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

Module 0 |

18

All rights reserved © 2012 Alcatel-Lucent

Module 0 - Page 18 | All rights reserved © 2012 Alcatel-Lucent

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

 Facility Information

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

www.alcatel-lucent.com/src

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

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

Module 1 — IP/MPLS Mobile Backhaul Transport Network Architectures

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

Module 1 - Page 1 | All rights reserved © 2012 Alcatel-Lucent

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 IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

2

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 2 | All rights reserved © 2012 Alcatel-Lucent

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

Module Objectives

Module 1 — IP/MPLS Mobile Backhaul Transport Network Architectures

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

Section 1 — Mobile Backhaul Standards Bodies and Terminology

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

Module 1 - Page 3 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives

 Terminology used to describe the Mobile Backhaul transport architecture and components  The two Backhaul transport service provider types, their functions, and interfaces  Trends driving the consumer’s needs for increased mobile service features and bandwidth  Industry standards bodies defining the transport architecture and its operation

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

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

Module 1 |

4

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 4 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we will introduce:

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

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

Module 1 |

5

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 1 - Page 5 | All rights reserved © 2012 Alcatel-Lucent

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

What is the IP/MPLS Mobile Backhaul Transport?

The Mobile Backhaul Network: • Provides connectivity between Base Stations (BS) and Network Controllers (NC) and directly between 4G BSs. • May include TDM, SONET/SDH, ATM, and Ethernet access and network interfaces Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

6

All rights reserved © 2012 Alcatel-Lucent

Mobile Backhaul Transport Components The image above shows three functional areas of a backhaul transport network. These are: The Cell Site – Where the mobile Base Stations (BS) and Cell Site Aggregator (CSA) nodes are found. •The Base Stations (BS) The BS are the 2G Global Systems for Mobile (GSM) Base Transceiver Station (BTS), 3G Universal Mobile Telecommunications System (UMTS) or Code Division Multiple Access (CDMA) 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...

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

Module 1 - Page 6 | All rights reserved © 2012 Alcatel-Lucent

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

Mobile Backhaul Transport Components

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

7

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 7 | All rights reserved © 2012 Alcatel-Lucent

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

Mobile Backhaul Transport Components (cont)

Mobile Service Provider (MSP) network • The service provider owns the end-to-end network • The UNI-BS may be DS1/E1, ATM, or Ethernet • The UNI-NC may be ATM over SONET or Ethernet • The Transport Network may be Ethernet, EoS, or TDM Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

8

All rights reserved © 2012 Alcatel-Lucent

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 MGs and the network control functions. The MSP could own the transport network, as shown here, or lease capacity from a Backhaul Transport Provider (BTP). •MSP Aggregation Gateway (MG) The MG aggregates and grooms traffic received from multiple cells sites and delivers it to the network controllers. This device is also known as the Mobile Aggregation Site Gateway (MASG) or Multi-Level Switch (MLS). •MSP Termination Device (MT) The MT aggregates base station traffic and terminates the Mobile Backhaul network at the cell site. This is also know as the CSA, CSG, or the Demarcation device. •User Network Interface – Base Station (UNI-BS) Interface between the Base Station equipment and the MT. This could be wired or wireless - Ethernet, TDM, microwave, Digital Subscriber Line (DSL), or WiMAX. •User Network Interface – Network Control (UNI-NC) Interface between the MG and the network controllers. These are either Ethernet, ATM, or TDM interface.

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

Module 1 - Page 8 | All rights reserved © 2012 Alcatel-Lucent

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

Mobile Service Provider (MSP)

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

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

Module 1 |

9

All rights reserved © 2012 Alcatel-Lucent

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 BTP provisions and maintains the transport network, and may aggregate traffic for multiple MSPs. BTP Terminology •BTP Aggregation Gateway (BG) The BTP Aggregation Gateway (BG) could reside in the MTSO, part of the 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 MSPfacing interfaces. BTP transport services originate and terminate at the BT and the BG nodes. •User Network Interface – MG (UNI-MG) For a BTP customer, the interface between the BG and the MG. •User Network Interface – MT (UNI-MT) For a BTP customer, the interface between the MT and the BT.

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

Module 1 - Page 9 | All rights reserved © 2012 Alcatel-Lucent

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

Backhaul Transport Provider (BTP)

• In mobile networks, the term MG can stand for MSP Aggregation Gateway, Mobile Gateway, or Media Gateway • In the remainder of this course, we will use the term Multi-Layer Switch (MLS) in place of the term MSP Aggregation Gateway (MG) • This avoids confusion with the term Mobile Gateway (MG) used in LTE deployments • Both the term MG and MLS appear in our design documents, so both are valid to describe the SROS routers located in the MTSO

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

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

Module 1 |

10

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 10 | All rights reserved © 2012 Alcatel-Lucent

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

Course Note: Terminology - MLS versus MG

• 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

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

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

Module 1 |

11

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 11 | All rights reserved © 2012 Alcatel-Lucent

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

Course Note: Addressing

Mobile Backhaul Transport Standards Bodies

 The 3rd Generation Partnership Project (3GPP™) – www.3gpp.org  The 3GPP2 – www.3gpp2.org  The International Telecommunications Union – Telecommunications Sector (ITU-T)– www.itu.int/ITU-T  The Internet Engineering Task Force (IETF) – www.ietf.org  The Metro Ethernet Forum (MEF) – www.mef.org  The Institute of Electrical and Electronics Engineers (IEEE) – www.ieee.org  Next Generation Mobile Networks (NGMN), www.ngmn.org

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

Module 1 |

12

All rights reserved © 2012 Alcatel-Lucent

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

•

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

The following pages introduce these organizations.

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

Module 1 - Page 12 | All rights reserved © 2012 Alcatel-Lucent

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

Several organizations have developed standards and guidelines pertinent to the development and deployment of Mobile Backhaul transport architectures:

Standards Bodies: 3GPP

 Founded by the European Telecommunications Standards Institute (ETSI)  Originally described Global Systems for Mobile communication (GSM) networks  Release 8-10 specifications describe LTE networks  Describes Quality of Service (QoS) (R5) and radio time and frequency synchronization requirements (R8)

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

Module 1 |

13

All rights reserved © 2012 Alcatel-Lucent

Standard Bodies: 3GPP In 1998, the European Telecommunications Standards Institute (ETSI) founded the 3GPP to produce technical specifications and technical reports covering Global Systems for Mobile communication (GSM) core networks and radio access technologies. Later, the 3GPP became responsible for maintaining and developing technical specifications and reports for GSM General Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE) technologies. The term Universal Mobile Telecommunications System (UMTS) is a blanket term for all these technologies. 3GPP committees, know as Technical Specification Groups (TSGs) or Working Groups (WGs), develop the technical specifications that describe the GSM EDGE Radio Access Network (RAN) (the TSG GERAN), the Radio Access Network (TSG RAN), the services and systems aspects (TSG SA) and the core network and terminals (TSG CT). The 3GPP specification Release 8 become the design basis for current LTE networks, and Release 9 added a few enhancements. Notable is that 3GPP Release 8 and 9 LTE deployments adhere to the 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.

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

Module 1 - Page 13 | All rights reserved © 2012 Alcatel-Lucent

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

The 3GPP – www.3gpp.org

Standards Bodies: 3GPP2

 Produces Code Division Multiple Access (CDMA) network specifications  3G standards  cdma2000®  EV-DO Revision A  Describes QoS and synchronization requirements for CDMA networks

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

Module 1 |

14

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 14 | All rights reserved © 2012 Alcatel-Lucent

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

The 3GPP2 – www.3gpp2.org

Standards Bodies: ITU-T

 Core network functionality  Broadband service delivery  Next-generation services  Transport connectivity requirements, Operations, Administration and Maintenace (OAM) functions, and synchronization

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

Module 1 |

15

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 15 | All rights reserved © 2012 Alcatel-Lucent

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

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

Standards Bodies: IETF

 “The goal of the IETF is to make the Internet work better”, www.ietf.org  Develops Requests for Comments (RFC) defining Internet:  Applications – Virtual Private Wire Services (VPWS)  Protocols – Internet Protocol (IP)/Multi-Protocol Label Switching (MPLS)  Network Management – Simple Network Management Protocol (SNMP)  Routing – Open Shortest Path First (OSPF)

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

Module 1 |

16

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 16 | All rights reserved © 2012 Alcatel-Lucent

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

The IETF – www.ietf.org

Standards Bodies: MEF



“The defining body for Carrier Ethernet” www.mef.org



Defines architectures, protocols and management techniques for Metro Ethernet Networks (MEN)



Describes MEF-6 E-line and E-LAN and MEF-22 Mobile Backhaul over Ethernet

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

Module 1 |

17

All rights reserved © 2012 Alcatel-Lucent

Standard Bodies: MEF Formed in 2001, the MEF calls itself “The defining body for Carrier Ethernet”. [6] Their stated mission is to accelerate the worldwide adoption of Carrier-class Ethernet networks and services. An alliance of over 150 organizations, the MEF develops Carrier Ethernet specification and implementation agreements to support Carrier Ethernet interoperability worldwide. Metro Ethernet transport networks play a key role in 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 Ethernetbased networks, whether built over native Ethernet links or transported over Synchronous Optical Network (SONET) transmission media. •E-line – A point-to-point or multi-point Ethernet virtual private line services. The point-to-point service is called an Ethernet Private Line (EPL), and the multi-point service is called an Ethernet Virtual Private Line (EVPL) service. The difference between the EPL and EVPL is the difference between a 1:1 mapping of a BS physical port to a UNINC physical port (EPL) and a many-to-one mapping of multiple BS physical ports to a single UNI-NC port. The EVPL can be implemented by assigning unique VLAN tags to each BS and maintaining those mappings end-to-end. •E-LAN – Ethernet Private LAN (EP-LAN) and Ethernet Virtual Private LAN (EVP-LAN) services provide multi-point L2 switched connectivity between multiple BS and NC elements, and support BS-BS and BS-NC connectivity. These services act as virtual Ethernet broadcast domains, allows for BS-BS communications within the same service. Traffic destined for a BS on another E-LAN service must be routed. •Mobile Backhaul over Ethernet – MEF 22 is an implementation agreement that is intended to standardize equipment and services used in Ethernet-based mobile backhaul deployments. It includes:  Specifications for OAM functions based on established standards  Class-of-service definitions  Recommendations for resiliency  Usage cases as examples of backhaul scenarios – Non-ethernet UNI-BS and UNI-NC over Ethernet transport, and Ethernet UNI-BS and UNI-NC over Ethernet transport

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

Module 1 - Page 17 | All rights reserved © 2012 Alcatel-Lucent

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

The MEF – www.mef.org

Standards Bodies: IEEE



“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

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

Module 1 |

18

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 18 | All rights reserved © 2012 Alcatel-Lucent

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

The IEEE – www.ieee.org

Standards Bodies: NGMN Alliance



“the engine of broadband wireless innovation”



Aims to direct mobile broadband services to a single, integrated network



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

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

Module 1 |

19

All rights reserved © 2012 Alcatel-Lucent

Standard Bodies: NGMN Alliance The NGNM Alliance is organized to allow sharing between organizations information on broadband technologies focusing on LTE and EPC deployments and evolution. According to the website, www.ngnm.org, their mission is: 1. “To establish clear performance targets, fundamental including spectrum and deployment scenarios 2. To give guidance to equipment developers and standardization bodies, leading to the implementation of a costeffect network evolution 3. To drive implementation of NGMN recommendations and to avoid duplication of work, establish liaison statements, project-agreements as needed with SDOs and industry organisations 4. To provide a forum for the industry for presentation and early assessment of new technology trends and application enablers as they apply to LTE & EPC environment 5. To share experiences and lessons learnt from initial network deployments to further drive development by offering a management and leadership network e.g. by establishing open high-profile Industry Workshops 6. To actively drive communication raising public awareness on the 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

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

Module 1 - Page 19 | All rights reserved © 2012 Alcatel-Lucent

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

The NGMN Alliance – www.ngmn.org

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

Module 1 |

20

All rights reserved © 2012 Alcatel-Lucent

Evolution to all-IP Wireless Broadband Services – 3GPP The 3GPP standards covers the following technologies: 

2G GSM: Offers voice and Short Message Service (SMS) over a circuit-switched network.



GPRS: Adds a packet-switched network and offers Internet on mobile handsets.



EDGE : Allows improved data transmission rates and reduced latency over GPRS. Industry watchers labeled EDGE 2.75G.



3G UMTS: Uses Wideband-CDMA (W-CDMA) as its main radio technology. High Speed Packet Access (HSPA) offers improvement in UMTS spectrum efficiency. Evolved High Speed Packet Access (HSPA+) introduces new functionalities and allows 40 Mbps downlink speeds and 10 Mbps uplink speeds.



4G LTE: Offers a throughput of 100Mbps in the downlink and 50Mbps in the uplink.

The evolution of the radio access and mobile core network was needed to support the requirements of the new services and applications. End users now have access to various types of content-rich and real-time applications. The transport network is also evolving from traditional TDM to an all-IP Ethernet network.

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

Module 1 - Page 20 | All rights reserved © 2012 Alcatel-Lucent

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

Evolution to all-IP Wireless Broadband Services – 3GPP

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

Module 1 |

21

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 21 | All rights reserved © 2012 Alcatel-Lucent

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

Evolution to all-IP Wireless Broadband Services – 3GPP2

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

Module 1 |

22

All rights reserved © 2012 Alcatel-Lucent

3GPP Releases Towards LTE – Key Milestones 3GPP work is organized into releases. Every release offers many new and improved functionalities. The main functionalities with respect to the evolution of the mobile core are summarized below: • R4 introduces NGN (Next Generation Network). NGN is a packet-based network that transports all information as IP packets. • R5 introduces IMS (IP Multimedia Subsystem) and HSDPA (High Speed Downlink Packet Access). 

IMS is an architectural framework for delivering IP multimedia services to various access networks. The IMS provides support for multimedia sessions based on SIP (Session Initiation Protocol).



HSPA (High Speed Packet Access) extends and improves the performance of W-CDMA. HSPA includes 2 protocols, the High Speed Downlink Packet Access (HSDPA) and the High Speed Uplink Packet Access (HSUPA). Many HSPA rollouts can be achieved by a software upgrade to existing 3G networks.

• R6 introduces HSUPA and IP QoS and adopts the all-IP packet networks. • R7 introduces Policy and Charging Rules Function (PCRF), Direct Tunnel and Evolved High Speed Packet Access (HSPA+) 

PCRF: Designed for both 3G and 4G/LTE Evolved Packet Core networks, the PCRF controls the interaction of users and applications with the network, in order to satisfy different services with different quality of service levels and charging rules.



Direct Tunnel allows the data path to bypass the SGSN node.



HSPA+ provides higher data rates with multiple input, multiple output technologies.

• R8 introduces LTE 

Covers the S3, S4 and S12 logical interfaces that are needed to provide interworking of LTE with existing UMTS/HSPA radio networks.

• R9 focuses on LTE/EPC enhancements 

Due to an aggressive schedule, R8 was limited to essential features hence the R9’s focus on enhancements.

• R10 introduces LTE Advanced 

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

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

Module 1 - Page 22 | All rights reserved © 2012 Alcatel-Lucent

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

3GPP Releases Towards LTE – Key Milestones

Section Summary

In this section, we learned:  The two Mobile Backhaul customer types; the MSP and the BTP  The Mobile Backhaul Transport standards bodies  Trends driving the move to higher capacity backhaul networks

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

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

Module 1 |

23

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 23 | All rights reserved © 2012 Alcatel-Lucent

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

 The purpose and use of the Mobile Backhaul Transport Network

Module 1 — IP/MPLS Mobile Backhaul Transport Network Architectures

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

Section 2 — Backhaul Service Architectures

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

Module 1 - Page 25 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives

 Model 1 – Hub and spoke  Virtual Private Wire Services (VPWS) transporting cell site traffic into MLS Local VPLS and VPRN Services  Model 2 – Subtended ring  VPWS transporting cell site traffic into Distributed Virtual Private Routed Network (VPRN) services We will use these models as guides as we study the protocols and services that create the Mobile Backhaul Transport Network.

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

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

Module 1 |

26

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 26 | All rights reserved © 2012 Alcatel-Lucent

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

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

• Hub and spoke – redundant, point-to-point services transport between CSA and MLS • MLS routers are the hub nodes and points of greatest traffic concentration • CDMA or GSM/UMTS • LTE-ready with E-line or E-LAN services Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

27

All rights reserved © 2012 Alcatel-Lucent

Backhaul Network Physical Topologies – Hub and Spoke A backhaul topology can take many forms and incorporate many different physical layer technologies. The topology used depends on the 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 UNIMT and UNI-MG. There is no routing in the BTP network, only point to point connections from the cell sites to the MTSO. For Ethernet base stations, the UNI-BS and UNI-NC are 100Mb/s or 1Gb/s Ethernet ports. For ATM and TDM BS, the UNI-BS is SONET/SDH or bundled DS1s/E1s and the UNI-NC is ATM over SONET or Ethernet. The UNI-MT and UNI-MG could be either Ethernet, TDM, or SONET/SDH.

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

Module 1 - Page 27 | All rights reserved © 2012 Alcatel-Lucent

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

Backhaul Network Physical Topologies – Hub and Spoke

• Ring/Subtended ring – partial or full mesh logical connectivity between CSA and MLS • Subtended ring - Rings of greater traffic concentration nearer the MTSO • Rings provide physical and logical path redundancy and dual-homing capability Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

28

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 28 | All rights reserved © 2012 Alcatel-Lucent

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

Backhaul Network Physical Topologies – Ring/Subtended Ring

• Points of concentration – higher capacity nodes are located closer to the MTSO • Helps reduce costs and complexity by placing lower cost nodes nearer to cell site Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

29

All rights reserved © 2012 Alcatel-Lucent

Points of Concentration The Points of Concentration (POC) illustrate traffic concentration, or aggregation, levels. As traffic flows downstream from the MTSO to the cell site, each POC level handles smaller aggregated traffic flows. POC1 A POC1 (MLS) routers aggregate RNC, BSC, and EPC traffic for hundreds and possibly up to a thousand cell sites. The POC1 routers must be highly reliable and support very high data rates, on average greater than 10Gbps. The MLS routers provide redundant NC element links and load balance cell traffic between the redundant MLS pairs. POC2 The aggregate ring POC2 routers concentrate traffic for an average of 50 to 60 cell sites, delivering toward the POC3 routers an average of up to 500Mbps of traffic. They typically serve as MPLS LSRs, and may connect 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.

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

Module 1 - Page 29 | All rights reserved © 2012 Alcatel-Lucent

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

Points of Concentration (POC)

• One-sector cell site average downlink bandwidth requirements • Common three-sector site – multiply the one-sector bandwidth requirement by 1.5-2.0 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

30

All rights reserved © 2012 Alcatel-Lucent

Cell Site Average Downlink Data Rates For TDM and ATM backhaul, the cell site traffic requirements are typically stated in terms of the aggregate number of E1/T1 links. Typically, 1-2 E1/T1 links are required for 2G and 3G voice and low speed data per BS, plus additional capacity for high speed data according to demand. For IP backhaul, the aggregate traffic requirements at a cell site will depend on the technology and service mix at the site. The table above gives representative average peak downlink requirements for a one-sector cell site. The number of users a cell site can support varies depending on the type of traffic, location, population density, and so forth, and can range from as few as 50 to over 100 users. Cell site sectors A sector is a channel or frequency. A transmission technology enables a set of frequencies, and a cell 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.

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

Module 1 - Page 30 | All rights reserved © 2012 Alcatel-Lucent

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

Cell Site Average Downlink Data Rates

Model 1 – Example Physical Architecture • This model employs a hub and spoke design • It supports both legacy IPBH traffic forwarded over bundled DS1s and EBH over Ethernet and EoS • Leased BTP access provides the backhaul transport Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

31

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 31 | All rights reserved © 2012 Alcatel-Lucent

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

Model 1 – Hub and Spoke Topology

Model 1 - Ethernet Backhaul (EBH) - ePipes • 3G voice, data and OAM ePipes terminate into MLS VPLSs • VPLS-VPRN cross-connect forwards traffic toward NC elements Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

32

All rights reserved © 2012 Alcatel-Lucent

Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet Traffic Ethernet Backhaul (EBH) - ePipes EBH supports 2 and 3G voice and data over an Ethernet transport. At the CSA, E-Line, or ePipe services, accept 802.1Q-tagged Ethernet base station traffic on an access port. The base station forwards traffic on three VLANs; one for 1x voice, another for DO data, and another for OAM traffic. The CSA passes these frames to one of three individual ePipe services, one for each traffic type, passes the tunneled traffic to the MEN, and the MEN delivers it to the MLS router. Outer VPLS At the MLS router, the ePipes terminate into one of three E-LAN, or Virtual Private LAN Service (VPLS), one for each traffic type. The outer VPLS ties the base station ePipes into Ethernet broadcast domains. All base station VLANs of the same traffic type terminate in a common outer VPLS, and the base station interface addresses come from a common subnet, typically /29. A VPLS can support several hundred spoke-SDPs, and so each VPLS could support 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. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 - Page 32 | All rights reserved © 2012 Alcatel-Lucent

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

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

ePipes “spoked” into VPLS • Each NodeB interface has /27 address • Only one VPRN interface per subnet • Smaller VRF size, but added complexity of VPLS Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

33

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 33 | All rights reserved © 2012 Alcatel-Lucent

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

ePipe Spoke to MLS Service – VPLS 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

34

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 34 | All rights reserved © 2012 Alcatel-Lucent

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

ePipe Spoke to MLS Service – VPRN Termination

R-VPLS takes the place of the VSM or external cross-connects • For routed connectivity, a VPLS may be bound to a single Layer 3 service interface • This interface becomes the gateway to the VPLS broadcast domain • The VPLS must be named and bound to the L3 interface by that name Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

35

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 35 | All rights reserved © 2012 Alcatel-Lucent

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

R-VPLS for VPLS to VPRN Service cross connect

Model 1 – Hub and Spoke Topology – iPipes

Model 1 - Ethernet Backhaul (EBH) - iPipes • 3G iPipes cross-connect into MLS VPRN interfaces • Carried over same transport as are ePipes Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

36

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 36 | All rights reserved © 2012 Alcatel-Lucent

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

EPC

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

37

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 37 | All rights reserved © 2012 Alcatel-Lucent

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

iPipe to MLS Service – Cross-connect 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

38

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 38 | All rights reserved © 2012 Alcatel-Lucent

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

iPipe to MLS Service – Spoke VPRN Termination

Model 1 - IP Backhaul (IPBH) • 2G IPBH traffic transported over bundled DS1s • Bundled DS1s terminate into VPRN interfaces Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

39

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Hub and Spoke Topology - IPBH IP Backhaul (IPBH) IPBH supports 2G and 3G voice and data traffic transported over TDM links. The BS forwards ML-PPP frames to the Digital Access Cross-Connect (DACS). The DACS multiplexes cell site traffic over Multi-chassis Automatic Protection Switching (MC-APS) protected OC-3 or OC-12 circuits. The working and protect 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.

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

Module 1 - Page 39 | All rights reserved © 2012 Alcatel-Lucent

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

Model 1 - Hub and Spoke Topology - IPBH

Model 1 - 4G LTE • 4G ePipes terminate into MLS IES • BS-BS traffic routed through MLS IESs • MME VRRP interface supported through MLS local VPLS Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

40

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 40 | All rights reserved © 2012 Alcatel-Lucent

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

Model 1 – 4G/LTE Services

Model 2 – Physical Architecture • • • •

Subtended Ring topology; access and aggregation rings VPWS transport 2 and 3G legacy traffic to MLS routers VPWS spoked to POC3 distributed VPRN for 3G and 4G Ethernet traffic POC2 routers are service-transparent LSRs

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

Module 1 |

41

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 41 | All rights reserved © 2012 Alcatel-Lucent

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

Model 2 – Subtended Ring Topology

Model 2 - Cell Site to MLS Base Connectivity • Access and aggregation rings are in separate ISIS areas • LSPs run between CSAs and POC3 routers, and between POC3 and POC1 routers • Psuedowire switching tunnels traffic across area boundaries Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

42

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 42 | All rights reserved © 2012 Alcatel-Lucent

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

Model 2 – Subtended Ring Topology – Logical Connectivity

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

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

Module 1 |

43

All rights reserved © 2012 Alcatel-Lucent

Model 2 – Subtended Ring Topology – EBH Services Backhaul 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...)

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

Module 1 - Page 43 | All rights reserved © 2012 Alcatel-Lucent

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

Model 2 – Subtended Ring Topology – EBH 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

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

Module 1 |

44

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 44 | All rights reserved © 2012 Alcatel-Lucent

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

Model 2 – Subtended Ring Topology – Legacy Services

BTS

Switches service traffic from one SDP to another at intermediate node • Reduces full mesh requirement between CSA and MLS routers • Connects traffic engineered LSPs across routing areas • Requires vc-switching configured in S-PE service context Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

45

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 45 | All rights reserved © 2012 Alcatel-Lucent

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

Pseudowire Switching on VPWS

Model 2 - Timing and Synchronization – SyncE and SSM • MLS1 distributes network timing from Primary Reference Clock (PRC) • Nodes use Synchronous Ethernet (SyncE) for TDM interface and NodeB/eNodeB RF timing • Nodes forward Synchronization Status Message (SSM) messages for clock traceability Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

46

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 1 - Page 46 | All rights reserved © 2012 Alcatel-Lucent

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

Model 2 – Subtended Ring Topology (cont)

 Resilient hub and spoke topology  Support for 2, 3 and 4G services  Overlay services possible over same infrastructure  Scalable to thousands of base stations Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

47

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 1 - Page 47 | All rights reserved © 2012 Alcatel-Lucent

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

Model 1 Network Key Design Points

 Efficient, resilient 2, 3 and 4G connectivity  Scalable - Dynamic cell site learning  Efficient eNodeB to eNodeB routing Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

48

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 1 - Page 48 | All rights reserved © 2012 Alcatel-Lucent

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

Model 2 Network Key Design Points

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

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

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

Module 1 |

49

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 49 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Section Summary (cont)

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

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

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

Module 1 |

50

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 50 | All rights reserved © 2012 Alcatel-Lucent

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

 The Model 1 architecture – Hub and Spoke to provide:

Section Summary (cont)

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

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

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

Module 1 |

51

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 51 | All rights reserved © 2012 Alcatel-Lucent

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

 The Model 2 architecture – Subtended Ring to provide:

Module 1 — IP/MPLS Mobile Backhaul Transport Network Architectures

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

Section 3 — Mobile Backhaul Transport Network Components

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

Module 1 - Page 53 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives

 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

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

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

Module 1 |

54

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 54 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we will:

Alcatel-Lucent’s Mobile Backhaul Solution

 Suitable to either MSP or BTP customer  Leverage existing physical network  Supports array of access technologies  Support for 2, 3, and 4G backhaul 7750 SR Family

7450 ESS Family

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

7705 SAR Family

Module 1 |

55

7210 SAS Family

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 1 - Page 55 | All rights reserved © 2012 Alcatel-Lucent

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

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

Alcatel-Lucent supports the Backhaul Transport Network end-toend with a wide range of service router products Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

56

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 56 | All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent Product Placement

Alcatel-Lucent supports the Backhaul Transport Network end-toend with a wide range of service router products Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

57

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Product Placement (cont) POC3 The POC3 routers may either originate and terminate MSP or BTP Layer 2 and 3 VPN services, or act as an MSP or BTP LSR, forwarding traffic through the transport network. For the MSP that owns the transport network, the POC3 routers aggregate traffic from multiple CSAs. For a BTP, the POC3 routers may aggregate multiple MSPs’ cell site traffic into VPWS SAPs, Ethernet VLANs, or TDM uplinks. These routers handle average aggregate cell site traffic of 200Mbps, and support MPLS FRR, Ethernet OAM, Ethernet timing distribution, control and data plane redundancy and TDM and Ethernet ports. They are highly available and may be temperature hardened. The CSA Router The CSA router performs TDM and Ethernet media conversion, and acts as an MSP Provider Edge (PE) router, originating the cell site VLL or VPRN services. For an MSP connected through a BTP, the CSA router consolidates BS traffic for delivery into the leased Ethernet or TDM circuits. The CSA must deliver reference timing to the TDM interfaces, including the BTS or NodeB. It supports end-to-end QoS and OAM functionality. The CSA handles average cell site traffic of 50Mbps, and supports MPLS FRR, Ethernet OAM, TDM and Ethernet access ports, Link State routing protocols, and BFD. It is temperature hardened and may include high availability features.

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

Module 1 - Page 57 | All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent Product Placement (cont)

Alcatel-Lucent 7750 SR-7 and SR-12

250 Gb/s FD capacity

7750 SR-12

500 Gb/s FD capacity

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

58

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 58 | All rights reserved © 2012 Alcatel-Lucent

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

7750 SR-7

58

Alcatel-Lucent 7750 SR-c12

45 Gb/s FD capacity

The 7750 SR-c12 is ideal for POC1 and POC2 roles • High availability – Redundant control, power, and cooling • 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

59

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent 7750 SR-c12 At POC1 or POC2, the Alcatel-Lucent 7750 SR-c12 platform is ideal when the greater port density of an SR-7 or SR12 is not required. Features (9.0R2): •Cooling, power and control plane redundancy •IPv4 and IPv6 BGP, ISIS, and OSPF support •Full SR-OS feature set •Full featured MPLS support – FRR, RSVP-TE, Label Distribution Protocol over Resource Reservation Protocol (LDPoRSVP) tunnels, inter-area RSVP-TE •Full SROS service set – VPRN, VPLS, VLL (aPipe, cPipes, ePipe, fPipe, iPipe), redundant pseudowires, pseudowire switching, Routed-VPLS (R-VPLS) •Line rate (4 Gb/s/CMA, 10Gb/s MDA) filter, routing and QoS policy processing •Highly scalable routing and forwarding databases •Multiple access technologies support: TDM, ATM, 10Gb/s Ethernet •IP, MPLS and Ethernet OAM and service assurance tools

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

Module 1 - Page 59 | All rights reserved © 2012 Alcatel-Lucent

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

7750 SR-c12

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

80 Gb/s FD capacity

7450 ESS-7

7450 ESS-12

250 Gb/s FD capacity

500 Gb/s FD capacity

The 7450 ESS-6, -7, and -12 are ideal for POC2 and POC3 roles • High availability – Redundant control, power, and cooling • Support for modular upgrades • 1 and 10 Gb/s Ethernet support • Investment protection through mixed mode (ESS and SR features) support Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

60

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent 7450 ESS-6, ESS-7 and ESS-12 At POC2 and POC3, the routers must provide resilient control planes and modularity to support additional interfaces and grow with the service mix. They must leverage high capacity rings, and be optimized to support fiber optic links. The Alcatel-Lucent 7450 ESS-6, -7, and -12 platforms are ideal in this application. Common features (9.0R2): •Cooling, power and control plane redundancy •Load sharing and redundant dual switch fabric modules supporting graceful degradation •IPv4 ISIS and OSPF support Full featured MPLS support – FRR, RSVP-TE, Label Distribution Protocol over Resource Reservation Protocol (LDPoRSVP) tunnels, inter-area RSVP-TE •Full Ethernet service set support –VPLS, ePipe, redundant pseudowires, pseudowire switching, Routed-VPLS (RVPLS) •Line rate filter, routing and QoS policy processing •Highly scalable routing and forwarding databases •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

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

Module 1 - Page 60 | All rights reserved © 2012 Alcatel-Lucent

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

7450 ESS-6/6V

Alcatel-Lucent 7705 SAR Family

1 Gb/s FD capacity

7705 SAR-8

7705 SAR-18

6 Gb/s FD capacity

70 Gb/s FD capacity

• The 7705 SAR-F is ideal for CSA role • The 7705 SAR-8 is ideal for POC3 and CSA roles • The 7705 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 1 |

61

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent 7705 SAR-8 and SAR-18 At the cell site the routers must be compact, temperature hardened, rugged, low cost, and provide an appropriate mix of interfaces for multiple generations of base stations and media. SAR-F, SAR-8, and SAR-18 common features (4.0R2): •IPv4 BGP, ISIS, and OSPF support, IPv6 interfaces and static routes •Full featured MPLS support – FRR, RSVP-TE, primary and secondary LSP paths, Shared Risk Link Groups (SRLG) •SROS service set support –VPRN, VPLS, VLL (aPipe, cPipes, ePipe, iPipe), redundant pseudowires, pseudowire switching •Media conversion supporting multiple access technologies: TDM, ATM, Ethernet, ML-PPP •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

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

Module 1 - Page 61 | All rights reserved © 2012 Alcatel-Lucent

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

7705 SAR-F

7210 SAS-D

7210 SAS-E

7210 SAS-M

Up to 10 Gb/s FD capacity

Up to 24 Gb/s FD capacity

Up to 64 Gb/s FD capacity

The 7210 SAS family is ideal for the CSA role • Low cost and rugged - ETR variants available • Up to 64 Gb/s switching fabric on SAS-M 10GigE model • Support for TDM and Ethernet interfaces

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

Module 1 |

62

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent 7210 SAS-E, M, and D 7210 SAS features (3.0R3): •SAS-D with 6 fixed Gigagit Ethernet SFP ports and 4 fixed 10/100/1000Base-TX copper ports •SAS-E with 12 fixed Gigabit Ethernet SFP ports and 12 fixed 10/100/1000Base-TX copper ports •SAS-M, SAS-M 10Gigabit Ethernet, and SAS-M 10Gigabit Ethernet-ETR variants available  Extended temperature range variants available  44 Gb/s and 64 Gb/s (10GigE variant) switching capacity  4 x T1/E1 expansion module available (standard SAS-M) Common features: •Compact, edge devices •SROS based operating system •Layer 2 VPN support: VPLS, ePipe; SAS-M - cPipe •H-QoS •MPLS support (SAS-M) •SyncE and IEEE 1588v2 support

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

Module 1 - Page 62 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 1 |

63

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 1 - Page 63 | All rights reserved © 2012 Alcatel-Lucent

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

Lab 1: Verify the Model 1 Ethernet Transport

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

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

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

Module 1 |

64

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 64 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Module Summary

 The names and descriptions of the network elements found in the cell sites, the transport network, and in the MTSO  Of the two Backhaul Transport customer types – the Mobile Service Provider (MSP) and the Backhaul Transport Provider (BTP)  The demarcation points between the BTP and the MSP networks  Key services provided by Mobile Backhaul Transport standards bodies  Factors which have driven the move toward a converged Backhaul Transport architecture  Of two Backhaul Transport architectures in use today – hub and spoke and subtended ring  The traffic aggregation levels provided by the network nodes

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

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

Module 1 |

65

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 65 | All rights reserved © 2012 Alcatel-Lucent

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

In this module, we learned:

Module Summary (cont) In this module, we learned:

 The services used to aggregate traffic from hundreds of cells sites at the MLS routers – VPLS and VPRN  Redundancy capabilities available to both hub and spoke and subtended ring topologies  Timing and synchronization options available for both TDM and RF timing  Where the SROS products fit in the listed concentration levels  7750 SR-7, -12 and -c12 at POC1 and 2  7450 ESS-6, -7, and -12 at POC2 and 3  7705 SAR at POC3 and CSA  7210 SAS at CSA Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

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

Module 1 |

66

All rights reserved © 2012 Alcatel-Lucent

Module 1 - Page 66 | All rights reserved © 2012 Alcatel-Lucent

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

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

Module Review Questions

a) Base Station Controller (BSC) b) Radio Network Controller (RNC) c) Serving Gateway (SGW) d) Policy and Charging Rules Function (PCRF) 2. Which two NC elements are found in the Evolved Packet Core (EPC)? (choose two) a) Serving Gateway (SGW) b) Gateway GPRS Support Node (GGSN) c) Mobile Switching Center (MSC) d) Mobility Management Entity (MME)

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

Module 1 |

67

All rights reserved © 2012 Alcatel-Lucent

Answers: 1. a, b 2. a, d

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

Module 1 - Page 67 | All rights reserved © 2012 Alcatel-Lucent

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

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

3. Which statement is a true characteristic of a Backhaul Transport Provider (BTP)? a) The BTP owns the entire network, end-to-end b) The BTP owns the BTP Aggregation Gateway and the BTP Termination devices c) The 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)

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

Module 1 |

68

All rights reserved © 2012 Alcatel-Lucent

Answers: 3. B 4. a, b

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

Module 1 - Page 68 | All rights reserved © 2012 Alcatel-Lucent

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

Module Review Questions (cont)

Module Review Questions (cont)

5. Which standards body developed the current LTE network specifications? 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

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

Module 1 |

69

All rights reserved © 2012 Alcatel-Lucent

Answers: 5. D 6. c

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

Module 1 - Page 69 | All rights reserved © 2012 Alcatel-Lucent

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

a) ITU-T

Module Review Questions (cont)

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

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

Module 1 |

70

All rights reserved © 2012 Alcatel-Lucent

Answers: 7. a, c, d 8. a, d.

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

Module 1 - Page 70 | All rights reserved © 2012 Alcatel-Lucent

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

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

Module Review Questions (cont)

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

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

Module 1 |

71

All rights reserved © 2012 Alcatel-Lucent

Answers: 9. a. 10. a.

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

Module 1 - Page 71 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 1 |

72

All rights reserved © 2012 Alcatel-Lucent

Answers: 11. b. 12. c.

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

Module 1 - Page 72 | All rights reserved © 2012 Alcatel-Lucent

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

a) Terminate all cell site tunnels on only one of the MLS routers

Module Review Questions (cont)

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

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

Module 1 |

73

All rights reserved © 2012 Alcatel-Lucent

Answers: 13. c. 14. b.

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

Module 1 - Page 73 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 1 |

74

All rights reserved © 2012 Alcatel-Lucent

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

www.alcatel-lucent.com

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

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

Module 2 — Implementing the Mobile Backhaul Transport Network

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

Module 2 - Page 1 | All rights reserved © 2012 Alcatel-Lucent

Module Objectives

 VLAN Tagging  Port MTU  Port hold timers  Describe TDM access port components and configuration  SONET/SDH framing formats  SONET/SDH hierarchical payload transport  Channelized and unchannelized OC-x/STM-x port build out  Provision ATM IMA and ML-PPP bundles for services access  View the completed bundle configuration and status

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

Module 2 |

2

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Mobile Backhaul Transport Network This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See www.alcatellucent.com/src for more information on the SRC program. To locate additional information relating to the topics presented in this manual, refer to the following:  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

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

Module 2 - Page 2 | All rights reserved © 2012 Alcatel-Lucent

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

Upon successful completion of this module, you will be able to:  Describe Backhaul Ethernet access port components and configuration

Module Objectives (cont)

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

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

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

Module 2 |

3

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 3 | All rights reserved © 2012 Alcatel-Lucent

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

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

Module Objectives (cont) Upon successful completion of this module, you will be able to:

 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

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

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

Module 2 |

4

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 4 | All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 — Implementing the Mobile Backhaul Transport Network

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

Section 1 — Mobile Backhaul Service Access Interfaces

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

Module 2 - Page 5 | All rights reserved © 2012 Alcatel-Lucent

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

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

Module 2 |

6

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 6 | All rights reserved © 2012 Alcatel-Lucent

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

Section Objectives

A base station, an NC element, or the transport network may require the following Ethernet port configurations:  VLAN tagging  Large or small frame size support  Fixed port speed and duplex settings  Port hold time settings

7705 SAR 8-Port GigE/FastE Ethernet MDA v2 Part number 3HE02776AB

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

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

Module 2 |

7

All rights reserved © 2012 Alcatel-Lucent

7x50 Ethernet Port Configuration The BS and NC elements gain access to the Backhaul Transport services through router access ports. When an Ethernet transport interconnects the CSA and POC routers, router network ports move traffic up and downstream. Where the network elements require Ethernet connectivity, the designer must configure the router network and access ports to suit the traffic delivered into and out of the backhaul services. A number of factors come into play when choosing how to configure the Ethernet ports. The type of devices connected to the UNI-BS and UNI-NC, the CSA and MLS physical capabilities, the deployed service types, and the service and network port MTUs all have a bearing on the access port configurations. For example, a NodeB may only accept 100Mb/s half-duplex links, where an eNodeB requires 1Gb/s full duplex. Alcatel-Lucent solutions design teams work from a set of blueprint documents when planning for a 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.

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

Module 2 - Page 7 | All rights reserved © 2012 Alcatel-Lucent

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

7x50 Ethernet Port Configuration

Ethernet network port encapsulation type can be configured as one of the following:  null – no tags, all traffic on that port is on the same VLAN  dot1q – accepts a 4 byte VLAN tagged frame Additionally, on access ports, all products but the 7705 SAR support:  qinq - adds two stacked VLAN TAGs

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

Module 2 |

8

All rights reserved © 2012 Alcatel-Lucent

Ethernet Port Encapsulation Not 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.

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

Module 2 - Page 8 | All rights reserved © 2012 Alcatel-Lucent

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

Ethernet Port Encapsulation

Ethernet Port MTU Size

Eth. Frame

Bytes

Network

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

Tunnel

4

4

4

PW Header

4

4

4

CW (opt)

4

4

4

12

12

4

4

RTP Header (opt) Payload

1500

FCS

1500

1500

1514

1518

1514

1518

1552

1560

4 Total:

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

Module 2 |

9

All rights reserved © 2012 Alcatel-Lucent

Ethernet Port MTU Size MTU The port MTU determines the largest Layer 2 PDU the router can accept on a port. Each encapsulation type sets a unique default MTU size to allow for the additional VLAN tag header fields, as required. The routers do not count the Frame Check Sequence (FCS) in the MTU calculated, and the MTU is CLI configurable. On network ports, the MTU needs to allow for MPLS tunnel and service labels and control words. The 7x50 routers will not fragment Layer 2 service payloads, so the network port MTUs must be sufficiently large to carry the largest customer payload plus overhead. Layer 3 services transport just the packet, and IP allows fragmentation. Control Word (CW) and Real-Time Transport Protocol (RTP) Header When transporting ATM and TDM services across an Ethernet/MPLS core, the edge routers may set an MPLS Control Word and RTP header. In an ATM service, the control word is optional, but supports packet reordering when the circuit requires it. For example, if an aPipe requires packet reordering, the ingress PE router will set a control word with flags, a sequence number and a length field. The control word goes between the payload and the service header, and is 4 bytes long. For a cPipe transporting structured (channelized) DS0s, RFC 5086 requires that a control word accompany the payload. Additionally, this RFC allows for an RTP header when timing information must be transported along with the payload. The RTP header carries a timestamp and a sequence number, and is 12 bytes long.

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

Module 2 - Page 9 | All rights reserved © 2012 Alcatel-Lucent

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

Access

Configuring an Ethernet Access Port

Syntax: Syntax:

[no] [no] mode mode {access|network|hybrid} {access|network|hybrid} [no] [no] encap-type encap-type {dot1q|null|qinq} {dot1q|null|qinq} [no] [no] autonegotiate autonegotiate [limited] [limited] speed speed {10|100|1000} {10|100|1000} duplex duplex {full|half} {full|half} [no] [no] mtu mtu mtu-bytes mtu-bytes

Example: Example: config# config# port port 1/1/3 1/1/3 config>port# config>port# ethernet ethernet config>port>ethernet# config>port>ethernet# mode mode access access config>port>ethernet# config>port>ethernet# encap-type encap-type dot1q dot1q config>port>ethernet# config>port>ethernet# autonegotiate autonegotiate limited limited config>port>ethernet# config>port>ethernet# speed speed 100 100 config>port>ethernet# config>port>ethernet# duplex duplex half half config>port>ethernet# mtu config>port>ethernet# mtu 1518 1518 config>port>ethernet# config>port>ethernet# back back config>port# config>port# no no shutdown shutdown

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

Module 2 |

10

All rights reserved © 2012 Alcatel-Lucent

Configuring an Ethernet Access Port Port Mode The port mode determines the encapsulation options. A hybrid port can be both an access and a network port, and is available only on the 7750 and 7450 products A:NodeA# configure port 1/1/3 ethernet mode access  Port encapsulation Dot1q or null for network ports; dot1q, null or qinq (except 7705 SAR) for access ports. A:NodeA# configure port 1/1/3 ethernet encap-type dot1q  Autonegotiation Some circumstances dictate that the port have auto-negotiation shut down. A base station may require fixed duplex and speed settings, or, if a port is a LAG member, the LAG configuration requires that the port have full auto-negotiate disabled. Limited autonegotiate allows the endpoints to indicate the fixed port speed and duplex when the link comes up. A:NodeA# configure port 1/1/3 ethernet autonegotiate limited  Speed and duplex Set when autonegotiate is disabled or limited. A:NodeA# configure port 1/1/3 ethernet speed 100  A:NodeA# configure port 1/1/3 ethernet duplex half  MTU Adjust to suit the connected network and services. A:NodeA# configure port 1/1/3 ethernet mtu 1518 

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

Module 2 - Page 10 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>port>ethernet config>port>ethernet

The port hold time holds down ports connected to flapping links • Allow network to stabilize before transitioning a port’s operational state • Example: On all network ports: A:NodeA>config>port>ethernet# hold-time up 5

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

Module 2 |

11

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 11 | All rights reserved © 2012 Alcatel-Lucent

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

Ethernet Network Port Hold Time

7x50 TDM Port Configuration

    

SONET or SDH framing Path configuration – STS3, STS1, DS3, DS1, vt15, vt2 ATM/IMA or MLPPP bundles Timing 1+1 Single-chassis/Multi-chassis APS

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

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

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

Module 2 |

12

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 12 | All rights reserved © 2012 Alcatel-Lucent

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

A base station, an NC element, or the transport network may require the following TDM port configurations:

SONET and SDH are related standards used for IPBH and in the MEN • SONET in the US, initiated by Bellcore and standardized by the American National Standards Institute (ANSI) • SDH is the ITU international version Both define optical and electrical characteristics for transporting voice and data traffic over a high speed, optical transport

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

Module 2 |

13

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 13 | All rights reserved © 2012 Alcatel-Lucent

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

SONET and SDH in the Backhaul Transport

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

Module 2 |

14

All rights reserved © 2012 Alcatel-Lucent

SONET and SDH Signal Levels and Line Rates The table above lists and compares STS-n and STM-n frame line rates. Rates are defined as integer multiples of the base STS-1 and STM-1. The most widely implemented rates are: •STS-1 – 51.84 Mb/s •OC/STS-3/STM-1 – 155.52 Mb/s •OC/STS-12/STM-4 – 622.08 Mb/s •OC/STS-48/STM-16 – 2488.32 Mb/s •OC/STS-192/STM-64 – 9963.28

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

Module 2 - Page 14 | All rights reserved © 2012 Alcatel-Lucent

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

SONET and SDH Signal Levels and Line Rates

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

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

Module 2 |

15

All rights reserved © 2012 Alcatel-Lucent

SONET/SDH Overview Basic STS-1 Frame The basis STS-1 frame is 810 bytes long, and typically illustrated as 9 rows of 90 columns each, each column one byte wide. The sender transmits the frame by rows and in bit order, meaning that it sends row 1, bit 0 first, then row 1, bit 1, and so forth. SONET transmits each frame in 125us for a data rate of 51.840 Mb/s. The frame includes 27 overhead bytes, for an effective payload data rate of 49.536 Mb/s. SONET Frame Overhead Each frame includes 27 bytes of frame overhead, called the Transport Overhead (TOH). The TOH includes the Section Overhead (SOH) and the Line Overhead (LOH):  SOH - 9 bytes; The SOH occupies the first 3 bytes in the first 3 rows transmitted, and handles point-to-point communications, performs framing, and STS-n performance monitoring  LOH – 18 bytes; The LOH uses the first 3 bytes in the remaining 6 rows. It handles individual STS-1 performance monitoring, provides data channels for OAM&P, includes pointers to identify where the payload is located in the frame, supports APS, and alarming functions. SONET Payload The SONET frame payload is the Synchronous Payload Envelope (SPE). The sender includes Path overhead (POH) with each payload, and the POH remains with the payload until the receiver de-multiplexes it. The POH is 9 bytes, and included bits that identify the path and its status. The path is the media and NEs between the payload’s assembly and disassembly.

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

Module 2 - Page 15 | All rights reserved © 2012 Alcatel-Lucent

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

SONET/SDH Overview

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

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

Module 2 |

16

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 16 | All rights reserved © 2012 Alcatel-Lucent

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

SONET/SDH Overview (cont)

 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

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

Module 2 |

17

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 17 | All rights reserved © 2012 Alcatel-Lucent

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

SONET/SDH Overview (cont)

 STM-1 payload may be subdivided into Virtual Containers (VCs) and Tributary Units (TUs)  TUG-3=51.84 Mbps  TUG-2=3xE1

Legend VC 12 = 2.304 Mb/s TUG-2 = 3x VC-12 TUG-3 = 7x TUG-2 AU-4 = 3x TUG-3 = 3x STS1

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

Module 2 |

18

All rights reserved © 2012 Alcatel-Lucent

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.  VC-3 – 9 rows x 85 columns at 48.96 Mb/s.  VC-4 – 9 rows x 261 columns at 150.336 Mb/s. A VC equates to a Tributary Unit Group (TUG), and a TUG multiplexes multiple TUs. A TU feeds a TUG, which may feed other, higher-level TUGs, which in turn feed VCs and AUs. E1 in STM-1 Frame A VC-12 transports an E1 circuit. SDH multiplexes these circuits for transport in a STM-1 container, called an AU4. •TUG-2 At the lowest level, SDH multiplexes three 4 column x 9 row VC-12s into a 12 column wide TUG-2. •TUG-3 A TUG-3 concatenates seven 12 column wide TUG-2s, for a total of 84 columns. Each TUG-3 includes a column of POH and a column of pointers and stuffing bits, for a total of 86 columns. •AU-4 An AU-4 carries three 86 column wide TUG-3s, plus one column of VC-4 POH and two stuffing columns, for a total of 261 columns. This fills out the VC capacity area of the STM-1 frame. Add to this the 9 bytes of SOH, and this completes the frame.

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

Module 2 - Page 18 | All rights reserved © 2012 Alcatel-Lucent

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

SONET/SDH Overview (cont)

OC-12/OC-3 VT Group Circuits

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

Module 2 |

19

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 19 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 2 |

20

All rights reserved © 2012 Alcatel-Lucent

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

.

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

Module 2 - Page 20 | All rights reserved © 2012 Alcatel-Lucent

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

OC-12 VT Group Circuits – SONET Framing

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

Module 2 |

21

All rights reserved © 2012 Alcatel-Lucent

OC12 VT Group Circuits – SDH Framing TUG Group Mode The Synchronous Digital Hierarchy (SDH) supports TDM circuits of different channel rates transported in containers. A container is the basic synchronous payload, and can be an E3, E1, DS3, DS1, or some higher multiple of a DSx or Ex. SDH then maps the containers to Virtual Containers (VCs), and VCs into Tributary Units (TUs). It multiplexes TUs into Tributary Unit Groups (TUGs), and then maps the TUGs into Administrative Units (AUs). Each level, VC, TU, TUG, and AU, adds overhead for control, error detection, alignment, and other OAM functions. POH pointers locate the AU and TUs in the STM-1 frame. Setting the OC-12 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 . 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.

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

Module 2 - Page 21 | All rights reserved © 2012 Alcatel-Lucent

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

OC12 VT Group Circuits – SDH Framing

Configuring OC-3/STM-1 ASAP Port Characteristics

Syntax: Syntax:

framing framing {sonet|sdh} {sonet|sdh} path path {sonet-sdh-index} {sonet-sdh-index} vt15-[sonet-sdh-index].[sonet-sdh-index].[sonet-sdh-index] vt15-[sonet-sdh-index].[sonet-sdh-index].[sonet-sdh-index]

Context: Context: config>port>sonet-sdh>path config>port>sonet-sdh>path Syntax: Syntax:

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

Example: Example: config# config# port port 1/2/1 1/2/1 sonet-sdh sonet-sdh config>port>sonet-sdh# config>port>sonet-sdh# framing framing sonet sonet config>port>sonet-sdh# config>port>sonet-sdh# path path sts1-1 sts1-1 config>port>sonet-sdh>path$ config>port>sonet-sdh>path$ payload payload vt15 vt15 config>port>sonet-sdh>path$ config>port>sonet-sdh>path$ no no shutdown shutdown config>port>sonet-sdh>path$ config>port>sonet-sdh>path$ back back config>port>sonet-sdh# config>port>sonet-sdh# path path vt15-1.1.1 vt15-1.1.1 config>port>sonet-sdh>path$ config>port>sonet-sdh>path$ no no shutdown shutdown config>port>sonet-sdh>path$ back config>port>sonet-sdh>path$ back config>port>sonet-sdh# config>port>sonet-sdh# back back config>port# config>port# no no shutdown shutdown

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

Module 2 |

22

All rights reserved © 2012 Alcatel-Lucent

Configuring OC-3/STM-1 ASAP Port Characteristics Shown here are the commands required to configure an OC-3/STM-1 port to support STS-1 VT15 DS1s. Each STS1 can transport 28 vt15s arranged in 7 groups of 4 vts (DS1s) each. The SROS default framing is SONET. Set SONET/SDH framing A:NodeA# configure port 1/2/1 sonet-sdh  Enable the STS-1 A:NodeA>config>port>sonet-sdh# path sts1-1 payload vt15  Define the payload A:NodeA>config>port>sonet-sdh# path vt15-1.1.1  (vt15-sts1-1.vtg 1.vt15 1) Turn up the payload A:NodeA>config>port>sonet-sdh# path vt15-1.1.1 no shutdown  Turn up the STS-1 A:NodeA>config>port>sonet-sdh# path sts1-1 no shutdown  Turn up the port A:NodeA>config>port>sonet-sdh# back  A:NodeA>config>port# no shutdown 

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

Module 2 - Page 22 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>port>sonet-sdh config>port>sonet-sdh

Configuring DS1 ATM Access Ports

Context: Context: config>port>tdm config>port>tdm [no] [no] ds1 ds1 ds1-id ds1-id clock-source clock-source node-timed node-timed

Context: Context: config>port>tdm>channel-group config>port>tdm>channel-group Syntax: Syntax:

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

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

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

Module 2 |

23

All rights reserved © 2012 Alcatel-Lucent

Configuring DS1 ATM Access Ports Configure 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 

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

Module 2 - Page 23 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

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

=============================================================================== =============================================================================== Path Path Info Info =============================================================================== =============================================================================== Description :: STS1 Description STS1 Admin :: up Oper :: up Admin Status Status up Oper Status Status up Mode : N/A CRC : Mode : N/A CRC : N/A N/A Encap :: N/A Configured :: N/A Encap Type Type N/A Configured MTU MTU N/A Operational :: N/A Operational :: N/A Operational MTU MTU N/A Operational MRU MRU N/A Last Path :: 574652477 Last State State Change Change :: 05/16/2011 05/16/2011 23:03:34 23:03:34 Path IfIndex IfIndex 574652477 Scramble :: N/A Payload :: vt15 Scramble N/A Payload vt15 Accounting Policy : N/A Collect-Stats : Accounting Policy : N/A Collect-Stats : N/A N/A Net. Net. Egress Egress Que Que Pol: Pol: N/A N/A Signal Label :: 0x02 Rx :: 0x01 Signal Label 0x02 Rx Signal Signal Label Label 0x01 Trace :: Alcatel Trace String String Alcatel 7750 7750 SR SR Rx Rx Trace Trace Str(Hex) Str(Hex) :: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...output ...output truncated truncated Cfg :: plop Cfg Alarm Alarm plop pplm pplm puneq puneq Alarm :: Alarm Status Status ...output ...output truncated truncated

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

Module 2 |

24

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 24 | All rights reserved © 2012 Alcatel-Lucent

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

A:NodeA# A:NodeA# show show port port 1/2/1.1 1/2/1.1

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

=============================================================================== =============================================================================== TDM TDM DS1 DS1 Interface Interface =============================================================================== =============================================================================== Description :: DS1 Description DS1 Interface :: 1/2/1.1.1.1 Interface 1/2/1.1.1.1 Type :: ds1 Framing :: esf Type ds1 Framing esf Admin :: up Oper :: up Admin Status Status up Oper Status Status up Physical :: yes Clock :: node-timed Physical Link Link yes Clock Source Source node-timed Last Channel :: 574653943 Last State State Change Change :: 05/16/2011 05/16/2011 23:34:29 23:34:29 Channel IfIndex IfIndex 574653943 Loopback :: none Invert :: false Loopback none Invert Data Data false Remote Loop respond: false In Remote Loop :: false Remote Loop respond: false In Remote Loop false Load-balance-algo Egr. :: N/A Load-balance-algo :: default default Egr. Sched. Sched. Pol Pol N/A BERT :: N/A BERT :: none BERT Duration Duration N/A BERT Pattern Pattern none BERT :: 00h00m00s Err BERT Synched Synched 00h00m00s Err Insertion Insertion Rate Rate :: 00 BERT :: 00 BERT :: idle BERT Errors Errors BERT Status Status idle BERT :: 00 BERT Total Total Bits Bits Cfg :: ais Cfg Alarm Alarm ais los los Alarm :: Alarm Status Status BER BER :: 50 BER SD SD Threshold Threshold :: 55 BER SF SF Threshold Threshold 50 =============================================================================== =============================================================================== ... ... output output truncated truncated Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

25

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 25 | All rights reserved © 2012 Alcatel-Lucent

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

A:NodeA# A:NodeA# show show port port 1/2/1.1.1.1 1/2/1.1.1.1

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

=============================================================================== =============================================================================== TDM TDM DS0 DS0 Chan Chan Group Group =============================================================================== =============================================================================== Description :: DS0GRP Description DS0GRP Interface :: 1/2/1.1.1.1.1 Interface 1/2/1.1.1.1.1 TimeSlots :: 1-24 TimeSlots 1-24 Speed : CRC :: 32 Speed : 64 64 CRC 32 Admin :: up Oper :: up Admin Status Status up Oper Status Status up BER BER SF SF Link Link Down Down :: disabled disabled Last Chan-Grp :: 574653944 Last State State Change Change :: 05/17/2011 05/17/2011 00:10:20 00:10:20 Chan-Grp IfIndex IfIndex 574653944 Configured Configured mode mode Admin Admin MTU MTU Scramble Scramble Physical Physical Link Link Idle Idle Cycle Cycle Flags Flags Payload Payload Fill Fill Type Type Signal Signal Fill Fill Type Type Ing. Ing. Pool Pool %% Rate Rate Egr. Sched. Egr. Sched. Pol Pol

:: access access :: 1524 1524 :: true true :: yes yes :: n/a n/a :: n/a n/a :: n/a n/a :: 100 100 :: N/A N/A

Encap Encap Type Type Oper Oper MTU MTU

:: atm atm :: 1524 1524

Bundle Bundle Number Number Load-balance-algo Load-balance-algo Payload Payload Pattern Pattern Signal Signal Pattern Pattern Egr. Egr. Pool Pool %% Rate Rate

:: 11 :: default default :: N/A N/A :: N/A N/A :: 100 100

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

Module 2 |

26

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 26 | All rights reserved © 2012 Alcatel-Lucent

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

A:NodeA# A:NodeA# show show port port 1/2/1.1.1.1.1 1/2/1.1.1.1.1

• An IMA bundle inverse multiplexes, or splits, an ATM cell stream over multiple DS1/E1 links • The IMA bundle group combines the individual links to create a “fatter” pipe between the two endpoints • The “logical link” concept is called an “IMA Group” • IMA bundles only operate as access ports Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

27

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 27 | All rights reserved © 2012 Alcatel-Lucent

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

Inverse Multiplexing over ATM (IMA)

IMA Bundle Configuration Commands Context: Context: config>port config>port [no] [no] bundle-ima-slot/mda.bundle-num bundle-ima-slot/mda.bundle-num multilink-bundle multilink-bundle

Context: Context: config>port>ml-bundle config>port>ml-bundle Syntax: Syntax:

ima ima atm atm member member port-id port-id

Example: Example: config# config# port port bundle-ima-1/2.1 bundle-ima-1/2.1 config>port# config>port# multilink-bundle multilink-bundle config>port>ml-bundle# config>port>ml-bundle# ima ima atm atm config>port>ml-bundle# config>port>ml-bundle# member member 1/2/1.1.1.1.1 1/2/1.1.1.1.1 config>port>ml-bundle# member config>port>ml-bundle# member 1/2/1.1.1.2.1 1/2/1.1.1.2.1 config>port>ml-bundle# back config>port>ml-bundle# back config>port# config>port# no no shutdown shutdown

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

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

Module 2 |

28

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 28 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

View the Completed IMA Bundle

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

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

Module 2 |

29

All rights reserved © 2012 Alcatel-Lucent

View the Completed IMA Bundle The 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.

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

Module 2 - Page 29 | All rights reserved © 2012 Alcatel-Lucent

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

 The bundle is Admin Up, Port State Up

 ML-PPP is a method of splitting, recombing, and sequencing PPP frames across multiple datalinks  PPP signals the Multilink Protocol (MP) option during individual link Link Control Protocol (LCP) negotiations  SROS supports up to 16xE1 or DS1 ML-PPP bundled links per bundle group on network interfaces; 8 on access

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

Module 2 |

30

All rights reserved © 2012 Alcatel-Lucent

Point to Point Protocol (PPP) / MultiLink-PPP RFC1990 describes ML-PPP as an extension to the PPP protocol which allows distributing PPP frames across multiple PPP links grouped together into a bundle. These bundled PPP links provide a single, virtual connection between two devices. ML-PPP allows more bandwidth than a single circuit can provide alone, and reduces costs when the required bandwidth is greater than one circuit, but less than the next higher aggregation level. ML-PPP transmits a single data stream by splitting and sequencing the datagram into multiple ML-PPP frames, and evenly distributing them across multiple physical links (that are logically grouped) for transmission. The far-end equipment recombines the received multi ML-PPP frames back to a single datagram. Fragmenting the datagram and transmitting it across multiple physical links allows the service provider to incrementally increase the bandwidth and lower the latency of the transmitting data. All datagram transiting through MLPPP are subject to fragmentation. ML-PPP Setup ML-PPP is signaled during a standard PPP 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.

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

Module 2 - Page 30 | All rights reserved © 2012 Alcatel-Lucent

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

Point to Point Protocol (PPP)/MultiLink-PPP

PPP is a Data Link Layer protocol for encapsulating datagrams for transport over serial links  PPP consists of:  Link Control Protocol (LCP) – establishes, configures, and tests the data link connection  Network Control Protocol (NCP) – establishes and configures different network layer protocols

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

Module 2 |

31

All rights reserved © 2012 Alcatel-Lucent

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 0xc021 LCP 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. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 31 | All rights reserved © 2012 Alcatel-Lucent

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

Point-to-Point Protocol (PPP)

 Before the endpoints can transmit data, they must signal the links and bundles  MP initialization occurs after individual link LCP signaling  MP acts as a logical PPP link on top of the member links  Data flows once the endpoints negotiate the bundle’s Layer 3 characteristics

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

Module 2 |

32

All rights reserved © 2012 Alcatel-Lucent

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 use a 12 bit versus a standard, 24 bit sequence number. When SSN is configured between the endpoints, they can use two bits in the header to identify four service classes, as detailed in RFC 2685, The Multi-class Extension to Multi-Link PPP. 3. Endpoint discriminator option – This option identifies the bundle to which a link belongs. This can take the form of an 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.

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

Module 2 - Page 32 | All rights reserved © 2012 Alcatel-Lucent

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

Link Negotiation/Bundle Negotiation

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

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

Module 2 |

33

All rights reserved © 2012 Alcatel-Lucent

Multilink Protocol (MP) Frame The PPP Multilink Protocol (MP) frame carries the bundled payload. The MP protocol ID 0x003D identifies this as a bundled payload, and includes a sequence number header field to support L2 fragmentation. The MP frames carry the IPCP PDU in the 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.

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

Module 2 - Page 33 | All rights reserved © 2012 Alcatel-Lucent

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

Multilink Protocol (MP) Frame

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

Module 2 |

34

All rights reserved © 2012 Alcatel-Lucent

Bundle Creation and Maintenance Establish communication phase (over a P2P link) •Each end sends LCP packets to configure and test the data link. •Once established, the peer may optionally be authenticated. SROS does not support authentication on PPP links. •If MP is desired, the nodes set the MRRU option. Initialize bundle •In SROS, the bundle configuration sets the MRRU, fragment threshold, short sequence, and multiclass options for the member links. The endpoints need to agree on the short sequence and multiclass values for the bundle to initialize; they negotiate the MRRU and fragment threshold. Once the bundle initializes, PPP can move on to the NCP phase. Configure network-layer protocols phase •Send NCP packet to choose and configure Network-layer protocol •Datagram from each network-layer protocol can be sent over the link MP Encapsulation Bundled messages uses a unique protocol ID, 0x003D. This distinguishes bundle member from link level transmissions. IPCP packets are transported in the payload field, after the MP protocol ID field.

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

Module 2 - Page 34 | All rights reserved © 2012 Alcatel-Lucent

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

Bundle Creation and Maintenance

Configuring DS1 PPP Access Ports

Context: Context: config>port>tdm config>port>tdm [no] [no] ds1 ds1 ds1-id ds1-id clock-source clock-source node-timed node-timed

Context: Context: config>port>tdm>channel-group config>port>tdm>channel-group Syntax: Syntax:

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

Example: Example: config# config# port port 1/2/1 1/2/1 config>port# config>port# description description “MLPPP “MLPPP bundle bundle 2” 2” config>port# tdm config>port# tdm config>port>tdm# ds1 1.1.1 config>port>tdm# ds1 1.1.1 config>port>tdm>ds1$ config>port>tdm>ds1$ clock-source clock-source node-timed node-timed config>port>tdm>ds1$ config>port>tdm>ds1$ channel-group channel-group 11 config>port>tdm>ds1>channel-group$ config>port>tdm>ds1>channel-group$ encap-type encap-type ipcp ipcp config>port>tdm>ds1>channel-group$ config>port>tdm>ds1>channel-group$ timeslots timeslots 1-24 1-24 config>port>tdm>ds1>channel-group$ config>port>tdm>ds1>channel-group$ no no shutdown shutdown config>port>tdm>ds1>channel-group$ config>port>tdm>ds1>channel-group$ back back config>port>tdm>ds1# config>port>tdm>ds1# no no shutdown shutdown config>port>tdm>ds1# config>port>tdm>ds1# back back config>port>tdm# config>port>tdm# back back config>port># config>port># back back Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

35

All rights reserved © 2012 Alcatel-Lucent

Configuring DS1 PPP Access Ports Configure 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 

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

Module 2 - Page 35 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

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

=============================================================================== =============================================================================== TDM TDM DS0 DS0 Chan Chan Group Group =============================================================================== =============================================================================== Description :: DS0GRP Description DS0GRP Interface :: 1/2/1.1.1.1.1 Interface 1/2/1.1.1.1.1 TimeSlots :: 1-24 TimeSlots 1-24 Speed : CRC :: 16 Speed : 64 64 CRC 16 Admin :: up Oper :: up Admin Status Status up Oper Status Status up BER BER SF SF Link Link Down Down :: disabled disabled Last Chan-Grp :: 574652503 Last State State Change Change :: 07/28/2011 07/28/2011 10:42:57 10:42:57 Chan-Grp IfIndex IfIndex 574652503 Configured :: access Configured mode mode access Admin :: 1502 Admin MTU MTU 1502 Scramble :: false Scramble false Physical :: yes Physical Link Link yes Idle Cycle Flags Idle Cycle Flags :: flags flags Payload Payload Fill Fill Type Type :: n/a n/a Signal Fill Type Signal Fill Type :: n/a n/a Ing. Ing. Pool Pool %% Rate Rate :: 100 100 Egr. :: N/A Egr. Sched. Sched. Pol Pol N/A ... ... output output truncated truncated

Encap Encap Type Type Oper Oper MTU MTU

:: ipcp ipcp :: 1502 1502

Bundle Bundle Number Number Load-balance-algo Load-balance-algo Payload Payload Pattern Pattern Signal Signal Pattern Pattern Egr. Egr. Pool Pool %% Rate Rate

:: 11 :: Default Default :: N/A N/A :: N/A N/A :: 100 100

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

Module 2 |

36

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 36 | All rights reserved © 2012 Alcatel-Lucent

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

A:NodeA# A:NodeA# show show port port 1/2/1.1.1.1.1 1/2/1.1.1.1.1

ML-PPP Bundle Configuration Commands Context: Context: config>port config>port [no] [no] bundle-ppp-slot/mda.bundle-num bundle-ppp-slot/mda.bundle-num multilink-bundle multilink-bundle

Context: Context: config>port>ml-bundle config>port>ml-bundle Syntax: Syntax:

member member port-id port-id short-sequence short-sequence mrru mrru mlppp mlppp

Context: Context: config>port>ml-bundle>mlppp config>port>ml-bundle>mlppp Syntax: Syntax:

endport-discriminator endport-discriminator class class {ip-address|global-mac-address|null} {ip-address|global-mac-address|null} discriminator-id discriminator-id

Example: Example: config# config# port port bundle-ppp-1/2.1 bundle-ppp-1/2.1 config>port# config>port# multilink-bundle multilink-bundle config>port>ml-bundle# config>port>ml-bundle# short short sequence sequence config>port>ml-bundle# config>port>ml-bundle# member member 1/2/1.1.1.1.1 1/2/1.1.1.1.1 config>port>ml-bundle# member config>port>ml-bundle# member 1/2/1.1.1.2.1 1/2/1.1.1.2.1 config>port>ml-bundle# mlppp config>port>ml-bundle# mlppp config>port>ml-bundle>mlppp# endpoint-discriminator config>port>ml-bundle>mlppp# endpoint-discriminator class class ip-address ip-address discriminator-id discriminator-id 10.10.10.10 10.10.10.10 config>port>ml-bundle>mlppp# back config>port>ml-bundle>mlppp# back config>port# config>port# no no shutdown shutdown Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

37

All rights reserved © 2012 Alcatel-Lucent

ML-PPP Bundle Configuration Commands Create the ML-PPP bundle You must type out “bundle-ppp-port.bundle-num”. A:NodeA# configure port bundle-ppp-1/2.1  Configure the bundle characteristics A:NodeA>config>port# multilink-bundle Define the bundle member DS1s. You should use at least two members. A:NodeA>config>port>ml-bundle# member 1/2/1.1.1.1.1  A:NodeA>config>port>ml-bundle# member 1/2/1.1.1.2.1  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 

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

Module 2 - Page 37 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

Multi-Class (MC) MLPPP Overview

Multi-Link Point-to-Point Protocol  Allows operators to converge multiple services and traffic types over a T1/E1 link Limitation:  No ability to prioritize specific applications

Multi-class MLPPP

Multi-Class MLPPP adds QoS for Multi-Link Groups  Uses MP frame Class bits  Four Classes of Service (CoS) — Enables prioritization of different services over a common network link

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

Module 2 |

38

All rights reserved © 2012 Alcatel-Lucent

MC MLPPP Overview If so required, you may differentiate the traffic passed over the multilink bundles by enabling Multi-Class support. A:NodeA>config>port>ml-bundle>mlppp# multiclass  The options are 2 to 4. As shown in the illustration above, multiclass 4 enables 4 CoS and allows you to use QoS profiles to prioritize the traffic sent across the bundle. 7750 SROS defines one default ingress and 3 default egress MLPPP QoS profiles. Egress QoS profiles buffer and schedule traffic leaving the MDA. Ingress QoS profiles set reassembly timeout values for rebuilding fragmenting frames on port ingress. See the 7750 SR OS QoS Guide for more information on MLPPP QoS profiles. A:MLS1# show qos mlppp-profile-egress =============================================================================== Multi-class MLPPP Egress Profiles =============================================================================== Profile-Id Description ------------------------------------------------------------------------------1 Default egress multi-class profile 1. 2 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. =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 38 | All rights reserved © 2012 Alcatel-Lucent

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

MLPPP

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

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

Module 2 |

39

All rights reserved © 2012 Alcatel-Lucent

View the Completed ML-PPP Bundle – No IPCP The 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.

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

Module 2 - Page 39 | All rights reserved © 2012 Alcatel-Lucent

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

 The bundle is Admin Up, Port State Link Up

A:NodeA# A:NodeA# show show multilink-bundle multilink-bundle bundle-ppp-1/2.1 bundle-ppp-1/2.1 detail detail =============================================================================== =============================================================================== Bundle Bundle bundle-ppp-1/2.1 bundle-ppp-1/2.1 Detail Detail =============================================================================== =============================================================================== Description :: MultiLink Description MultiLink Bundle Bundle Bundle Id : bundle-ppp-1/2.1 :: mlppp Bundle Id : bundle-ppp-1/2.1 Type Type mlppp Admin :: up Oper :: up Admin Status Status up Oper Status Status up Minimum :: 11 Bundle :: 574619649 Minimum Links Links Bundle IfIndex IfIndex 574619649 Total :: 22 Active :: 22 Total Links Links Active Links Links Red :: 00 Yellow Red Diff Diff Delay Delay Yellow Diff Diff Delay Delay :: 00 Red Diff Delay Act : none MRRU :: 1524 Red Diff Delay Act : none MRRU 1524 Short :: true Oper :: 1524 Short Sequence Sequence true Oper MRRU MRRU 1524 Oper :: 1526 Fragment Oper MTU MTU 1526 Fragment Threshold Threshold :: 128 128 bytes bytes Up :: 0d Bandwidth :: 3968 Up Time Time 0d 00:01:56 00:01:56 Bandwidth 3968 KBit KBit PPP Primary PPP Input Input Discards Discards :: 00 Primary Member Member Port: Port: 1/2/1.1.1.1.1 1/2/1.1.1.1.1 Mode :: access Mode access Interleave-Frag :: false Interleave-Frag false ------------------------------------------------------------------------------------------------------------------------------------------------------------Member #TS Up Member Port Port Id Id #TS Admin Admin Oper Oper Act Act Down Down Reason Reason Up Time Time ------------------------------------------------------------------------------------------------------------------------------------------------------------1/2/1.1.1.1.1 31 up 0d 1/2/1.1.1.1.1 31 up up up yes yes N/A N/A 0d 00:04:56 00:04:56 1/2/1.1.1.2.1 31 up up yes N/A 0d 1/2/1.1.1.2.1 31 up up yes N/A 0d 00:04:57 00:04:57 =============================================================================== =============================================================================== ... ... output output truncated truncated Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

40

All rights reserved © 2012 Alcatel-Lucent

View the Completed ML-PPP Bundle – IPCP Complete Once the bundle is associated with an L3 interface, the bundle status becomes operationally up. The show multilink-bundle bundle-ppp-1/2.1 detail command shows the 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.

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

Module 2 - Page 40 | All rights reserved © 2012 Alcatel-Lucent

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

View the Completed ML-PPP Bundle – IPCP Complete

A:NodeA# A:NodeA# show show multilink-bundle multilink-bundle bundle-ppp-1/2.1 bundle-ppp-1/2.1 ppp ppp =============================================================================== =============================================================================== Bundle Bundle bundle-ppp-1/2.1 bundle-ppp-1/2.1 Multilink Multilink PPP PPP Information Information =============================================================================== =============================================================================== Local Local EpId EpId Class Class :: IP IP Address Address Local Local Discriminator: Discriminator: 10.10.10.10 10.10.10.10 Yellow Short :: true Yellow Diff Diff Delay Delay :: 00 Short Sequence Sequence true MRRU : 1524 Oper MRRU :: 1524 MRRU : 1524 Oper MRRU 1524 Interleave-Frag :: false PPP Interleave-Frag false PPP Input Input Discards Discards :: 00 Multiclass Classes : 4 Multiclass Classes : 4 Ing Egr Ing QoS QoS Profile Profile Id Id :: 00 Egr QoS QoS Profile Profile Id Id :: 00 Magic :: Disabled Magic Number Number Disabled =============================================================================== =============================================================================== =============================================================================== =============================================================================== PPP PPP Protocols Protocols for for bundle-ppp-1/2.1 bundle-ppp-1/2.1 =============================================================================== =============================================================================== Protocol Last Restart Protocol State State Last Change Change Restart Count Count Last Last Cleared Cleared ------------------------------------------------------------------------------------------------------------------------------------------------------------ipcp opened 11/16/2011 33 11/15/2011 ipcp opened 11/16/2011 12:17:56 12:17:56 11/15/2011 12:05:10 12:05:10 ... ... output output truncated truncated =============================================================================== =============================================================================== Local Local Mac Mac address address :: 60:39:01:02:00:05 60:39:01:02:00:05 Remote Remote Mac Mac address address :: Local IPv4 address : 203.0.113.9 Remote IPv4 Local IPv4 address : 203.0.113.9 Remote IPv4 address: address: 203.0.113.10 203.0.113.10 ... ... output output truncated truncated Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

41

All rights reserved © 2012 Alcatel-Lucent

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



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

Other states: initial, starting, closed, stopped, closing, stopping, requestSent, askReceived, ackSent •Local IPv4 address: - The local bundle L3 interface IP address •Remove IPv4 address: - The local bundle L3 interface address •Magic Number: - The magic number provides a method to detect loopbacks. If the value of the local magic number is the same as the value of remote magic number, then it is possible that the link might be looped back. If the two magic numbers do not match, then the link is not looped back. Default disabled.

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

Module 2 - Page 41 | All rights reserved © 2012 Alcatel-Lucent

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

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

1 Hour Lab Objectives:  On the CSA routers, provision three IMA DS1s and create an IMA bundle to support 3G base station traffic  On the CSA routers, configure three ML-PPP DS1s and create an ML-PPP bundle to support 3G base station traffic

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

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

Module 2 |

42

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 42 | All rights reserved © 2012 Alcatel-Lucent

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

Lab 2: Configure TDM ATM IMA Interfaces

Section Summary

 How to configure Ethernet access port mode, encapsulation type, autonegotiation, MTU, and hold time  How to build out OC-3 virtual tributaries, DS1s and channel groups  Commands and procedures used to create and monitor ATM IMA and ML-PPP bundle groups

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

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

Module 2 |

43

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 43 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Module 2 — Implementing the Mobile Backhaul Transport Network

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

Section 2 — Timing and Synchronization in the Backhaul Transport Network

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

Module 2 - Page 45 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 2 |

46

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 46 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we will:

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

47

All rights reserved © 2012 Alcatel-Lucent

Synchronous Network Timing Requirements What is synchronization? “Synchronization is the ability to achieve equivalent values for time, frequency, and phase at different elements in the network.” Alcatel-Lucent. 7705 SAR Synchronization 1.0 v1.0. Timing and Synchronization Requirements In the backhaul transport, synchronization addresses two important requirements: 1. Air interface timing – To avoid RF interference, the base station RF interfaces must meet 3GPP-prescribed minimum frequency and phase accuracy requirements. Base stations communicate with the handsets and neighboring base stations via RF signals. 

Frequency accuracy – Frequency Division Duplexing (FDD) radio technologies such as GSM 2G and WCDMA must meet a frequency accurancy of +/- 50 parts per billion (ppb). One ppb is equal to one bit per one billion bits. [63] For example, an 840MHz GSM carrier must be accurate to within 42Hz, or 50 ppb. Many operators set a more stringent requirement to provide base station error margins when modulating the signal for transmission. For example, the BS transport interface requirement is 16ppb to allow for BS HW oscillator limitations.



Phase (time) accuracy – Time Division Duplexing (TDD) radio technologies such as CDMA, CDMA2000, and LTE TDD require a varying clock accuracy between +/- 3us to +/- 1.25us. The general standard is 1us +/- 500ns. This insures proper handover between CDMA and LTE networks, proper LTE Multiple Input/Multiple Output (MIMO) mechanism operation and supports future LTE features which might require phase synchronization. Most often a carrier addresses both FDD and TDD synchronization to improve BS handover performance.

2. TDM timing – The CSA and backhaul transport TDM interfaces require frequency synchronization to meet Bit Error Rate (BER), frame delay, bit jitter, delay difference, and other requirements. ITU-T G.824 allows for a maximum jitter (delay variation) of .1 Unit Interval (UI) – Peak-to-Peak (UIpp) on a DS1 interface, where a UI measures 647ns for a T1 signal, and 488ns for an E1.

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

Module 2 - Page 47 | All rights reserved © 2012 Alcatel-Lucent

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

Synchronous Network Timing Requirements

• • • •

Hierarchical master-slave topology at physical layer Arranged by Stratum level Best quality clocks at the central office level Downstream clocks follow upstream clock frequency

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

Module 2 |

48

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 48 | All rights reserved © 2012 Alcatel-Lucent

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

North American Network Timing Hierarchy

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

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

Module 2 |

49

All rights reserved © 2012 Alcatel-Lucent

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 intervals of the measured UI compared to the nominal UI. Wander represents a long term clock rate drift, over hours or days. Temperature changes, component aging, and slave clock inaccuracies result in wander. Wander is measured over a period of time, and the measurement is called Time Interval Error (TIE), also known as phase error. An SEC must be able to attenuate jitter and wander. They do this by averaging out these differences and slowly adjusting their reference clocks.

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

Module 2 - Page 49 | All rights reserved © 2012 Alcatel-Lucent

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

Building Integrated Timing Supply (BITS)

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

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

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

Module 2 |

50

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 50 | All rights reserved © 2012 Alcatel-Lucent

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

ITU-T SDH Equipment Clock (SEC)

Synchronization – Frequency v. Phase and Time

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

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

Module 2 |

51

All rights reserved © 2012 Alcatel-Lucent

Synchronization – Frequency v. Phase and Time All Backhaul base stations require frequency synchronized clocks. This ensures correct RF operation and avoids frame slips on the TDM uplinks. Synchronizing both frequency and phase/Time of Day (ToD) is more challenging. A node can recover the clock frequency from a physical layer technique, such as the bit stream on a DS1 or the RF carrier on a microwave circuit. However, physical-layer techniques 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 runs an algorithm against this timestamp information to determine when the next clock pulse should occur. This algorithm has to compensate for delay variation the packet experiences end-to-end, termed Packet Delay Variation (PDV). Frequency Synchronization - Important for RF carrier alignment and to avoid data-over or underruns. Phase Synchronization - Ensures transmit frame timeslot alignment to avoid overlap between base stations. Time Synchronization – Necessary for event correlation, alarming, billing, security, and transaction processing.

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

Module 2 - Page 51 | All rights reserved © 2012 Alcatel-Lucent

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

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

 Physical timing  A receiver sets its SEC from transitions in the received physical bit stream  Lines up clock pulses and frequency, but transitions still may occur at different points in time

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

Module 2 |

52

All rights reserved © 2012 Alcatel-Lucent

Physical versus Adaptive Timing Techniques Physical Timing Physically timed nodes recover the clock from the received bit stream. By referencing the transitions on the wire, the receiver can set its local clock pulses to match the transition rate. Physical timing occurs on a link-by-link basis. The link encoding method must ensure enough transitions, even if the source is sending no data. An SROS router can derive physical timing from an external BITS port, a DSx, Ex, or OC-x port, or a Synchronous Ethernet port.

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

Module 2 - Page 52 | All rights reserved © 2012 Alcatel-Lucent

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

Physical versus Adaptive Timing Techniques

Adaptive timing  A receiver sets its SEC frequency by a calculated time offset  A receivers sets its ToD and phase by the timestamp values  Recovery algorithm must compensate for Packet Delay Variation (PDV)

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

Module 2 |

53

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 53 | All rights reserved © 2012 Alcatel-Lucent

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

Physical versus Adaptive Timing Techniques (cont)

Synchronization techniques • Physical – External GPS, Synchronous Ethernet, Line Timing • Packet-based – IEEE 1588v2, Adaptive Clock Recovery

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

Module 2 |

54

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 54 | All rights reserved © 2012 Alcatel-Lucent

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

Packet Network Synchronization Techniques

Application

Frequency

Relative Phase

Solutions

GSM W-CDMA FDD MBMS*

50 ppb

10 to 100 ms

• Timing over Packet (ACR, 1588v2) • SyncE • E1/T1 Line timing

LTE FDD LTE MBMS

50 ppb

10 to 100 ms

• Timing over Packet • SyncE

CDMA2000

50 ppb

6 us (20 us worst case)

• GPS

W-CDMA TDD LTE TDD

50 ppb over one timeslot

2.5 us

• GPS • 1588v2 and SyncE

e911 LBS**

N/A

200 ns

• GPS • 1588v2 and SyncE

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

Module 2 |

55

All rights reserved © 2012 Alcatel-Lucent

Synchronization Requirements This table shows the synchronization requirements for various backhaul applications as defined by ITU-T and 3GPP recommendations and standards. Notice that although the reference specifies phase accuracy requirements for FDD applications, the TDD application requirements are much more stringent. SyncE Synchronous Ethernet provides an accurate frequency reference, but no phase or Time of Day (ToD) reference. It is suited well for FDD applications, and is easily deployed. IEEE 1588v2 and PTPv2 PTPv2 provides phase and ToD accurancy, but is susceptible to network conditions, such as delay and packet loss. It is more accurate as a reference on high bandwidth links versus lower bandwidth links, where PDV negatively impacts 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.

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

Module 2 - Page 55 | All rights reserved © 2012 Alcatel-Lucent

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

Synchronization Requirements

Current solutions may use a mixture of physical and packet-based techniques • Physical, such as GPS, SyncE, or line timing at the cell site • SyncE or 1588/PTP in the packet transport • Line timing on TDM interfaces Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

56

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 56 | All rights reserved © 2012 Alcatel-Lucent

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

Synchronization Source Locations

Section Summary

 Why the Backhaul Transport Network needs timing for proper operations  The differences between physical layer and packet-based synchronization techniques  Where current design guidelines place the synchronization sources in the Backhaul Transport Network

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

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

Module 2 |

57

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 57 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Module 2 — Implementing the Mobile Backhaul Transport Network

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

Section 3 — Timing and Synchronization – Synchronous Ethernet

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

Module 2 - Page 59 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives

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

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

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

Module 2 |

60

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 60 | All rights reserved © 2012 Alcatel-Lucent

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

 Explain Synchronous Ethernet (SyncE) operation

ITU-T G.8261/Y.1361 physical layer-based timing technology unaffected by network load  The POC1 physical layer transmit clock is locked to a high-quality reference clock (BITS port)  The receivers lock their clock the received 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

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

Module 2 |

61

All rights reserved © 2012 Alcatel-Lucent

Synchronous Ethernet Nodes running Synchronous Ethernet (SyncE) synchronize their clocks to the Ethernet bit stream. The usually free running Ethernet physical layer clocks synchronize to a PRC traceable throughout the network. Synchronous Ethernet replaces a portion of the standard Ethernet preamble with a 4-bit synchronization pattern and a 4-bit coding violation pattern. At the source, the PRC drives the Ethernet PHY. Each node derives their reference clock from the PHY layer, based on the ITU-T G.813 SDH Equipment Clock (SEC) model. G.813 requires:  A slave clock traceable to a PRC  Multiple reference inputs  A slave capable of maintaining holdover within ITU prescribed limits (see the North American Timing Hierarchy earlier in this Module.)

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

Module 2 - Page 61 | All rights reserved © 2012 Alcatel-Lucent

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

Synchronous Ethernet

Each SyncE capable node maintains a Synchronous Ethernet Equipment Slave Clock (EEC)  EEC should be accurate to system>sync-if-timing# ref-order ref-order bits bits ref1 ref1 ref2 ref2

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

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

config# config# card card 11 mda mda 11 sync-e sync-e

 Enabled by default on SAR MDAs

5.Enable SSM on ring ports

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

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

Module 2 |

68

All rights reserved © 2012 Alcatel-Lucent

Configuring Synchronous Ethernet SROS CLI uses the term “SSM” to describe ESMC configuration and management. Hence, in this section we use the term SSM in reference to ESMC operation. To configure synchronous Ethernet on the Backhaul Network: • Set the router timing sources and timing reference order. The order you choose depends on the network design and the clock source node locations. Setting the timing reference order correctly is key to ensuring the nodes choose the correct primary, secondary, and tertiary timing reference sources. Additionally, you may allow the router to pick references by the 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.

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

Module 2 - Page 68 | All rights reserved © 2012 Alcatel-Lucent

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

Configure Synchronous Ethernet Support 1.Set router timing reference order

Nodes set timing references based on their position and relation to the two MLS routers • MLS1 is the network SSU; reference selection is hop-by-hop • Based on their configurations, MLS2 and others trace their clock reference to MLS1 as SSU • QL Selection allows ring nodes to choose alternate source if better quality available Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

69

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 69 | All rights reserved © 2012 Alcatel-Lucent

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

SSM Operation – Model 2 Subtended Ring

•1 MLS1 sends QL-PRC out of its SSM-enabled ports •2 Other ring nodes choose their reference source by timing reference priority, advertised quality, or both •3 Each node returns QL-DNU towards selected source, MLS1 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

70

All rights reserved © 2012 Alcatel-Lucent

SSM Operation – Model 2 Normal Operations SSM Normal Operation Message Flow – SDH Mode The SROS sets the SSM port operation modes to SDH (Option 1) by default. This determines the SSM messages sent in the network. POC1 MLS1 POC1 MLS1 sends a QL-PRC out on all SyncE/SSM enabled ports. 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 ports In normal operations, as shown above, the nodes can receive QL-PRC messages on all ring ports- all SSM-enabled ports deliver ESMC messages. In this example, however, we configure our timing references on the ports providing the most direct link to the network SSU, MLS1. Splitting the network as shown helps speed convergence in the case a reference goes offline, while maintaining traceability to the primary SSU. Reference configuration is a static process; there is no dynamic selection protocol involved. The nodes update their clocks from the bit stream received on the highest priority reference port (unless QL selection is enabled). QL-DNU For source traceability, each node returns to the chosen source a QL-DNU message. POC1 MLS2 MLS2’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 Traceability From the cell site back to the network SSU, the network nodes can trace their clock to the MTSO PRC. Each node only has one port slaved to the upstream clock source.

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

Module 2 - Page 70 | All rights reserved © 2012 Alcatel-Lucent

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

SSM Operation – Model 2 Normal Operations

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

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

Module 2 |

71

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 71 | All rights reserved © 2012 Alcatel-Lucent

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

SSM Operation – Failure On MLS1 Link

At time of break, other nodes are unaware that MLS1 is unavailable 4 POC3-1 receives QL-EEC1 on its primary reference • 5 With ql-selection enabled, POC3-1 chooses its • qualified reference 2 source, POC3-2 6 • All other nodes except POC2-1 remain on reference 1; POC2-1 chooses POC3-1 as its primary reference Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

72

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 72 | All rights reserved © 2012 Alcatel-Lucent

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

SSM Operation – Failure On MLS1 Link (cont)

Set the MLS1 router Timing References

Syntax: Syntax:

begin begin bits bits interface-type interface-type {ds1 {ds1 [{esf|sf}] [{esf|sf}] || e1 e1 [{pcm30crc|pcm31crc}]} [{pcm30crc|pcm31crc}]} ref1 ref1 source-port source-port slot/mda/port[.channel] slot/mda/port[.channel] ref2 ref2 source-port source-port slot/mda/port[.channel] slot/mda/port[.channel] [no] [no] ref-order ref-order [] [] [no] revert [no] revert [no] ql-selection [no] ql-selection commit commit abort abort

Example: Example: config# config# system system sync-if-timing sync-if-timing config>system>sync-if-timing# config>system>sync-if-timing# begin begin config>system>sync-if-timing# config>system>sync-if-timing# ref1 ref1 source-port source-port 1/2/1 1/2/1 config>system>sync-if-timing# ref1 config>system>sync-if-timing# ref1 no no shutdown shutdown config>system>sync-if-timing# ref2 source-port 5/1/1* config>system>sync-if-timing# ref2 source-port 5/1/1* config>system>sync-if-timing# config>system>sync-if-timing# ref2 ref2 no no shutdown shutdown config>system>sync-if-timing# config>system>sync-if-timing# bits bits interface-type interface-type ds1 ds1 sf sf config>system>sync-if-timing# config>system>sync-if-timing# bits bits no no shutdown shutdown config>system>sync-if-timing# config>system>sync-if-timing# ref-order ref-order bits bits ref1 ref1 ref2 ref2 config>system>sync-if-timing# config>system>sync-if-timing# revert revert config>system>sync-if-timing# ql-selection config>system>sync-if-timing# ql-selection * Reference 2 must be on last IOM set and config>system>sync-if-timing# config>system>sync-if-timing# commit commit SyncE and SSM must be enabled on config>system>sync-if-timing# config>system>sync-if-timing# back back Ethernet MDAs and ports config>system# back config>system# back Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

73

All rights reserved © 2012 Alcatel-Lucent

Set the Node Timing References Configure the node timing references and reference order in the configure system sync-if-timing context.  begin – Enter edit or create mode  bits - Set the BITS port characteristics. Options are DS1, ESF or SF, or E1 PCM30 or PCM31. You must turn up the BITS port.  ref1 – Set the first timing reference port. If configured on an SR-7, the port must be on IOMs 1 or 2; if on an SR-12, the port must be on IOMs 1-5. On the SAR-8, ref1 and ref2 must be on different MDAs. If ref1 or ref2 point to an Ethernet port, SyncE must be enabled on the MDA. To allow the router to choose the source by QL, SSM must be enabled on the port.  ref2 – Set the second timing reference port. The port must be on an SR-7 IOMs 3-5 or an SR-12 IOMs 6-10. On the SAR-8, ref1 and ref2 must be on different MDAs. See ref1 for Ethernet port requirements. You must turn up ref1 and ref2.  ref-order – Determines the order in which the node chooses its reference source. The SR/ESS default is bits ref1 ref2. If the ref-order specifies bits on a redundant CPM-equipped 7750 SR7 or SR12, the active CPM first takes its BITS input from the active CPM BITS port. If that input becomes disqualified, it will take its input from the standby CPM BITS port.  revert – Revert allows the clock to switch back to a higher priority reference if the current reference becomes unqualified. The default is no revert.  ql-selection – Allows the node to select the timing reference by quality level rather than the configured reference order. It uses the reference order as a tie breaker, if necessary.  commit – Saves changes to the timing configuration. Until you issue commit, the changes have no effect.

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

Module 2 - Page 73 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>system>sync-if-timing config>system>sync-if-timing

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

=============================================================================== =============================================================================== System Interface Timing Operational Info System Interface Timing Operational Info =============================================================================== =============================================================================== System Status CPM A : Master Locked System Status CPM A : Master Locked Reference Input Mode : Revertive Reference Input Mode : Revertive Quality Level Selection : Enabled Quality Level Selection : Enabled Reference Selected : BITS A Reference Selected : BITS A System Quality Level : stu System Quality Level : stu Current Frequency Offset (ppm) : +0 Current Frequency Offset (ppm) : +0 Reference Order Reference Order

: bits ref1 ref2 : bits ref1 ref2

Reference BITS A Reference BITS A Input Admin Status Input Admin Status Rx Quality Level Rx Quality Level Quality Level Override Quality Level Override Qualified For Use Qualified For Use Selected For Use Selected For Use Interface Type Interface Type Framing Framing Line Coding Line Coding ...output truncated ...output truncated

: up : up : stu : stu : prs : prs : Yes : Yes : Yes : Yes : DS1 : DS1 : SF : SF : B8ZS : B8ZS

...output ...output truncated truncated

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

Module 2 |

74

All rights reserved © 2012 Alcatel-Lucent

View the timing configuration – show system sync-if-timing The show system sync-if-timing command shows the system timing configuration.  System Status CPM A indicates the CPM Master is locked to the primary reference.  Reference selected indicates BITS A is the current reference.  System quality level represents the systems master clock quality level. For an SF-framed DS1, it is QL-STU. For ESF and E1, the quality level represents the QL passed in the SSM bits.  Reference order indicates the provisioned clock reference order.  BITS A is admin up, and qualified for use.  BITS A is the selected reference. 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 

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

Module 2 - Page 74 | All rights reserved © 2012 Alcatel-Lucent

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

A:MLS1# A:MLS1# show show system system sync-if-timing sync-if-timing

Configuring MLS1 for SyncE Support

Context: Context: config>card>mda config>card>mda [no] [no] sync-e sync-e

Context: Context: config>port>ethernet>ssm config>port>ethernet>ssm Syntax: Syntax:

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

Example: Example: config# config# card card 55 mda mda 11 sync-e sync-e config>card>mda# config>card>mda# back back config>card# config>card# back back config# config# port port 5/1/1 5/1/1 config>port# config>port# ethernet ethernet config>port>ethernet# config>port>ethernet# ssm ssm config>port>ethernet>ssm# config>port>ethernet>ssm# code-type code-type sonet sonet config>port>ethernet>ssm# no config>port>ethernet>ssm# no shutdown shutdown config>port>ethernet>ssm# config>port>ethernet>ssm# back back config>port>ethernet# config>port>ethernet# back back config>port# config>port# back back

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

Module 2 |

75

All rights reserved © 2012 Alcatel-Lucent

Configuring MLS1 for SyncE Support MDA SyncE Support The MDA must support synchronous Ethernet. To turn up SyncE support on the MDA: A:NodeA# configure card 5 mda 1 sync-e  On the 7705 SAR with the Ethernet version 2 and later MDAs, sync-e is enabled by default. Port SSM Support If you want the nodes to exchange ESMC messages, you must enable SSM on the ports. Optionally, you may set the SSM code type; the default is SDH. This determines the clock type and events exchanged. A:NodeA# configure port 5/1/1 ethernet ssm code-type sonet  Turn up SSM on the port. A:NodeA# configure port 5/1/1 ethernet ssm no shutdown 

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

Module 2 - Page 75 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

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

=============================================================================== =============================================================================== Ethernet Ethernet Interface Interface =============================================================================== =============================================================================== Description Description Interface Interface Link-level Link-level Admin State Admin State Oper State Oper State Physical Link Physical Link Single Fiber Mode Single Fiber Mode

: 10/100/Gig Ethernet SFP : 10/100/Gig Ethernet SFP : 5/1/1 : 5/1/1 : Ethernet : Ethernet : up : up : up : up : Yes : Yes : No : No

Oper Speed Oper Speed Config Speed Config Speed Oper Duplex Oper Duplex Config Duplex Config Duplex MTU MTU

: 1 Gbps : 1 Gbps : 1 Gbps : 1 Gbps : full : full : full : full : 9212 : 9212

...output truncated ...output truncated Sync. Status Msg. : Enabled Sync. Status Msg. : Enabled Tx DUS/DNU : Disabled Tx DUS/DNU : Disabled SSM Code Type : sonet SSM Code Type : sonet

Rx Quality Level : 0xf(dus) Rx Quality Level : 0xf(dus) Tx Quality Level : 0x1(prs) Tx Quality Level : 0x1(prs)

...output truncated ...output truncated

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

Module 2 |

76

All rights reserved © 2012 Alcatel-Lucent

View MLS1 SSM configuration – show port 5/1/1 The show port 5/1/1 command shows the port SSM configuration and state.  SSM is Enabled  Code type is set to SONET to support a 1544 kb/s clock rate.  RX quality level represents the received QL on this port. Since this is the PRS (Option 1 PRC), the far end device returns a DUS (Option 1 DNU).  TX quality level shows this node sent QL PRS to the next hop.

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

Module 2 - Page 76 | All rights reserved © 2012 Alcatel-Lucent

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

A:MLS1# A:MLS1# show show port port 5/1/1 5/1/1

View POC2-1 timing configuration

=============================================================================== =============================================================================== System Interface Timing Operational Info System Interface Timing Operational Info =============================================================================== =============================================================================== System Status CSM A : Master Locked System Status CSM A : Master Locked Reference Input Mode : Non-revertive Reference Input Mode : Non-revertive Quality Level Selection : Enabled Quality Level Selection : Enabled Reference Order Reference Order Reference Input 1 Reference Input 1 Admin Status Admin Status Configured Quality Level Configured Quality Level Rx Quality Level Rx Quality Level Qualified For Use Qualified For Use Selected For Use Selected For Use Source Port Source Port ...output truncated ...output truncated

: ref1 ref2 external : ref1 ref2 external : up : up : none : none : prs : prs : Yes : Yes : Yes : Yes : 1/2/7 : 1/2/7

POC2-1 Reference 1 set to MLS1-facing SyncE/SSM port  MLS1 sends QL-PRS  POC-2 chooses SyncE/SSM source port as its reference Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

77

All rights reserved © 2012 Alcatel-Lucent

View POC2-1 timing configuration POC2-1 has locked its clock to its MLS1-facing port SyncE reference. The clocking source is MLS1 connected through SyncE/SSM source port 1/2/7.  Quality Level Selection – Enabled.  Rx Quality Level – The level set by MLS1, QL PRS  Qualified For Use – The port is properly configured for SyncE and SSM support.  Selected For Use – POC2-1 has selected this port as its timing reference.  Source Port – The port through which POC2-1 receives timing for this reference input.

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

Module 2 - Page 77 | All rights reserved © 2012 Alcatel-Lucent

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

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

View MLS1 timing configuration – SyncE/SSM port not selected

=============================================================================== =============================================================================== System Interface Timing Operational Info System Interface Timing Operational Info =============================================================================== ===============================================================================

... ...

Reference Input 2 Reference Input 2 Admin Status Admin Status Rx Quality Level Rx Quality Level Quality Level Override Quality Level Override Qualified For Use Qualified For Use Selected For Use Selected For Use Not Selected Due To Not Selected Due To Source Port Source Port ...output truncated ...output truncated

: up : up : dus : dus : none : none : Yes : Yes : No : No : ssm quality : ssm quality : 5/1/1 : 5/1/1

MLS1 Reference 2 set to MLS2 return port 5/1/1  MLS2 sends QL-DUS in response to MLS1 QL-PRS  MLS1 does not select its reference 2 for reason “ssm quality”  If MLS1 loses both BITS and ref1, it can select its ref2 SSM source Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

78

All rights reserved © 2012 Alcatel-Lucent

View MLS1 timing configuration – SyncE/SSM port not selected The MLS1 router sets ref2 to the MLS2-facing SSM port. Since MLS1 is the PRC and sends QL PRS to MLS2, MLS2 returns QL-DUS.  Rx Quality Level – QL-DUS returned by MLS2.  Qualified For Use – Yes, it is a valid SyncE port.  Selected For Use – No, since MLS2 set QL-DUS and better reference available.  Not Selected Due To – ssm quality. Node will not select QL-DUS (Option 1 DNU) over another, better QL. The MLS1 router will select this port if MLS2 router sends a better QL than the current MLS1 reference and QL selection is enabled. This could occur if the BITS reference fails, the ref1 SONET port becomes unavailable, and MLS1 goes into free run.

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

Module 2 - Page 78 | All rights reserved © 2012 Alcatel-Lucent

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

A:MLS1# A:MLS1# show show system system sync-if-timing sync-if-timing

.75 Hour Lab Objectives:  Configure BITS timing on MLS1 and MLS2  Configure MLS1 as PRS (SONET coding) with BITS as its primary reference  Configure MLS2 to synchronize off of its MLS1 port then BITS  Configure the SARs to synchronize off of MLS1 then MLS2  Disable MLS1 BITS then CSA1 ports and observe how the routers choose new references Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

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

Module 2 |

79

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 79 | All rights reserved © 2012 Alcatel-Lucent

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

Lab 3 : Configure SyncE and SSM

Section Summary

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

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

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

Module 2 |

80

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 80 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Module 2 — Implementing the Mobile Backhaul Transport Network

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

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

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

Module 2 - Page 81 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives

 Explain how IEEE 1588v2 and the Precision Time Protocol (PTP) v2 provide packet-based timing in the Backhaul Transport network  Describe the PTPv2 Message format  Trace PTPv2 message flow in normal and failure operations  Provision PTPv2 in the Backhaul Transport

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

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

Module 2 |

82

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 82 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we will:

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)

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

Module 2 |

83

All rights reserved © 2012 Alcatel-Lucent

IEEE 1588v2 and PTPv2 IEEE 1588v2 describes a master/slave timing distribution method where the network nodes route the timing reference data. The core nodes need not support the timing distribution scheme, but must route packets between the master and slave nodes. The master and slave can be on entirely different network segments, as long as the intermediate nodes can route packets between them. PTPv2 defines the message format for use in an IEEE 1588v2 model. The slave nodes choose a master by running a Best Master Clock Algorithm (BMCA). The slaves run the BMCA against a range of master clock characteristics, and based on these characteristics, chooses the best available reference. A slave may choose a different reference later, if a better one becomes available. We will discuss the BMCA in more detail later in this section. PTP Operation SyncE nodes slave off of the Ethernet bit stream. PTP nodes slave off of a calculated frequency offset value based upon timestamps transported in PTP messages. PTP and SyncE/SSM may be used in the same network in what is called a hybrid timing model for redundancy or to overcome physical network limitations, such as when SyncE is not supported on the MEN. As the PTP 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.

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

Module 2 - Page 83 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588v2 and PTPv2

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

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

Module 2 |

84

All rights reserved © 2012 Alcatel-Lucent

IEEE 1588v2 Operating Modes IEEE 1588v2 defines two synchronization operating modes: • One-way – The slave uses a single master to slave message set to determine its clock offset. • Two-way– The slave uses two message sets, master to slave and slave to master, to determine its clock offset. One-Way versus Two-Way Operation • One-way operation allows the slave to calculate its clock offset in relation to the master based on two timestamps. 1. The master sends a time stamped Sync message to the slave. The timestamp represents the 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 DelayResp(onse) message. 4. The slave calculates the master slave delay, and adjusts the offset to allow for these variations. This avoids any one-way delay induced skew, and results in a more accurate calculated slave clock. Two-way, if combined with two-step clock, explained in the next slide, can provide full synchronization, frequency and phase, and time of day. SROS supports two-way operation. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 84 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588v2 and PTPv2 Operation Modes

IEEE 1588v2 defines two clock operation modes:  One-step clock – SROS supported; The slave adjusts its clock offset considering one-way delay only  Two-step clock – The slave considers Packet Delay Variation (PDV) in its offset calculation

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

Module 2 |

85

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 85 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588v2 Clock Operation Modes

IEEE 1588v2 defines four clock types  Ordinary clock – a PTP client with a single port  Boundary clock – a clock with multiple ports that can be a time source  End-to-end Transparent clock – Computes the time a PTP packet is in residence and passes this to the downstream node.  Peer-to-peer Transparent clock - Computes residence time and propagation delay and passes this to the downstream node. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

86

All rights reserved © 2012 Alcatel-Lucent

IEEE 1588v2 Clocks IEEE 1588v2 describes four clock types:  Ordinary Clock: A PTP client that has a single PTP port in the domain and maintains the domain timescale. It could be a master, delivering the time reference, or a slave-only clock.  Boundary Clock (BC): A clock that has multiple PTP ports in a domain and maintains the domain timescale. It may serve as the master and may synchronize to another clock as a slave. BCs can break up an end-to-end flow into more manageable PDV segments. In addition, BCs permit scaling and can reduce the number of PTP packets in the network.  Transparent Clock (TC): A device that time stamps the ingress and egress packet flows to account for the time the packet is in residence in the TC device. A TC updates the event messages’ correction fields as the messages pass through it and then forwards the messages towards the slave port. The TC does not necessarily keep time but assists in minimizing PDV. A transparent clock can take 2 general forms: • End-to-End TC - Computes the residence time within the device. The downstream slave clock uses the corrections to adjust its local time base to be in sync with the master. • Peer to Peer TC - Computes the message residence time in a node and also provides corrections for the propagation delay of the link between nodes. It provides this correction information to the slave so it can adjust its time. A domain can have either an End-to-End or a Peer-to-Peer TC, but not both. 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.

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

Module 2 - Page 86 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588v2 Clock Types

Event Messages – for time critical information; time stamped by the sender  Sync – Carries the initial timestamp delivered from master clock.  Delay_Req – Requests a second timestamp, the time at which the recipient received the request, for PDV calculation General Messages – Not timestamped, but used for clock maintenance.  Announce – Provides clock status and characteristics for both the slave and its master. This information is used by the BMCA.  Follow_Up – Delivers to the slave an accurate egress Sync message timestamp for two-step clock operation.  Delay_Resp – Returns to the slave the second time stamp for PDV calculation.  Management – Provide access to IEEE 1588v2 specific parameters.  Signaling – Carry requests and commands between clocks. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

87

All rights reserved © 2012 Alcatel-Lucent

SROS Supported PTP Message Types SROS supports ordinary master or slave clocks, and so supports the messages necessary to synchronize and maintain the domain’s clocks. Event Messages Carry 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 Messages The are messages used for clock maintenance, but not for synchronization. •Announce – Provides master and slave clock status and characteristics. The slave announces the intervals over which it wants to receive messages from the master, and the master announces its clock quality, accuracy, and other characteristics for the slave to use for selecting the best master. •Follow_Up – Used with a two-step clock to provide the actual time the Sync message left the 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.

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

Module 2 - Page 87 | All rights reserved © 2012 Alcatel-Lucent

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

SROS Supported PTP Message Types

34-byte long header included with each PTP message  Indicates the message type  Includes a sequence ID and correction field for transparent clock use  Sent out all PTP logical ports  PTP uses UDP transport  Port 319 – Event port  Port 320 – General message port

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

Module 2 |

88

All rights reserved © 2012 Alcatel-Lucent

PTP Message Header IEEE 1588 describes the PTP message header format.  Transport – Bit 0 is used for compatibility with 1588v1 and is set to 0 for v2. Bits 1-3 are reserved (000).  Message Type – Identifies the PTP message type. The current standard describes 10 message types, carried after the header in TLV format. The following are supported in SROS: • Announce – Message type B • Delay_Req(uest) – Message type 1 • Delay Res(ponse) – Message type 9 • Management – Message type D • Signaling – Message type C • Sync – Message type 0.  Version – PTP Version. Currently version 2.  Message Length – Total PTP message length, in octets including the header.  Domain Number – 0-255. Default is 0. Identifies the 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.

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

Module 2 - Page 88 | All rights reserved © 2012 Alcatel-Lucent

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

PTPv2 Message Header

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

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

Module 2 |

89

All rights reserved © 2012 Alcatel-Lucent

PTPv2 Signaling Message Signaling 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.

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

Module 2 - Page 89 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 2 |

90

All rights reserved © 2012 Alcatel-Lucent

PTPv2 Announce Message IEEE 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.

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

Module 2 - Page 90 | All rights reserved © 2012 Alcatel-Lucent

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

PTPv2 Announce Message

Sync and Delay_Req Messages  10-bytes  Carries origin timestamp  PTP Event messages Delay_Resp Messages  20-bytes  Carries Delay_Req message receipt timestamp  Identifies requesting PTP port  PTP General message

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

Module 2 |

91

All rights reserved © 2012 Alcatel-Lucent

PTP Sync and Delay Messages The One-step message set includes the Sync, Delay-Req and Delay-Resp Messages. •Sync - Sent by the master to deliver the initial timestamp. The slave records the time it receives this message to use in it offset calculations. The timestamp takes the form , 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.

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

Module 2 - Page 91 | All rights reserved © 2012 Alcatel-Lucent

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

PTPv2 Sync and Delay Messages

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

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

Module 2 |

92

All rights reserved © 2012 Alcatel-Lucent

IEEE 1588 PTP Unicast Negotiation Sequence Announcement 1. An IEEE 1588 slave announces itself on the network with a PTP Request Unicast Announce TLV, signaling message type 0xb0. A receiving device only answers messages targeting its configured PTP port, as specified in the 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.

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

Module 2 - Page 92 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588 PTP Unicast Negotiation Sequence

Synchronization in two-way, one-step operation 1 The master sends periodic Announce messages at rate set by slave 2 The master timestamps each Sync packet (t1), in hardware, at egress 3 The slave takes a timestamp (t2) when the message arrives 4 The slave sends a Delay_Req(uest) message to the configured master and sets a timestamp (t3) 5 The master responds to the slave with Delay_Resp(onse) message (t4) 6 The slave calculates the mean* one-way delay and the clock offset, and adjusts its clock accordingly

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

Module 2 |

93

All rights reserved © 2012 Alcatel-Lucent

IEEE 1588 Two-Way, One-Step Time Transfer Sequence The SROS nodes take all time stamps in hardware. By time stamping messages in hardware, the sender and receiver more accurately reflect the actual transmission and reception times, and are not influenced by their own processing delays. 1. The master sends periodic Announce messages at the rate set by the slave in the Announce Request message. 2. The master sends Sync messages at rate set by the slave. The master timestamps the Sync messages (t1). 3. The slave records the time it receives the Sync messages (t2), and uses this difference in its delay and offset calculations. 4. The slave sets a timestamp (t3) and sends a Delay_Req(uest) message. 5. The master sets a timestamp (t4) sends a Delay_Resp(onse) message. 6. The slave uses the cumulated timestamps in its delay and offset calculations. The time the slave takes to synchronize its clock will vary, but it can take in excess of 10 minutes for the synchronization process to complete. Once completed the slave locks its SSU to the 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.

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

Module 2 - Page 93 | All rights reserved © 2012 Alcatel-Lucent

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

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

A slave node may receive announcements from multiple masters • The slave captures information from each potential master • The slave runs a Best Master Clock Algorithm (BMCA) against each master’s information to select the best master

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

Module 2 |

94

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 94 | All rights reserved © 2012 Alcatel-Lucent

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

1588v2 Best Master Clock Selection

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

95

All rights reserved © 2012 Alcatel-Lucent

1588v2 Alternate BMCA 1588v2 allows for an alternative BMCA (ABMCA) which may use additional criteria for master clock selection. 1588v2 Profiles 1588v2 profiles define unique clock characteristics based on an application, such as when using 1588v2 in a telecommunications environment. This profile may set specific announce and sync intervals, time out values, clock mode and operation, and master clock selection criteria. SROS Profiles SROS supports two profiles: • The IEEE 1588-2008 profile – This profile uses the standard BMCA described previously. • The ITU-T G.8265.1-2010 Telecom profile - SROS supports the ITU-T G.8265.1 “ITU-T PTP Profile for Frequency Distribution without Timing Support from the Network (Unicast Mode)” profile. This profile allows for an ABMCA which considers the 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.

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

Module 2 - Page 95 | All rights reserved © 2012 Alcatel-Lucent

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

1588v2 Alternate BMCA

PTP Slave Logical PTP Port State Machine

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

Module 2 |

96

All rights reserved © 2012 Alcatel-Lucent

PTP Slave Logical PTP Port State Machine PTP ports start in the initial state. Once the clock is configured and turned up, the ports go to the listening state. The PTP grandmaster announces its presence on the network. Once the slave receives the master 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 summary command displays the master and slave port states.

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

Module 2 - Page 96 | All rights reserved © 2012 Alcatel-Lucent

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

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

Each node is configured as a boundary clock*  Only one PTP slave port per node  Nodes can be masters to multiple slaves  Passive PTP ports to provide redundancy  Timing domain design ensures clock traceability Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

97

*Note: SROS 9R4 only supports master or slave

All rights reserved © 2012 Alcatel-Lucent

PTP in the Model 2 Ring Architecture Within 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.

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

Module 2 - Page 97 | All rights reserved © 2012 Alcatel-Lucent

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

PTP in the Model 2 Ring Architecture

Each node chooses a single PTP master  Only one traceable path back to the master  Redundant paths available in case master goes offline or becomes unavailable Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

98

All rights reserved © 2012 Alcatel-Lucent

Resulting Model 2 Timing Distribution Tree Based on the advertised clock source quality and their level reference order, the nodes prune redundant paths back to the master. Each node uses the ABMCA to choose its PTP slave and master ports. Since a node cannot have two masters, those ports that the node does not select as PTP slaves or masters become PTP passive ports - this eliminates potential loops. The ABMCA ensures that only one PTP master exists on each network segment. PTP Port States The 1588v2 standard defines the following PTP port states: Initializing – The node initializes PTP data, hardware, and communications. No messages leave the PTP port in this state. Faulty – The protocol is failed. The PTP port will only send management messages in response to other management messages on the 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.

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

Module 2 - Page 98 | All rights reserved © 2012 Alcatel-Lucent

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

Resulting Model 2 Timing Distribution Tree

1 Send message at:

MLS1t1=1278.663325s

2 Receive message at:

CSA1t2 = 1278.663375s

3

1 The PTP Master, MLS1, sets a timestamp in the Sync message; at the same time, t1, CSA1 clock is fast by 20KHz 2 CSA1 receives the packet with no delay 3 CSA1 adjusts its clock by the difference, -20 KHz

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

Module 2 |

Adjust to: MLS1t1 1278.663325s - CSA1t2 1278.663375s MLS1t1-CSA1t2 = -50us 1/-50us = -20KHz

99

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 99 | All rights reserved © 2012 Alcatel-Lucent

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

Offset Calculation with no Path Delay

3 Receive message

at CSA1t2: 1278.663377s

1 Send message at:

MLS1t1=1278.663325s

Adjust to: MLS1t1 1278.663325s - CSA1t2 1278.663377s MLS1t1-CSA1t2 = -52us 1/-52us = -19.3KHz

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

4

2 The intermediate nodes impose residence delay of 1us each as the packet travels to the slave node 3 CSA1 receives the message 2us after MLS1 sent it 4 CSA1 adjusts its clock by the difference plus the delay, 1/-52 us = -19.3KHz Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

100

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 100 | All rights reserved © 2012 Alcatel-Lucent

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

Path Delay Effect on Received Timestamp

• Clock offset = 152-100 = 52 usecs (not considering path delay) • Mean path delay = [(152-100)+(109-157)]/2 = 2 usecs (result of t3-t4 timestamps) • Clock offset less mean path delay = 52 usecs – 2 usecs = -50 usecs Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

101

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 101 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588 PTP Offset Calculations

Ex: Each node is configured as a boundary clock  Each node chooses a master from its configured domain  Each node requests announce and sync messages from potential masters, and chooses its master by reference order and/or quality level  To avoid timing loops, BMCA chooses only one slave port per node Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

102

All rights reserved © 2012 Alcatel-Lucent

PTP Message Flow – Model 2 Unicast Negotiations The MLS, POC2 and 3 and CSA routers are PTP enabled and configured as boundary clocks. This means that they act both as masters and slaves. The 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-bylink basis. MLS1 and POC2-1 exchange announce and sync messages, and depending on the PTP profile used, the slave node chooses the reference by priority, quality level, or both. The same process occurs on all PTP enabled nodes. Clock Traceability and Loop Avoidance A PTP node chooses only one master; the BMCA ensures a node only has one slave port active at a time. The ITU-T G.8265.1 Telecom Frequency profile allows the nodes to choose their master by quality level. The 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.

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

Module 2 - Page 102 | All rights reserved © 2012 Alcatel-Lucent

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

PTP Message Flow - Model 2 Unicast Negotiations

The PTP domain master sends periodic announce messages at the specified rate - Default 1 every 2 seconds  The master forwards time stamped periodic sync messages – Default 64 messages per second  The slave sends Delay request  The master returns Delay response – Default 64 messages per second Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

103

All rights reserved © 2012 Alcatel-Lucent

PTP Message Flow - Model 2 Synchronization Once 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).

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

Module 2 - Page 103 | All rights reserved © 2012 Alcatel-Lucent

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

PTP Message Flow - Model 2 Synchronization

Link failure between MLS1 and POC2-1 1 POC2-1 goes into holdover after 5 minutes of missing MLS1 messages 2 POC2-1 sends QL-EEC toward POC3-1 3 POC3-1 receives QL-PRC from direction of MLS2 4 Nodes choose better reference according to their configurations Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

104

All rights reserved © 2012 Alcatel-Lucent

PTP Message Flow – Failure on MLS1 Link POC2-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.

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

Module 2 - Page 104 | All rights reserved © 2012 Alcatel-Lucent

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

PTP Message Flow – Failure on MLS1 Link

Configuring for PTP Master – 7750 SR Context: Context: config>system config>system ptp ptp

Context: Context: config>system>ptp config>system>ptp Syntax: Syntax:

clock-type clock-type ordinary ordinary {master|slave} {master|slave} [no] [no] domain domain network-type network-type {sdh|sonet} {sdh|sonet} [no] [no] shutdown shutdown

Example: Example: config>system# config>system# ptp ptp config>system>ptp# config>system>ptp# clock-type clock-type ordinary ordinary master master config>system>ptp# config>system>ptp# domain domain 44 config>system>ptp# config>system>ptp# network-type network-type sonet sonet config>system>ptp# no config>system>ptp# no shutdown shutdown

Configure the master clock configure system ptp context  The master and slave domains must match  The master and slave network type must match  You must turn up the clock once you complete its configuration Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

105

All rights reserved © 2012 Alcatel-Lucent

Configuring for PTP Master – 7750 SR The clock configuration steps differ for the 7750 SR and the 7705 SAR. 7750 SR Master Configure the clock in the configure system ptp context: A:NodeA# configure system ptp  •clock-type – Currently supported is clock type ordinary master or slave. •domain – The PTP domain specifies one or more devices communicating with each other as defined by the 1588v2 protocol. Domain membership defines messages, operations, and data exchange. Each domain gets a unique numeric identifier, from 0-255. •0 is the default domain •1-3 are alternate domains •4-127 are user defined •128-255 are Reserved. SROS on the 7750 uses the default domain 0 to identify the 1588 profile, and domain 4 to identify the G.8265.1 telecom profile. •network-type – Identifies the SSM QL codes passed in the clockClass values for the G.8265.1 telecom profile. PTP configuration requires that you set a number of variables, so the configuration process covers several slides.

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

Module 2 - Page 105 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

Configuring for PTP Slave – 7705 SAR

Syntax: Syntax:

clock-type clock-type {{ordinary {{ordinary {master|slave} {master|slave} || boundary} boundary} source-interface source-interface clock-mda clock-mda domain domain priority1 priority1 [0-255] [0-255] priority2 priority2 [0-255] [0-255] profile profile {ieee1588-2008|itu-telecom-freq} {ieee1588-2008|itu-telecom-freq} ptp-port ptp-port [1-10] [1-10]

Example: Example: config>system>ptp>clock# config>system>ptp>clock# clock-type clock-type ordinary ordinary slave slave config>system>ptp>clock# config>system>ptp>clock# source-interface source-interface loop_ptp loop_ptp config>system>ptp>clock# config>system>ptp>clock# clock-mda clock-mda 1/2 1/2 config>system>ptp>clock# config>system>ptp>clock# domain domain 44 config>system>ptp>clock# config>system>ptp>clock# profile profile itu-telecom-freq itu-telecom-freq config>system>ptp>clock# config>system>ptp>clock# ptp-port ptp-port 11

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

Module 2 |

106

All rights reserved © 2012 Alcatel-Lucent

Configuring for PTP Slave – 7705 SAR Under 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...

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

Module 2 - Page 106 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>system>ptp>clock config>system>ptp>clock

Configuring for PTP Slave – 7705 SAR (cont)

Syntax: Syntax:

clock-type clock-type {{ordinary {{ordinary {master|slave} {master|slave} || boundary} boundary} source-interface source-interface clock-mda clock-mda domain domain priority1 priority1 [0-255] [0-255] priority2 priority2 [0-255] [0-255] profile profile {ieee1588-2008|itu-telecom-freq} {ieee1588-2008|itu-telecom-freq} ptp-port ptp-port [1-10] [1-10]

Example: Example: config>system>ptp>clock# config>system>ptp>clock# clock-type clock-type ordinary ordinary slave slave config>system>ptp>clock# source-interface config>system>ptp>clock# source-interface loop_ptp loop_ptp config>system>ptp>clock# config>system>ptp>clock# clock-mda clock-mda 1/2 1/2 config>system>ptp>clock# config>system>ptp>clock# domain domain 44 config>system>ptp>clock# config>system>ptp>clock# profile profile itu-telecom-freq itu-telecom-freq config>system>ptp>clock# config>system>ptp>clock# ptp-port ptp-port 11

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

Module 2 |

107

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 107 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>system>ptp>clock config>system>ptp>clock

Configuring for PTP Slave – 7705 SAR (cont)

Syntax: Syntax:

[no] [no] shutdown shutdown peer peer [1..10] [1..10]

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

description description description description ip-address ip-address

Example: Example: config>system>ptp>clock>ptp-port# config>system>ptp>clock>ptp-port# peer peer 11 config>system>ptp>clock>ptp-port>peer# config>system>ptp>clock>ptp-port>peer# ip-address ip-address 192.0.2.0 192.0.2.0 config>system>ptp>clock>ptp-port>peer# config>system>ptp>clock>ptp-port>peer# description description peer_MLS1 peer_MLS1 config>system>ptp>clock>ptp-port>peer# config>system>ptp>clock>ptp-port>peer# back back config>system>ptp>clock>ptp-port# config>system>ptp>clock>ptp-port# no no shutdown shutdown config>system>ptp>clock>ptp-port# config>system>ptp>clock>ptp-port# back back config>system>ptp>clock# config>system>ptp>clock# no no shutdown shutdown config>system>ptp>clock# config>system>ptp>clock# exit exit all all

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

Module 2 |

108

All rights reserved © 2012 Alcatel-Lucent

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  2 = 1 message/4 seconds  3 = 1 message/8 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.

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

Module 2 - Page 108 | All rights reserved © 2012 Alcatel-Lucent

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

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

Set the Node Timing References – 7705 SAR

Syntax: Syntax:

begin begin [no] [no] ref-order ref-order [] [] commit commit abort abort

Example: Example: config# config# system system sync-if-timing sync-if-timing config>system>sync-if-timing# config>system>sync-if-timing# begin begin config>system>sync-if-timing# config>system>sync-if-timing# ref-order ref-order ref1 ref1 ref2 ref2 external external config>system>sync-if-timing# config>system>sync-if-timing# ref1 ref1 source-ptp-clock source-ptp-clock 11 config>system>sync-if-timing# config>system>sync-if-timing# ref1 ref1 no no shutdown shutdown config>system>sync-if-timing# config>system>sync-if-timing# commit commit config>system>sync-if-timing# config>system>sync-if-timing# back back config>system# config>system# back back

Enable PTP as a timing reference  Modify reference order to specify PTP source as required  Configure the PTP reference source

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

Module 2 |

109

All rights reserved © 2012 Alcatel-Lucent

Set the Node Timing References Configure the node timing references and reference order in the configure system sync-if-timing context.  begin – Enter edit or create mode  ref-order – Determines the order in which the node chooses its reference source. The 7705 SAR default is ref1 ref2 external. The 7750 SR default is bits ref1 ref2 ptp.  ref1|ref2 - When configuring the node as a ptp slave, you must specify the reference clock. When configured as a master, this step is not necessary. Note that the clock must exist, there are no default PTP clock sources. A:NodeA>config>system>sync-if-timing# ref1 source-ptp-clock 1   commit – Saves changes to the timing configuration. Until you issue commit, the changes have no effect.

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

Module 2 - Page 109 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>system>sync-if-timing config>system>sync-if-timing

A:MLS1# A:MLS1# show show system system ptp ptp =============================================================================== =============================================================================== IEEE IEEE 1588/PTP 1588/PTP Clock Clock Information Information =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Local Local Clock Clock ------------------------------------------------------------------------------------------------------------------------------------------------------------Clock :: ordinary,master PTP :: ITU-T Clock Type Type ordinary,master PTP Profile Profile ITU-T G.8265.1 G.8265.1 Domain :: 44 Network :: sonet Domain Network Type Type sonet Admin :: up Oper :: up Admin State State up Oper State State up Clock :: 0003fafffe688fc0 :: 80 Clock Id Id 0003fafffe688fc0 Clock Clock Class Class 80 (prs) (prs) Clock Accuracy : unknown Clock Variance : ffff Clock Accuracy : unknown Clock Variance : ffff (not (not computed) computed) Clock Clock :: 128 Clock Priority1 Priority1 :: 128 128 Clock Priority2 Priority2 128 PTP :: master Last :: 10/21/2011 PTP Port Port State State master Last Changed Changed 10/21/2011 16:12:45 16:12:45 =============================================================================== ===============================================================================

• The default profile is ITU-T Telecom Profile G.8265.1 • The network type default is SDH, must be set to SONET • The clock class identifies the clock quality level

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

Module 2 |

110

All rights reserved © 2012 Alcatel-Lucent

View the Master PTP Configuration – 7750 SR A:NodeA# show system ptp  PTP Profile: – Domain 4 sets the ITU-T Telecom Profile. This allows the nodes to select their Master by quality level. When set to ITU-T G.8265.1, the node chooses its master first by the QL value advertised in the PTP Announce message Clock Quality field. If it receives the same QL value on different domains, it chooses by the Priority values sent in the Announce messages. Network Type: - The default is SDH. Set to SONET to support SONET quality levels. Clock Class: - Indicates the master clock class as defined in G.8265.1 Table 1. PTP Port State: - The logical PTP port state.

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

Module 2 - Page 110 | All rights reserved © 2012 Alcatel-Lucent

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

View the PTP Master Configuration – 7750 SR

View the PTP Master Peers – 7750 SR

=============================================================================== =============================================================================== IEEE IEEE 1588/PTP 1588/PTP Peer Peer Information Information =============================================================================== =============================================================================== IP :: 192.0.2.1 Announce IP Address Address 192.0.2.1 Announce Direction Direction :: tx tx Clock :: 0003fafffe6bd7c0 :: 11 Clock Id Id 0003fafffe6bd7c0 Remote Remote PTP PTP Port Port ------------------------------------------------------------------------------------------------------------------------------------------------------------IP :: 192.0.2.227 Announce IP Address Address 192.0.2.227 Announce Direction Direction :: tx tx Clock Id : 7c2064fffec348b8 Remote PTP :: 11 Clock Id : 7c2064fffec348b8 Remote PTP Port Port ------------------------------------------------------------------------------------------------------------------------------------------------------------IP :: 192.0.2.228 Announce IP Address Address 192.0.2.228 Announce Direction Direction :: tx tx Clock Id : 7c2064fffec3040e Remote PTP :: 11 Clock Id : 7c2064fffec3040e Remote PTP Port Port =============================================================================== ===============================================================================

• The MLS routers can peer by system ID • The CSA routers peer by the source interface address • The clock ID is based on the chassis MAC address Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

111

All rights reserved © 2012 Alcatel-Lucent

View the PTP Master Peers – 7750 SR A:NodeA# show system ptp peers detail  IP Address: – Lists the peer’s IP address. Announce direction: - tx for master, rx for slave Clock ID: - 8 bytes based on the chassis MAC address Remote PTP Port: - The logical PTP port number for this peer.

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

Module 2 - Page 111 | All rights reserved © 2012 Alcatel-Lucent

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

A:MLS1# A:MLS1# show show system system ptp ptp peers peers detail detail

View the PTP Master Peer Details – 7750 SR

=============================================================================== =============================================================================== IEEE IEEE 1588/PTP 1588/PTP Peer Peer Information Information =============================================================================== =============================================================================== IP :: 192.0.2.227 Announce IP Address Address 192.0.2.227 Announce Direction Direction :: tx tx Clock Id : 143e60fffe7eada6 Remote PTP :: 11 Clock Id : 143e60fffe7eada6 Remote PTP Port Port =============================================================================== =============================================================================== =============================================================================== =============================================================================== IEEE IEEE 1588/PTP 1588/PTP Unicast Unicast Negotiation Negotiation Information Information =============================================================================== =============================================================================== IP Dir Rate Duration Time IP Address Address Dir Type Type Rate Duration State State Time ------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.227 Tx Granted 192.0.2.227 Tx Announce Announce 11 pkt/2 pkt/2 ss 300 300 Granted 11/22/2011 11/22/2011 14:48:37 14:48:37 192.0.2.227 Tx 64 Granted 192.0.2.227 Tx Sync Sync 64 pkt/s pkt/s 300 300 Granted 11/22/2011 11/22/2011 14:46:12 14:46:12 192.0.2.227 Tx Granted 192.0.2.227 Tx Delay Delay Resp Resp 64 64 pkt/s pkt/s 300 300 Granted 11/22/2011 11/22/2011 14:46:12 14:46:12 =============================================================================== =============================================================================== ...continued on the next slide ...continued on the next slide

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

Module 2 |

112

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 112 | All rights reserved © 2012 Alcatel-Lucent

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

A:MLS1# A:MLS1# show show system system ptp ptp peer peer 192.0.2.227 192.0.2.227 detail detail

A:MLS1# A:MLS1# show show system system ptp ptp peer peer 192.0.2.227 192.0.2.227 detail detail ... ... =============================================================================== =============================================================================== IEEE IEEE 1588/PTP 1588/PTP Packet Packet Statistics Statistics =============================================================================== =============================================================================== Input Output Input Output ------------------------------------------------------------------------------------------------------------------------------------------------------------PTP 4946482 9930069 PTP Packets Packets 4946482 9930069 Announce 0 38635 Announce 0 38635 Sync 0 4944952 Sync 0 4944952 Follow 00 00 Follow Up Up Delay Request 4944951 00 Delay Request 4944951 Delay 00 4944951 Delay Response Response 4944951 Signaling 1531 1531 Signaling 1531 1531 Request 1531 00 Request Unicast Unicast Transmission Transmission TLVs TLVs 1531 Announce 511 00 Announce 511 Sync 510 00 Sync 510 Delay 510 00 Delay Response Response 510 Grant Unicast Transmission (Accepted) TLVs 0 1531 Grant Unicast Transmission (Accepted) TLVs 0 1531 Announce 00 511 Announce 511 Sync 0 510 Sync 0 510 Delay 00 510 Delay Response Response 510 ... ... Continued Continued on on next next slide slide

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

Module 2 |

113

All rights reserved © 2012 Alcatel-Lucent

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. IEEE 1588/PTP Packet Statistics The counters indicate the number of received and transmitted PTP packets. •Input The master receives signaling messages: Request Announce, Request Sync, and Delay Request. •Output The master sends Announce and Sync messages. It also sends Delay Response messages.

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

Module 2 - Page 113 | All rights reserved © 2012 Alcatel-Lucent

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

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

A:MLS1# A:MLS1# show show system system ptp ptp peer peer 192.0.2.227 192.0.2.227 detail detail ... ... Grant 00 00 Grant Unicast Unicast Transmission Transmission (Denied) (Denied) TLVs TLVs Announce 00 00 Announce Sync 00 00 Sync Delay Response 0 00 Delay Response 0 Cancel 00 00 Cancel Unicast Unicast Transmission Transmission TLVs TLVs Announce 0 0 Announce 0 0 Sync 00 00 Sync Delay 00 00 Delay Response Response Ack 00 00 Ack Cancel Cancel Unicast Unicast Transmission Transmission TLVs TLVs Announce 00 00 Announce Sync 00 00 Sync Delay 00 00 Delay Response Response Other TLVs 0 00 Other TLVs 0 Other 00 00 Other Discards 00 00 Discards Bad 00 00 Bad PTP PTP domain domain Alternate 00 00 Alternate Master Master Other 0 00 Other 0 =============================================================================== ===============================================================================

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

Module 2 |

114

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 114 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 2 |

115

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 115 | All rights reserved © 2012 Alcatel-Lucent

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

View The PTP Slave Configuration – 7750 SR

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

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

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

Module 2 - Page 116 | All rights reserved © 2012 Alcatel-Lucent

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

View The PTP Slave Configuration – 7705 SAR

A:CSA1# show system ptp clock 1 ptp-port 1 peer 1 detail A:CSA1# show system ptp clock 1 ptp-port 1 peer 1 detail =============================================================================== =============================================================================== Peer-1 Peer-1 =============================================================================== =============================================================================== IP Address : 192.0.2.0 static/dynamic : static IP Address : 192.0.2.0 static/dynamic : static Current Master : TRUE Current Master : TRUE Description : peer_MLS1 Description : peer_MLS1 Clock Id : 0003fafffe688fc0 Port Number : 1 Clock Id : 0003fafffe688fc0 Port Number : 1 GM Clock Id : 0003fafffe688fc0 GM Clock Class : 80 GM Clock Id : 0003fafffe688fc0 GM Clock Class : 80 GM Clock Accuracy : unknown(254) GM Clock Variance : not computed GM Clock Accuracy : unknown(254) GM Clock Variance : not computed GM Clock Priority1 : 128 GM Clock Priority2 : 128 GM Clock Priority1 : 128 GM Clock Priority2 : 128 Step Type : one-step Step Type : one-step Last Rx Anno Msg : 11/22/2011 14:54:36 Last Rx Anno Msg : 11/22/2011 14:54:36 ----------------------------------------------------------------------------------------------------------------------------------------------------Unicast Info Unicast Info ----------------------------------------------------------------------------------------------------------------------------------------------------Dir Type Rate Dur Result Time Remain Dir Type Rate Dur Result Time Remain ----------------------------------------------------------------------------------------------------------------------------------------------------Rx Anno 1 pkt/2 s 300 granted 11/22/2011 14:53:35 241 Rx Anno 1 pkt/2 s 300 granted 11/22/2011 14:53:35 241 Sync 64 pkts/s 300 granted 11/22/2011 14:53:41 249 Sync 64 pkts/s 300 granted 11/22/2011 14:53:41 249 DelayResp 64 pkts/s 300 granted 11/21/2011 14:53:41 249 DelayResp 64 pkts/s 300 granted 11/21/2011 14:53:41 249 ----------------------------------------------------------------------------------------------------------------------------------------------------=============================================================================== =============================================================================== ...continued on next page ...continued on next page Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

117

All rights reserved © 2012 Alcatel-Lucent

View the PTP Slave PTP Port Peer – 7705 SAR A:NodeA# show system ptp clock 1 ptp-port 1 peer 1 detail  Peer-1 IP Address: – Lists the 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.

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

Module 2 - Page 117 | All rights reserved © 2012 Alcatel-Lucent

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

View The PTP Slave PTP Port Peer – 7705 SAR

A:CSA2# show system ptp clock 1 ptp-port 1 peer 1 detail A:CSA2# show system ptp clock 1 ptp-port 1 peer 1 detail ...continued from previous page ...continued from previous page ...output truncated ...output truncated

=============================================================================== =============================================================================== PTP Peer 1 Algorithm State Statistics (in seconds) PTP Peer 1 Algorithm State Statistics (in seconds) =============================================================================== =============================================================================== Free-run : 604 Free-run : 604 Acquiring : 120 Acquiring : 120 Phase-Tracking : 1440 Phase-Tracking : 1440 Hold-over : 0 Hold-over : 0 Locked : 75504 Locked : 75504 =============================================================================== ===============================================================================

...continued on next page ...continued on next page

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

Module 2 |

118

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 118 | All rights reserved © 2012 Alcatel-Lucent

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

View the PTP Slave Configuration – 7705 SAR (cont)

A:CSA2# show system ptp clock 1 ptp-port 1 peer 1 detail A:CSA2# show system ptp clock 1 ptp-port 1 peer 1 detail ...continued from previous page ...continued from previous page ...output truncated ...output truncated =============================================================================== =============================================================================== PTP Peer-1 Clock Recovery PTP Peer-1 Clock Recovery - Internal Digital Phase Locked Loop (DPLL) Statistics - Internal Digital Phase Locked Loop (DPLL) Statistics =============================================================================== =============================================================================== sync delay-req phase phase sync delay-req phase phase pkt delay pkt delay error error pkt delay pkt delay error error stddev stddev stddev stddev stddev stddev time (ns) (ns) (ns) (ns) time (ns) (ns) (ns) (ns) ------------------------------------------------------------------------------------------------------------------------------------------------------------11/22/2011 14:55:51 7 233 -327 21 11/22/2011 14:55:51 7 233 -327 21 11/22/2011 14:53:51 7 225 -376 12 11/22/2011 14:53:51 7 225 -376 12 11/22/2011 14:51:50 6 206 -445 25 11/22/2011 14:51:50 6 206 -445 25 11/22/2011 14:49:50 10 223 -513 16 11/22/2011 14:49:50 10 223 -513 16 11/22/2011 14:47:50 19 236 -551 9 11/22/2011 14:47:50 19 236 -551 9 11/22/2011 14:45:50 4 223 -563 7 11/22/2011 14:45:50 4 223 -563 7 11/22/2011 14:43:50 0 249 -589 13 11/22/2011 14:43:50 0 249 -589 13 11/22/2011 14:41:50 3 233 -599 7 11/22/2011 14:41:50 3 233 -599 7 11/22/2011 14:39:50 3 230 -609 8 11/22/2011 14:39:50 3 230 -609 8 ...output truncated ...output truncated Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

119

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 119 | All rights reserved © 2012 Alcatel-Lucent

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

View the PTP Slave Configuration – 7705 SAR (cont)

View the Slave Timing References – 7750 SR

=============================================================================== =============================================================================== System Interface Timing Operational Info System Interface Timing Operational Info =============================================================================== =============================================================================== System Status CPM A : Master Locked System Status CPM A : Master Locked Reference Input Mode : Non-revertive Reference Input Mode : Non-revertive Quality Level Selection : Disabled Quality Level Selection : Disabled Reference Selected : ptp Reference Selected : ptp System Quality Level : prs System Quality Level : prs Current Frequency Offset (ppm) : +0 Current Frequency Offset (ppm) : +0 Reference Order : ptp ref1 ref2 bits Reference Order : ptp ref1 ref2 bits ...output truncated ...output truncated Reference PTP Reference PTP Admin Status : up Admin Status : up Rx Quality Level : prs Rx Quality Level : prs Quality Level Override : none Quality Level Override : none Qualified For Use : Yes Qualified For Use : Yes Selected For Use : Yes Selected For Use : Yes =============================================================================== ===============================================================================

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

Module 2 |

120

All rights reserved © 2012 Alcatel-Lucent

View the Slave Timing References – 7750 SAR The MLS2 slave has locked its master clock to reference input 1. Note that this can take some time, up to 15 minutes or more for the slave to synchronize with and qualify the master clock.  System Status CPM A: – 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.

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

Module 2 - Page 120 | All rights reserved © 2012 Alcatel-Lucent

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

A:MLS2# show system sync-if-timing A:MLS2# show system sync-if-timing

View the Slave Timing References – 7705 SAR

=============================================================================== =============================================================================== System Interface Timing Operational Info System Interface Timing Operational Info =============================================================================== =============================================================================== System Status CSM A : Master Locked System Status CSM A : Master Locked Reference Input Mode : Non-revertive Reference Input Mode : Non-revertive Quality Level Selection : Disabled Quality Level Selection : Disabled Reference Order Reference Order

: ref1 ref2 external : ref1 ref2 external

Reference Input 1 Reference Input 1 Admin Status Admin Status Configured Quality Level Configured Quality Level Rx Quality Level Rx Quality Level Qualified For Use Qualified For Use Selected For Use Selected For Use Source Port Source Port Source PTP Clock Source PTP Clock ...output truncated ...output truncated

: up : up : none : none : prs : prs : Yes : Yes : Yes : Yes : None : None : 1 : 1

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

Module 2 |

121

All rights reserved © 2012 Alcatel-Lucent

View the Slave Timing References – 7705 SAR The CSA slave has locked its master clock to reference input 1. Note that this can take some time, up to 15 minutes or more for the slave to synchronize with and qualify the master clock.  Rx Quality Level – The level set by master, QL-PRS  Qualified For Use – The reference PTP clock is synchronized to a suitable master port.  Selected For Use – The CSA has selected this port as its timing reference.  Source Port – There is no source port for PTP.  Source PTP Clock – The slave is configured to synchronize off PTP clock 1.

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

Module 2 - Page 121 | All rights reserved © 2012 Alcatel-Lucent

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

A:CSA2# show system sync-if-timing A:CSA2# show system sync-if-timing

To ensure reliable and accurate time delivery: • Use only high bandwidth, low latency links between the clocks • Assign PTP packets to Forwarding Class Network Control (NC) and ensure elevated treatment for these packets • Limit the number of hops between the master and slave to no more than 5 intermediate nodes (PTP over fiber) • Use boundary or transparent clocks to extend the PTP domain reach without increasing PDV • Keep the ports on which the PTP packets are sent or received local to the PTP master or slave MDA  If MDA 1/1 hosts the PTP master source interface network port, then the ports through which it sends and receives PTP packets should be 1/1/1, 1/1/2, etc.

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

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

Module 2 |

122

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 122 | All rights reserved © 2012 Alcatel-Lucent

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

IEEE 1588v2/PTPv2 Design Considerations

.5 Hour Lab Overview:

 Configure MLS1 as the PTP master and slave the SAR routers off MLS1  Configure MLS2 as the SAR router secondary reference  Fail the MLS1 reference and observe MLS2 become the master NOTE: 7750 will not operate as PTP slave without SF/CPM-3 installed Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

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

Module 2 |

123

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 123 | All rights reserved © 2012 Alcatel-Lucent

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

Lab 4 : Configure IEEE 1588v2 and PTP

Section Summary

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

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

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

Module 2 |

124

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 124 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Module 2 — Implementing the Mobile Backhaul Transport Network

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

Section 5 — Routing and Routing Protocols

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

Module 2 - Page 125 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 2 |

126

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 126 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we will:

Section Objectives (cont)

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

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

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

Module 2 |

127

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 127 | All rights reserved © 2012 Alcatel-Lucent

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

 Describe routing in the Model 2 network

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

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

Module 2 |

128

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 128 | All rights reserved © 2012 Alcatel-Lucent

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

Routing in the Mobile Backhaul Transport Network

Transport may be TDM, Ethernet, or both  Strictly L3 services for 2G IPBH over TDM uplink  Routed or MPLS for 3G EBH and LTE traffic  May use static routes from CSA to MLS routers  Floating static routes between CSA and MLS routers  BFD on static routes for rapid failure detection  LDP-sync used to avoid discarded traffic while waiting for label signaling  May use hierarchical routing protocol between CSA and MLS routers

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

Module 2 |

129

All rights reserved © 2012 Alcatel-Lucent

Routing in Model 1 Hub and Spoke Topology The Model 1 topology uses both a TDM and Ethernet transport. For 2G IPBH traffic delivered over bundled DS1s, no routing protocol is necessary. From the BTS and MLS perspective, the ML-PPP bundle interfaces are directly connected and on the same subnet. However, the EBH NodeB and eNodeB are separated from the MLS router by the CSA router, requiring routing between the network segments. In this model 1 topology, the design engineers chose to use static routing, though they could have used an IGP, as well. Although dynamic routing could work here as well, static routing keeps the CSA forwarding tables small, and the few point-to-point links simplify the routing domain to the point where static routing is manageable. Reasons for using static routes in a Backhaul Transport The design may implement static routes in case where:  Customer equipment does not support dynamic routing  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.

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

Module 2 - Page 129 | All rights reserved © 2012 Alcatel-Lucent

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

Routing in the Model 1 Hub and Spoke Topology

CSA to MTSO floating static routes  Two paths to each MLS router  Set higher preference on backup path Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

130

All rights reserved © 2012 Alcatel-Lucent

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.

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

Module 2 - Page 130 | All rights reserved © 2012 Alcatel-Lucent

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

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

A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.5 A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.13 preference 10

 A floating static route provides a means for traffic to follow a backup static route in the event the router detects a failure along the path used by the primary static route. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

131

All rights reserved © 2012 Alcatel-Lucent

Floating Static Routes in the Model 1 Network In the example above, CSA1 has two static routes configured. The top static route points all traffic destined for 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.6 A:MLS1>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.22 preference 10 A:MLS2>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.21 A:MLS2>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.14 A:MLS2>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.21 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.

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

Module 2 - Page 131 | All rights reserved © 2012 Alcatel-Lucent

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

Floating Static Routes in the Model 1 Network

A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.5 bfd-enable A:CSA1>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.13 preference 10

 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

132

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 132 | All rights reserved © 2012 Alcatel-Lucent

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

BFD on the Model 1 Network Static Routes

LDP-Sync protects against black holed LDP packets  Prevents router from sending packets over path for which it has no label  Router holds down route until it has label in LFIB for target FEC  Requires timer set on each IP interface where the feature is used

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

Module 2 |

133

All rights reserved © 2012 Alcatel-Lucent

LDP-Sync on the Static Routes LDP Sync on the static routes ensures that the ingress router does not forward packets over a path until it has a label for it. Since LDP and the IGP converge independently, the ingress router could black hole packets for which it has a valid route but does not yet have a label. Assume that the CSA1-MLS1 link failed and CSA1 and MLS1 had moved traffic to their secondary routes. Without LDP-Sync enabled: 1. The link between CSA1 and MLS1 recovers, causing the routers to activate the primary routes and place them in their FIBs. 2. Due to the link failure, both routers had removed from their LFIB the labels they once had for the primary route. The routers activate the route immediately, but find no corresponding label in their LFIB. Because the secondary route is not longer the best, the routers remove that 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.

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

Module 2 - Page 133 | All rights reserved © 2012 Alcatel-Lucent

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

LDP-Sync on the Static Routes

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

 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

134

All rights reserved © 2012 Alcatel-Lucent

LDP-Sync on Primary Static Route On the primary static routes, the CSA and MLS routers enable LDP-Sync. Static Route Configuration A:MLS1>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.6 bfd-enable ldpsync A:MLS1>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.22 preference 10 A:MLS2>config>router# static-route 192.0.2.0/32 next-hop 192.0.2.21 A:MLS2>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.14 bfd-enable ldpsync A:MLS2>config>router# static-route 192.0.2.2/32 next-hop 192.0.2.21 preference 10 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

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

Module 2 - Page 134 | All rights reserved © 2012 Alcatel-Lucent

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

LDP-sync on Primary Static Route

View the CSA Primary Static Route

=============================================================================== =============================================================================== Static Static Route Route Table Table (Router: (Router: Base) Base) Family: Family: IPv4 IPv4 =============================================================================== =============================================================================== ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Prefix :: 192.0.2.0/32 Prefix 192.0.2.0/32 Nexthop :: 192.0.2.5 Nexthop 192.0.2.5 Type :: Nexthop Nexthop :: IP Type Nexthop Nexthop Type Type IP Interface :: CSA1_MLS1 Active :: YY Interface CSA1_MLS1 Active Prefix :: n/a Prefix Prefix List List n/a Prefix List List Type Type :: n/a n/a Metric : 1 Preference :: 55 Metric : 1 Preference Admin :: Up Tag :: 00 Admin State State Up Tag BFD : enabled BFD : enabled CPE-check :: disabled CPE-check disabled LDP :: enabled LDP Sync Sync enabled LDP :: enabled LDP Sync Sync enabled ... ... output output truncated truncated ------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Static Routes: 4 No. of Static Routes: 4

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

Module 2 |

135

All rights reserved © 2012 Alcatel-Lucent

View the CSA Primary Static Route A:NodeA# show router static-route detail  BFD: – Enabled on all CSA interfaces and static routes. LDP Sync: - Enabled on primary route only Preference: - The default preference is used for the primary route.

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

Module 2 - Page 135 | All rights reserved © 2012 Alcatel-Lucent

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

A:CSA1# A:CSA1# show show router router static-route static-route detail detail

View the CSA BFD Sessions

=============================================================================== =============================================================================== BFD BFD Session Session =============================================================================== =============================================================================== Interface State Tx Interface State Tx Intvl Intvl Rx Rx Intvl Intvl Multipl Multipl Remote Protocol Tx Remote Address Address Protocol Tx Pkts Pkts Rx Rx Pkts Pkts Type Type ------------------------------------------------------------------------------------------------------------------------------------------------------------CSA1_MLS1 Up 500 500 33 CSA1_MLS1 Up (3) (3) 500 500 192.0.2.5 static 8709 7477 iom 192.0.2.5 static 8709 7477 iom CSA1_MLS2 Up (3) 500 500 3 CSA1_MLS2 Up (3) 500 500 3 192.0.2.13 static 9719 9719 iom 192.0.2.13 static 9719 9719 iom ------------------------------------------------------------------------------------------------------------------------------------------------------------No. No. of of BFD BFD sessions: sessions: 22 =============================================================================== ===============================================================================

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

Module 2 |

136

All rights reserved © 2012 Alcatel-Lucent

View the CSA BFD Sessions A:NodeA# show router bfd session  The CSA routers maintain a separate BFD session for each MLS router. The MLS routers maintain a BFD session for only the primary CSA link. A:MLS1# show router bfd session =============================================================================== BFD Session =============================================================================== Interface Remote Address

State

Tx Intvl

Rx Intvl

Multipl

Protocols

Tx Pkts

Rx Pkts

Type

------------------------------------------------------------------------------MLS1_CSA1 192.0.2.6

Up (3) static

500

500

3

2753

2751

iom

------------------------------------------------------------------------------No. of BFD sessions: 1 ===============================================================================

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

Module 2 - Page 136 | All rights reserved © 2012 Alcatel-Lucent

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

A:CSA1# A:CSA1# show show router router bfd bfd session session

View LDP Sync Status

=============================================================================== =============================================================================== Sync Sync Status Status of of LDP LDP interfaces interfaces =============================================================================== =============================================================================== If If Timer Time If Ind* Ind* If Name Name Timer Running? Running? Timeout Timeout Time Yes/No used Left Yes/No used Left ------------------------------------------------------------------------------------------------------------------------------------------------------------22 MLS1_CSA1 Yes 180 174 MLS1_CSA1 Yes 180 174 44 MLS1_MLS2 No 00 00 MLS1_MLS2 No =============================================================================== =============================================================================== •• indicates indicates that that the the corresponding corresponding row row element element may may have have been been truncated. truncated.

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

Module 2 |

137

All rights reserved © 2012 Alcatel-Lucent

View LDP Sync Status A:NodeA# tools dump router static-route ldp-sync-status  Once an interface on which a timer is configured recovers, the router starts the LDP sync timer on that interface. While the Time Left is greater than 0, the router holds down the associated static routes. A:MLS1# show router static-route =============================================================================== Static Route Table (Router: Base)

Family: IPv4

=============================================================================== Prefix Next Hop

Tag

Met

Pref Type Act

Interface

------------------------------------------------------------------------------192.0.2.1/32 192.0.2.22 192.0.2.2/32

0

192.0.2.22

5

NH

Y

1

5

NH

N

1

10

NH

Y

MLS1_MLS2 0

192.0.2.6 192.0.2.2/32

1

n/a 0 MLS1_MLS2

------------------------------------------------------------------------------No. of Static Routes: 3 =============================================================================== MLS1 continues to forward traffic to CSA1 via MLS2, until the LDP sync timer on the MLS1-CSA1 interface recovers.

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

Module 2 - Page 137 | All rights reserved © 2012 Alcatel-Lucent

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

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

The Model 1 topology uses OSPF to advertise routes between MLS routers  Share routes for L3 service redundancy  Adjust SPF timers to reduce calculation frequency

A:MLS1>config>router>ospf# A:MLS1>config>router>ospf# timers timers spf-wait spf-wait 2000 2000 50 50 100 100

Event

2nd run = 100ms

400ms

1600ms

SPF Event Timeline 1st run = 50ms

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

200ms

800ms

max wait = 2000ms

Module 2 |

138

All rights reserved © 2012 Alcatel-Lucent

OSPF in Model 1 To ensure full L3 service redundancy, the Model 1 topology runs OSPF between the two MLS routers. The system interfaces, MLS-to-MLS interfaces, and some NC element interfaces belong to area 0. Only the MLS-MLS interfaces advertise routes, the others are passive interfaces. Routing policies export directly connected interfaces and the static routes to the other MLS router.

OSPF Timers You may modify the default OSPF timers to enable faster convergence. Ideally, the routers should run the SPF calculation only once per event. To facilitate this, the Model 1 design specifies the SPF timer values shown in the diagram above. Times are measured in milliseconds (ms). config>router>ospf>timers spf-wait max-spf-wait [spf-initial-wait [spf-second-wait]] • max-spf-wait – 2000 ms. The maximum interval between consecutive SPF calculations. The default is 1000ms. • spf-initial-wait – 50ms. This allows the sender time to flood the update before running its SPF algorithm on the update. This also gives the other routers in the domain time to collect additional updates for the same event, and run their SPF calculation for the same event. The default is 1000ms. • spf-second-wait – 100ms. This doubles the wait period before running another SPF calculation. This exponential interval reduces router CPU utilization. The default is 1000ms. Each interval doubles until the router reaches the max-spf-wait value, then remains at the max-interval until the router receives no new events.

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

Module 2 - Page 138 | All rights reserved © 2012 Alcatel-Lucent

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

OSPF in Model 1

Routing protocol convergence is affected by the following conditions: 1. Link failure detection 2. Time to generate and send a Link State Advertisement (LSA)/Link State Packet (LSP) after a topology change occurs 3. Time to flood the LSAs/LSPs throughout the network 4. SPF timers 5. Time to update the Routing Information Base (RIB) and FIB

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

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

Module 2 |

139

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 139 | All rights reserved © 2012 Alcatel-Lucent

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

Routing Protocol Convergence Factors

Transport is Ethernet or Ethernet over SONET  Hierarchical routing with POC3 routers as ISIS area border routers  Traffic engineering enabled on both areas  Aggregation ring as Level 2 only shares default route with access area  Each POC1, 2, and 3 router is in its own area  Access ring is common Level 1 area  iBGP for VPRN route distribution

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

Module 2 |

140

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 140 | All rights reserved © 2012 Alcatel-Lucent

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

Routing in the Model 2 Subtended Ring Topology

Hierarchical ISIS routing  CSA routers on same access ring in same L1 area  POC3 L1/L2 routers summarize access ring networks to L2 routers  Each POC1, POC2 and POC3 router in its own L2 area to ensure they only form L2 adjacencies Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

141

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 141 | All rights reserved © 2012 Alcatel-Lucent

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

Routing in the Model 2 Subtended Ring Topology (cont)

iBGP supports VPRN route distribution  iBGP Configured only on the POC1 and POC3 routers  POC1 route reflectors reduce the number of BGP peers at POC3 routers  Next-hop tracking removes VPRN prefixes immediately if the IGP removes the route to next hop Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

142

All rights reserved © 2012 Alcatel-Lucent

iBGP in the Model 2 Topology Internal BGP is required to support route distribution in RFC4364 IP VPNs (VPRN). Since the Model 2 topology uses distributed VPRN services between the POC1 and POC3 routers, iBGP must be configured between these routers. Note that the POC2 routers do not run BGP. BGP Route Reflectors BGP route reflectors (RR) reduce the full mesh requirement when running iBGP sessions. In this example, the POC1 routers are configured as BGP route reflectors, and the POC3 routers act as RR clients. The grouping of clients to 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 Tracking SROS enables next hop tracking by default, and it cannot be disabled. This allows the router to remove prefixes from the VPRN VRF if the IGP removes the route to the next hop. Without this feature, the routes will remain in the VRF until the BGP hold timer, 90 seconds by default, expires.

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

Module 2 - Page 142 | All rights reserved © 2012 Alcatel-Lucent

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

iBGP in the Model 2 Topology

iBGP in the Model 2 Topology (cont)

A:MLS1# A:MLS1# show show router router bgp bgp neighbor neighbor =============================================================================== =============================================================================== BGP BGP Neighbor Neighbor =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Peer Peer :: 192.0.2.2 192.0.2.2 Group Group :: Aggregate Aggregate ------------------------------------------------------------------------------------------------------------------------------------------------------------Peer :: 65100 Peer :: 00 Peer AS AS 65100 Peer Port Port Peer :: 192.0.2.2 Peer Address Address 192.0.2.2 Local :: 65100 Local :: 00 Local AS AS 65100 Local Port Port Local :: 0.0.0.0 Local Address Address 0.0.0.0 Peer :: Internal Peer Type Type Internal State :: Connect Last :: Idle State Connect Last State State Idle ... ...

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

Module 2 |

143

All rights reserved © 2012 Alcatel-Lucent

iBGP in the Model 2 Topology (cont) BGP Peer Tracking The Model 2 topology enables BGP peer tracking on the VPRN peer nodes. Without peer tracking enabled, if a BGP peer goes down or becomes unreachable, its peer routers maintain their peering sessions for the duration of the BGP hold timer, by default 90 seconds. Enabling peer tracking allows the router to drop the peering session immediately after the IGP removes its route to the peer address, enabling faster convergence and failure recovery. In the slide above, the POC3 router with the System ID 192.0.2.2 goes offline, and 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 tracking

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

Module 2 - Page 143 | All rights reserved © 2012 Alcatel-Lucent

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

BGP peer tracking enabled  Router drops peer connection immediately

Configure the BGP Route Reflectors Context: Context: config>router config>router Syntax: Syntax:

autonomous-system autonomous-system as-number as-number

Context: Context: config>router>bgp config>router>bgp group group name name

Context: Context: config>router>bgp>group config>router>bgp>group Syntax: Syntax:

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

Example: Example: configure configure router router autonomous-system autonomous-system 65100 65100 configure configure router router bgp bgp group group Aggregate Aggregate config>router>bgp>group$ config>router>bgp>group$ cluster cluster 10.10.10.10 10.10.10.10 config>router>bgp>group$ enable-peer-tracking config>router>bgp>group$ enable-peer-tracking config>router>bgp>group$ config>router>bgp>group$ next-hop-self next-hop-self config>router>bgp>group$ config>router>bgp>group$ peer-as peer-as 65100 65100 config>router>bgp>group$ config>router>bgp>group$ type type internal internal config>router>bgp>group$ config>router>bgp>group$ neighbor neighbor 192.0.2.2 192.0.2.2 config>router>bgp>group>neighbor$ config>router>bgp>group>neighbor$ back back config>router>bgp>group$ config>router>bgp>group$ Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

144

All rights reserved © 2012 Alcatel-Lucent

Configure the BGP Route Reflectors On the MLS routers, configuring the cluster ID automatically causes the routers to become Route Reflectors.  autonomous-system – BGP requires an autonomous system configured on the node. Here we use private AS numbers, from 64512 to 65534. These AS numbers should not be advertised onto the public Internet or to other networks.  group - BGP groups provide a means to configure BGP characteristics for a number of nodes. The group name does not have to match between members, but should be consistent for ease of management. The group name can be up to 32 characters long.  cluster – Configures the cluster ID for the RR node. The cluster ID takes the form of a 4-octet dotted decimal number, ranging from 0.0.0.1-255.255.255.255. You do not configure a cluster ID on the peer nodes (POC3).  enable-peer-tracking – Allows the router to drop a BGP peer immediately if the IGP route to the peer address is removed.  next-hop-self – Tells the node to set its own interface as the BGP next hop for any routes it advertises to its peers. This helps ensures that the iBGP peer can reach the next hop for the advertised route.  peer-as - Identifies the AS number for the BGP peer. If the peer AS matches the local AS number, the peering is internal BGP. If they differ, it is an external BGP peering.  type {internal|external} – Specifies BGP peering type. Though the SROS assumes the peering type by the peer AS value, this command explicitly defines it.  neighbor – Specifies the 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.

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

Module 2 - Page 144 | All rights reserved © 2012 Alcatel-Lucent

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

Syntax: Syntax:

A:MLS1# A:MLS1# show show router router bgp bgp neighbor neighbor =============================================================================== =============================================================================== BGP BGP Neighbor Neighbor =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Peer Peer :: 192.0.2.2 192.0.2.2 Group Group :: Aggregate Aggregate ------------------------------------------------------------------------------------------------------------------------------------------------------------Peer :: 65100 Peer :: 179 Peer AS AS 65100 Peer Port Port 179 Peer :: 192.0.2.2 Peer Address Address 192.0.2.2 Local :: 65100 Local :: 50834 Local AS AS 65100 Local Port Port 50834 Local Address : 192.0.2.0 Local Address : 192.0.2.0 Peer :: Internal Peer Type Type Internal State :: Established Last :: Active State Established Last State State Active Last :: recvKeepAlive Last Event Event recvKeepAlive Last :: Hold Last Error Error Hold Timer Timer Expire Expire Local Family : IPv4 Local Family : IPv4 Remote :: IPv4 Remote Family Family IPv4 Hold Time :: 90 Keep :: 30 Hold Time 90 Keep Alive Alive 30 Active :: 90 Active :: 30 Active Hold Hold Time Time 90 Active Keep Keep Alive Alive 30 Cluster :: 10.10.10.10 Cluster Id Id 10.10.10.10 Preference :: 170 Num Preference 170 Num of of Update Update Flaps Flaps :: 00 ... ... Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

145

All rights reserved © 2012 Alcatel-Lucent

View the BGP RR Status A:NodeA# show router neighbor 192.0.2.2  Peer: – Peer node system ID. Group: - Peer group name. Peer AS: - Local AS number for iBGP peers. Matches on all peers. State: - Established - The BGP peering is up. Cluster ID: - Only set on the RR routers.

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

Module 2 - Page 145 | All rights reserved © 2012 Alcatel-Lucent

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

View the BGP RR Status

A:MLS1# A:MLS1# show show router router bgp bgp neighbor neighbor =============================================================================== =============================================================================== BGP BGP Neighbor Neighbor =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Peer Peer :: 192.0.2.2 192.0.2.2 Group Group :: Aggregate Aggregate ------------------------------------------------------------------------------------------------------------------------------------------------------------... ... Graceful :: Disabled Stale :: n/a Graceful Restart Restart Disabled Stale Routes Routes Time Time n/a Advertise Inactive : Disabled Peer Tracking :: Enabled Advertise Inactive : Disabled Peer Tracking Enabled Advertise :: None Advertise Label Label None Auth :: n/a Auth key key chain chain n/a Disable :: Disabled Peer :: Enabled Disable Cap Cap Nego Nego Disabled Peer Tracking Tracking Enabled Auth key chain : n/a Auth key chain : n/a ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Neighbors Neighbors :: 11 =============================================================================== =============================================================================== ** indicates indicates that that the the corresponding corresponding row row element element may may have have been been truncated. truncated.

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

Module 2 |

146

All rights reserved © 2012 Alcatel-Lucent

View the BGP RR Status (cont) A:NodeA# show router neighbor 192.0.2.2  Peer Tracking: – Enabled for the peer.

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

Module 2 - Page 146 | All rights reserved © 2012 Alcatel-Lucent

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

View the BGP RR Status (cont)

MLS routers may have eBGP peers in external networks  Peers configured within VPRN or on the Base router context  Use export policies to determine which routes to export  An iBGP peering is configured between MLS routers to share externally learned routes  MLS routers tag and propagate routes according to peering policies Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

147

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 147 | All rights reserved © 2012 Alcatel-Lucent

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

eBGP in the Backhaul Transport Network

.5 Hour Lab Overview:

   

Configure BFD on MLS to CSA interfaces Configure BFD in the IGP Verify traffic-engineering extensions are enabled in the IGP Verify BFD sessions using OAM tools

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

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

Module 2 |

148

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 148 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

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

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

Module 2 |

149

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 149 | All rights reserved © 2012 Alcatel-Lucent

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

Section Summary

Section Summary (cont)

 LDP-Sync holds down routes on recovered links until LDP can converge and the peers can exchange labels associated with routes using that link  LDP-Sync requires a timer configured on the router interfaces  iBGP route reflectors reduce the number of BGP peerings required to support distributed VPRN services  BGP peer tracking allows the routers to remove BGP peers immediately upon detection rather than waiting for the hold time to expire  BGP next-hop tracking allows the router to remove routes from the VRF immediately after the IGP removes the route to the next hop

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

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

Module 2 |

150

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 150 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Section Summary (cont)

 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

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

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

Module 2 |

151

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 151 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

Module 2 — Implementing the Mobile Backhaul Transport Network

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

Section 6 — MPLS in the Backhaul Transport Network

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

Module 2 - Page 153 | All rights reserved © 2012 Alcatel-Lucent

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

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

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

Module 2 |

154

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 154 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we will:

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

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

Module 2 |

155

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 155 | All rights reserved © 2012 Alcatel-Lucent

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

Why MPLS in the Backhaul Transport?

The Backhaul Transport may use LDP or RSVP LSPs  Example 1: LDP in the Model 1 Topology for compatibility  Example 2: RSVP in the Model 2 Topology for path redundancy and traffic engineering

RSVP in Model 2

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

Module 2 |

156

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 156 | All rights reserved © 2012 Alcatel-Lucent

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

MPLS in the Mobile Backhaul Transport Network

The LDP tunnels following the route to the target node  LDP follows the IGP route, so the tunnel follows the active static route to and from the target MLS router  LDP must be enabled on the CSA-to-MLS and MLS-to-MLS interfaces Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

157

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 157 | All rights reserved © 2012 Alcatel-Lucent

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

Example 1: LDP in Model 1

RSVP LSPs used for traffic engineering and redundancy • Disjoined, redundant paths and tunnels between CSA and POC3 and POC3 and MLS routers • Secondary standby paths and FRR for LSP redundancy

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

Module 2 |

158

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 158 | All rights reserved © 2012 Alcatel-Lucent

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

Example 2: RSVP in Model 2

MPLS Admin Groups are provisioned to ensure disjoined paths  Paths associated with the target PE, upper and lower  Admin group UPPER for primary path to upper PE (POC3-1)  Admin group LOWER for primary path to lower PE (POC3-2) A:CSA1>config>router>mpls# A:CSA1>config>router>mpls# info info --------------------------------------------------------------------admin-group admin-group "LOWER" "LOWER" 22 admin-group admin-group "UPPER" "UPPER" 11 ... ... lsp lsp "CSA1 "CSA1 to to POC3-1“ POC3-1“ to to 192.0.2.0 192.0.2.0 primary primary "POC3-1-1" "POC3-1-1" include include "UPPER" "UPPER" exit exit secondary secondary "POC3-1-2“ "POC3-1-2“ standby standby include include "LOWER" "LOWER" exit exit no no shutdown shutdown exit exit Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

159

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 159 | All rights reserved © 2012 Alcatel-Lucent

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

LSPs in the Access Ring

MPLS Admin Groups provisioned to ensure disjoined paths, as inaccess ring  POC1-1 to POC1-2 LSP has no secondary path (would be same as bypass)  POC3-POC3 LSPs use manual bypass tunnels to keep bypass on aggregate ring A:POC3-1>config>router>mpls# A:POC3-1>config>router>mpls# info info --------------------------------------------------------------------... ... path path "bypass_POC3-2“ "bypass_POC3-2“ hop hop 11 192.0.2.4 192.0.2.4 strict strict ... ... hop hop 55 192.0.2.3 192.0.2.3 strict strict no no shutdown shutdown ... ... lsp lsp "bypass_POC3-2" "bypass_POC3-2" bypass-only bypass-only to to 192.0.2.3 192.0.2.3 primary primary "bypass_POC3-2“ "bypass_POC3-2“ exit exit no no shutdown shutdown exit exit Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

160

All rights reserved © 2012 Alcatel-Lucent

LSPs in the Aggregation Ring As in the access ring, each LSP has a primary and secondary disjoined path. LSPs connect the POC3 routers to each of the POC1 routers, upper and lower. The LSPs terminating on the upper POC1 and POC3 routers follow the UPPER links on the primary path, and the LOWER links on the standby secondary path. LSPs to the lower routers follow the LOWER path, then the UPPER. LSPs between POC1 routers Each POC1 to POC1 router LSP includes just a primary path. Since fast reroute will choose the only possible alternative path to the target router, there is no need for a standby path. If the traffic 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 tailend of the protected LSP. (notes continue on the next page...)

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

Module 2 - Page 160 | All rights reserved © 2012 Alcatel-Lucent

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

LSPs in the Aggregation Ring

Configure the POC3 Manual Bypass Tunnels

Context: Context: config>router>mpls>path config>router>mpls>path Syntax: Syntax: hop hop {strict|loose} {strict|loose} [no] shutdown [no] shutdown Context: Context: config>router>mpls>lsp config>router>mpls>lsp Syntax: Syntax: [no] [no] to to [no] primary [no] primary [no] shutdown [no] shutdown Example: Example: configure configure router router mpls mpls config>router>mpls# config>router>mpls# path path “bypass_POC_3-2” “bypass_POC_3-2” config>router>mpls>path$ config>router>mpls>path$ hop hop 11 192.0.2.4 192.0.2.4 strict strict config>router>mpls>path$ config>router>mpls>path$ hop hop 22 192.0.2.0 192.0.2.0 strict strict config>router>mpls>path$ config>router>mpls>path$ hop hop 33 192.0.2.1 192.0.2.1 strict strict config>router>mpls>path$ config>router>mpls>path$ hop hop 44 192.0.2.5 192.0.2.5 strict strict config>router>mpls>path$ config>router>mpls>path$ hop hop 55 192.0.2.3 192.0.2.3 strict strict config>router>mpls>path$ config>router>mpls>path$ no no shutdown shutdown config>router>mpls>path$ config>router>mpls>path$ back back config>router>mpls# config>router>mpls# lsp lsp “bypass_POC3-2” “bypass_POC3-2” bypass-only bypass-only config>router>mpls>lsp$ config>router>mpls>lsp$ to to 192.0.2.3 192.0.2.3 config>router>mpls>lsp$ config>router>mpls>lsp$ primary primary “bypass_POC3-2” “bypass_POC3-2” config>router>mpls>lsp>primary$ config>router>mpls>lsp>primary$ exit exit no Alcatel-Lucent IP/MPLSconfig>router>mpls>lsp# Mobile Backhaul Transport v1.0 Module 2 | 161 config>router>mpls>lsp# no shutdown shutdown

All rights reserved © 2012 Alcatel-Lucent

Configure the POC3 Manual Bypass Tunnels By default, the head end will choose a manual bypass tunnel over a dynamic tunnel. •An LSP must be configured as “bypass-only” to be considered as a potential manual bypass tunnel. •The protected LSP must be configured with CSPF and fast-reroute facility enabled. •The manual bypass tunnel must merge back to the protected LSP Path. •The manual bypass tunnel path must avoid the next hop router. •If the head end has more than one available manual bypass tunnel available for the protected LSP, it chooses the one with the lowest path cost. If two or more have the same path cost, it chooses the first available.

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

Module 2 - Page 161 | All rights reserved © 2012 Alcatel-Lucent

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

Context: Context: config>router>mpls config>router>mpls Syntax: Syntax: path path lsp lsp [bypass-only] [bypass-only]

POC3-1 to POC3-2 LSPs  The manual bypass tunnel path lists each hop explicitly  Head-end will only select manual bypass if it avoids the next hop node and merges to the original LSP path  Dynamic bypass may be disabled

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

Module 2 |

162

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 162 | All rights reserved © 2012 Alcatel-Lucent

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

Choosing the Manual Bypass Tunnel

LSP between POC3-1 and POC3-2 link failure example •1 BFD detects the link failure between POC3-1 and POC3-2 •2 POC3-1 moves the 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

163

All rights reserved © 2012 Alcatel-Lucent

Link Failure Example, Model 2 This slide illustrates a manual bypass tunnel used to reroute traffic from a link failure between POC3-1 and POC32. The manual bypass must be configured on the node acting as the PLR. In this example, POC3-1 is the PLR. An LSP is up between POC3-1 and POC3-2. POC3-1 chooses as the primary path the IGP best path to POC3-2. The manual bypass LSP protecting the POC3-1 and POC3-2 LSP follows the strict path from POC3-1 through POC2-1, MLS1, MLS2, POC2-2 and POC3-2. Recovery procedure 1. POC3-1 BFD session to POC3-2 drops as a result of a link failure between the two nodes. 2. POC3-1 moves LSP POC3-1_POC3-2 traffic to the manual bypass tunnel. The bypass routes traffic through POC21 and around the ring through MLS2 toward POC3-2. POC3-1 will try, according to its retry attempt and timer settings, to re-signal the primary path.

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

Module 2 - Page 163 | All rights reserved © 2012 Alcatel-Lucent

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

Link Failure Example, Manual Bypass Tunnel in Model 2

A:POC3-1# A:POC3-1# show show router router mpls mpls bypass-tunnel bypass-tunnel protected-lsp protected-lsp =============================================================================== =============================================================================== MPLS MPLS Bypass Bypass Tunnels Tunnels =============================================================================== =============================================================================== Legend dd -- Dynamic pp -- P2mp Legend :: mm -- Manual Manual Dynamic P2mp =============================================================================== =============================================================================== To State Out Reserved To State Out Out I/F I/F Out Label Label Reserved Protected Protected Type Type BW BW (Kbps) (Kbps) LSP LSP Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.3 Up 1/2/7 131069 00 11 mm 192.0.2.3 Up 1/2/7 131069 Protected LSPs Protected LSPs POC3-1_POC3-2::POC3-1_POC3-2 From: To: POC3-1_POC3-2::POC3-1_POC3-2 From: 192.0.2.2 192.0.2.2 To: 192.0.2.3 192.0.2.3 ------------------------------------------------------------------------------------------------------------------------------------------------------------Bypass Bypass Tunnels Tunnels :: 11 =============================================================================== ===============================================================================

The manual bypass tunnel terminating on POC3-2 via POC2-1 protects LSP POC3-1_POC3-2

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

Module 2 |

164

All rights reserved © 2012 Alcatel-Lucent

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

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

Module 2 - Page 164 | All rights reserved © 2012 Alcatel-Lucent

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

View the Manual Bypass Tunnel Status

.5 Hour Lab Objectives:  Create MPLS Admin Groups and assign the inteface to the groups  Create RSVP LSPs with primary and secondary standby paths including and excluding specific admin groups  Verify the LSPs using OAM commands

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

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

Module 2 |

165

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 165 | All rights reserved © 2012 Alcatel-Lucent

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

Lab 6 : Configure RSVP LSPs in Model 1 Topology

Section Summary

 The Model 1 LDP tunnels follow the static route paths, preferred and secondary  The Model 2 topology uses regional LSPs to reduce the number of RSVP sessions and flooded messages and quicken recovery  Admin-group assignments help the head-end router choose disjoined paths for each LSP’s primary and secondary paths  Fast reroute facility and manual bypass tunnels provide predictable behavior bypass tunnel behavior

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

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

Module 2 |

166

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 166 | All rights reserved © 2012 Alcatel-Lucent

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

In this section, we learned:

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.

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

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

Module 2 |

167

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 167 | All rights reserved © 2012 Alcatel-Lucent

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

Module Summary

Module Summary (cont)

 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

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

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

Module 2 |

168

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 168 | All rights reserved © 2012 Alcatel-Lucent

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

In this Module, we learned:

Module Summary (cont)

 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

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

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

Module 2 |

169

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 169 | All rights reserved © 2012 Alcatel-Lucent

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

In this Module, we learned:

Module Summary (cont)

 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

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

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

Module 2 |

170

All rights reserved © 2012 Alcatel-Lucent

Module 2 - Page 170 | All rights reserved © 2012 Alcatel-Lucent

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

In this Module, we learned:

Module Review Questions

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

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

Module 2 |

171

All rights reserved © 2012 Alcatel-Lucent

Answers: 1. a, d 2. b, c, d

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

Module 2 - Page 171 | All rights reserved © 2012 Alcatel-Lucent

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

1. SROS routers support which two encapsulation types on Ethernet access ports? (Choose two.)

Module Review Questions (cont)

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

Turn up BFD on the port Enable auto-negotiate on the port Set a port up hold-time Set an LDP-Sync timer on the port

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

Module 2 |

172

All rights reserved © 2012 Alcatel-Lucent

Answers: 3. c, d 4. c

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

Module 2 - Page 172 | All rights reserved © 2012 Alcatel-Lucent

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

3. Ethernet auto-negotiate determines what two Ethernet port characteristics? (Choose two.)

Module Review Questions (cont)

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

173

All rights reserved © 2012 Alcatel-Lucent

Answers: 5. a 6. a

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 173 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

5. On a DS1 channel group, what characteristic determines the type of payload the link will transport?

Module Review Questions (cont)

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

174

All rights reserved © 2012 Alcatel-Lucent

Answers: 7. b 8. 4, 1, 2, 3

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 174 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

7. A node signals its desire to implement ML-PPP during what phase of the circuit’s initialization?

Module Review Questions (cont)

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

175

All rights reserved © 2012 Alcatel-Lucent

Answers: 9. a, c 10. c

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 175 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

9. Which two synchronization techniques sets the node’s SEC/EEC by the received bit stream? (Choose two.)

Module Review Questions (cont)

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

176

All rights reserved © 2012 Alcatel-Lucent

Answers: 11. d 12. a, c, d

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 176 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

11.A SyncE reference’s SEC goes into holdover. On SDH mode, what SSM quality level will it advertise to its peers?

Module Review Questions (cont)

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 ethernet ssm d) configure port tdm

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

177

All rights reserved © 2012 Alcatel-Lucent

Answers: 13. a, b, d 14. b

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 177 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

13.An SROS node configured for SyncE SDH mode might receive which three advertised quality levels? (Choose three.)

Module Review Questions (cont)

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

178

All rights reserved © 2012 Alcatel-Lucent

Answers: 15. C 16. c

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 178 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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?

Module Review Questions (cont)

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

179

All rights reserved © 2012 Alcatel-Lucent

Answers: 17. b, c, d 18. a, b, c

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 179 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

17.The SROS IEEE 1588v2/PTPv2 slave implementation uses which three messages’ contents to calculate the clock offset? (Choose three.)

19. For what reason does the Model 1 network run BFD on the CSA-MLS static routes? a) To allow the routers to choose the best available static route b) On failure recovery, to hold down the routes until BFD converges c) To recognize a possible link failure in the MEN d) To support pseudowire redundancy 20. Which three are characteristics of the Model 2 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

180

All rights reserved © 2012 Alcatel-Lucent

Answers: 19. c 20. a, b, d

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 180 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module Review Questions (cont)

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 |

181

All rights reserved © 2012 Alcatel-Lucent

Answers: 21. b 22. a

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 2 - Page 181 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module Review Questions (cont)

TTP36002 Edition 1

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 1 | All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

2

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 2 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module Objectives

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — Mobile Backhaul Service Fundamentals

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 3 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives In this section, we will:

 Review SAP and SDP characteristics  Determine the type of service required to transport 2G, 3G, or 4G traffic

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

4

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 4 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Review the SROS service components: Customer, Service, SAP, SDP

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

5

All rights reserved © 2012 Alcatel-Lucent

Service Components The Alcatel-Lucent Router is based on the service model where service edge routers are deployed at the provider edge. Services are provisioned on the router and transported across an IP and/or IP/MPLS provider core network in encapsulation tunnels created using Generic Router Encapsulation (GRE) or MPLS Label Switched Paths (LSPs). The service model uses logical service entities to construct a service. The logical service entities are designed to provide a uniform, service-centric configuration, management, and billing model for service provisioning. The Service model is based on the following components:  Subscribers  SAP  Customer  Service  SDP  Service Tunnels

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 5 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Service Components

SAP SAPIdentifiers Identifiers  Physical PhysicalEthernet Ethernetport, port,SONET/SDH SONET/SDHport portor orchannel, channel,TDM TDM port or channel port or channel  Encapsulation Encapsulationidentifier identifier(ID) (ID) (eg. (eg.VLAN VLANID, ID,Q-tag) Q-tag)  Can only be created on Access interfaces Can only be created on Access interfaces

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

6

All rights reserved © 2012 Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 6 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Service Access Point (SAP)



AAservice servicedistribution distributionpoint point(SDP) (SDP)acts actsas asaalogical logicalway wayto todirect directtraffic trafficfrom fromone one router to another. router to another.

SDPs SDPsare arelocally locallyunique; unique;the thesame sameSDP SDPID IDcan canbe beused usedon onanother anotherrouter router  SDPs use the System IP address to identify far end destinations SDPs use the System IP address to identify far end destinations  SDP SDPisisnot notspecific specificto toone oneservice; service;many manyservices servicescan canuse usethe thesame sameSDP SDP 



All Allservices servicesbound boundto toan anSDP SDPuse usethe thesame sameencapsulation encapsulationas asdefined definedby bythat thatSDP SDP (GRE or MPLS) (GRE or MPLS)



Operations Operationson onan anSDP SDPwill willaffect affectall allservices servicesthat thatare arebound boundto tothat thatSDP SDP

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

7

All rights reserved © 2012 Alcatel-Lucent

Service Distribution Point (SDP) Characteristics A service distribution point (SDP) acts in a logical way to direct traffic from one router to another through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end router which directs packets to the correct service egress SAPs on that device. A distributed service consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and an SDP binding the service to the service tunnel. An SDP has the following characteristics:  An SDP is locally unique to a participating router. The same SDP ID can appear on other routers.  An SDP uses the system IP address to identify the far-end edge router.  An SDP is not specific to any one service or any type of service. Once an SDP is created, services are bound to the SDP. An SDP can also have more than one service type associated with it.  All services mapped to an SDP use the same transport encapsulation type defined for the SDP (either GRE or MPLS).  An SDP is a management entity. Even though the SDP configuration and the services carried within are independent, they are related objects. Operations on the SDP affect all the services associated with the SDP. For example, the operational and administrative state of an SDP controls the state of services bound to the SDP. An SDP from the local device to a far-end device requires a return path SDP from the far-end device back to the local device. Each device must have an SDP defined for every remote router to which it wants to provide service. SDPs must be created first, before a distributed service can be configured.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 7 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Service Distribution Point (SDP) Characteristics

SDPs tie the control plane service label signaling (T-LDP) to the transport tunnels (LDP/RSVP or GRE)  In order to direct a service to use an SDP for distribution, the service is joined to the SDP using a spoke-sdp or a mesh-sdp.  VPLS is the only service that allows the use of a mesh-sdp.  Spoke-sdp is used in all other cases where a distributed service is required.  A service-label is not signaled until the service is bound to an SDP using spoke or mesh  The transport may be either RSVP-TE with FRR or LDP  The term pseudowire is often used synonymously with spoke- or mesh-sdp.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

8

All rights reserved © [year] Alcatel-Lucent

Using an SDP within a Service When an SDP is bound to a service, it is bound as either a spoke SDP or a mesh SDP. The type of SDP indicates how flooded traffic is transmitted. Spoke-SDP A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received. Mesh-SDP All mesh SDPs bound to a service are logically treated like a single bridge “port” for flooded traffic where flooded traffic received on any mesh SDP on the service is replicated to other “ports” (spoke SDPs and SAPs) and not transmitted on any mesh SDPs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 8 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Using an SDP within a Service

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

9

All rights reserved © 2012 Alcatel-Lucent

Transport Tunnel A Transport tunnel is used by an SDP to direct traffic from one router to another. Multi-node VPWS and VPLS traffic is transported using uni-directional service tunnels. Service tunnels originate on an SDP on one node and terminate at a destination node. The destination node directs packets to the correct service egress interfaces on that device. Service tunnels can be configured to use Generic Router Encapsulation (GRE) or MPLS Label Switched Paths (LSPs). Services that originate and terminate on the same node do not require service tunnels or SDPs

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 9 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Logical Service Level View

Service Connectivity by Technology

GSM

X

UMTS CDMA 1x Voice

X

BS-BS IP/Ethernet (ePipe/VPLS /VPRN/IES)

X X

X

X

X

CDMA 1x Data

X

LTE

X

X

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

10

All rights reserved © 2012 Alcatel-Lucent

Service Connectivity by Technology In both the Hub and Spoke and Subtended Ring topologies, the type of Base Station, NodeB, and wireless technology determine the service deployed. Additionally, the service provider type, BTP or MSP, also influences the services used to carry traffic through the transport network. TDM Base Stations GSM base stations may use DS1 or E1 links to carry traffic to the CSA router. These could either be individual links, or bundles. In the case the BS uses individual links, a cPipe services may be employed to carry traffic from the CSA to the MLS routers. Where MP bundled links are deployed, a iPipe may be used. Ethernet-capable BS use ePipe services, terminated either at a POC3 or MLS router. TDM NodeB CDMA NodeBs use MP-bundled DS1s or E1s to carry traffic to the CSA or directly to the NodeB. Where terminated on the CSA, an iPipe provides the transport. Where terminated on the MLS directly, an IES or VPRN provides the MTSO Layer 3 interface. Ethernet-capable NodeBs use ePipe services. ATM NodeB An ATM NodeB uses IMA bundles to carry ATM traffic to the CSA. The CSA could transport this traffic via an aPipe or an iPipe service. Ethernet capable base stations use ePipe services. Ethernet BTS, NodeB, or eNodeB The network could use any Ethernet service, L2 or L3, depending on the design. In this course, we use ePipes to carry BS traffic to the downstream L3 services. However, the CSAs could terminate VPLS, VPRN, or IES, depending on the customer’s needs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 10 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Wireless Technology

Connectivity BS/NodeB to Network Controller (NC) Transport TDM IP/Ethernet ATM type (cPipe/ (ePipe/VPLS/ (aPipe) iPipe) VPRN/IES)

Section Summary In this section, we:

 Reviewed SAP and SDP characteristics  Determined the service types required to transport 2G, 3G, or 4G traffic

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

11

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 11 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Reviewed the SROS service components: Customer, Service, SAP, SDP

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — Model 1 Detailed Configuration – 3G Voice and Data

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 13 | All rights reserved © 2012 Alcatel-Lucent

In this section, we will:  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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

14

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 14 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section Objectives

Model 1 - Ethernet Backhaul (EBH) - ePipes • 3G voice, data and OAM ePipes terminate into MLS VPLSs • VPLS-VPRN cross-connect forwards traffic toward NC elements Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

15

All rights reserved © 2012 Alcatel-Lucent

Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet Traffic This section explores the various services and service components the Model 1 network employs to deliver 3G voice traffic to the NC elements. Though we only follow the service configuration for voice traffic, data and OAM traffic service follow a similar model. For each service type, the network incorporates a separate set of ePipe, VPLS, and VPRN services. We call the CSA-facing MLS VPLS the outer VPLS services. Notice we have added another set of VPLS services on the NC side of the VPRN; we call this the inner VPLS. In some instances, the inner VPLS distributes traffic to the NC elements. This depends on the 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 loops

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 15 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 – ePipes, VPLS, and VPRN for 3G Ethernet Traffic

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

16

All rights reserved © 2012 Alcatel-Lucent

Model 1 3G Ethernet Services - Overview The diagram above shows an overview of the Model 1 design services to support 3G 1x CDMA voice and data traffic. CSA1 to MLS ePipes Redundant ePipes transport Ethernet frames to and from the 3G NodeB. At the MLS, the ePipe spokes into an outer VPLS. The outer VPLS provides a virtual broadcast domain into which multiple like BS can terminate, sharing an address on the same subnet. Split horizon groups may be necessary to prevent direct NodeB to NodeB communications. MLS Outer VPLS The outer VPLS cross connects into a local VPRN through a Versatile Services Module (VSM) hosted Cross Connect Aggregate Group (CCAG). The CCAG interface becomes the BS’ gateway interface. MLS VPRN The MLS VPRN CCAG provides bidirectional logical links between the L2 VPLS and the L3 VPRN interfaces. The outer VPLS forwards NodeB packets to and from the VPRN through this interface. The VPRN includes interfaces to the various NC elements, including VRRP protected interfaces cross connecting into an inner, NC-facing VPLS. MLS VPLS The MLS inner VPLS provides redundant L2 interfaces to certain NC elements. A management VPLS might run STP on behalf of some of the inner VPLS VLANs. The inner VPLS supports VRRP running on the VPRN-VPLS cross connect interface, and includes an inter-chassis SAP. Router-Specific Configurations  Redundant pseudowires are configured on the CSA router.  The MLS routers terminate the ePipes into outer VPLS spoke SDPs.  VRRP-protected VPRN interfaces forward traffic into inner VPLS SAPs.  OSPF runs between the local VPRNs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 16 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 3G Ethernet Services - Overview

In the following pages, we will build these services in phases:  Phase 1 – The CSA to MLS ePipes  Phase 2 – The MLS outer VPLS  Phase 3 – The MLS VPRN  Phase 4 – The MLS inner VPLS Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

17

All rights reserved © 2012 Alcatel-Lucent

Model 1 3G Ethernet Services Configuration Phases Phase 1 - CSA1 to MLS ePipe ePipe 1 uses redundant PWs, with the primary terminated on MLS1. To load balance traffic, alternate base stations may terminate the primary on MLS2. QoS is applied on the router interfaces and on SAP ingress. Phase 2 - MLS Outer VPLS VPLS 1 terminates the ePipe spoke SDPs, and includes a cross-connect SAP. The CCAG provides a virtual Ethernet port to the VPRN 1 base station gateway interface. The VPLS could include static MAC address entries for each supported NodeB, tied to the spoke SDP. QoS is applied in CCAG SAP ingress. Phase 3 - MLS Local VPRN The VPRN is a local service; this example illustrates a 3G voice traffic VPRN. The service provides interfaces to the cell sites, multiple external networks, and the NC elements. The VPRN service defines its own OSPF area, and isolates traffic to a dedicate VRF. Most interfaces are passive, though the interfaces facing the peer MLS and some external networks are active. The two MLS routers share this 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_MLSx The to_MLS1 and to_MLS2 interfaces provide a routed link between the two MLS router VPRNs. The VPRNs form an OSPF adjacency over these interfaces. A LAG physically connects the two MLS routers and the interfaces use VLAN tag 1. Phase 4 – MLS Inner VPLS The Inner VPLS creates a virtual broadcast domain for each traffic type. It allows the NodeB access to external networks, NC elements, and provides a redundant layer 2 forwarding path through an inter-chassis LAG SAP. It may be protected by a management VPLS, though for voice traffic it is not. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 17 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 3G Ethernet Services Configuration Phases

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 – Phase 1 – Distributed ePipes with PW Redundancy

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 19 | All rights reserved © 2012 Alcatel-Lucent

A:CSA1>config>service# A:CSA1>config>service# epipe epipe 11 customer customer 11 create create config>service>epipe$ description config>service>epipe$ description “Distributed “Distributed epipe epipe for for 3G 3G Voice" Voice" config>service>epipe# sap 1/1/1:100 create config>service>epipe# sap 1/1/1:100 create config>service>epipe>sap# config>service>epipe>sap# back back config>service>epipe# config>service>epipe# no no shutdown shutdown

• SAPs are only configured on the CSA router • Spoke SDPs terminate the ePipe into the MLS router “outer” VPLS

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

20

All rights reserved © 2012 Alcatel-Lucent

Phase 1 – Model 1 3G Distributed ePipe SAPs To configure a distributed epipe service, you must configure service entities on the originating and far-end nodes. You must use the same service ID on both ends (for example, epipe 1 on CSA1 and epipe 1 on MLS1). The spoke-sdp sdp-id:vc-id must match on both sides. A distributed epipe consists of endpoints on different nodes. By default, QoS policy ID 1 is applied to ingress and egress service SAPS. Existing filter policies or other existing QoS policies can be associated with service SAPs on ingress and egress. Ingress and egress SAP parameters can be applied to local and distributed epipe service SAPs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 20 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 1 – Model 1 3G Distributed ePipe SAPs

Pseudowire (PW) redundancy protects against node failure in a VPWS (and VPLS)  The CSA VPWS has a spoke SDP, or PW, terminating on each MLS router  “endpoint” in the VPWS configuration ensures only one active egress path  The service configuration specifies the primary PW by the “precedence primary” keywords

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

21

All rights reserved © 2012 Alcatel-Lucent

Phase 1 - Pseudowire (PW) Redundancy Already in place within the transport network are redundancy features, such as BFD, standby LSP paths, and FRR. However, these techniques do not protect against service end-point failures, ie a nodal failure. SROS allows for multi-homing a service to a primary and a backup remote PE router, a feature called pseudowire (PW) redundancy. Within a VPWS, a multi-homed, local PE, shown here as CSA1, hosts the redundant spoke SDPs. CSA1 chooses between two or more spoke SDPs and forwards traffic to a single egress PE router. If the primary egress PE router fails or becomes inaccessible, the originator sends traffic to a secondary egress PE. It is important to remember that a VPWS service can only have one active forwarding path. The remote primary and secondary egress PEs, Remote PEs MLS1 and MLS2, share duplicated VPWS service configurations, each with a return spoke SDP toward the local PE. To ensure that the re-directed traffic makes it to the target CE device, the two egress PEs can protect the access ports with MC-APS or MC-LAGs. Endpoint A standard VPWS has two implied endpoints; the service SAP and the spoke SDP, if a distributed service, or two SAPs, if a local service. A VPWS can have only one path to a destination, and traffic only flows from one endpoint to another. Within the redundant PW service configuration, you explictly specify an endpoint. The endpoint is an additional service component, and is a named entity. A:NodeA>config>service>epipe$ endpoint 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 21 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 1 - Pseudowire (PW) Redundancy

Phase 1 - Configuring Redundant Pseudowires Context: Context: config>service>epipe config>service>epipe [no] [no] endpoint endpoint create create revert-time revert-time [revert-time|infinite] [revert-time|infinite] [no] spoke-sdp endpoint [no] spoke-sdp endpoint create create

Context: Context: config>service>epipe>spoke-sdp config>service>epipe>spoke-sdp Syntax: Syntax:

[no] [no] precedence precedence | | primary primary

Example: Example: config>service>epipe# config>service>epipe# endpoint endpoint ENET_BTS1_URC1 ENET_BTS1_URC1 create create config>service>epipe>endpoint$ revert-time config>service>epipe>endpoint$ revert-time 90 90 config>service>epipe>endpoint$ config>service>epipe>endpoint$ back back config>service>epipe# config>service>epipe# spoke-sdp spoke-sdp 1:1 1:1 endpoint endpoint ENET_BTS1_URC1 ENET_BTS1_URC1 create create config>service>epipe>spoke-sdp$ config>service>epipe>spoke-sdp$ precedence precedence primary primary config>service>epipe>spoke-sdp$ config>service>epipe>spoke-sdp$ back back config>service>epipe# config>service>epipe# spoke-sdp spoke-sdp 2:1 2:1 endpoint endpoint ENET_BTS1_URC1 ENET_BTS1_URC1 create create config>service>epipe>spoke-sdp$ config>service>epipe>spoke-sdp$ back back config>service>epipe# config>service>epipe# exit exit all all

 Pseudowire redundancy supported on all VPWS  Default spoke SDP precedence is none (4)  Service SAP in a second, implied endpoint Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

22

All rights reserved © 2012 Alcatel-Lucent

Phase 1 - Configuring Redundant Pseudowires SROS supports PW redundancy on aPipe, cPipe, ePipe, fPipe, and iPipe VPWS, as well as VPLS. Endpoint Endpoint defines the endpoint object; it can have any textual name, up to 32 characters long. This controls the traffic flow egressing the active and standby pseudowires. The create keyword is required by default. A:NodeA# configure service epipe 1 endpoint ENET_BTS1_URC1 create  Revert time In the endpoint, a revert timer can be set to control, in seconds, when the PE moves traffic back to the primary (precedence 0) spoke SDP. A:NodeA>config>service>epipe>endpoint# revert-time 90  The default is 0 (immediately), and can be set from 0-600 or infinite (never revert). The revert time has no effect when no primary spoke SDP exists, as it will not move traffic to other secondary spoke SDPs. Spoke SDP Binding Creation Upon the spoke 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 PE The remote PEs, MLS1 and MLS2, require only a single spoke SDP binding and SAP, as required by the VPWS configuration. The intelligence of the redundant PW resides on the multi-homing peer, the local PE, CSA1. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 22 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Syntax: Syntax:

Phase 1 - Pseudowire Status Flags

1

Peer PW Status Description TLV Flag 0x00000000 Pseudowire forwarding ( clear all failures )

2

0x00000020

Pseudowire forwarding Standby

3

0x00000006

Remote pseudowire active, remote SAP is down

4

0x00000026

Remote pseudowire in standby, remote SAP is down

5

0x00000001

Pseudowire Not Forwarding (MTU problems, etc)

6

0x00000021

7

0x00000018

8

0x00000038

Remote pseudowire in standby and not forwarding Remote pseudowire is active but operationally down Remote pseudowire is in standby and operationally down

Priority determines pseudowire selection order  Local PE picks best spoke SDP based on status priority  Local PE will only discard traffic if both local spoke SDPs are down  If PW status tied on both spoke SDPs, local precedence decides Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

23

All rights reserved © 2012 Alcatel-Lucent

Phase 1- Pseudowire Status Flags The status flags indicate the local and remote spoke SDP status. The PEs signal the spoke SDP status in T-LDP Label Mapping and Notification messages. On each PE, the status bits represent the local SAP forwarding status. If the SAP is part of a MC-LAG or MC-APS and the service uses Interchassis Backup PW (ICB-PW), the PE can set the SAP status to standby (0x20), otherwise, it is up (0x0) or down (0x26). We will discuss ICB-PW later in this module. The local PEs learn the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 23 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Priority

The local PE chooses the active spoke SDP  It initially tells the remote PE that all SAPs are Up  It reads the local and remote status bits to choose the active spoke SDP  If a tie occurs between the spoke SDPs, it can choose by precedence (shown) Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

24

All rights reserved © 2012 Alcatel-Lucent

Phase 1 - Choosing the Active Pseudowire Initially, for all spoke SDPs associated with an endpoint, the local PE signals the remote PE a status of Pseudowire Forwarding - this establishes all the spoke SDPs. Then, the local PE determines which of the redundant spoke SDPs is the healthiest, and chooses it as the active spoke SDP. Active Selection Criteria The local PE chooses the active spoke SDP based on the following criteria: 1. It reads each spoke 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 24 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 1 - Choosing the Active Pseudowire

Phase 1 - View the Local PE Endpoint Status

=============================================================================== =============================================================================== Service 1 endpoints Service 1 endpoints =============================================================================== =============================================================================== Endpoint :: Enet_BTS1_URC1_CSA1 Endpoint name name Enet_BTS1_URC1_CSA1 Description : (Not Specified) Description : (Not Specified) Revert time : 90 Revert time : 90 Act Hold Delay : 0 Act Hold Delay : 0 Standby Signaling Master : false Standby Signaling Master : false Standby Signaling Slave : false Standby Signaling Slave : false Tx Active : 1:1 Tx Active : 1:1 Tx Active Up Time : 0d 00:16:20 Tx Active Up Time : 0d 00:16:20 Revert :: N/A Revert Time Time Count Count Down Down N/A Tx :: 44 Tx Active Active Change Change Count Count Last :: 08/10/2011 Last Tx Tx Active Active Change Change 08/10/2011 12:38:07 12:38:07 ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 1:1 1:1 Prec:0 Prec:0 Oper Status: Status: Up Up Spoke-sdp: 2:1 Prec:4 Oper Status: Spoke-sdp: 2:1 Prec:4 Oper Status: Up Up =============================================================================== =============================================================================== =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

25

All rights reserved © 2012 Alcatel-Lucent

Phase 1 - View the Local PE Endpoint Status A:NodeA# show service id 1 endpoint  Tx Active: – Shows the active spoke SDP. In this example, the primary 1:1 is active. Tx Active Up Time: - How long the active spoke SDP has been up. Tx Active Change Count: - How often the active spoke SDP has changed. Members: - List the spoke SDPs that are members in the endpoint object. A change in the remote or local pseudowire status can cause a change.  The remote PE withdrawals its label  The remote PE signals a pseudowire status change, such as a remote spoke SDP or SAP failure  The local 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 25 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA1# show service id 1 endpoint A:CSA1# show service id 1 endpoint

The local PE sets standby-signaling-master on the endpoint  The local PE sends status 0x20 on the secondary spoke SDP  The remote PE VPLS shows the spoke SDP as Forwarding Standby  The remote PE egress label indicates Status Signaled Down Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

26

All rights reserved © 2012 Alcatel-Lucent

Phase 1 – Signaling the Secondary as Standby Since CSA1 spoke SDP 1:1 is the primary spoke SDP, traffic flows from CSA1 to MLS1. However, unless otherwise configured, traffic can return over both MLS1 spoke SDP 1:1 and MLS2 spoke SDP 2:1. This default behavior does not create a loop, as the local PE service has only one active transmit path. To ensure the remote PEs only transmit over the active path, you can enable standby signaling from the local PE to the remote PE: A:NodeA>config>service>epipe>endpoint# standby-signaling-master  By default, the remote 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 26 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 1 – Signaling the Secondary as Standby

Phase 1 - View the Remote PE LDP Bindings

=============================================================================== =============================================================================== LDP LDP LSR LSR ID: ID: 192.0.2.0 192.0.2.0 =============================================================================== =============================================================================== ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Type :: V-Eth VcId :: 11 Type V-Eth VcId SvcId :: 11 SdpId :: 22 SvcId SdpId Peer Address : 192.0.2.2 Vc-switching :: No Peer Address : 192.0.2.2 Vc-switching No LMTU :: 1500 RMTU :: 1500 LMTU 1500 RMTU 1500 Egr. :: 131064D Egr. :: No Egr. Lbl Lbl 131064D Egr. Ctl Ctl Word Word No Egr. :: None Egr. Egr. Flags Flags None Egr. Status Status Bits Bits :: Supported Supported (0x20) (0x20) Egr. Egr. Egr. Flow Flow Label Label Tx Tx :: No No Egr. Flow Flow Label Label Rx: Rx: No No Ing. :: 131062U Ing. :: No Ing. Lbl Lbl 131062U Ing. Ctl Ctl Word Word No Ing. :: None Ing. Ing. Flags Flags None Ing. Status Status Bits Bits :: Supported Supported (0x0) (0x0) Ing. Ing. Ing. Flow Flow Label Label Tx Tx :: No No Ing. Flow Flow Label Label Rx: Rx: No No =============================================================================== =============================================================================== No. No. of of VC VC Labels: Labels: 22 =============================================================================== =============================================================================== ... ...

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

27

All rights reserved © 2012 Alcatel-Lucent

Phase 1 - View the Remote PE LDP Bindings A:NodeA# show router ldp bindings service-id 1 detail  LDP LSR ID: - Local node system ID Peer Address: - Remote peer system ID Egr Label: – Shows the label passed by the remote peer PE for this spoke SDP. A:MLS1# show router ldp bindings service-id 1 detail =============================================================================== LDP LSR ID: 192.0.2.0 =============================================================================== Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn S - Status Signaled Up,

D - Status Signaled Down

E - Epipe Service, V - VPLS Service, M - Mirror Service A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service BU - Alternate Next-hop for Fast Re-Route, TLV - (Type, Length: Value) =============================================================================== ... MLS1 indicates Status Signaled Down for this LDP binding. In the service, it shows status “pwFwdingStandby”. Egr. Status Bits: - Indicates flag values 0x20, pseudowire forwarding standby. With the spoke SDP in standby, the remote peer PE (CSA1) only forwards traffic over the active spoke SDP.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 27 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show router router ldp ldp bindings bindings service-id service-id 11 detail detail

 Redundant PWs protect against nodal failures  Can protect against misconfiguration or provisioning errors, but lost or dropped packets may occur Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

28

All rights reserved © 2012 Alcatel-Lucent

Phase 1 – CSA1 Spoke SDP Bindings Failure conditions Planned and unplanned outages Physical, routing, and MPLS redundancy make it unlikely that an SDP will fail. However, none of these can protect a single-homed, distributed service from nodal failure. Hence, PW redundancy helps provide a path to the destination in the case one of the redundant downstream routers goes offline, either as a planned outage or as a result of an equipment outage. System and circuit maintenance Best practice is to never make routine changes on live systems and circuits unless in a maintenance window. PW redundancy can also help protect against configuration errors, such as shutting down a protocol or tunnel inadvertently, but a few lost or dropped packets may occur in these circumstances.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 28 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 1 – CSA1 Spoke SDP Bindings

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 – Phase 2 – Outer VPLS Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 29 | All rights reserved © 2012 Alcatel-Lucent

MLS1# MLS1# configure configure service service MLS1>config>service# MLS1>config>service# vpls vpls 11 customer customer 11 create create MLS1>config>service>vpls$ MLS1>config>service>vpls$ no no shutdown shutdown

 The MLS1 and MLS2 local services all use the same customer ID  On each router, the service configuration differs only by the spoke SDP Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

30

All rights reserved © 2012 Alcatel-Lucent

Phase 2 – VPLS Service Creation Show above is the service creation command on MLS1; MLS2 mirrors this configuration in all ways but the spoke SDP sdp-id:vc-id.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 30 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 2 - VPLS Service Definition

Phase 2 – Creating the Spoke SDP Binding

A:MLS1>config>service>vpls>spoke-sdp$ A:MLS1>config>service>vpls>spoke-sdp$ exit exit A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# info info ------------------------------------------------------------------------------------------stp stp shutdown shutdown exit exit spoke-sdp spoke-sdp 1:1 1:1 create create spoke-sdp spoke-sdp 2:1 2:1 create create exit exit no no shutdown shutdown -------------------------------------------------------------------------------------------

 The service has been bound to SDP 1 and 2  For redundancy, CSA1 and 2 each ties into the MLS1 and MLS2 outer VPLS  Spoke SDP vc-ids must match those configured on the CSA ePipes facing this router Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

31

All rights reserved © 2012 Alcatel-Lucent

Phase 2 – Creating the Spoke SDP Binding For redundancy, each CSA1 and CSA2 ePipe has a spoke SDP terminated in each of the two MLS routers’ outer VPLS 1. Each outer VPLS includes two spoke SDP bindings, one for CSA1 and one for CSA2. Remember that the vc-ids must match on each end, though they don’t have to match within the service.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 31 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# spoke-sdp spoke-sdp 1:1 1:1 create create A:MLS1>config>service>vpls>spoke-sdp$ A:MLS1>config>service>vpls>spoke-sdp$ back back A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# spoke-sdp spoke-sdp 2:1 2:1 create create

A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# split-horizon-group split-horizon-group “group1” “group1” create create A:MLS1>config>service>vpls>split-horizon-group# A:MLS1>config>service>vpls>split-horizon-group# back back A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# spoke-sdp spoke-sdp 1:1 1:1 split-horizon-group split-horizon-group group1 group1 create create A:MLS1>config>service>vpls>spoke-sdp$ A:MLS1>config>service>vpls>spoke-sdp$ exit exit A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# info info ------------------------------------------------------------------------------------------stp stp shutdown shutdown exit exit spoke-sdp spoke-sdp 1:1 1:1 split-horizon-group split-horizon-group "group1" "group1" create create no no shutdown shutdown exit exit spoke-sdp spoke-sdp 2:1 2:1 split-horizon-group split-horizon-group "group1" "group1" create create no no shutdown shutdown exit exit no no shutdown shutdown -------------------------------------------------------------------------------------------

 Split horizon groups help prevent L2 loops on the outer VPLS spoke SDPs  No need for Spanning Tree Protocol (STP) on the spoke SDPs  Traffic entering the VPLS on the split horizon group cannot directly enter another group spoke SDP Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

32

All rights reserved © 2012 Alcatel-Lucent

Phase 2 – Spoke SDP Split Horizon Groups Split Horizon Groups In some instances, you may want to prevent direct BS-BS communications in the VPLS service, which could potentially cause a L2 loop. A split horizon group associated with the ePipe spoke SDPs ensures that all traffic received on a spoke SDP within the split horizon group leaves the VPLS before it is forwarded on to the target network. This means packets received on the SHG must be forwarded through the VPRN service. You must create the split horizon group (SHG), then associate the spoke SDPs to the SHG. You must associate the spoke SDPs with the SHG at the time you create them; you cannot add them later.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 32 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 2 – Spoke SDP Split Horizon Groups

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 – Phase 2 – Cross Connected Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 33 | All rights reserved © 2012 Alcatel-Lucent

 Used to interconnect “Ethernet” encapsulated services like a VPLS or VLL into an IES or VPRN service  The complete 10 Gbps forwarding path is available to support an aggregate of up to 10 Gbps halfduplex  Maintains egress and ingress features of the services to which it is interconnecting, including the ability to remap QoS, enforce policing and shaping and accounting for each service.  Multiple VSMs incrementally increase the interconnecting bandwidth and provide load sharing/fault tolerance

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

34

All rights reserved © 2012 Alcatel-Lucent

Phase 2 - Versatile Services Module (VSM) for CCAG SAPs Both the MLS VPLS and VPRN services use CCAG SAPs. These require a VSM installed in the router. The VSM provides roughly the equivalent connectivity as looping back external ports, but with various improvements: •The interconnect function is performed internally eliminating the need for the physical port MAC, PHY, cable and other MDA specific components producing a more reliable adaptor. •Bandwidth is utilized in a more efficient manner than with externally cabled ports. Typically, the offered load presented to each side of the cross connect port pair is asymmetric in nature. When physical ports are used to cross connect services, each service is egress bandwidth limited to the link speed of the TX-RX path it is using. If one TX-RX path is underutilized, egress services on the other path cannot make use of the available bandwidth. Since the VSM is forwarding all services over the same path, all the available bandwidth may be used up to the 10 Gbps (half duplex) capability. The MDA is called a “vsm-cca” in the CLI to tie together the CCAG concepts underlying the VSM. VSM-CCAs may be placed into CCAGs (Cross Connect Aggregation Groups). A CCAG provides a mechanism to aggregate multiple vsmcca’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).

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 34 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 2 - Versatile Services Module (VSM) for CCAG SAPs

Phase 2 - Cross Connect Aggregation Group (CCAG)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

35

All rights reserved © 2012 Alcatel-Lucent

Phase 2 - CCAG The VSMs can be spread across IOMs. Each VSM support 10 Gbps of half-duplex service interconnect traffic. A Cross Connect Aggregation Group (CCAG) provides a mechanism to aggregate multiple VSM Cross Connect Adapters (CCAs) into a single forwarding group. The CCAG uses conversation hashing to dynamically distribute cross connect traffic to the active VSMs in the aggregation group. In the event an active VSM fails or is removed from the group, the conversation hashing function will redistribute the traffic over the remaining active VSMs within the group.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 35 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 CCAG includes one or more VSMs  Up to 8 VSMs per CCAG

 CCID is the binding point for services and IP interfaces in a CCAG  Interconnected services are assigned the same CCID; ex: ccag-1.a:1 and ccag-1.b:1  Ingress and egress QoS, filtering and accounting policies are assigned to the CCID Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

36

All rights reserved © 2012 Alcatel-Lucent

CCID – Cross Connect Identifier Services and IP interfaces are bound to a CCAG through a CCID (Cross Connect Identifier). When two services or a service and an IP interface are assigned the same CCID, the CCAG will attempt to provide a crosss connection path between the objects. The CCID enables multiple pairs of cross connected services to share the same CCAG. From a services perspective, a CCID is an object that not only binds two services together, but also provides the attachment point for the ingress and egress QoS, filtering and accounting policies. When considered in conjunction with the CCAG, it allows the actual cross connection path (through the VSMs) to be indirectly associated with the services using the CCAG and maintain a simplified provisioning model over port level cross connected services. VSM Virtual Paths The function of the VSM is to connect an egress forwarding path directly to an ingress forwarding path, allowing a packet to exit and reenter the system on the same MDA interface. This creates a half duplex forwarding environment for all cross connected objects using the VSM and differs from the full duplex nature of externally cross connected ports which support two distinct forwarding paths. VSM provisioning emulates full duplex provisioning with two logical Path A and Path B constructs which each emulates a TX-RX path for the CCAG. Although Path A and Path B use the same TX bandwidth at the hardware level (represented by the shared egress forwarding path for a given VSM), defining these distinct paths within a CCAG allows for optional provisioning of rate limiting on each path. When enabled, rate limiting on a path is spread across all the VSMs in the CCAG. For example, you may limit forwarding bandwidth in a CCAG based on limits applied to the Paths (e.g. Path A = 3 Mbps, Path B = 7 Mbps). This allocated more bandwidth to the B path than the A where asymmetric traffic flows appear. Objects on Path A must interconnect with objects on Path B  SAPs are assigned to a Path when created on the CCID  IP interfaces are assigned to a Path when bound to a CCAG;  ex: sap ccag-1.a:1 or sap ccag-1.b:1 SAPs are defined as belonging to either Path A or Path B when the SAP is created on the CCID. An IP interface is assigned to Path A or Path B when it is bound to a CCAG. A Path A object can only be paired with a Path B object and vice versa.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 36 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 2 - Cross Connect Identifier (CCID)

Phase 2 - Provision a CCAG

Syntax: Syntax:

[no] ccag create [no] ccag create [no] description [no] description [no] member-cca [no] member-cca path sap-sap [no] mtu path sap-sap [no] mtu

Example: config>vsm# ccag 1 create Example: config>vsm# ccag 1 create config>vsm>ccag# description “Service Cross Connect CSA1-MLS1 VPLS” config>vsm>ccag# description “Service Cross Connect CSA1-MLS1 VPLS” config>vsm>ccag# member-cca 5/1 config>vsm>ccag# member-cca 5/1 config>vsm>ccag# path a sap-sap mtu 9212 config>vsm>ccag# path a sap-sap mtu 9212 config>vsm>ccag# path b sap-sap mtu 9212 config>vsm>ccag# path b sap-sap mtu 9212 config>vsm>ccag# exit all config>vsm>ccag# exit all

 For resiliency and load balancing, a typical deployment would assign at least two VSMs as member-cca’s  The default path MTU is 1514  You must define both paths a and b

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

37

All rights reserved © 2012 Alcatel-Lucent

Phase 2 – Provision a CCAG This command creates a Cross Connect Aggregation Group (CCAG). A CCAG represents a group of CCAs as a common forwarding entity. Objects requiring a CCA cross connect function are mapped to a CCAG, not the individual CCAs within the CCAG. The CCAG treats each active member CCA as a possible destination when forwarding packets between the cross connected objects mapped to the CCAG. The system uses both conversation hashing functions and direct service mappings to determine the load sharing distribution between the active CCAs. All packets for a given conversation flow through the same CCA to preserve packet order. Packet ordering may be momentarily affected during convergence events when CCAs are dynamically added or removed from the active list. The CCAG context is used to manage the following functions per CCAG instance: • Informational description of the CCAG • Administrative state of the CCAG • Alpha path bandwidth and weight parameters • Beta path bandwidth and weight parameters • CCA total bandwidth limit • CCA membership in the CCAG ccag-id – Identifies the CCAG instance. The system can have up to eight CCAGs. member-cca – identifies the CCAG member VSM CCA. A CCAG can have up to eight member-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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 37 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Context: config>vsm Context: config>vsm

Phase 2 – Create the Outer VPLS CCAG SAP

A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# info info ------------------------------------------------------------------------------------------stp stp shutdown shutdown exit exit sap sap ccag-1.b:1 ccag-1.b:1 create create description description “Outer “Outer VPLS VPLS 11 to to VPRN VPRN 22 crossconnect” crossconnect” exit exit no no shutdown shutdown -------------------------------------------------------------------------------------------

 Create the “b” path SAP in the VPLS 1 service  Requires a corresponding “a” path in the VPRN 2 service  Each CCAG SAP requires a VLAN tag assigned

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

38

All rights reserved © 2012 Alcatel-Lucent

Phase 2 – Create the outer VPLS CCAG SAP The CCAG SAP components define the following characteristics: •ccag-id – Defines the group of CCAs used to forward packets associated with this SAP. •path a or b - Identifies the bandwidth control grouping use to manage CCA egress bandwidth. This pairing helps the system identify buffering resources it will use to manage egress packet queuing. •cc-id – Explicit cross-connects the SAP to another, in this case, one defined on a VPRN interface, configured with the same cc-id.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 38 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1>config>service>vpls# A:MLS1>config>service>vpls# sap sap ccag-1.b:1 ccag-1.b:1 create create A:MLS1>config>service>vpls>sap$ A:MLS1>config>service>vpls>sap$ back back

A:MLS1# A:MLS1# show show service service id id 11 sap sap ccag-1.b:1 ccag-1.b:1 =============================================================================== =============================================================================== Service Service Access Access Points(SAP) Points(SAP) =============================================================================== =============================================================================== Service :: 11 Service Id Id SAP :: ccag-1.b:1 Encap :: q-tag SAP ccag-1.b:1 Encap q-tag Description :: Outer Description Outer VPLS VPLS 11 to to VPRN VPRN 22 crossconnect crossconnect Admin :: Up Oper :: Up Admin State State Up Oper State State Up Flags :: None Flags None Multi :: None Multi Svc Svc Site Site None Last Last Status Status Change Change :: 08/22/2011 08/22/2011 11:16:38 11:16:38 Last Mgmt Change : 08/22/2011 Last Mgmt Change : 08/22/2011 11:14:38 11:14:38 =============================================================================== ===============================================================================

 Default encap-type is q-tag  Loopback (hairpin) cables could also be used, but would tie up two physical ports

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

39

All rights reserved © 2012 Alcatel-Lucent

Phase 2 - View the CCAG SAP A:NodeA# show service id 1 sap ccag-1.a:1  Encap: – Always q-tag. Hairpins in place of CCAG In the instance where the customer does not use VSMs, an external loopback cable can be used to cross connect service SAPs. In the VPLS service, you would create a SAP tied to physical port: A:NodeA# configure service id 1 sap 1/1/6 create  In the VPRN, you would create an interface, also tied to a physical port. Then, using a jumper, tie transmit to receive (or set MDI/MDI-X). Remember, however, that this ties up two physical ports, though you could support multiple physical crossconnects by setting dot1q or qinq on the ports.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 39 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 2 - View the CCAG SAP

An R-VPLS takes the place of the VSM or external cross-connects • Only one R-VPLS interface per L2 service • Set the VPLS service-name to associate it with L3 service interface • Set allow-ip-int-binding in the VPLS service

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

40

All rights reserved © 2012 Alcatel-Lucent

Phase 2 – Routed VPLS A standard IP interface within an existing IES or VPRN service context may be bound to a service name. Subscriber and group IP interfaces are not allowed to bind to a VPLS service context. A VPLS service only supports binding for a single IP interface; however, the routing context to which the VPLS is bound may have more than one bound VPLS service. Assigning the Service Name to the R-VPLS The R-VPLS requires a name. A:NodeA# configure service vpls 4 service-name  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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 40 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 2 – Routed VPLS

Phase 2 – Routed VPLS (cont)

=============================================================================== =============================================================================== Interface Interface Table Table (Service: (Service: 2) 2) =============================================================================== =============================================================================== Interface-Name Adm Opr(v4/v6) Port/SapId Interface-Name Adm Opr(v4/v6) Mode Mode Port/SapId IP-Address PfxState IP-Address PfxState ------------------------------------------------------------------------------------------------------------------------------------------------------------toOuterVPLS Up Up/-VPRN rvpls toOuterVPLS Up Up/-VPRN rvpls 203.0.113.1/30 n/a 203.0.113.1/30 n/a ------------------------------------------------------------------------------------------------------------------------------------------------------------Interfaces Interfaces :: 11 =============================================================================== ===============================================================================

In the VPRN, an interface must be bound to the VPLS service. A:MLS1>config>service>vprn# interface toOuterVPLS vpls OuterVPLS Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

41

All rights reserved © 2012 Alcatel-Lucent

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 

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 41 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show router router 22 interface interface "toOuterVPLS" "toOuterVPLS"

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 – Phase 3 – Local VPRN Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 43 | All rights reserved © 2012 Alcatel-Lucent

A:MLS1>config>service# A:MLS1>config>service# vprn vprn A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$ Traffic" Traffic" A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$

22 customer customer 11 create create description description "VPRN "VPRN Service Service for for 3G 3G Voice Voice

A:MLS2>config>service# A:MLS2>config>service# vprn vprn A:MLS2>config>service>vprn$ A:MLS2>config>service>vprn$ Traffic" Traffic" A:MLS2>config>service>vprn$ A:MLS2>config>service>vprn$ A:MLS1>config>service>vprn$ A:MLS1>config>service>vprn$ A:MLS2>config>service>vprn$ A:MLS2>config>service>vprn$

22 customer customer 11 create create description description "VPRN "VPRN Service Service for for 3G 3G Voice Voice

router-id router-id 198.51.100.1 198.51.100.1 route-distinguisher route-distinguisher 65000:2 65000:2 no no shutdown shutdown

router-id router-id 198.51.100.2 198.51.100.2 route-distinguisher route-distinguisher 65000:2 65000:2 no no shutdown shutdown

Create the local VPRN service on MLS1 and MLS2  No MP-BGP required, as these are local services  Each service needs a unique Router ID for IGP and EGP use  Each PE’s service needs a route distinguisher to build its local VRF Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

44

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – Create the MLS router Local VPRN Service The VPRN service must be defined and associated with the customer ID created in an earlier configuration. A description for the VPRN should always be included for ease of reference and troubleshooting. The router-ID is manually configured to establish a predictable identifier for the protocols that require one, such as OSPF and BGP. This is preferred over leaving the router-ID selection to the default mechanism, which can result in unpredictable values. Though this is a local service, it still requires a route distinguisher set in the service instance. Each PE requires a route distinguisher so that it can build and maintain its local Virtual Routing and Forwarding (VRF) table.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 44 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – Create the MLS router Local VPRN Service

The MLS routers host multiple local VPRNs, one for voice, data, and OAM traffic  Each traffic 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# A:MLS1>config>service>vprn# interface interface outer_VPLS1 outer_VPLS1 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ sap sap ccag-1.a:1 ccag-1.a:1 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ ip-address ip-address 192.0.2.1/27 192.0.2.1/27 A:MLS1>config>service>vprn>if$ mac A:MLS1>config>service>vprn>if$ mac 00:00:00:00:01:01 00:00:00:00:01:01 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ static-arp static-arp 192.0.2.2 192.0.2.2 00:00:00:00:01:02 00:00:00:00:01:02 A:MLS1>config>service>vprn>if$ back A:MLS1>config>service>vprn>if$ back A:MLS1>config>service>vprn# A:MLS1>config>service>vprn# interface interface inner_VPLS3 inner_VPLS3 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ sap sap ccag-1.a:2 ccag-1.a:2 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ ip-address ip-address 192.0.2.34/27 192.0.2.34/27 A:MLS1>config>service>vprn>if$ back A:MLS1>config>service>vprn>if$ back A:MLS1>config>service>vprn# A:MLS1>config>service>vprn# interface interface to_MLS2 to_MLS2 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ ip-address ip-address 192.0.2.165/30 192.0.2.165/30 A:MLS1>config>service>vprn>if$ A:MLS1>config>service>vprn>if$ sap sap lag-1:1 lag-1:1 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

45

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – Create the VPRN Interface In most cases, the VPRNs on the two MLS routers mirror each other. The exceptions are the interfaces between the MLS routers, some directly connected NC elements, and the VRRP protected NC gateway interfaces. The MLS inter-chassis interfaces must route traffic between the VPRN instances, in the case where the traffic must flow from a L2 service on one MLS router to the VPRN on the other. This flow characteristic is possible when a failure occurs on the CSA 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 45 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 - Create the VPRN Interfaces

A:MLS1>config>service>vprn# A:MLS1>config>service>vprn# interface interface to_BTS1_URC1_DO to_BTS1_URC1_DO A:MLS1>config>service>vprn>if# A:MLS1>config>service>vprn>if# dhcp dhcp A:MLS1>config>service>vprn>if>dhcp$ A:MLS1>config>service>vprn>if>dhcp$ server server 192.168.1.1 192.168.1.1 192.168.1.2 192.168.1.2 A:MLS1>config>service>vprn>if>dhcp$ A:MLS1>config>service>vprn>if>dhcp$ gi-address gi-address 198.51.100.65 198.51.100.65 A:MLS1>config>service>vprn>if>dhcp$ A:MLS1>config>service>vprn>if>dhcp$ no no shutdown shutdown A:MLS1>config>service>vprn>if>dhcp$ A:MLS1>config>service>vprn>if>dhcp$ back back

DHCP relay is configured on a per interface basis  The interface proxies DHCP requests on behalf of the URC  The URC discovers its IP address via DHCP discover broadcast into outer VPLS  Once IP configured, the URC establishes signaling link with NC element

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

46

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – Configure DHCP Relay for Data Only services DHCP relay configured on DO interfaces allows the DO URC to discover its IP address and IP configuration details. •server – Specifies the list of target DHCP server(s) to which the interface will forward requests. The list can include up to eight servers, and if multiple servers are listed, the request is fowarded to all of them. •gi-address – This is the DHCP gateway interface address. Also known as the “gi-addr”, this address identifies the interface address to be used for relaying DHCP packets.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 46 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – Configure DHCP Relay for Data Only services

A:MLS1# A:MLS1# show show router router 33 interface interface to_BTS1_URC1_DO to_BTS1_URC1_DO detail detail =============================================================================== =============================================================================== Interface Interface Table Table (Service: (Service: 2) 2) =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Interface Interface ------------------------------------------------------------------------------------------------------------------------------------------------------------If :: to_BTS1_URC1_DO If Name Name to_BTS1_URC1_DO Admin :: Up Oper :: Up/-Admin State State Up Oper (v4/v6) (v4/v6) Up/-Protocols :: OSPFv2 Protocols OSPFv2 IP :: 198.51.100.65/27 Address :: Primary IP Addr/mask Addr/mask 198.51.100.65/27 Address Type Type Primary IGP :: Disabled Broadcast IGP Inhibit Inhibit Disabled Broadcast Address Address :: Host-ones Host-ones ... ... DHCP DHCP Details Details Description Description :: (Not (Not Specified) Specified) Admin State :: Up Lease :: 00 Admin State Up Lease Populate Populate Servers :: 192.168.1.1 Servers 192.168.1.1 192.168.1.2 192.168.1.2 Gi-Addr :: 198.51.100.65 Gi-Addr Gi-Addr 198.51.100.65 Gi-Addr as as Src Src Ip Ip :: Disabled Disabled ** == inferred inferred gi-address gi-address from from interface interface IP IP address address

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

47

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – Configure DHCP Relay for Data Only services A:NodeA# show router 2 interface to_BTS1_URC1_DO detail  DHCP relay configured on DO interfaces allows the DO URC to discover its IP address and IP configuration details. •server – Specifies the list of target DHCP server(s) to which the interface will forward requests. The list can include up to eight servers, and if multiple servers are listed, the request is fowarded to all of them. •gi-address – This is the DHCP gateway interface address. Also known as the “gi-addr”, this address identifies the interface address to be used for relaying DHCP packets.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 47 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – View DHCP Relay Configuration

A:MLS1>config>service>vprn# A:MLS1>config>service>vprn# interface interface outer_VPLS1 outer_VPLS1 A:MLS1>config>service>vprn>if# A:MLS1>config>service>vprn>if# mac mac 00:00:00:01:00:01 00:00:00:01:00:01 A:MLS1>config>service>vprn>if# A:MLS1>config>service>vprn>if# static-arp static-arp 192.0.2.2 192.0.2.2 00:00:00:01:00:02 00:00:00:01:00:02 A:MLS1>config>service>vprn>if# A:MLS1>config>service>vprn>if#

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

48

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 48 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – Configure Static ARP Entries

 VRRP presents a virtual router to the sub-network  A Virtual Router ID (VRID) represents a virtual router instance  The NC element forwards traffic toward the virtual gateway address  VRRP instance determines the current master physical interface Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

49

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – VRRP on NC VPRN Interfaces Consider the diagram above. Both MLS1 and MLS2 have interfaces attached to a common subnet, 192.0.2.32/27. 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 nonowner mode, the virtual interface address belongs to no real interface, but still represents to network hosts the default gateway address. VRRP ensures that when hosts route their traffic to this virtual default gateway address, it actually routes through the 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 1255, with 255 the highest priority. When the master operates in owner mode, VRRP automatically assigns its priority to 255. VRRP assigns all non-owner master and backup routers priority to 100 by default. When configuring a VRRP router for non-owner mode, assign the master the higher priority, for example, 220. Then assign lower priorities to the backups as desired. By using progressively lower priorities for a group of backup routers, you can control the order in which routers become masters. A VRID can have up to 16 backup IP address in non-owner mode.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 49 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – VRRP on NC VPRN interfaces

 A network can host multiple VRIDs and load-balance traffic across them  NC element gateway address determines VRID targeted  Owner mode – master interface “owns” backup address  Non-owner mode – backup a third address Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

50

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – VRRP Load Balancing VRRP supports load balancing traffic on the same network segment across VRIDs. In this case, the network is configured with multiple virtual interfaces, all on the same sub-network. Assume again that Routers MLS1 and MLS2 present two real IP interfaces to the same Layer 3 network segment. Operating in owner mode, MLS1 is master for VRID 1 and its real interface IP address 192.0.2.33 becomes VRID 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  Router MLS2 real interface IP address: 192.0.2.34/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:  Router MLS1 real interface IP address: 192.0.2.33/27  Router MLS2 real interface IP address: 192.0.2.34/27  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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 50 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – VRRP Load Balancing

 Master advertises itself on the network every 1 second  Advertisement sent to multicast address 224.0.0.18  Backup waits for [(3 * Advertisement Interval) + Skew Time] to attempt to become master  Skew time partially based on interface priority value Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

51

All rights reserved © 2012 Alcatel-Lucent

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. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 51 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – VRRP Advertisements and Elections

A:MLS1>config>service>vprn# A:MLS1>config>service>vprn# interface interface inner_VPLS3 inner_VPLS3 A:MLS1>config>service>vprn>if# A:MLS1>config>service>vprn>if# vrrp vrrp 11 A:MLS1>config>service>vprn>if>vrrp$ A:MLS1>config>service>vprn>if>vrrp$ backup backup 192.0.2.35 192.0.2.35 A:MLS1>config>service>vprn>if>vrrp$ priority A:MLS1>config>service>vprn>if>vrrp$ priority 230 230 A:MLS1>config>service>vprn>if>vrrp$ A:MLS1>config>service>vprn>if>vrrp$ no no preempt preempt A:MLS1>config>service>vprn>if>vrrp$ A:MLS1>config>service>vprn>if>vrrp$ ping-reply ping-reply A:MLS1>config>service>vprn>if>vrrp$ A:MLS1>config>service>vprn>if>vrrp$ back back A:MLS1>config>service>vprn>if# A:MLS1>config>service>vprn>if# exit exit all all

A:MLS2>config>service>vprn# A:MLS2>config>service>vprn# interface interface inner_VPLS3 inner_VPLS3 A:MLS2>config>service>vprn>if# A:MLS2>config>service>vprn>if# vrrp vrrp 11 A:MLS2>config>service>vprn>if>vrrp$ A:MLS2>config>service>vprn>if>vrrp$ backup backup 192.0.2.35 192.0.2.35 A:MLS2>config>service>vprn>if>vrrp$ no A:MLS2>config>service>vprn>if>vrrp$ no preempt preempt A:MLS2>config>service>vprn>if>vrrp$ A:MLS2>config>service>vprn>if>vrrp$ ping-reply ping-reply A:MLS2>config>service>vprn>if>vrrp$ A:MLS2>config>service>vprn>if>vrrp$ back back A:MLS2>config>service>vprn>if# A:MLS2>config>service>vprn>if# exit exit all all

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

52

All rights reserved © 2012 Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 52 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – Configure VRRP in the VPRN Service

 MLS1 master interface goes offline  MLS2 VRRP Master Down Timer expires 2 3  MLS2 becomes the master interface and sends a gratuitous ARP for the virtual interface MAC into the network 4  The NC element forwards frames toward the virtual interface MAC address, which the switch has learned on MLS2 facing port 1

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

53

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – VRRP Recovery If 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_Timer and transition to backup.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 53 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – VRRP Recovery

OSPF configured within the VPRN service  MLS1 and MLS2 become neighbors in the same OSPF area  Interfaces to BTS and NC elements configured as passive  Local routes have preference over remotely learned, duplicate routes  Supports redundancy in the case the router strikes the local route from the VRF A:MLS1>config>service>vprn# A:MLS1>config>service>vprn# ospf ospf area area 0.0.0.51 0.0.0.51 A:MLS1>config>service>vprn>ospf>area$ A:MLS1>config>service>vprn>ospf>area$ interface interface to_VPLS2 to_VPLS2 A:MLS1>config>service>vprn>ospf>area>if$ A:MLS1>config>service>vprn>ospf>area>if$ passive passive A:MLS1>config>service>vprn>ospf>area>if$ A:MLS1>config>service>vprn>ospf>area>if$ back back A:MLS1>config>service>vprn>ospf>area$ A:MLS1>config>service>vprn>ospf>area$ interface interface toMLS2 toMLS2 A:MLS1>config>service>vprn>ospf>area>if$ A:MLS1>config>service>vprn>ospf>area>if$ back back A:MLS1>config>service>vprn>ospf>area$ A:MLS1>config>service>vprn>ospf>area$ back back A:MLS1>config>service>vprn>ospf$ A:MLS1>config>service>vprn>ospf$ back back

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

54

All rights reserved © 2012 Alcatel-Lucent

Phase 3 – Routing in the VPRN An IGP is configured within the VPRN 2 instances. The MLS routers duplicate many addresses between the VPRN instances, but this means that if MLS1 strikes the local route, it can replace it with the route learned from MLS2. Then, packets targeting the new route entry travel over the inter-chassis link to MLS2’s service.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 54 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 3 – Routing in the VRPN

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 – Phase 4 – Inner VPLS Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 55 | All rights reserved © 2012 Alcatel-Lucent

VPLS VPLS44 sap sap1/1/4:4 1/1/4:4 sap saplag-1:4 lag-1:4 sap sapccag-1.b:4 ccag-1.b:4

VPLS VPLS44 sap sap1/1/4:4 1/1/4:4 sap saplag-1:4 lag-1:4 sap sapccag-1.b:4 ccag-1.b:4

 Layer 2 loop can form in the topology shown  Some NC elements (DO-RNC, for example) connect to the VPLS service through redundant Ethernet switches  The VPLS needs a way to break the loop but still support link redundancy Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

56

All rights reserved © [year] Alcatel-Lucent

Phase 4 – Inner VPLS Management VPLS (mVPLS) By design, certain NC elements connect to the MLS inner VPLS through redundant Ethernet switches. This can cause a Layer 2 loop, as depicted above. SROS provides a means to break the loop while maintaining the redundant Ethernet links. Called a management VPLS (m-VPLS), it is a separate service designed to run Spanning Tree Protocol (STP) on behalf of a set of VPLS services. Rapid STP (RSTP) runs among the management VPLS (mVPLS) instances. It detects a loop in the mVPLS domain and, based on the priority of the mVPLS moves to a blocking state, thus breaks the loop. Note that RSTP recognizes mVPLS instances as interfaces. To facilitate the transition of traffic to the new SAP, the forwarding databases of the affected user VPLS (uVPLS) instances are flushed if a topology change occurs. mVPLS features include:  mVPLS is used to remove loops in the network caused by the implementation of SAP redundancy.  When RSTP in the mVPLS blocks an interface, the uVPLS is also blocked.  mVPLS instances are interconnected in a loop that is identical to the loop within the customer VPLS.  An mVPLS instance does not carry customer traffic.  Load balancing can be achieved with two mVPLS instances, with each instance managing multiple VLANs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 56 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 4 – Inner VPLS Management VPLS (mVPLS)

mVPLS mVPLS3000 3000 stp stppriority priority28762 28762 sap sap1/1/4:3000 1/1/4:3000 managed-vlan-list managed-vlan-list range range4-4 4-4 sap saplag-1:3000 lag-1:3000 managed-vlan-list managed-vlan-list range range4-4 4-4 mVPLS mVPLS3000 3000 stp stppriority priority28762 28762 sap sap1/1/4:3000 1/1/4:3000 managed-vlan-list managed-vlan-list range range4-4 4-4 sap saplag-1:3000 lag-1:3000 managed-vlan-list managed-vlan-list range range4-4 4-4

 Create an mVPLS on the MLS routers  Each mVPLS needs a SAP on the managed links; must be dot1q or qinq  The managed-vlan-list identifies the managed VLANs on that SAP  The switches A and B must run STP Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

57

All rights reserved © [year] Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 57 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 4 – Inner VPLS Management VPLS (mVPLS) (cont)

A:MLS1# A:MLS1# show show service service service-using service-using vpls vpls ============================================================================== ============================================================================== Services Services [vpls] [vpls] =============================================================================== =============================================================================== ServiceId Type Adm ServiceId Type Adm Opr Opr CustomerId CustomerId Service Service Name Name ------------------------------------------------------------------------------------------------------------------------------------------------------------44 uVPLS Up uVPLS Up Up Up 11 3000 mVPLS Up 3000 mVPLS Up Up Up 11 ------------------------------------------------------------------------------------------------------------------------------------------------------------Matching Matching Services Services :: 22 ------------------------------------------------------------------------------------------------------------------------------------------------------------=============================================================================== =============================================================================== A:MLS2# A:MLS2# show show service service service-using service-using vpls vpls ============================================================================== ============================================================================== Services Services [vpls] [vpls] =============================================================================== =============================================================================== ServiceId Type Adm ServiceId Type Adm Opr Opr CustomerId CustomerId Service Service Name Name ------------------------------------------------------------------------------------------------------------------------------------------------------------44 uVPLS Up uVPLS Up Up Up 11 3000 mVPLS Up 3000 mVPLS Up Up Up 11 ------------------------------------------------------------------------------------------------------------------------------------------------------------Matching Matching Services Services :: 22 -------------------------------------------------------------------------------------------------------------------------------------------------------------

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

58

All rights reserved © [year] Alcatel-Lucent

Phase 4 – View the mVPLS Status A:NodeA# show service service-using vpls  VPLS 4 is now being displayed as uVPLS. Both VPLSs have SAPs on the same port within the defined managed VLAN list in the mVPLS configuration. •type – The service type shown. mVPLS is the management VPLS, and uVPLS is a service managed by an mVPLS instance.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 58 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 4 – View the mVPLS Status

Phase 4 – Verifying the mVPLS – MLS1

=============================================================================== =============================================================================== Stp Stp info, info, Service Service 3000 3000 =============================================================================== =============================================================================== Bridge :: 70:00.62:aa:ff:00:00:00 Bridge Id Id 70:00.62:aa:ff:00:00:00 Top. Top. Change Change Count Count :: 11 Root :: 70:00.62:a9:ff:00:00:00 :: Up Root Bridge Bridge 70:00.62:a9:ff:00:00:00 Stp Stp Oper Oper State State Up Primary Bridge : N/A Topology Change : Primary Bridge : N/A Topology Change : Inactive Inactive Mode :: Rstp Last Mode Rstp Last Top. Top. Change Change :: 0d 0d 01:00:56 01:00:56 Vcp Active Prot. : N/A Vcp Active Prot. : N/A Root :: 2049 External :: 10 Root Port Port 2049 External RPC RPC 10 =============================================================================== =============================================================================== Stp Stp port port info info =============================================================================== =============================================================================== Sap/Sdp/PIP OperPortPortPortSap/Sdp/PIP Id Id OperPortPortPort- OperOper- LinkLink- Active Active State Role State Num Edge Type State Role State Num Edge Type Prot. Prot. ------------------------------------------------------------------------------------------------------------------------------------------------------------1/1/4:3000 Up Designated 2048 1/1/4:3000 Up Designated Forward Forward 2048 True True Pt-pt Pt-pt Rstp Rstp lag-1:3000 Up Root Forward 2049 False Pt-pt lag-1:3000 Up Root Forward 2049 False Pt-pt Rstp Rstp =============================================================================== ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

59

All rights reserved © [year] Alcatel-Lucent

Phase 4 – Verifying the mVPLS – MLS1 A:NodeA# show service id 3000 stp  •Port role – Either root, designated, alternate, or backup. •Port state – Discard, block, listen or forward.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 59 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

mVPLS mVPLS

A:MLS1# A:MLS1# show show service service id id 3000 3000 stp stp

uVPLS A:MLS1# uVPLS A:MLS1# show show service service id id 44 stp stp =============================================================================== =============================================================================== Inherited Inherited Stp Stp State State (from (from mVPLS), mVPLS), Service Service 44 =============================================================================== =============================================================================== Sap/Spoke OperPruneMngd Mngd Mngd Sap/Spoke Id Id OperPrune- PortPortMngd by by Mngd by by Mngd by by State State Service Sap/spoke MSTI State State State State Service Sap/spoke MSTI ------------------------------------------------------------------------------------------------------------------------------------------------------------1/1/4:4 Up -Forward 1/1/4:3000 CIST 1/1/4:4 Up Forward 3000 3000 1/1/4:3000 CIST lag-1:4 Up Forward 3000 lag-1:3000 CIST lag-1:4 Up Forward 3000 lag-1:3000 CIST =============================================================================== ===============================================================================

 The uVPLS port states follow the mVPLS state.  The show service id stp command displays the port state and the service and SAP managing the port.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

60

All rights reserved © [year] Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 60 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Phase 4 – Verifying the mVPLS – MLS1 (cont)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

61

All rights reserved © [year] Alcatel-Lucent

Module 3 - Page 61 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 3G Ethernet – Detailed Configuration

Lab 7 : Configure ePipe, VPRN and VPLS for 3G Voice Service

MLS1

CR1

CSA2

1.5 Hour

MLS2

Lab Objectives:  On the CSA routers, provision redundant ePipe spoke SDPs and NodeB/BTS facing SAPs  On the MLS routers, provision outer and inner VPLS services, local VPRNs, VRRP, and routing protocols  Verify service operation with SROS OAM tools Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

62

All rights reserved © [year] Alcatel-Lucent

Module 3 - Page 62 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

CSA1

Section Summary In this section, we :

 Provisioned the 3G Ethernet voice traffic distributed ePipe services  Configured the 3G Ethernet voice traffic outer VPLS  Provisioned the 3G Ethernet voice traffic VPRN service  Configured the 3G Ethernet voice traffic inner VPLS  Explored pseudowire redundancy as deployed in the Model 1 and 2 distributed VPWS  Configured PW redundancy in an ePipe service  Created CCAGs for L2 and L3 service virtual Ethernet cross connects  Configured VRRP on NC element facing interfaces  Evaluated management VPLS for STP application in the inner VPLS services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

63

All rights reserved © [year] Alcatel-Lucent

Module 3 - Page 63 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Reviewed the Model 1 3G Ethernet voice, data, and control traffic paths and services

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 3 — Model 1 Detailed Configuration – 3G TDM

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 65 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives In this section, we will:  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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

66

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 66 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Review the Model 1 3G TDM BS traffic paths and services

Model 1 - Ethernet Backhaul (EBH) - iPipes • 3G iPipes cross-connect into MLS VPRN interfaces • Carried over the same transport as the ePipes Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

67

All rights reserved © 2012 Alcatel-Lucent

Model 1 – iPipes/VPRN for 3G IP-over-TDM (IPoTDM) Voice Traffic A TDM-connected BS delivers packetized voice traffic to the CSA router over ML-PPP bundled DS1 or E1 circuits. The iPipe extracts the IP packets from the IP-over-ML-PPP-over-TDM UNI-BS, and forwards the packets alone through the VPWS to the far-end L3 interface. The MLS iPipe SAP or spoke SDP acts on behalf of the BS to accept and deliver Ethernet frames to and from the MLS L3 interface Ethernet port. In the case where the iPipe cross connects via a CCAG to a VPRN, the iPipe SAP and VPRN interface are the Ethernet endpoints.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 67 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 – iPipes/VPRN for 3G IP-over-TDM (IPoTDM) Voice Traffic

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

68

All rights reserved © 2012 Alcatel-Lucent

Model 1 TDM over iPipes Overview The diagram above shows an overview of the Model 1 design services to support 3G CDMA voice traffic. CSA1 to MLS iPipes Redundant iPipes transport IP packets to and from BTS ML-PPP bundled DS1 or E1 links. The CSA iPipe passes the BTS its IP address and target BSC addresses during IPCP negotiations. At the MLS, the iPipe cross connects into a local VPRN through a Versatile Services Module (VSM) hosted Cross Connect Aggregate Group (CCAG). The CCAG presents to the iPipe a requisite Ethernet interface acting on behalf of the BTS. MLS VPRN The MLS VPRN provides the BTS gateway interfaces. The CCAG provides bidirectional logical links between the L2 iPipe and the L3 VPRN interfaces. When the VPRN needs to build a frame which will transport a packet destined for the BTS, it uses the iPipe 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 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 iPipes into cross connected VPRN interfaces.  VRRP-protected VPRN interfaces forward traffic into inner VPLS SAPs.  OSPF runs between the local VPRNs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 68 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 3G IPoTDM over iPipes Overview

 Ipipe is a point to point Ethernet interworking VPWS service that makes it possible to provide connectivity between hosts that are attached to different point to point access circuits (ATM,FR, PPP, Ethernet) on either end of a pseudowire.  Only IP traffic can be transported over an iPipe.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

69

All rights reserved © 2012 Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 69 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Introduction to IP Interworking VPWS (iPipe)

The CSA router sends the BTS an IP address via IPCP  A multilink bundle is configured as the BTS SAP  The MLS1 iPipe SAP acts as an Ethernet interface on the BTS’ behalf  Sends and answers BTS ARP requests  The VPRN interface is the BTS’ gateway L3 interface Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

70

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Distibuted iPipe Configured on the CSA router are bundled DS1 or E1 links. In the iPipe SAP context, IPCP is configured to pass the the BTS its IP address and controller information.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 70 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Distributed iPipe

 The ce-address identifies the destination IP address for traffic egressing the iPipe service  The iPipe maintains an ARP cache and its Ethernet SAP sends and replies to ARP requests  The iPipe discards any frames not targeting the iPipe Ethernet SAP MAC address (00:00:00:00:10:10, as illustrated) Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

71

All rights reserved © 2012 Alcatel-Lucent

iPipe ce-address and Forwarding Behavior When two Ethernet devices communicate via IP, they must encapsulate the IP packets in Ethernet frames. The sender needs a destination MAC address for the frames, so it maintains an ARP cache and sends ARP requests for unknown MAC addresses. Since the BTS uses PPP frames to transport its IP packets, it has no assigned MAC address. In the iPipe context, the MLS1 router acts as an Ethernet interface for the BTS, answering ARP requests on its behalf. The CCAG becomes a point-to-point link between two L3 interfaces, the iPipe service and the VPRN interface. Ce-address In order to forward unicast frames destined for the RNC, the MLS1 iPipe needs to know the VPRN 2 interface MAC address. When the iPipe SAP is first configured and administratively enabled, MLS1 sends an ARP request message over the iPipe-VPRN CCAG Ethernet SAP, request the VPRN interface MAC address and using the iPipe SAP ce-address as the target IP address. Until it receives an ARP reply, the iPipe discards any unicast IP packets destined for the VPRN interface. The iPipe forwards IP broadcast and multicast packets using the broadcast or direct mapped multicast MAC address. Forwarding to the BTS 1. In order to forward unicast frames destined to the BTS, the MLS1 iPipe validates the destination MAC address of any frames it receives from the VPRN interface. If the VPRN does not have an ARP cache entry for the destination IP, it sends an ARP request on the CCAG. The iPipe will only respond to requests for the BTS IP address. 2. If the IP packet is unicast, the destination MAC must match that of the Ethernet SAP. If the IP packet is multicast or broadcast, the MAC destination address must be an appropriate multicast or broadcast MAC address. 3. The iPipe removes the Ethernet header and encapsulates the IP packet directly into the PW without a control word. 4. CSA1 removes the PW encapsulation and forwards the IP packet over the ML-PPP bundle. A PE does not flush the ARP cache unless the SAP goes admin or operationally down. The PE with the Ethernet SAP sends unsolicited ARP requests to refresh the ARP cache every T seconds. ARP requests are staggered at an increasing rate if no reply is received to the first unsolicited ARP request. T is configurable by user through the mac-refresh CLI command. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 71 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

iPipe ce-address and Forwarding Behavior

A:CSA1>config>service# A:CSA1>config>service# ipipe ipipe 10 10 customer customer 11 create create config>service>ipipe$ description config>service>ipipe$ description “Distributed “Distributed ipipe ipipe for for 3G 3G TDM TDM Services" Services" config>service>ipipe# config>service>ipipe# sap sap bundle-ppp-1/1.10 bundle-ppp-1/1.10 create create config>service>ipipe>sap$ back config>service>ipipe>sap$ back config>service>ipipe>sap$ config>service>ipipe>sap$ ce-address ce-address 192.0.2.162 192.0.2.162 config>service>ipipe>sap$ config>service>ipipe>sap$ ipcp ipcp config>service>ipipe>sap>ipcp$ config>service>ipipe>sap>ipcp$ assign-peer-ce-addr assign-peer-ce-addr config>service>ipipe>sap>ipcp$ config>service>ipipe>sap>ipcp$ dns dns 198.151.100.250 198.151.100.250 config>service>ipipe>sap>ipcp$ config>service>ipipe>sap>ipcp$ back back config>service>ipipe# config>service>ipipe# no no shutdown shutdown

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

72

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Configuring an iPipe Service This command configures an iPipe service instance. No MAC learning or filtering is provided on an Ipipe. Additionally, we show the BTS SAP configuration. •sap bundle-ppp-1/1.10 – An ML-PPP bundle already exists on the CSA router, and it terminates at the BTS. However, the bundle is not fully operational until it is provisioned in the iPipe service. •ce-address – This is the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 72 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Configuring an Ipipe Service

A:MLS1>config>service# A:MLS1>config>service# ipipe ipipe 10 10 customer customer 11 create create config>service>epipe# sap ccag-1.b:10 config>service>epipe# sap ccag-1.b:10 create create config>service>epipe>sap# config>service>epipe>sap# ce-address ce-address 192.0.2.161 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

73

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Configuring Distributed iPipe SAPs A CE address corresponding to the local end CE address needs to be configured under the SAP context before the SAP will come up operationally.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 73 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Configuring Distributed Ipipe SAPs

Example: Example: A:CSA1>config>service# A:CSA1>config>service# ipipe ipipe 10 10 A:CSA1>config>service>ipipe# A:CSA1>config>service>ipipe# endpoint endpoint A:CSA1>config>service>ipipe>endpoint$ A:CSA1>config>service>ipipe>endpoint$

ipipe ipipe back back A:CSA1>config>service>ipipe$ A:CSA1>config>service>ipipe$ spoke-sdp spoke-sdp 1:10 1:10 A:CSA1>config>service>ipipe# spoke-sdp A:CSA1>config>service>ipipe# spoke-sdp 1:10 1:10

create create endpoint endpoint ipipe ipipe create create precedence precedence primary primary ce-address 192.0.2.161 ce-address 192.0.2.161

Example: Example: A:MLS1>config>service# A:MLS1>config>service# ipipe ipipe 10 10 A:MLS1>config>service>ipipe# A:MLS1>config>service>ipipe# spoke-sdp spoke-sdp 1:10 1:10 create create A:MLS1>config>service>ipipe>spoke-sdp$ A:MLS1>config>service>ipipe>spoke-sdp$ ce-address ce-address 192.0.2.162 192.0.2.162 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

74

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Configuring the iPipe Primary SDP Bindings Note that at this point in our configuration steps, the iPipe service will show as being operationally up even if the spoke-sdp ce-address is not configured. However, you will not be able to ping between the CE devices as no data will be transmitted through the iPipe until the spoke-sdp ce-address is configured on CSA1 and MLS1. Note that the spoke SDP ce-address is the far-end L3 interface address. The CSA1 spoke SDP defines the VPRN2 CCAG interface address, while the MLS1 spoke SDP defines the BTS IP address.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 74 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Configuring the iPipe Primary SDP Bindings

Example: Example: A:CSA1>config>service# A:CSA1>config>service# ipipe ipipe 10 10 A:CSA1>config>service>ipipe# A:CSA1>config>service>ipipe# endpoint endpoint A:CSA1>config>service>ipipe>endpoint$ A:CSA1>config>service>ipipe>endpoint$

ipipe ipipe create create back back A:CSA1>config>service>ipipe$ A:CSA1>config>service>ipipe$ spoke-sdp spoke-sdp 2:10 2:10 endpoint endpoint ipipe ipipe create create A:CSA1>config>service>ipipe>spoke-sdp$ ce-address 192.0.2.161 A:CSA1>config>service>ipipe>spoke-sdp$ ce-address 192.0.2.161

Example: Example: A:MLS2>config>service# A:MLS2>config>service# ipipe ipipe 10 10 A:MLS2>config>service>ipipe# A:MLS2>config>service>ipipe# spoke-sdp spoke-sdp 2:10 2:10 create create A:MLS2>config>service>ipipe>spoke-sdp$ A:MLS2>config>service>ipipe>spoke-sdp$ ce-address ce-address 192.0.2.162 192.0.2.162 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

75

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Configuring the iPipe Secondary SDP Bindings Secondary Standby Spoke SDP To finish the configuration, you would add the redundant pseudowire to MLS2: A:CSA1>config>service>ipipe# spoke-sdp 2:10 endpoint ipipe create  A:CSA1>config>service>ipipe>spoke-sdp$ ce-address 192.0.2.161  You would also configure the iPipe on MLS2.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 75 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Configuring the iPipe Secondary SDP Bindings

Model 1 - Verifying the CSA iPipe Service =============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 10 Service Id Id 10 Service :: Ipipe Service Type Type Ipipe Description :: MLPPP_BTS10_URC10 Description MLPPP_BTS10_URC10 Customer :: 11 Customer Id Id Last Last Status Status Change: Change: 08/23/2011 08/23/2011 13:25:52 13:25:52 Last Last Mgmt Mgmt Change Change :: 08/23/2011 08/23/2011 13:26:28 13:26:28 Admin :: Up Oper :: Up Admin State State Up Oper State State Up MTU :: 1500 MTU 1500 Vc :: False Vc Switching Switching False SAP :: 11 SDP :: 22 SAP Count Count SDP Bind Bind Count Count ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:bundle-ppp-1/1.10 ipcp 1526 1526 Up Up sap:bundle-ppp-1/1.10 ipcp 1526 1526 Up Up sdp:1:10 n/a 00 1546 Up Up sdp:1:10 S(192.0.2.0) S(192.0.2.0) n/a 1546 Up Up sdp:2:10 n/a 00 1546 Up Up sdp:2:10 S(192.0.2.1) S(192.0.2.1) n/a 1546 Up Up =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

76

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Verifying the CSA iPipe Service A:NodeA# show service id 10 base  •MTU: - Note that the default service MTU of an Ipipe service is 1500 as opposed to the default service MTU of 1514 for an epipe. This value represents just the IP packet size.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 76 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA1# A:CSA1# show show service service id id 10 10 base base

Model 1 - Verifying the CSA iPipe Bundle SAP

=============================================================================== =============================================================================== Service Service Access Access Points(SAP) Points(SAP) =============================================================================== =============================================================================== Service :: 10 Service Id Id 10 SAP :: bundle-ppp-1/1.10 Encap :: ipcp SAP bundle-ppp-1/1.10 Encap ipcp Description :: (Not Description (Not Specified) Specified) Admin :: Up Oper :: Up Admin State State Up Oper State State Up Flags :: None Flags None Multi :: None Multi Svc Svc Site Site None Last Last Status Status Change Change :: 08/23/2011 08/23/2011 13:24:44 13:24:44 Last :: 08/23/2011 Last Mgmt Mgmt Change Change 08/23/2011 13:09:57 13:09:57 ------------------------------------------------------------------------------------------------------------------------------------------------------------Ipipe Ipipe SAP SAP Configuration Configuration Information Information ------------------------------------------------------------------------------------------------------------------------------------------------------------Ce :: 192.0.2.162 Assign :: false Ce IP IP Address Address 192.0.2.162 Assign to to Peer Peer false Peer Peer Pri Pri DNS DNS Addr Addr :: 198.51.100.250 198.51.100.250 Peer Peer Sec Sec DNS DNS Addr Addr :: Not Not configured configured Configured :: 192.0.2.162 Discovered Configured CE CE IP IP 192.0.2.162 Discovered CE CE IP IP :: n/a n/a ... ...

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

77

All rights reserved © 2012 Alcatel-Lucent

Model 1 - Verifying the CSA iPipe Bundle SAP A:NodeA# show service id 10 sap bundle-ppp-1/1.10  The CE IP Address of 192.0.2.162 is the CE IP address of the BTS directly attached to the SAP. Since this is PPP SAP, there is no associated MAC address.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 77 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA1# A:CSA1# show show service service id id 10 10 sap sap bundle-ppp-1/1.10 bundle-ppp-1/1.10

Model 1 - Verifying the iPipe MLS1 Ethernet SAP

=============================================================================== =============================================================================== Service Service Access Access Points(SAP) Points(SAP) =============================================================================== =============================================================================== Service :: 10 Service Id Id 10 SAP :: ccag-1.b:10 Encap :: q-tag SAP ccag-1.b:10 Encap q-tag Description :: MLPPP_BTS10_URC10 Description MLPPP_BTS10_URC10 Admin :: Up Oper :: Up Admin State State Up Oper State State Up Flags : None Flags : None Multi :: None Multi Svc Svc Site Site None Last Last Status Status Change Change :: 08/23/2011 08/23/2011 14:32:13 14:32:13 Last :: 08/23/2011 Last Mgmt Mgmt Change Change 08/23/2011 14:32:04 14:32:04 ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Ipipe Ipipe SAP SAP Configuration Configuration Information Information ------------------------------------------------------------------------------------------------------------------------------------------------------------Configured Discovered Configured CE CE IPv4 IPv4 :: 192.0.2.161 192.0.2.161 Discovered CE CE IPv4: IPv4: n/a n/a SAP :: 00:00:00:10:00:10 Mac SAP MAC MAC Address Address 00:00:00:10:00:10 Mac Refresh Refresh Inter*: Inter*: 14400 14400 ... ... Ipipe Ipipe SAP SAP IPv4 IPv4 ARP ARP Entry Entry Info Info ------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.161 62:aa:ff:00:02:19 192.0.2.161 62:aa:ff:00:02:19 dynamic dynamic 03h59m39s 03h59m39s

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

78

All rights reserved © 2012 Alcatel-Lucent

Model 1 - Verifying the iPipe MLS1 Ethernet SAP The CE IP Address shown in the figure is the CE IP address belonging to the VPRN 2 CCAG interface. Since this is an Ethernet SAP, the MAC address was dynamically learned from the VPRN interface.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 78 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show service service id id 10 10 sap sap ccag-1.b:10 ccag-1.b:10

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

79

All rights reserved © 2012 Alcatel-Lucent

Model 1 3G IPoTDM iPipes – Detailed View The detail, above, shows the services and service features used to support 3G TDM traffic over an Ethernet transport. CSA1 to MLSx iPipe •CSA1 - iPipe 10 transports IP packets delivered from a TDM base station to the MLS routers. The BTS Universal Radio Controller (URC) terminates an ML-PPP bundle, and delivers packetized voice, data, and control traffic over load balanced PPP links. The CSA extracts the IP packets and delivers them to the target MLS through the iPipe service. Each ce-address entry enables IP forwarding within the iPipe service. On the CSA1 end, the spoke SDP ce address is the far-end L3 interface address, VPRN 2 interface to_iPipe10. The SAP ce address belongs to the URC, and supports IPCP signaling between it and the iPipe bundle SAP. The 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 79 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 3G IPoTDM iPipes – Detailed View

Section Summary In this section, we:  Reviewed the Model 1 3G TDM traffic paths and services  Provisioned the 3G TDM voice traffic VPRN service interfaces  Employed redundant pseudowires in the iPipe service

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

80

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 80 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Provisioned the 3G TDM voice traffic distributed iPipe services

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 4 — Model 1 Detailed Configuration – 4G LTE Voice and Data Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 81 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives In this section, we will:  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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

82

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 82 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Review the Model 1 LTE services

Model 1 - 4G LTE • 4G ePipes terminate into MLS IES • BS-BS traffic routed through MLS IESs • MME VRRP interface supported through MLS local VPLS Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

83

All rights reserved © 2012 Alcatel-Lucent

Model 1 – ePipes, IES, and Local VPLS for LTE Traffic The Backhaul Transport carries LTE user and OAM packets through dedicated redundant ePipes originating and terminating on the CSA routers. These tie into spoke SDP IES interfaces configured in a single MLS router IES. All traffic is routed at the MLS routers. Each eNodeB connects to the CSA router through a gigabit Ethernet link, using dot1q encapsulation. Each VLAN, one for user and one for OAM traffic, is assigned a /30 or /31 mask address. The MLS IES interfaces become the eNodeBs gateway. VRRP for MME Interfaces Local VPLS support multiple MMEs, and VRRP-protected, cross-connected IES interfaces provide MME routed access. The eNodeB networks are included in the base routing instance. MPLS is only used on the spoke SDPs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 83 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 – ePipes, IES, and Local VPLS for LTE Traffic

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

84

All rights reserved © 2012 Alcatel-Lucent

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. Router-Specific Configurations  Redundant pseudowires are configured on the CSA router.  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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 84 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 LTE Services Overview

LTE S1-MME traffic • The Mobility Management Entity (MME) manages access and mobility • The S1-MME interface is the reference point for the control plane protocol between the eNodeB and the MME • This traffic is forwarded through a telecom VLAN, IES, and local VPLS Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

85

All rights reserved © 2012 Alcatel-Lucent

Model 1 – LTE S1-MME Traffic The Backhaul Transport provides a flat, L2 network for transporting LTE packets. Routing occurs at the MLS routers, reducing processing and nodal delay. S1-MME Traffic The MME is the LTE control plane element responsible for high volume mobility management and connection management. MME performs the following actions: • Authenticates the user and authorizes the user equipment access to network connections after interacting with the HSS (Home Subscriber Server) • Selects the appropriate serving and PDN gateways to handle the connection • Establishes, modifies and releases user connections • Selects the Serving GPRS Support Node (SGSN) for handovers to 2G or 3G 3GPP access networks • Allows a law enforcing agency to receive information regarding user signaling activities. • The MME is also responsible for searching for an idle UE to establish a connection to it. The S1-MME interface controls the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 85 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 – LTE S1-MME Traffic

LTE S1-U traffic • • • •

The S1-U carries only user traffic (no signaling or OAM) The S1-U session terminates at the SGW All user traffic routes through the SGW This traffic is forwarded through a telecom VLAN and IES

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

86

All rights reserved © 2012 Alcatel-Lucent

Model 1 –LTE S1-U Traffic The S1-U interface transports only user traffic. The GPRS Tunneling Protocol (GTP)-User plane, GTP-U, tunnels user traffic between the eNodeB and the Serving Gateway (SGW). SGW Functions The Serving Gateway (SGW) terminates the interfaces towards the E-UTRAN. For each Evolved Packet System (EPS) associated UE there is a single SGW node handling all the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 86 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 –LTE S1-U Traffic

EPC Traffic Flows • All EPC inter-element traffic routes through the MLS routers • The S5/8 interfaces support SGW-PGW communications for user plane tunneling and tunnel management • The S11 interface carries control traffic between the MME and the SGW • The S6a enables the transfer of subscription and authentication between the MME and the HSS function. • The Gx interface supports PGW to PCRF QoS and Policy and Charging Enforcement Functions (PCEF) Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

87

All rights reserved © 2012 Alcatel-Lucent

Model 1 – EPC Element Traffic Flows – S5, S6a, S11, and Gx All traffic between the EPC elements is routed at the MLS routers, either directly or alternately over the interchassis LAG. The routers form an OSPF adjacency over the inter-chassis LAG, and as we learned earlier, either route to directly connected or remote interfaces depending on network conditions. S5/8 Interface The S5/S8 interface is the reference point between SGW and PGW. The S5 interface is used when the SGW and PGW are part of the same network. The S8 interface is used in roaming scenarios where the SGW is located in the visiting network and the PGW is located in the home network. These interfaces provide support for user plane tunneling and tunnel management between SGW and PGW. They support the creation of control sessions per UE per PDN connection as well as the creation, modification and deletion of individual user data tunnels. These interfaces are also used for SGW relocation due to UE mobility, in the case where the UE moves to an area served by a different SGW. The S5/S8 interface supports both control plane and user plane functions. The PGW: • Allocates an IP address per PDN for the UE during initial attachment • Applies the quality of service rules received from PCRF for a given connection • Allows a law enforcing agency to receive information regarding user data • Serves as the mobility anchor during handovers between LTE and non-3GPP access networks (e.g. CDMA/HRPD) • May perform packet filtering on a per-user basis by implementing deep packet inspection for example. S6a Interface The S6a interface carries control traffic between the MME and the Home Subscriber Server (HSS). The HSS is the master database that contains subscriber AAA information, and the MME uses the HSS to validate the 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...)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 87 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 – EPC Element Traffic Flows – S5, S6a, S11, and Gx

The X2 interface supports inter-eNodeB traffic • It supports inter-eNodeB UE handoff and load management • This traffic is routed at the MLS User IES interfaces

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

89

All rights reserved © 2012 Alcatel-Lucent

Model 1 – X2 Interface for eNodeB to eNodeB Traffic X2 Interface X2 is the reference point between 2 eNodeBs. When a UE moves from one eNodeB to another and both are served by the same MME, an X2 handover procedure is performed. This traffic is routed at the MLS IES interfaces.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 89 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 – X2 Interface for eNodeB to eNodeB Traffic

Model 1 - Create the MLS eNodeB and MME IES Services A:MLS1>config>service# A:MLS1>config>service# ies ies A:MLS1>config>service>ies$ A:MLS1>config>service>ies$

2000 2000 customer customer 11 description description “L3 “L3

create create MME-1 MME-1 VRRP VRRP VPLS" VPLS"

A:MLS1>config>service# A:MLS1>config>service# ies ies 4000 4000 customer customer 11 create create A:MLS1>config>service>ies$ A:MLS1>config>service>ies$ description description “eNodeB “eNodeB IES" IES" A:MLS1>config>service>ies$ A:MLS1>config>service>ies$ no no shutdown shutdown A:MLS2>config>service# A:MLS2>config>service# ies ies 2000 2000 customer customer 11 create create A:MLS2>config>service>ies$ A:MLS2>config>service>ies$ description description "" L3 L3 MME-1 MME-1 VRRP VRRP VPLS VPLS "" A:MLS2>config>service>ies$ A:MLS2>config>service>ies$ no no shutdown shutdown A:MLS2>config>service# A:MLS2>config>service# ies ies 4000 4000 customer customer 11 create create A:MLS2>config>service>ies$ A:MLS2>config>service>ies$ description description "eNodeB "eNodeB IES" IES" A:MLS2>config>service>ies$ A:MLS2>config>service>ies$ no no shutdown shutdown

Create the eNode and MME VPLS IES on MLS1 and MLS2 • One IES for eNodeB telecom (user and control) and OAM traffic • One for MME Pool routed traffic Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

90

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 90 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1>config>service>ies$ A:MLS1>config>service>ies$ no no shutdown shutdown

The eNodeB IES includes interfaces for telecom and OAM traffic  Each interface is tied to a return CSA spoke SDP  Each interface defines the interface MAC and eNodeB static ARP cache entries A:MLS1>config>service>ies# A:MLS1>config>service>ies# interface interface “toEnodeB_1_telecom” “toEnodeB_1_telecom” create create A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ spoke-sdp spoke-sdp 1:100 1:100 create create A:MLS1>config>service>ies>if>spoke-sdp$ A:MLS1>config>service>ies>if>spoke-sdp$ back back A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ address address 192.0.2.176/31 192.0.2.176/31 A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ mac mac 00:00:01:00:01:01 00:00:01:00:01:01 A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ static-arp static-arp 192.0.2.177 192.0.2.177 00:00:01:00:01:02 00:00:01:00:01:02 A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ back back A:MLS1>config>service>ies# A:MLS1>config>service>ies# interface interface “toEnodeB_1_OAM” “toEnodeB_1_OAM” A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ spoke-sdp spoke-sdp 1:101 1:101 create create A:MLS1>config>service>ies>if>spoke-sdp$ A:MLS1>config>service>ies>if>spoke-sdp$ back back A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ ip-address ip-address 192.0.2.178/31 192.0.2.178/31 A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$

mac mac 00:00:01:00:01:03 00:00:01:00:01:03 static-arp static-arp 192.0.2.179 192.0.2.179 00:00:01:00:01:04 00:00:01:00:01:04 A:MLS1>config>service>ies>if$ back A:MLS1>config>service>ies>if$ back A:MLS1>config>service>ies# A:MLS1>config>service>ies# Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

91

All rights reserved © 2012 Alcatel-Lucent

Model 1 - Create the MLS eNodeB IES Interfaces The eNodeB IES includes two spoke SDP interfaces for each eNodeB, one for telecom and one for OAM traffic. The interfaces statically define the interface MAC addresses and include eNodeB static ARP cache entries. The IES interfaces are advertised by the IGP via a routing policy, shown later in this section. The active CSA ePipe spoke SDP forwards traffic toward the MLS routers, and the EPC element-facing interfaces are IGP advertised. Hence, the MLS can find the destination network, regardless of the active EPC element interface.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 91 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Create the MLS eNodeB IES Interfaces

Model 1 – Set the IES Service VC-MTU

or A:MLS1>config>service>ies# A:MLS1>config>service>ies# interface interface eNodeB_telecom eNodeB_telecom A:MLS1>config>service>ies>if# A:MLS1>config>service>ies>if# ip-mtu ip-mtu 1500 1500 A:MLS1>config>service>ies>if# A:MLS1>config>service>ies>if# back back

 The IES signals a VC-MTU for the spoke SDPs; the VC-MTU must be compatible with the ePipe service MTU  An L3 service has no service MTU; the default signaled VC-MTU is based on the SDP path MTU (path MTU - 14 bytes)  An L2 service VC-MTU equals the service MTU - 14 bytes (1500 bytes for a default VPLS or ePipe service)  Setting the spoke SDP interface IP-MTU overrides the SDP path MTU Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

92

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Set the IES Service Interface MTU Size MTU Concerns The PEs signal service VC-MTUs when they signal service labels. The VC-MTU is not configurable; on an L2 service. it is based on the service MTU minus the encapsulation overhead. On an ePipe service, this is 1514-14=1500. If the L2 and L3 VC-MTUs 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 92 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1>config>service>sdp# A:MLS1>config>service>sdp# path-mtu path-mtu 1514 1514

The MME IES provides an MME VRRP virtual gateway interface  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# A:MLS1>config>service>ies# interface interface “L3 “L3 MME MME VPLS VPLS interface” interface” A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ sap sap ccag-1.a:2000 ccag-1.a:2000 create create A:MLS1>config>service>ies>if>sap$ A:MLS1>config>service>ies>if>sap$ back back A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ address address 192.0.2.97/27 192.0.2.97/27 A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ tos-marking-state-trusted tos-marking-state-trusted A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ vrrp vrrp 10 10 A:MLS1>config>service>ies>if>vrrp$ A:MLS1>config>service>ies>if>vrrp$ backup backup 192.0.2.99 192.0.2.99 A:MLS1>config>service>ies>if>vrrp$ A:MLS1>config>service>ies>if>vrrp$ no no preempt preempt A:MLS1>config>service>ies>if>vrrp$ A:MLS1>config>service>ies>if>vrrp$ ping-reply ping-reply A:MLS1>config>service>ies>if>vrrp$ A:MLS1>config>service>ies>if>vrrp$ back back A:MLS1>config>service>ies>if$ A:MLS1>config>service>ies>if$ back back A:MLS1>config>service>ies# A:MLS1>config>service>ies#

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

93

All rights reserved © 2012 Alcatel-Lucent

Model 1 - Create the MLS MME VPLS IES Interfaces The MLS MME VPLS IES provides a VRRP protected interface for the MME. •tos-marking-state trusted – An 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 93 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 - Create the MLS MME VPLS IES Interfaces

Model 1 - Verifying the MLS IES 2000 Service

=============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 2000 Vpn :: 00 Service Id Id 2000 Vpn Id Id Service :: IES Service Type Type IES Name :: (Not Name (Not Specified) Specified) Description :: L3 Description L3 MME-1 MME-1 VRRP VRRP VPLS VPLS Customer :: 11 Customer Id Id Last Last Status Status Change: Change: 09/28/2011 09/28/2011 09:01:51 09:01:51 Last Last Mgmt Mgmt Change Change :: 09/28/2011 09/28/2011 08:58:35 08:58:35 Admin :: Up Oper :: Up Admin State State Up Oper State State Up SAP :: 11 SAP Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:ccag-1.a:2000 q-tag 9212 9212 Up Up sap:ccag-1.a:2000 q-tag 9212 9212 Up Up =============================================================================== ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

94

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Verifying the MLS IES 2000 Service A:NodeA# show service id 2000 base 

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 94 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show service service id id 2000 2000 base base

Model 1 - Verifying the MLS IES 4000 Service

=============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 4000 Vpn :: 00 Service Id Id 4000 Vpn Id Id Service :: IES Service Type Type IES Name :: (Not Name (Not Specified) Specified) Description :: eNodeB Description eNodeB IES IES Customer :: 11 Customer Id Id Last Last Status Status Change: Change: 09/28/2011 09/28/2011 08:59:04 08:59:04 Last Last Mgmt Mgmt Change Change :: 09/28/2011 09/28/2011 08:58:35 08:58:35 Admin :: Up Oper :: Up Admin State State Up Oper State State Up SAP :: 00 SAP Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sdp:1:100 Spok 1514 1514 Up Up sdp:1:100 S(192.0.2.2) S(192.0.2.2) Spok 1514 1514 Up Up sdp:1:101 Spok 1514 1514 Up Up sdp:1:101 S(192.0.2.2) S(192.0.2.2) Spok 1514 1514 Up Up =============================================================================== ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

95

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Verifying the MLS IES 4000 Service A: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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 95 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show service service id id 4000 4000 base base

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

96

All rights reserved © 2012 Alcatel-Lucent

Model 1 LTE Services – Detailed View The detail above, shows the services and service features used to support 4G LTE voice, data, control, and OAM traffic. CSA1 to MLS ePipes For each eNodeB, the CSA hosts two redundant ePipe services, one for user traffic and one for eNodeB OAM functions. MLS eNodeB IES IES 4000 terminates the ePipe spoke SDPs. The MLS routes all eNodeB traffic via the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 96 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 1 LTE Services – Detailed View

Section Review In this section, we:  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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

97

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 97 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Reviewed the Model 1 LTE services

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 5 — Service Resiliency in the Model 2 Network

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 99 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives In this section, we will:

 Investigate MC-LAG as the feature might be used to protect multihomed Ethernet NC elements  Deploy Interchassis Backup Pseudowires (ICB-PW) to avoid blackholing traffic destined to the standby multi-chassis peer  Provision MC-APS for MLS SONET/SDH protection

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

100

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 100 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Implement pseudowire switching to support traffic engineering and control FIB sizes across IGP areas

PW switching ties spoke SDPs together across routing areas or protocols and different MPLS protocols  It improves scalability by removing the need for a full mesh of SDPs between the CSA and POC1 routers  It is supported on all VPWS services  The Switching PE (S-PE) ties the spoke SDPs together, while the Terminating PEs (T-PE) terminate the services Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

101

All rights reserved © 2012 Alcatel-Lucent

Pseudowire Switching across Routing Areas The Model 2 network divides the access and aggregation rings into different ISIS levels. This helps to limit control plane traffic and FIB sizes. However, since traffic engineering does not work across routing areas, an approach is needed to ensure the use of admin groups, FRR, and other TE techniques. Pseudowire switching uses an intermediate PE router as a switching PE (S-PE), breaking the service into segments. The S-PE ties two spoke 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 Function You create the S-PE function in the VPWS context, using the vc-switching command. A:NodeA# configure service epipe 3 customer 1 vc-switching create  The vc-switching keyword allows only two endpoint objects, both spoke SDPs, and they should each terminate on the T-PE routers. For label mapping, the S-PE:  Acts as a slave to the T-PEs for PW signaling.  Waits for labels from the T-PEs. These messages pass SAP MTUs and other information the S-PE must relay to the opposite T-PE.  Appends a PW switching point TLV to the FEC TLV, recording its system address. For status messages, the S-PE:  Can process and relay status messages generated by the T-PE or generate them itself.  Appends the PW switching TLV to messages it originates (Notification and Label Mapping) or to messages it receives with this TLV (from another S-PE)  Sends status unchanged if both S-PE spoke SDPs are up, sends SDP-binding down if one of the local spoke SDPs is down  Sends the vc-id of the next PW segment in the PW switching TLV

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 101 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 - Pseudowire Switching across Routing Areas

The T-PE routers signal service labels upstream toward the S-PE  The S-PE signals labels towards the next hop only after it receives a label message from a downstream router (ordered control)  The S-PE includes the previous segment’s vc-id and its own system ID as well as the PW status bits Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

102

All rights reserved © 2012 Alcatel-Lucent

Message Propagation in a Switched PE The S-PE only propagates service label mapping messages it receives from the T-PE routers. Here, MLS1 is the originating T-PE, and once the service becomes operational it sends a service label mapping message to the next upstream router, POC3-1, the S-PE. POC2-1 only acts as an LSR. POC3-1 generates its own service label mapping message and sends it to the other T-PE, CSA1. It includes the PW switching TLV, and includes the previous vc-id and its own System ID. CSA1 receives the label mapping message and, once its end is configured and operational, can forward traffic toward MLS1. Label Actions at the S-PE The S-PE swaps both the MPLS transport labels and the VC labels. POC2 only swaps the MPLS transport label. PW Status Messages The S-PE relays T-PE router-generated status messages and generates status messages of its own.  The S-PE must notify the T-PEs and other S-PEs (if part of the service) of the status of its own spoke SDPs. Assuming one of the S-PE router spoke SDPs were to fail, the S-PE would send a PW status message to its peer indicating the spoke SDP is down. It appends to this message the PW switching TLV.  The S-PE must forward notification messages it receives from the T-PEs. For example, if the MC T-PE were to signal a change on the active SAP, it would signal this in a PW status message to the S-PE. Since this status affects 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 102 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Switched PW Message Propagation

Configuring PW Switching

Context: Context: config>service# config>service# [no] [no] epipe epipe customer customer vc-switching vc-switching create create

Context: Context: config>service>epipe# config>service>epipe# Syntax: Syntax:

[no] [no] spoke-sdp spoke-sdp create create

Example: Example: config>service# config>service# epipe epipe 33 customer customer 11 vc-switching vc-switching create create config>service>epipe$ spoke-sdp 1:1 config>service>epipe$ spoke-sdp 1:1 create create config>service>epipe>spoke-sdp$ config>service>epipe>spoke-sdp$ back back config>service>epipe# config>service>epipe# spoke-sdp spoke-sdp 4:2 4:2 create create config>service>epipe>spoke-sdp$ back config>service>epipe>spoke-sdp$ back config>service>epipe# config>service>epipe# no no shutdown shutdown

 The vc-switching keyword configures the S-PE  The service remains down until both spoke SDPs become operational  No SAPS and only two spoke SDPs allowed Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

103

All rights reserved © 2012 Alcatel-Lucent

Configuring PW Switching Configure the PW switching services as follows: 1. Configure an ePipe on the T-PEs. Configure the ePipe on the T-PEs as you would any VPWS service. If the T-PE is a MC peer and you plan to use ICB-PWs, configure the service with the MC-APS or MC-LAG SAPs. We discuss MC-LAG, MC-APS, and ICB-PW use later in this section. If the T-PE originates redundant PWs, then configure them as we discussed in previous sections. The spoke SDP targets will be the S-PEs, rather than the opposite T-PE. 2. Configure the S-PE. Shown above are the configuration commands for the S-PE, POC3-1. The service remains down until the S-PE receives labels from the T-PEs, or another S-PE. The S-PE will not distribute labels until both its spoke SDPs are up. That means that though its spoke SDP to TPE1 is up, and it has received and signaled a label to T-PE1, it will not signal a label to T-PE2 until it receives a label from T-PE2, as well.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 103 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Syntax: Syntax:

A:POC3-1# A:POC3-1# show show service service id id 33 base base =============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 33 Vpn :: 00 Service Id Id Vpn Id Id Service :: Epipe Service Type Type Epipe ... ... Admin :: Up Oper :: Up Admin State State Up Oper State State Up MTU : 1514 MTU : 1514 Vc :: True Vc Switching Switching True SAP Count :: 00 SDP :: 22 SAP Count SDP Bind Bind Count Count ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sdp:1:1 Spok 00 1550 Up sdp:1:1 S(192.0.2.2) S(192.0.2.2) Spok 1550 Up Up Up sdp:4:2 Spok 00 1550 Up sdp:4:2 S(192.0.2.128) S(192.0.2.128) Spok 1550 Up Up Up =============================================================================== ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

104

All rights reserved © 2012 Alcatel-Lucent

View the S-PE Service Status A: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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 104 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the S-PE Service Status

Access Redundancy in the Model 2 Network – Multi-chassis-Link Aggregation Group (LAG) Interchassis Backup-Pseudowire (ICB-PW) Multi-chassis-Automatic Protection Switching (MC-APS}

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 105 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 3 — Implementing Mobile Backhaul Transport Services

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

106

All rights reserved © 2012 Alcatel-Lucent

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 Characteristics MC-LAG is an SROS proprietary solution to providing both link and nodal redundancy on Ethernet access links. • It is transparent to the CE device and customer. The MC-LAG configuration and control protocol are only deployed in the PE routers. No functional changes are required on the CE device LAGs. • No MPLS or service is required on the CE devices. The CE connects to the service through an Ethernet LAG, as if it was connected to a single chassis. • There is no need to run Spanning Tree Protocol or a management VPLS. The MC-LAG protocol ensures only one CE-PE link is active at a time. Inter-chassis signaling The MC-LAG protocol signals the LAG member status between the two chassis. It is a routed protocol, using UDP port 1025. • As a routed protocol, it 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 selection The first PE up becomes the active PE. You can adjust the port priorities on one PE to make it the preferred active MC-LAG member. Then, if all active port numbers match, the nodes choose by a calculated weight value.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 106 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Multi-Chassis LAG (MC-LAG)

 Based on IEEE 802.3ad  LACP messages are sent over each link every 1 s (fast) or 30 s (slow).  Uses the OSSP destination MAC (01:80:C2:00:00:02).  Three parameters uniquely identify a LAG instance to the local node:  LACP key - default 32768 for first LAG. Must be set for MC-LAG  System ID - derived from base MAC address or set specifically for MC-LAG  System priority - default 32768. Must be set for MC-LAG  Actor (self) and Partner (other side of the link) info is contained in every LACP packet.  The actor initiates LACP packet exchange Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Alcatel-Lucent Virtual Private LAN Services v2.0

Module 3 |

107

All rights reserved © 2012 Alcatel-Lucent

LACP Basics LACP is based on the IEEE 802.3ad standard. LACP messages are carried in IEEE OSSP frames (see Module 2, SyncE/SSM). Each LAG instance includes:  LACP key – The default is 32768. These must match between the MC-LAG peers and the peer CE.  System-ID – Derived from the chassis MAC by default, but must be configured on an MC-LAG.  System priority – Default is 32768, but must be set on an MC-LAG. The LACP actor is the active side of the LAG, while the partner is the passive side. The actor initiates LACP packet transmission.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 107 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LACP Basics

A:MLS1>config>lag# A:MLS1>config>lag# info info ------------------------------------------------------------------------------------------mode mode access access port port 1/1/1 1/1/1 priority priority 100 100 port port 1/1/2 1/1/2 priority priority 100 100 lacp active lacp active administrative-key administrative-key 32768 32768 no no shutdown shutdown ------------------------------------------------------------------------------------------*A:PE1>config>redundancy>multi-chassis# *A:PE1>config>redundancy>multi-chassis# info info ------------------------------------------------------------------------------------------peer peer 10.0.0.2 10.0.0.2 create create mc-lag mc-lag lag lag 11 lacp-key lacp-key 11 system-id system-id 00:00:00:00:00:01 00:00:00:00:00:01 system-priority system-priority 100 100 no no shutdown shutdown exit exit exit exit -------------------------------------------------------------------------------------------

Create on each MC peer  Key, system ID, and systempriority must match  Can assign port priority to control active peer

*A:MLS2>config>lag# *A:MLS2>config>lag# info info ------------------------------------------------------------------------------------------mode mode access access port port 1/1/1 1/1/1 port port 1/1/2 1/1/2 lacp lacp active active administrative-key administrative-key 32768 32768 no no shutdown shutdown ------------------------------------------------------------------------------------------*A:PE2>config>redundancy>multi-chassis# *A:PE2>config>redundancy>multi-chassis# info info ------------------------------------------------------------------------------------------peer peer 10.0.0.1 10.0.0.1 create create mc-lag mc-lag lag lag 11 lacp-key lacp-key 11 system-id system-id 00:00:00:00:00:01 00:00:00:00:00:01 system-priority system-priority 100 100 no shutdown no shutdown exit exit exit exit -------------------------------------------------------------------------------------------

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

108

All rights reserved © 2012 Alcatel-Lucent

MC-LAG on PE Nodes When configuring an MC-LAG across two PE devices, you must inform the PE devices of their peer using the multi-chassis peer command. In addition, LACP keys, System ID MAC addresses, and priorities must be equal. When configuring MC-LAG on the PEs, you do need to specify matching keys. This differs from setting up standard LAGs, where the system sets up the LACP keys. A:NodeA>config>redundancy>multi-chassis# peer 10.10.10.12 create  A:NodeA>config>redundancy>multi-chassis>peer# mc-lag  A:NodeA>config>redundancy>mc>peer>mc-lag# lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100  A:NodeA>config>redundancy>mc>peer>mc-lag# no shutdown  A:NodeA>config>redundancy>mc>peer>mc-lag# back  A:NodeA>config>redundancy>multichassis>peer# no shutdown  LAG on the CE Nodes The CE node configuration is a standard LAG with LACP enabled. A:CR1>config>lag# info ---------------------------------------------mode access port 1/1/5 port 1/1/6 port 1/1/7 port 1/1/8 lacp active administrative-key 32768 no shutdown ---------------------------------------------Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 108 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MC-LAG on the Remote PEs

On the MLS router, the MC-LAG LAG groups become the CE SAPs  The remote PEs signal LAG member status as SAP status  The local PE, CSA1, chooses the spoke SDP associated with the active remote MC-LAG PE

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

109

All rights reserved © 2012 Alcatel-Lucent

PW Redundancy and MC-LAG Pseudowire redundancy combined with MC-LAG protects both the pseudowire and the CE access interfaces. If the active MC-LAG links become unavailable, the CSA can choose the redundant PE spoke SDP, following the active SAP state. LAG SAP states Shown above, the MC-LAG protocol chooses MLS1 as the active MC-LAG PE. By default, this is the first MC-LAG peer to become operational. MLS1 signals its service SAP and spoke SDP is up, status 0x0. At the same time, MLS2 is the standby MC-LAG PE, and it signals its spoke SDP in standby but its SAP is down, 0x26. CSA1 chooses spoke SDP 1:1 over spoke SDP 2:1 on the merits of the better remote status reported by MLS1. A:CSA1# show service id 1 sdp detail ... =============================================================================== Services: Service Destination Points Details =============================================================================== ------------------------------------------------------------------------------Sdp Id 1:1

-(192.0.2.0)

... Peer Pw Bits

: None

... ------------------------------------------------------------------------------Sdp Id 2:1

-(192.0.2.1)

... Peer Pw Bits

: lacIngressFault lacEgressFault pwFwdingStandby

If the MC-LAG were to change states and the MLS2 LAG became active, then MLS1 would signal its spoke SDP as standby and SAP down, and CSA1 would choose the backup spoke SDP to MLS2, assuming a better status. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 109 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

PW Redundancy and MC-LAG

A:CSA1# A:CSA1# show show router router ldp ldp bindings bindings detail detail ... ... =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Type :: E-Eth VcId :: 11 Type E-Eth VcId SvcId : 1 SdpId :: 11 SvcId : 1 SdpId Peer :: 192.0.2.0 Vc-switching :: No Peer Address Address 192.0.2.0 Vc-switching No LMTU : 1500 RMTU : LMTU : 1500 RMTU : 1500 1500 Egr. :: 131059S Egr. :: No Egr. Lbl Lbl 131059S Egr. Ctl Ctl Word Word No Egr. :: None Egr. Egr. Flags Flags None Egr. Status Status Bits Bits :: Supported Supported (0x0) (0x0) Ing. :: 131070U Ing. :: No Ing. Lbl Lbl 131070U Ing. Ctl Ctl Word Word No Ing. :: None Ing. Ing. Flags Flags None Ing. Status Status Bits Bits :: Supported Supported (0x0) (0x0) ------------------------------------------------------------------------------------------------------------------------------------------------------------Type :: E-Eth VcId :: 11 Type E-Eth VcId SvcId : 1 SdpId :: 22 SvcId : 1 SdpId Peer :: 192.0.2.1 Vc-switching :: No Peer Address Address 192.0.2.1 Vc-switching No LMTU :: 1500 RMTU :: 1500 LMTU 1500 RMTU 1500 Egr. :: 131058D Egr. :: No Egr. Lbl Lbl 131058D Egr. Ctl Ctl Word Word No Egr. :: None Egr. Egr. Flags Flags None Egr. Status Status Bits Bits :: Supported Supported (0x26) (0x26) Ing. :: 131068U Ing. :: No Ing. Lbl Lbl 131068U Ing. Ctl Ctl Word Word No Ing. :: None Ing. Ing. Flags Flags None Ing. Status Status Bits Bits :: Supported Supported (0x0) (0x0) ... ...

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

110

All rights reserved © 2012 Alcatel-Lucent

View the Local PE Spoke SDP States A:NodeA# show router ldp bindings detail  MLS1 signals status 0x0, indicating that both its spoke SDP and SAP are up. Egr. Lbl: - On the egress label for peer 192.0.2.1, “D” indicates the peer signaled the spoke SDP status down, indicating the service SAP is down (standby MC-LAG member) and the service is down. Egr. Status Bits: - Shows the status signaled by the remote PE. Ing. Status Bits: - Shows the local SAP status signaled to the remote PE.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 110 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the Local PE Spoke SDP States

MLS1 SDP1 fails  Spoke SDP 1:1 fails and the local PE moves traffic to the secondary spoke SDP (it will forward as long as the spoke SDP is up)  MLS2’s LAG SAP is still in standby, so MLS2 black-holes packets  SAP state doesn’t follow SDP state Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

111

All rights reserved © 2012 Alcatel-Lucent

PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure Spoke SDP states The configuration shown ties the MC-LAG SAP state to the spoke SDPs, but does it tie the spoke SDP states to the SAP? In other words, a change in the LAG state affects the signaled spoke SDP state, but a change in the spoke SDP state 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).

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 111 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure

A:CSA1# show router ldp bindings detail A:CSA1# show router ldp bindings detail ... ... =============================================================================== =============================================================================== LDP Service FEC 128 Bindings LDP Service FEC 128 Bindings =============================================================================== =============================================================================== ------------------------------------------------------------------------------------------------------------------------------------------------------------Type : E-Eth VcId : 1 Type : E-Eth VcId : 1 SvcId : 1 SdpId : 2 SvcId : 1 SdpId : 2 Peer Address : 192.0.2.1 Vc-switching : No Peer Address : 192.0.2.1 Vc-switching : No LMTU : 1500 RMTU : 1500 LMTU : 1500 RMTU : 1500 Egr. Lbl : 131058D Egr. Ctl Word : No Egr. Lbl : 131058D Egr. Ctl Word : No Egr. Flags : None Egr. Status Bits : Supported (0x26) Egr. Flags : None Egr. Status Bits : Supported (0x26) Ing. Lbl : 131068U Ing. Ctl Word : No Ing. Lbl : 131068U Ing. Ctl Word : No Ing. Flags : None Ing. Status Bits : Supported (0x0) Ing. Flags : None Ing. Status Bits : Supported (0x0) =============================================================================== =============================================================================== No. No. of of VC VC Labels: Labels: 11 ... ...

 The failure on the primary spoke SDP did not cause a signaled status change on the secondary spoke SDP  MLS2 still indicates its SAP is down (0x26) Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

112

All rights reserved © 2012 Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 112 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure (cont)

PW Redundancy and MC-LAG – Spoke SDP 1:1 Failure (cont)

=============================================================================== =============================================================================== Service Basic Information Service Basic Information =============================================================================== =============================================================================== Service Id : 1 Vpn Id : 0 Service Id : 1 Vpn Id : 0 Service Type : Epipe Service Type : Epipe ... ... Admin State : Up Oper State : Down Admin State : Up Oper State : Down MTU : 1514 MTU : 1514 ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points Service Access & Destination Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:lag-2 null 1514 1514 Up sap:lag-2 null 1514 1514 Up Down Down sdp:1:1 Spok 00 1550 Up sdp:1:1 S(192.0.2.2) S(192.0.2.2) Spok 1550 Up Up Up =============================================================================== ===============================================================================

 With the LAG SAP in standby, MLS2 shows its ePipe status down  MLS2 black holes any traffic arriving over the active spoke SDP Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

113

All rights reserved © 2012 Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 113 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS2# show service id 1 base A:MLS2# show service id 1 base

Interchassis Backup Pseudowire (ICB-PW)

SAP SAP icb icb SPOKE SPOKE SPOKE SPOKE icb icb

ePipe ePipe 11 endpoint endpoint SAP SAP sap sap lag-2 lag-2 endpoint endpoint SAP SAP spoke-sdp spoke-sdp 3:1 3:1 endpoint endpoint SAP SAP icb icb endpoint SPOKE endpoint SPOKE spoke-sdp spoke-sdp 1:1 1:1 endpoint endpoint SPOKE SPOKE spoke-sdp spoke-sdp 3:2 3:2 endpoint endpoint SPOKE SPOKE icb icb

Interchassis backup PW ensures last resort path to destination  Used in case all other redundancy fails  Sends traffic between chassis over interchassis spoke SDPs  Each MC peer VPWS includes two endpoints, one for the spoke SDP to CSA1 and one for the MC-LAG SAP, each with a backup spoke SDP Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

114

All rights reserved © 2012 Alcatel-Lucent

Interchassis Backup Pseudowire (ICB-PW) In the previous example, the MC-LAG protected the CE links, and PW redundancy protected the distributed service. However, nothing ties the spoke SDP status to the MC-LAG status, and thus a situation can exist where the local PE chooses to forward traffic to a remote PE which cannot forward it on to the CE. However, SROS supports a special type of PW called an Interchassis Backup PW (ICB-PW), that is used only on routers with multi-chassis protected SAPs. ICB-PW can protect the service and SAPs by providing a path between the MC-LAG PE routers in the case where traffic enters the service on one PE and exits toward the CE on the opposite MC peer. It may be used in ePipe, aPipe, iPipe, or cPipe services. A VPWS has two implicit endpoints, a SAP and a spoke SDP or two SAPs. Forwarding rules state that the switch fabric will only forward traffic between objects in different endpoints. An ICB-PW provides a backup to an object associated with the same endpoint. In the ICB-PW, you must explicitly define the endpoints, as we did on the redundant PWs, but now you must define two. SAP endpoint To create an ICB-PW, one endpoint must contain a LAG (or APS) SAP object. The SAP endpoint can contain an ICB spoke SDP as a backup. Only one endpoint object can be forwarding at a time. SDP endpoint The second endpoint contains the remote PE spoke SDP. It can contain an ICB spoke SDP as a backup, as well. When the service is configured, it contains two endpoints, one for the SAP and its backup, and one for the remote spoke SDP and its backup. Both backup spoke SDPs terminate on the MC peer PE. ICB endpoints An ICB-PW in endpoint SAP on PE1 must cross connect to endpoint SPOKE on PE2, and the ICB-PW on endpoint SAP on PE2 must cross connect to endpoint SPOKE on PE1. For example, on PE1 and PE2 you create two spoke-SDPs, 3:1 and 3:2. Knowing that the VC-IDs on the spoke SDPs must match on each end, you use 3:1 as the ICB-PW for 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 114 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ePipe ePipe 11 endpoint endpoint SAP SAP sap sap lag-2 lag-2 endpoint endpoint SAP SAP spoke-sdp spoke-sdp 3:2 3:2 endpoint endpoint endpoint SPOKE endpoint SPOKE spoke-sdp spoke-sdp 1:1 1:1 endpoint endpoint spoke-sdp spoke-sdp 3:1 3:1 endpoint endpoint

Both the primary spoke SDP and LAG member are up  Traffic flows over the primary path  Inter-chassis spoke SDPs not used  Traffic only flows from one endpoint to another, never within an endpoint Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

115

All rights reserved © 2012 Alcatel-Lucent

ICP-PW – Normal operations Here we see that both the primary spoke SDP and LAG members are up. Traffic only flows from endpoint to endpoint, and only one endpoint object forwards traffic at a time. The local PE, CSA1, does not forward traffic down its secondary spoke SDP, and all of MLS2’s spoke SDP and SAP are in standby. (notes continued on next page...)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 115 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ICB-PW – Normal operations

A:CSA1# A:CSA1# show show router router ldp ldp bindings bindings detail detail ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Type :: E-Eth VcId :: 11 Type E-Eth VcId SvcId : 1 SdpId :: 11 SvcId : 1 SdpId Peer :: 192.0.2.0 Vc-switching :: No Peer Address Address 192.0.2.0 Vc-switching No LMTU :: 1500 RMTU :: 1500 LMTU 1500 RMTU 1500 Egr. :: 131054S Egr. :: No Egr. Lbl Lbl 131054S Egr. Ctl Ctl Word Word No Egr. :: None Egr. Egr. Flags Flags None Egr. Status Status Bits Bits :: Supported Supported (0x0) (0x0) Ing. :: 131067U Ing. :: No Ing. Lbl Lbl 131067U Ing. Ctl Ctl Word Word No Ing. :: None Ing. Ing. Flags Flags None Ing. Status Status Bits Bits :: Supported Supported (0x0) (0x0) ------------------------------------------------------------------------------------------------------------------------------------------------------------Type :: E-Eth VcId :: 11 Type E-Eth VcId SvcId : 1 SdpId :: 22 SvcId : 1 SdpId Peer :: 192.0.2.1 Vc-switching :: No Peer Address Address 192.0.2.1 Vc-switching No LMTU :: 1500 RMTU :: 1500 LMTU 1500 RMTU 1500 Egr. :: 131059D Egr. :: No Egr. Lbl Lbl 131059D Egr. Ctl Ctl Word Word No Egr. :: None Egr. Egr. Flags Flags None Egr. Status Status Bits Bits :: Supported Supported (0x20) (0x20) Ing. Lbl : 131070U Ing. Ctl Word : No Ing. Lbl : 131070U Ing. Ctl Word : No Ing. :: None Ing. Ing. Flags Flags None Ing. Status Status Bits Bits :: Supported Supported (0x0) (0x0) -------------------------------------------------------------------------------------------------------------------------------------------------------------

 MLS2 sends status 0x20, Pseudowire Forwarding SAP in Standby, rather than 0x26 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

116

All rights reserved © 2012 Alcatel-Lucent

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

: None

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 116 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ICB-PW - Normal Operations (cont)

A:MLS2# A:MLS2# show show service service id id 11 base base ... ... Admin :: Up Oper :: Up Admin State State Up Oper State State Up ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:lag-2 null 1514 1514 Up sap:lag-2 null 1514 1514 Up Down Down sdp:1:1 Spok 00 1550 Up sdp:1:1 S(192.0.2.2) S(192.0.2.2) Spok 1550 Up Up Up sdp:3:1 Spok 00 1550 Up sdp:3:1 S(192.0.2.0) S(192.0.2.0) Spok 1550 Up Up Up sdp:3:2 S(192.0.2.0) Spok 0 1550 Up sdp:3:2 S(192.0.2.0) Spok 0 1550 Up Up Up =============================================================================== ===============================================================================

 Though the SAP is down, the MLS2 ePipe service remains operationally Up  Note the three spoke SDP bindings, two of which terminate as ICB PWs on MLS1 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

117

All rights reserved © 2012 Alcatel-Lucent

ICB-PW Normal Operations (cont) MLS1 shows the LAG SAP and all three spoke spoke SDPs up. A:MLS1# show service id 1 base ... Admin State

: Up

Oper State

: Up

... ------------------------------------------------------------------------------Service Access & Destination Points ------------------------------------------------------------------------------Identifier

Type

AdmMTU

OprMTU

Adm

Opr

------------------------------------------------------------------------------sap:lag-2

null

1514

1514

Up

Up

sdp:1:1 S(192.0.2.2)

Spok

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

===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 117 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ICB-PW - Normal Operations (cont)

The Primary Spoke SDP fails  CSA1 moves traffic to the backup spoke SDP  MLS1 is still the active MC-LAG member  Traffic flows from MLS2 endpoint SPOKE to endpoint SAP, across the SAP ICB-PW, then SPOKE to SAP and on to the CE Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

118

All rights reserved © 2012 Alcatel-Lucent

ICP-PW – Primary Spoke SDP fails, MLS1 LAG active Previously, a failure on SDP1 resulted in lost data at MLS2. Now, the ICB-PW between MLS2 and MLS1 provides a last resort path to the CE devices. A:CSA1# show service id 1 sdp detail ... Sdp Id 1:1 -(192.0.2.0) ... Flags : SdpOperDown NoIngVCLabel NoEgrVCLabel Peer Pw Bits : None ... Sdp Id 2:1 -(192.0.2.1) ... Flags : None Peer Pw Bits : pwFwdingStandby ... • The MLS2 LAG SAP is still in standby. A:MLS2# show service id 1 base ... Service Access & Destination Points ------------------------------------------------------------------------------Identifier Type AdmMTU OprMTU Adm Opr ------------------------------------------------------------------------------sap:lag-2 null 1514 1514 Up Down sdp:1:1 S(192.0.2.2) Spok 0 1550 Up Up sdp:3:1 S(192.0.2.0) Spok 0 1550 Up Up sdp:3:2 S(192.0.2.0) Spok 0 1550 Up Up ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 118 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ICB-PW – Primary Spoke SDP fails, MLS1 LAG active

ICB-PW – Primary Spoke SDP fails, MLS1 LAG active (cont) =============================================================================== =============================================================================== Service Service 11 endpoints endpoints =============================================================================== =============================================================================== Endpoint :: SAP Endpoint name name SAP ... ... Tx :: lag-2 Tx Active Active lag-2 ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------SAP :: lag-2 Oper SAP lag-2 Oper Status: Status: Up Up Spoke-sdp: 3:2 Prec:4 (icb) Oper Status: Spoke-sdp: 3:2 Prec:4 (icb) Oper Status: Up Up =============================================================================== =============================================================================== Endpoint :: SPOKE Endpoint name name SPOKE ... ... Tx :: 3:1 Tx Active Active (SDP) (SDP) 3:1 ... ... ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 1:1 1:1 Prec:4 Prec:4 Oper Status: Status: Down Down Spoke-sdp: Oper Spoke-sdp: 3:1 3:1 Prec:4 Prec:4 (icb) (icb) Oper Status: Status: Up Up

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

119

All rights reserved © 2012 Alcatel-Lucent

ICB-PW – Primary Spoke SDP fails, MLS1 LAG active (cont) MLS1 SAP endpoint ICB PW, SDP 3:1, becomes active as a result of the primary SDP failure. SAP LAG-2 is still the active MC-LAG member. MLS2 MLS2 SAP LAG-2 is down, however, its SAP endpoint ICB-PW, SDP 3:1, is active, providing a path for traffic entering on the active secondary SDP to the active LAG member SAP on MLS1. A:MLS2# show service id 1 endpoint =============================================================================== Service 1 endpoints =============================================================================== Endpoint name

: SAP

... Tx Active (SDP)

: 3:1

... ------------------------------------------------------------------------------Members ------------------------------------------------------------------------------SAP

: lag-2

Spoke-sdp: 3:1 Prec:4 (icb)

Oper Status: Down Oper Status: Up

===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 119 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show service service id id 11 endpoint endpoint

Configuring ICB-PW

Syntax: Syntax:

[no] [no] endpoint endpoint [no] [no] spoke-sdp spoke-sdp endpoint endpoint icb icb create create

Example: Example: config>service>epipe# config>service>epipe# endpoint endpoint SAP SAP create create config>service>epipe>endpoint$ config>service>epipe>endpoint$ back back config>service>epipe# config>service>epipe# sap sap lag-2 lag-2 endpoint endpoint SAP SAP create create config>service>epipe>sap$ config>service>epipe>sap$ back back config>service>epipe# config>service>epipe# spoke-sdp spoke-sdp 3:1 3:1 endpoint endpoint SAP SAP icb icb create create config>service>epipe>spoke-sdp$ config>service>epipe>spoke-sdp$ back back config>service>epipe# config>service>epipe# endpoint endpoint SPOKE SPOKE create create config>service>epipe>endpoint$ config>service>epipe>endpoint$ back back config>service>epipe# config>service>epipe# spoke-sdp spoke-sdp 1:1 1:1 endpoint endpoint SPOKE SPOKE create create config>service>epipe>spoke-sdp$ back config>service>epipe>spoke-sdp$ back config>service>epipe# config>service>epipe# spoke-sdp spoke-sdp 3:2 3:2 endpoint endpoint SPOKE SPOKE icb icb create create

 Create the endpoints with 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

120

All rights reserved © 2012 Alcatel-Lucent

Configuring ICB-PW ICB-PW should only be used with PW redundancy and MC-LAG or MC-APS on the edge PE routers. Endpoint Two explicit endpoints must be created, one to protect the SAP and one to protect the remote PE PW. The local PE only forwards traffic between endpoints, and only one object per endpoint may be forwarding traffic. ICB Spoke SDP Binding Creation You must first create the protected SAP or spoke SDP, then create the ICB PW. You use the icb keyword in the spoke SDP context. A:NodeA>config>service>epipe# spoke-sdp 3:1 endpoint SPOKE icb create  Precedence ICB PW have the lowest precedence of all spoke SDPs. This is not configurable. Configuration on the MC Peer PE The MC peer PE requires a similar configuration, noting that the spoke SDPs have to terminate in opposite endpoints than those on which they were created.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 120 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Context: Context: config>service>epipe config>service>epipe

A:MLS1# A:MLS1# show show service service id id 11 endpoint endpoint ... ... =============================================================================== =============================================================================== Service Service 11 endpoints endpoints =============================================================================== =============================================================================== Endpoint :: SPOKE Endpoint name name SPOKE Description :: (Not Description (Not Specified) Specified) Revert time : 0 Revert time : 0 Act :: 00 Act Hold Hold Delay Delay Standby Signaling Master : Standby Signaling Master : false false Standby :: false Standby Signaling Signaling Slave Slave false Tx :: 1:1 Tx Active Active (SDP) (SDP) 1:1 Tx :: 0d Tx Active Active Up Up Time Time 0d 02:18:24 02:18:24 Revert :: N/A Revert Time Time Count Count Down Down N/A Tx :: 12 Tx Active Active Change Change Count Count 12 Last :: 08/16/2011 Last Tx Tx Active Active Change Change 08/16/2011 10:38:25 10:38:25 ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 1:1 1:1 Prec:4 Prec:4 Oper Status: Status: Up Up Spoke-sdp: Oper Spoke-sdp: 3:1 3:1 Prec:4 Prec:4 (icb) (icb) Oper Status: Status: Up Up =============================================================================== =============================================================================== =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

121

All rights reserved © 2012 Alcatel-Lucent

View the MLS1 SPOKE Endpoint Status – Normal operations A:NodeA# show service id 1 endpoint  Tx Active: – Shows the active spoke SDP. In this example, the primary 1:1 is active. Tx Active Up Time: - How long the active spoke SDP has been up. Tx Active Change Count: - How often the active spoke SDP has changed. Members: - List the spoke SDPs that are members in the endpoint object. Only one endpoint object can be forwarding at a time, and the ICB spoke SDP has the lowest precedence.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 121 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the MLS1 SPOKE endpoint status – Normal operations

A:MLS1# A:MLS1# show show service service id id 11 endpoint endpoint ... ... =============================================================================== =============================================================================== Service Service 11 endpoints endpoints =============================================================================== =============================================================================== Endpoint :: SPOKE Endpoint name name SPOKE Description :: (Not Description (Not Specified) Specified) Revert :: 00 Revert time time Act :: 00 Act Hold Hold Delay Delay Standby :: false Standby Signaling Signaling Master Master false Standby :: false Standby Signaling Signaling Slave Slave false Tx :: 3:1 Tx Active Active (SDP) (SDP) 3:1 Tx :: 0d Tx Active Active Up Up Time Time 0d 00:00:01 00:00:01 Revert :: N/A Revert Time Time Count Count Down Down N/A Tx :: 13 Tx Active Active Change Change Count Count 13 Last Tx Active Change : Last Tx Active Change : 08/16/2011 08/16/2011 13:12:31 13:12:31 ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 1:1 1:1 Prec:4 Prec:4 Oper Status: Status: Down Down Spoke-sdp: 3:1 Prec:4 (icb) Oper Status: Spoke-sdp: 3:1 Prec:4 (icb) Oper Status: Up Up

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

122

All rights reserved © 2012 Alcatel-Lucent

View the MLS1 SPOKE Endpoint Status – Primary Spoke SDP failed A: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 Status MLS2’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: Down Spoke-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: Up Spoke-sdp: 3:2 Prec:4 (icb) Oper Status: Up =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 122 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the MLS1 SPOKE endpoint status – Primary Spoke SDP failed

   

PW redundancy protects the S-PEs ICB-PW protects the POC1 T-PEs MC-LAG or MC-APS protects the NC elements and access ports PW switching allows TE across areas, and increases scalability

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

123

All rights reserved © 2012 Alcatel-Lucent

PW Redundancy, PW Switching, and ICB-PW - MC-LAG Access The Model 2 network may include all the techniques discussed in this section to provide reliability and scalability. Configured on CSA1 are redundant PWs terminated at the POC3 routers. SDP1 follows the UPPER links, as configured in the MPLS section in M2, and SDP2 follows the LOWER links. POC3-1 and POC3-2 are configured as S-PEs for the redundant, switched spoke SDPs. POC3-1 spoke SDP 4:2 follows the UPPER links on its primary LSP path, and the LOWER links on its standby path. POC3-2 spoke SDP 4:2 follows the LOWER links, then the UPPER. FRR protects all the LSPs, with manual bypass tunnels configured on the POC3 routers to keep aggregation ring traffic off of the access ring. POC2-1 and POC2-2 act only as LSRs. MLS1 and MLS2 (POC1-1 and POC1-2) terminate the VPWS service. They include LSPs and SDPs terminated on the opposite MLS router to support the ICB-PWs. FRR protects the LSPs, but they include no standby paths. An MC-LAG is configured to protect the ePipe service access interfaces, with MLS1 configured as the preferred active MC peer.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 123 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

PW Redundancy, PW Switching and ICB-PW - MC-LAG Access

Automatic Protection Switching (APS) is designed to protect SONET/SDH equipment from ring or linear unidirectional or bidirectional failures  The NEs monitor the network health  Upon failure detection, the network quickly switches over live traffic to a backup, or protection, facility  SROS facility is the physical line and line terminating hardware Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

124

All rights reserved © 2012 Alcatel-Lucent

Automatic Protection Switching APS is designed to protect SONET/SDH lines from ring linear uni or bi-directional failures. The Network Elements (NEs) in a SONET/SDH network constantly monitor the network. They can recognize faults on the active circuit, called the “working” facility, by monitoring the bits in the SONET/SDH header K1 and K2 bytes. These bits indicate alarm conditions and switch requests. When a node detects a failure, the network proceeds through a coordinated, predefined sequence of steps to transfer (or switchover) live traffic to the backup facility (called “protection” facility.) This is done very quickly to minimize lost traffic. Traffic remains on the protection facility until the working facility fault is cleared, at which time the traffic may optionally be reverted to the working facility. 1+1, 1:n, 1:1 These terms represent the protection scheme employed on a SONET/SDH circuit. •1+1 - Each working circuit has a dedicated protection circuit, and the same traffic travels both. They 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Section 6 · PageModule 124 3 - Page 124 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Automatic Protection Switching (APS)

The SONET line overhead and SDH multiplex section overhead K1 and K2 bytes carry APS protocol messages • K1 bits 1-4 to request switch • K2 bits 6-8 to indicate status • Sent on protection circuit

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

125

All rights reserved © 2012 Alcatel-Lucent

Linear APS Signaling The SONET/SDH K1 and K2 bytes signal APS protocol messages. The table on the next page lists the SONET/SDH linear APS messages. Either node can initiate a switch, by sending a request down the protection circuit. A switch can also occur in the case of Loss of Signal (LOS), Loss of Frame (LOF), detected Alarm Indication Signal (AIS), or a line Bit Error Rate > 10^3. This signaling channel also keeps the two nodes synchronized. MC-APS Signaling When running MC-APS, the protect router selects the working circuit. To keep the working and protect routers synchronized, they maintain a UDP transported Multi-chassis Sync (MCS) session over a routed interface. MCS ensures consistent configuration between chassis  Group membership and configuration  Ensures one side is configured as working and the other protection  Synchronizes working circuit status between the routers  Ensures the working router knows when the protection router has changed the working circuit selection

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Section 6 · PageModule 125 3 - Page 125 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Linear APS Signaling

Bidirectional 1+1 APS  One protection link for each working link  APS protects circuits on a port by port basis  APS links may transport IMA or ML-PPP bundled traffic  SROS Default

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

127

All rights reserved © 2012 Alcatel-Lucent

Bi-Directional APS 1+1 The APS standard, ANSI T1.105.01-2000, mandates that when using the 1+1 architecture, the active OC-N/STM signal is permanently transmitted to both the working and protection ports so that in the egress direction the same payloads are transmitted identically on both ports. For efficiency, SROS does not transmit the same payload on the standby port that we transmit on the active port. If an ADM measures for quality (and switch-over) purposes, then this measurement will perform equally well on the idle stream. In bi-directional mode:  A failure of the signal in either direction causes both near-end and far-end equipment to switch to the protecting lines  The highest priority local request is compared to the remote request (received from the far-end node using an APS command), and whichever has the greater priority is selected The APS priority requests are: 1 – Lockout of protect port 2 – Forced switch 3 – Signal failure – low priority 4 – Signal degradation – low priority 5 – Manual switch

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Section 6 · PageModule 127 3 - Page 127 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Bi-Directional APS 1+1

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

128

All rights reserved © 2012 Alcatel-Lucent

Single Chassis APS Options Same IOM/MDA In this configuration, APS protects the physical port. The working and protection facilities are on different ports. Same IOM/Different MDA APS protects both the port and the MDA. The protection facility protects against a failure on the working port or its host MDA. Different IOM/Different MDA APS protects the port, MDA, and IOM. Any combination of the three, including all three, are protected.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Section 6 · PageModule 128 3 - Page 128 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Single Chassis APS Options

Multi-Chassis 1+1 APS protects from physical link and node failures  Provides stateful ML-PPP protection, even across two different physical routers (MC-APS)  Synchronization across two SRs maintained using Multi-Chassis synchronization (MCS)  Maintains existing ML-PPP signaling sessions

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

129

All rights reserved © 2012 Alcatel-Lucent

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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Section 6 · PageModule 129 3 - Page 129 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Multi-Chassis APS (MC-APS)

Configuring MC-APS Context: Context: config>port config>port aps- aps-

Context: Context: config>port>aps config>port>aps Syntax: Syntax:

[no] [no] neighbor neighbor [no] protect-circuit [no] protect-circuit [no] [no] working-circuit working-circuit [no] [no] revert-time revert-time [no] [no] hold-time hold-time

Example: Example: config# config# port port aps-1 aps-1 config>port$ config>port$ aps aps config>port>aps$ config>port>aps$ neighbor neighbor 192.0.2.1 192.0.2.1 config>port>aps$ config>port>aps$ revert-time revert-time 99 config>port>aps$ config>port>aps$ hold-time hold-time 70 70 config>port>aps$ working-circuit config>port>aps$ working-circuit 1/2/1 1/2/1 config>port>aps$ config>port>aps$ back back config>port$ config>port$ no no shutdown shutdown

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

130

All rights reserved © 2012 Alcatel-Lucent

Configuring MC-APS First, you create the logical APS group, where the possible range is 1-64: A:NodeA>config# port aps-1  Then, identify the neighbor. This must be an IP-reachable address: A:NodeA>config>port$ aps  A:NodeA>config>port>aps$ neighbor 192.0.2.1  Depending on the node’s role, configure either the working or protection circuit: A:NodeA>config>port>aps$ working-circuit 1/2/1  Or A:NodeA>config>port>aps$ protect-circuit 1/2/1  You may adjust the revert and hold time values, depending on the design. •revert-time – A value, in minutes, that determines how long the router waits to switch traffic back to the working circuit once it recovers. The default is 5 minutes, and the values are 0-60 minutes. •hold-time – Specifies the time, in 100s of milliseconds, the router waits after failing to receive an advertisement from the neighbor before determining the multi-chassis link is down. The values are 10-650. The hold time is normally 3 times the advertise interval, which determines how frequently the neighbors tell each other, in 100s of millseconds, that they are operational. The default advertise interval is 10. Finally, turn up the APS group.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 130 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Syntax: Syntax:

Verifying MC-APS

=============================================================================== =============================================================================== APS APS Group Group Info Info =============================================================================== =============================================================================== Interface Tx/Rx Interface Admin/Oper Admin/Oper MC-Ctl MC-Ctl Work|Work1 Work|Work1 Prot|Work2 Prot|Work2 Active Active Tx/Rx State State Circuit Circuit Circuit K1 State State Circuit Circuit Circuit K1 Byte Byte ------------------------------------------------------------------------------------------------------------------------------------------------------------aps-1 Up/Up Up 1/2/1 N/A 1/2/1 N/A aps-1 Up/Up Up 1/2/1 N/A 1/2/1 N/A =============================================================================== =============================================================================== Interface Interface -- aps- aps- [] [] -- applies applies to to APS APS Annex Annex BB only: only: LL -- lockout lockout Circuit -- // Circuit // [] [] -- applies applies to to APS APS Annex Annex BB only: only: PP -- primary UU -- up primary up SS -- secondary DD -- down secondary down =============================================================================== ===============================================================================

 Active circuit shows port number on active working or protection node  Active circuit N/A if opposite peer’s circuit is active Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

131

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Verifying APS A:NodeA# show aps aps-1  •MC-Ctl State: - Indicates the MCS is up. •Work|Work1 Circuit – Indicates the working circuit ID. •Prot|Work2 Circuit – Indicates the physical port that acts as the protection circuit ID. •Active Circuit – Indicates the current active circuit. For MC-APS, shows N/A if the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 131 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show aps aps aps-1 aps-1

A:MLS1>config# A:MLS1>config# port port aps-1 aps-1 A:MLS1>config>port# A:MLS1>config>port# info info --------------------------------------------------------------------------------------aps aps neighbor neighbor 192.0.2.1 192.0.2.1 hold-time hold-time 70 70 revert-time revert-time 99 working-circuit working-circuit 1/2/1 1/2/1 exit exit sonet-sdh sonet-sdh path path atm atm exit exit no no shutdown shutdown exit exit exit exit no no shutdown shutdown

Within APS group context  Neighbor is system ID, loopback, or other IP reachable address  One chassis hosts the working circuit and the other the protect circuit Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

A:MLS2>config# A:MLS2>config# port port aps-1 aps-1 A:MLS2>config>port# A:MLS2>config>port# info info --------------------------------------------------------------------------------------aps aps neighbor neighbor 192.0.2.0 192.0.2.0 hold-time hold-time 70 70 revert-time revert-time 99 protect-circuit protect-circuit 1/2/1 1/2/1 exit exit sonet-sdh sonet-sdh path path atm atm exit exit no no shutdown shutdown exit exit exit exit no no shutdown shutdown Module 3 |

132

All rights reserved © 2012 Alcatel-Lucent

MC-APS for ATM Ports You will configure the peer addresses in the APS group. This address must be IP reachable. One neighbor must specify the working circuit while the other specifies the protect circuit.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 132 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MC-APS for ATM Ports

   

PW redundancy protects the S-PEs ICB-PW protects the POC1 T-PEs MC-APS protects the NC elements and access ports PW switching allows TE across areas, and increases scalability

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

133

All rights reserved © 2012 Alcatel-Lucent

PW Redundancy, PW Switching and ICB-PW - MC-APS Access As with the MC-LAG configuration, the MLS routers signal the SAP state, active or standby, in the PW status bits. POC3-1 forwards the status it receives from the T-PE routers. A change in the MLS signaled PW status will influence the CSA routers’ choice of active PW.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 133 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

PW Redundancy, PW Switching and ICB-PW - MC-APS Access

Section Review In this section, we :

 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

134

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 134 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Implemented pseudowire switching to support traffic engineering and control FIB sizes across IGP areas

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 6 — Model 2 ePipe and Distributed VPRN for Ethernet Services

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 135 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives In this section, we will:

 Observe the active ePipe pseudowire controlling the POC3 VPRN interface states

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

136

All rights reserved © [year] Alcatel-Lucent

Module 3 - Page 136 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Review the Model 2 ePipe and distributed VPRN configuration for 3 and 4G voice, data, and control

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

137

All rights reserved © 2012 Alcatel-Lucent

Model 2 – ePipes and VPRN for 3G and LTE Ethernet Traffic As we learned, the Model 2 subtended ring Model transported Ethernet backhaul traffic over redundant ePipes connected to a distributed VPRN via spoke SDP interfaces. The VPRN endpoints are the POC3 and POC1 routers. At the POC 1 router, interchassis LAG interfaces support VPRN route updates and L3 redundancy. VRRP protects some NC facing interfaces. If the NC element includes an L2 switch function, there is no need for separate VRRP-supporting VPLS on the MLS routers. If necessary, additional VPLS may be provisioned to support VRRP signaling, as we learned in the previous section.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 137 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 – ePipes and VPRN for 3G and LTE Ethernet Traffic

CSA-POC3 ePipes carry 3 and 4G Ethernet traffic to distributed VPRN  PW redundancy on the CSA  POC3 and POC1 (MLS) routers are VPRN PEs  Standby-signaling-master on redundant PW take down redundant VPRN interface  VRRP on RNC interfaces Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

138

All rights reserved © 2012 Alcatel-Lucent

Model 2 3G and 4G ePipes and VRPN Services - Overview The overview above shows the services and service features used to support 3G and 4G voice, data and OAM traffic in the Model 2 distributed VPRN service design. CSA1 to POC3 ePipes On the CSA1 router, the ePipe uses redundant spoke SDPs to tie into the POC3 router VPRN interfaces. Enabled on the ePipe endpoint is standby-signaling-master, which causes the CSA to signal the standby secondary SDP state to the POC3 routers. This causes the POC3 router on which the standby spoke SDP terminates to take down the associated VPRN interface and block traffic destined for the NodeB. POC1-POC3 VPRN The distributed VPRN delivers routed traffic to and from the NodeB and the RNC, other NC and EPC elements, and external networks. The POC2 routers serve only as LSRs, and are not service aware. A unique route-distinguisher is set within each 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. Router-Specific Configurations  Redundant pseudowires are configured on the CSA router.  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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 138 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 3G and 4G ePipes and VRPN Services - Overview

 The POC3 VPRN interfaces are spoke SDPs to the CSA ePipes  The CSA active spoke SDP determines the active VPRN interface, standby-signaling-master on the endpoint  The VPRN “to NodeB” interfaces share the same IP address  MP-BGP distributes the active static route so the MLS routers know the active path to the NodeB loopback interface Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

139

All rights reserved © 2012 Alcatel-Lucent

Model 2 – POC3 VPRN Interfaces The CSA ePipes terminate into the POC3 router distributed VPRN interfaces. Since only one spoke SDP is active, only one of the POC3 NodeB interfaces is active. Routing toward the BS On each of the two POC3 routers, static routes define the path to the 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 =============================================================================== Interface Table (Service: 5) =============================================================================== Interface-Name

Adm

Opr(v4/v6)

Mode

IP-Address

Port/SapId PfxState

------------------------------------------------------------------------------toNodeB

Up

192.0.2.182/30

Down/--

VPRN

spoke-2:50 n/a

------------------------------------------------------------------------------Interfaces : 1 ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 139 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 – POC3 VPRN Interfaces

A:POC3-1>config>service>vprn# A:POC3-1>config>service>vprn# info info ------------------------------------------------------------------------------------------route-distinguisher route-distinguisher 65100:150 65100:150 vrf-target vrf-target target:65100:50 target:65100:50 interface interface "to "to NodeB" NodeB" create create address address 192.0.2.182/30 192.0.2.182/30 spoke-sdp spoke-sdp 2:50 2:50 create create no no shutdown shutdown exit exit exit exit static-route static-route 198.51.100.0/29 198.51.100.0/29 black-hole black-hole static-route static-route 198.51.100.3/32 198.51.100.3/32 next-hop next-hop 192.0.2.181 192.0.2.181 spoke-sdp spoke-sdp 33 create create no no shutdown shutdown exit exit spoke-sdp spoke-sdp 44 create create no no shutdown shutdown exit exit no no shutdown shutdown -------------------------------------------------------------------------------------------

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

140

All rights reserved © 2012 Alcatel-Lucent

View the POC3-1 VPRN Configuration Black hole static routes The VPRN black hole static routes ensure the VPRN PE routers have an active route to the NodeB loopback interface during failure transition from the active to the standby pseudowire. Assumed is that the entire MLS router chassis has gone offline, causing the CSA router to move traffic to the secondary spoke SDP. While MP-BGP converges, the MLS routers can route traffic based on the POC3 routeradvertised black hole static route. POC3-2 advertises a more specific black hole route than does POC3-1. Since POC3-2 protects POC3-1, NodeB traffic should route to POC3-2. Likewise, if ePipe traffic travels through POC3-2 and POC3-1 SDPs have recovered, once MP-BGP has converged, NodeB traffic will once again flow to POC3-1. Avoiding black holed traffic on recovery To avoid black holed NodeB traffic on recovery, or in the case of rapid, intermittent failures on the primary spoke SDP, you can set a revert time on the ePipe endpoint. A:NodeA# configure service epipe 50 endpoint epipe50 revert-time infinite  Additionally, setting a revert time of infinite keeps traffic on the secondary spoke SDP until you force traffic back to the primary SDP. A:NodeA# clear service id 50 spoke-sdp 2:50 ingress-vc-label 

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 140 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the POC3-1 VPRN Configuration

A:POC3-2# A:POC3-2# show show service service id id 55 interface interface "toNodeB" "toNodeB" detail detail ...output ...output truncated truncated ------------------------------------------------------------------------------------------------------------------------------------------------------------Interface Interface ------------------------------------------------------------------------------------------------------------------------------------------------------------If :: to If Name Name to NodeB NodeB Admin Oper :: Down/-Admin State State :: Up Up Oper (v4/v6) (v4/v6) Down/-Down Down Reason Reason Code: Code: assocObjNotReady assocObjNotReady Protocols :: None Protocols None IP Address :: Primary IP Addr/mask Addr/mask :: 192.0.2.182/30 192.0.2.182/30 Address Type Type Primary ... ... SDP :: spoke-2:50 SDP Id Id spoke-2:50 Spoke-SDP Spoke-SDP Details Details Admin Admin State State :: Up Up Hash :: Disabled Hash Label Label Disabled Peer Peer Fault Fault Ip: Ip: None None Peer :: pwFwdingStandby Peer Pw Pw Bits Bits pwFwdingStandby Peer Peer Vccv Vccv CV CV Bits Bits :: lspPing lspPing Peer Peer Vccv Vccv CC CC Bits Bits :: mplsRouterAlertLabel mplsRouterAlertLabel Flags :: None Flags None

Oper :: Up Oper State State Up Hash Hash Lbl Lbl Sig Sig Cap Cap :: Disabled Disabled

 POC3-2 interface “to NodeB” is operationally down since the spoke SDP is in standby Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

141

All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 141 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the POC3-2 “to NodeB” Interface

Active SDP Failure Scenario – CSA2 Chooses New Active PW

=============================================================================== =============================================================================== Service Service 50 50 endpoints endpoints =============================================================================== =============================================================================== Endpoint :: epipe50 Endpoint name name epipe50 ... ... Tx :: 2:50 Tx Active Active 2:50 Tx :: 0d Tx Active Active Up Up Time Time 0d 00:02:10 00:02:10 Revert :: N/A Revert Time Time Count Count Down Down N/A Tx :: 30 Tx Active Active Change Change Count Count 30 Last :: 10/03/2011 Last Tx Tx Active Active Change Change 10/03/2011 07:30:57 07:30:57 ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 1:50 1:50 Prec:0 Prec:0 Oper Status: Status: Down Down Spoke-sdp: Oper Spoke-sdp: 2:50 2:50 Prec:4 Prec:4 Oper Status: Status: Up Up =============================================================================== =============================================================================== =============================================================================== ===============================================================================

 CSA2 signals the standby spoke SDP as active  POC3-2 brings up its VPRN interface  POC1-1 replaces the POC3-1 NodeB route with the POC3-2 route Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

142

All rights reserved © 2012 Alcatel-Lucent

Active SDP Failure Scenario – CSA2 Chooses New Active PW POC3-1 hosts the active interface. The active interface status is tied to the active spoke SDP status. 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 NodeB traffic while POC1-1 waits for the more specific route from POC3-2. 3. CSA2 signals the secondary SDP as active. 4. POC3-2 brings up its NodeB interface and activates its static route. 5. POC3-2 MP-BGP advertises the NodeB /32 route to POC1-1. 6. POC1-1 forwards the NodeB traffic to POC3-2 using the more specific route.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 142 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA2# A:CSA2# show show service service id id 50 50 endpoint endpoint

Active SDP Failure Scenario – POC3-2 Interface

=============================================================================== =============================================================================== Interface Interface Table Table (Service: (Service: 5) 5) =============================================================================== =============================================================================== Interface-Name Adm Opr(v4/v6) Port/SapId Interface-Name Adm Opr(v4/v6) Mode Mode Port/SapId IP-Address PfxState IP-Address PfxState ------------------------------------------------------------------------------------------------------------------------------------------------------------to Up Up/-VPRN spoke-2:50 to NodeB NodeB Up Up/-VPRN spoke-2:50 192.0.2.182/30 n/a 192.0.2.182/30 n/a ------------------------------------------------------------------------------------------------------------------------------------------------------------Interfaces Interfaces :: 22 =============================================================================== ===============================================================================

 CSA2 signals the standby SDP as active  POC3-2 brings up its VPRN interface  POC1-1 replaces the POC3-1 NodeB route with the POC3-2 route Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

143

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 143 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:POC3-2# A:POC3-2# show show router router 55 interface interface

A:POC1-1# A:POC1-1# show show router router 55 route-table route-table =============================================================================== =============================================================================== Route Route Table Table (Service: (Service: 5) 5) =============================================================================== =============================================================================== Dest Type Proto Age Pref Dest Prefix Prefix Type Proto Age Pref Next Metric Next Hop[Interface Hop[Interface Name] Name] Metric ------------------------------------------------------------------------------------------------------------------------------------------------------------192.0.2.56/29 Local Local 01h07m04s 00 192.0.2.56/29 Local Local 01h07m04s To_RNC 00 To_RNC 192.0.2.180/30 Remote 170 192.0.2.180/30 Remote BGP BGP VPN VPN 00h02m02s 00h02m02s 170 192.0.2.1 00 192.0.2.1 198.51.100.0/31 Remote 170 198.51.100.0/31 Remote BGP BGP VPN VPN 00h49m56s 00h49m56s 170 192.0.2.1 00 192.0.2.1 198.51.100.3/32 Remote 170 198.51.100.3/32 Remote BGP BGP VPN VPN 00h02m02s 00h02m02s 170 192.0.2.1 00 192.0.2.1 ------------------------------------------------------------------------------------------------------------------------------------------------------------No. No. of of Routes: Routes: 44 =============================================================================== ===============================================================================

 CSA2 signals the standby SDP as active  POC3-2 brings up its VPRN interface  POC1-1 replaces the POC3-1 NodeB route with the POC3-2 route Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

144

All rights reserved © 2012 Alcatel-Lucent

Active SDP Failure Scenario – New NodeB Route A:NodeA# show router 5 route-table  Upon a POC3-1 nodal failure or restart for maintenance, POC1-1 replaces the POC3-1 NodeB route with the new route learned from POC3-2. With BGP enable-peer-tracking on, POC1-1 removed the POC3-1 route as soon as the IGP removed its route to the next hop. POC1-1 depends on the standard BGP timers to insert the new /32 route:  Minimum Route Advertisement Interval (MRAI) – In seconds, range 1-255. This minimum interval, in seconds, at which a router can advertise a prefix to its peer. Set to the default of 30 seconds.  Keep-alive timer – In seconds, range 0-21854. Determines how often a router sends a keepalive to its peer. Set to the default, 30 seconds.  Hold timer – In seconds, range 0 or 3-65535, usually set to 3 times the keep alive timer. Specifies the maximum time BGP waits between successive keepalive or update messages before closing the peer connection.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 144 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Active SDP Failure Scenario – New NodeB Route

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

145

All rights reserved © 2012 Alcatel-Lucent

Model 1 3G/4G ePipes and Distributed VPRN – Detailed View CSA1 – On the ePipe endpoint, standby-signaling-master ensures only one POC3 VPRN interface is active. POC3 VPRN – The POC3 VPRNs include duplicate NodeB interfaces. Only the interface associated with the active ePipe spoke SDP is active. The router with the active interface advertises a static route to the NodeB loopback interface. •Static ARP entries may be included for the NodeB MAC address. •Each PE sets a unique route-distinguisher. This ensures that each BGP peer accepts overlapping routes from both POC3 routers, again aiding convergence. •Static routes route traffic to the NodeB loopback interfaces. MLS Router VPRN •Auto bind RSVP-TE is used to simplify provisioning. The 7705 SARs do not currently support auto bind RSVP-TE on VPRN services. •VRRP protects the RNC interface.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 145 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 3G/4G ePipes and Distributed VPRN – Detailed View

Section Objectives In this section, we :

 Observed standby-signaling-master controlling the VPRN services’ active NodeB interface state

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

146

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 146 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Reviewed the Model 2 ePipe and distributed VPRN configuration for 3 and 4G voice, data, and control

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 7 — Model 2 Legacy Services for 2G and 3G Voice, Data, and Control Traffic

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 147 | All rights reserved © 2012 Alcatel-Lucent

Section Objectives In this section, we will:

 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

148

All rights reserved © [year] Alcatel-Lucent

Module 3 - Page 148 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Review the Model 2 legacy (ATM and TDM) 2 and 3G voice, data, and control traffic paths and 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

149

All rights reserved © 2012 Alcatel-Lucent

Model 2 – cPipe and aPipes for 2G and 3G TDM and ATM Traffic In this section, we focus on building the aPipe and cPipe services the Model 2 network deploys to support TDM and ATM base stations. The service endpoints are the CSA and POC1 routers. The POC3 routers switch the traffic from one ISIS level to another, so we will explore pseudowire switching and its use in these services. The MLS routers protect the TDM and ATM NC links with MC-APS, so we will discuss MC-APS use in combination with pseudowire redundancy.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 149 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 – cPipe and aPipes for 2G and 3G TDM and ATM Traffic

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

3G aPipes

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 151 | All rights reserved © 2012 Alcatel-Lucent

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

152

All rights reserved © 2012 Alcatel-Lucent

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. Router-Specific Configurations  Redundant pseudowires are configured on the CSA router.  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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 152 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 Legacy Services – aPipe Overview

 ATM uses a fixed size cell consisting of 53 Bytes  First 5 Bytes contains header information such as the connection identifier  Remaining 48 Bytes contains the data or Payload

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

153

All rights reserved © 2012 Alcatel-Lucent

ATM Cell Format What is ATM? ATM was designed for the high-speed transfer of Voice, Video and Data using cell relay technology Uses small, Fixed-size Cells Connection-oriented Service Supports multiple service types Applicable to LAN and WAN

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 153 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ATM Cell Format

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

154

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 154 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ATM Header Format

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

155

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 155 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Virtual Path and Virtual Channels

 This hop-by-hop forwarding is known as cell relay

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

156

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 156 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Virtual Channels and Virtual Paths

7705 Supported ATM VC-Types

 ATM-VCC (Default on the 7705)  Virtual Channel Connection. An ATM connection that is switched based on the cell 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# *A:CSA1# configure configure service service apipe apipe 10 10 vc-type vc-type atm-vcc atm-vcc customer customer 11 create create *A:CSA1>config>service>apipe$ *A:CSA1>config>service>apipe$

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

157

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 157 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

The VC-type is a 15-bit value that defines the type of VC signalled to the peer

aPipe Overview

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

158

All rights reserved © 2012 Alcatel-Lucent

aPipe Overview Apipe provides a bi-directional layer 2 connection of ATM service between users via IP/MPLS network.  Support both local cross-connect and remote connect.  Standard UNI/NNI cells received on the ATM SAP are encapsulated into PW packet using N:1 cell mode or AAL5 SDU mode. ATM VPWSs (Apipe) provide a point-to-point ATM service between users connected to SROS nodes on an IP/MPLS network. Users are either directly connected to an SROS PE or through an ATM access network. In both cases, an ATM PVC (for example, a virtual channel (VC) or a virtual path (VP)) is configured on the PE router. This feature supports local cross-connecting when users are attached to the same PE node. VPI/VCI translation is supported in the ATM VPWS.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 158 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 ATM VPWS is used to carry ATM cells over an MPLS network.

Cell Mode Encapsulation

 Allows a service provider to offer an ATM PVC or SVC based service across a network  Used to transmit a single ATM cell or multiple ATM cells per Packet Switch Network (PSN) PDU  Allows multiple ATM VCCs or VPCs to be carried within a single PSN tunnel  Supports the binding of multiple VCCs/VPCs to a single pseudowire  7705 SAR currently only supports N=1 cell mode (vc-type atm-vcc)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

159

All rights reserved © 2012 Alcatel-Lucent

aPipe Cell Mode Encapsulation N:1 Cell Mode In the simplest case, this encapsulation can be used to transmit a single ATM cell per service PDU. However, in order to more efficiently use the available bandwidth, several ATM cells may optionally be encapsulated in a single PCU. This process is called cell concatenation. According to RFC 4717, in N:1 Cell Mode ATM cells are transported individually. The encapsulation of a single ATM cell is the only REQUIRED encapsulation for ATM. The encapsulation of more than one ATM cell in a PSN frame is optional and supported by SROS. N:1 Cell Mode in the Backhaul Transport Though the 7750 SR can support N:1 cell mode, vc-type atm-vpc, currently supported in the Model 2 network is N=1 cell mode; the 7705 SAR only supports vc-type atm-vcc. The NodeBs assign unique VPI/VCI combinations to each NodeB service, thus the NodeBs require separate aPipes for each VPI/VCI combination. AAL5 SDU Frame Mode The AAL5 payload VCC service defines a mapping between the payload of an AAL5 VCC and a single pseudowire. The AAL5 payload VCC service requires ATM segmentation and reassembly support on the PE. Even the smallest TCP packet requires two ATM cells when sent over AAL5 on a native ATM device. It is desirable to avoid this padding on the pseudowire. Therefore, once the ingress PE reassembles the AAL5 PDU, the PE discards the PAD and PDU trailer and then the ingress PE inserts the resulting payload into a pseudowire PDU. The egress PE MUST regenerate the PAD and trailer before transmitting the AAL5 frame on the egress ATM port. Alcatel-Lucent backhaul solutions don’t currently implement AAL5 SDU Mode.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 159 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

N:1 Cell Mode

 ATM N:1 cell mode supports ATM cell concatenation.  As the cell is being packed, the concatenation can be terminated by: • Max cells: maximum number of ATM cells to concatenation. • Max delay: maximum delay for ATM cells in hundreds of microseconds. • Cell Loss Priority (CLP)-change: allow the CLP change to be an indication to complete the cell concatenation.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

160

All rights reserved © 2012 Alcatel-Lucent

ATM Cell Concatenation Cell concatenation helps the aPipe service make efficient use of the transport bandwidth. ATM delivers a constant cell stream at the SONET/SDH interfaces by inserted idle cells when there is no data to send. An aPipe configured for cell concatenation can remove the idle cells at service ingress and insert them at egress. However, this introduces delay at the service edge as the ingress PE builds the service PDU. A single ATM cell experiences the least delay, but makes the least efficient use of the aggregate bandwidth. Concatenation Parameters A number of parameters and events determine the number of cells/service PDU.  The maximum number of cells to concatenate – This depends on the traffic class and interface MTU.  The maximum delay in 100s of milliseconds – Based on acceptable network delay for this traffic type.  A change in the CLP bit – A change in the CLP bit indicates the end of the concatenated PDU For UBR traffic, the current recommended settings are:  Max cells 26 – tied to the max interface MTU.  Max delay for the service – the network delay  Change in the CLP bit enabled For CBR traffic:  Max cells 1 to 6 – This is service dependent  Max delay for the service – the network delay  Change in the CLP bit enabled

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 160 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ATM Cell Concatenation

A:CSA1# A:CSA1# show show service service id id 200 200 sdp sdp 1:200 1:200 detail detail ...output ...output truncated truncated ------------------------------------------------------------------------------------------------------------------------------------------------------------APIPE APIPE Service Service Destination Destination Point Point specifics specifics ------------------------------------------------------------------------------------------------------------------------------------------------------------Admin Oper Admin Concat Concat Limit Limit :: 11 Oper Concat Concat Limit Limit :: 11 Peer Max Peer Concat Concat Limit Limit :: 11 Max Concat Concat Delay Delay :: 400 400 ------------------------------------------------------------------------------------------------------------------------------------------------------------Number Number of of SDPs SDPs :: 11 ------------------------------------------------------------------------------------------------------------------------------------------------------------=============================================================================== ===============================================================================

 Default settings  Concatenation limit – 1 cell per packet (no max-cells)  Max Concatenation delay – 400ms (no max-delay)  No CLP change (no clp-change)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

161

All rights reserved © 2012 Alcatel-Lucent

View Cell Concatenation Settings Configure Cell Concatentation • Configure on the spoke SDP CLP change: A:NodeA>config>service>apipe# spoke-sdp 1:200 cell-concatenation clp-change  • Configure the number of cells per packet: A:NodeA>config>service>apipe# spoke-sdp 1:200 cell-concatenation max-cells [1..29]  • Configure the maximum delay per packet: A:NodeA>config>service>apipe# spoke-sdp 1:200 cell-concatenation max-delay [1..400] 

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 161 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View Cell Concatenation Settings

Service Category CBR RT-VBR NRT-VBR ABR* UBR

Typical Application Circuit Emulation Services Interactive Multimedia Bursty applications – File Transfers Best Effort service with flow control feedback LAN Traffic

Traffic Parameters* PCR PCR, SCR, MBS PCR, SCR, MBS PCR, MCR (no guarantees)

• *ABR is not supported on the 7750 or 7705 Products

 ATM Provides five standard service Categories  Commited Bit Rate (CBR)  Real Time – Variable Bit Rate (RT-VBR)  Non-Real Time – VBR (NRT-VBR)  Available Bit Rate (ABR)  Unspecified Bit Rate (UBR) Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

* Peak Cell Rate (PCR) Sustainable Cell Rate (SCR) Maximum Burst Size (MBS) Minimum Cell Rate (MCR) 162

All rights reserved © 2012 Alcatel-Lucent

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)

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 162 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ATM Service Categories

    

ATM QoS applied per VC (VPI/VCI) ATM NodeB supports 5 different traffic types 18 DSPs (6 cards x 3 DSPs/card) per NodeB (Vendor specific) Up to 32 VPI/VCIs required across all traffic types N:1 (7750 only) requires only 5 aPipes to support all traffic across all VCs - one QoS profile per VP/one VP per aPipe

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

163

All rights reserved © 2012 Alcatel-Lucent

ATM N to 1 Cell Mode QoS Application The diagram above shows a total of 32 VCs carried over a single IMA bundle from the NodeB to the CSA. Depending on the vendor, the NodeB may have a total of 18 Digital Signal Processors (DSPs) installed. The NodeB supports several traffic types - some, such as OAM traffic, require only a single VC. However, others, such as user voice and data, requireup to 18 VCs, one per NodeB DSP. As shown, the NodeB carries 5 traffic types, each requires a different QoS treatments, for a total of 5 QoS profiles on the CSA router. N:1 cell mode allows a single aPipe to carry traffic from multiple VCs. When the aPipe is configured for type atmvcp, all traffic of type UBR, for example, can originate on the same VPI. The service SAP accepts all traffic on the bundle in VPI 100. With 5 QoS profiles shown, each carrying a different traffic class and unique cell drop threshold (CDT), N to 1 cell mode allows just 5 aPipes to carry traffic from 32 individual VCs.  aPipe 100 - carries Unspecified Bit Rate (UBR) AAL5 traffic with a Cell Drop Threshold (CDT) of 24ms, on VPI 100.  aPipe 101 - carries Constant Bit Rate (CBR) traffic with a CDT of 11ms, on VPI 101.  aPipe 102 - carries CBR traffic with a CDT of 20ms on VPI 102.  aPipe 103 - carries CBR traffic with a CDT of 20ms on VPI 103.  aPipe 104 - carries CBR traffic with a CDT of .9ms on VPI 104.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 163 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ATM N:1 Cell Mode QoS Application

• Control word optional for cell mode • Required for AAL5 SDU frame mode

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

164

All rights reserved © 2012 Alcatel-Lucent

aPipe Packet Format The metro domain shown deploys MPLS Label Switch Routers. The core LSRs only look at the top label to switch the labeled frame across the MPLS domain. It is possible that additional labels get pushed along the way. The egress LER infers from the VC label on how to process the frame and then forwards it to the appropriate outgoing port. The VC label is not visible until the frame reaches the egress LER due to the MPLS tunneling hierarchy. LDP or RSVP signaling is required to distribute the outer labels, and LSRs are necessary to determine the routes to establish the required Label-Switched Paths (LSPs). Martini encapsulation can be used to carry the 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 164 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

aPipe Packet Format

Creating the CSA aPipe Service

config>service>apipe$ config>service>apipe$ sap sap bundle-ima-1/1.1:200/10 bundle-ima-1/1.1:200/10 create create config>service>apipe>sap$ back config>service>apipe>sap$ back config>service>apipe# config>service>apipe# endpoint endpoint "ATM_IMA_URC200" "ATM_IMA_URC200" create create config>service>apipe>endpoint# back config>service>apipe>endpoint# back config>service>apipe# config>service>apipe# spoke-sdp spoke-sdp 1:200 1:200 endpoint endpoint "ATM_IMA_URC101" "ATM_IMA_URC101" create create config>service>apipe>spoke-sdp$ config>service>apipe>spoke-sdp$ precedence precedence primary primary config>service>apipe>spoke-sdp$ config>service>apipe>spoke-sdp$ back back config>service>apipe# config>service>apipe# spoke-sdp spoke-sdp 2:200 2:200 endpoint endpoint "ATM_IMA_URC101" "ATM_IMA_URC101" create create config>service>apipe>spoke-sdp$ back config>service>apipe>spoke-sdp$ back config>service>apipe# config>service>apipe# no no shutdown shutdown

 Use vc-type atm-vcc for N = 1 cell mode  Redundant pseudowires terminate on POC3 routers  SAP is IMA bundle with VPI/VCI for a single VCC

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

165

All rights reserved © 2012 Alcatel-Lucent

Creating the CSA aPipe Service According to RFC 4717, the VCC cell transport service is characterized by the mapping of a single ATM VCC (VPI/VCI) to a Pseudo Wire. This service is fully transparent to the ATM Adaptation Layer. The VPC service is defined by mapping a single VPC (VPI) to a Pseudo Wire. As such it emulates a Virtual Path cross-connect across the PSN. All VCCs belonging to the VPC are carried transparently by the VPC service. The AAL5 SDU encapsulation is more efficient for small AAL5 SDUs than the VCC cell encapsulations. In turn it presents a more efficient alternative to the cell relay service when carrying RFC 2684 encapsulated IP PDUs across a PSN. The AAL5-SDU encapsulation requires Segmentation and Reassembly on the PE-CE ATM interface. Once reassembled, the AAL5-SDU is carried via a Pseudo Wire to the egress PE. And herein lies another advantage of the AAL5-SDU encapsulation. The encapsulation allows multiple VCCs/VPCs to be carried within a single pseudo wire. However, a service provider may wish to provision a single VCC to a pseudo wire in order to satisfy QoS or restoration requirements. The encapsulation also supports the binding of multiple VCCs/VPCs to a single Pseudo Wire. This capability is useful in order to make more efficient use of the PW demultiplexing header space as well as to ease provisioning of the VCC/VPC services.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 165 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA2>config>service# A:CSA2>config>service# apipe apipe 200 200 vc-type vc-type atm-vcc atm-vcc customer customer 11 create create config>service>apipe$ description “Distributed config>service>apipe$ description “Distributed apipe apipe for for 3G 3G ATM ATM Services" Services"

A:POC3>config>service# A:POC3>config>service# apipe apipe 200 200 vc-type vc-type atm-vcc atm-vcc vc-switching vc-switching customer customer 11 create create config>service>apipe$ config>service>apipe$ description description “Distributed “Distributed apipe apipe for for 3G 3G ATM ATM Services" Services" config>service>apipe$ config>service>apipe$ spoke-sdp spoke-sdp 1:200 1:200 create create config>service>apipe>spoke-sdp$ config>service>apipe>spoke-sdp$ back back config>service>apipe$ config>service>apipe$ spoke-sdp spoke-sdp 2:200 2:200 create create config>service>apipe>spoke-sdp$ back config>service>apipe>spoke-sdp$ back config>service>apipe$ config>service>apipe$ no no shutdown shutdown

 POC3 is the S-PE  Use vc-type atm-vcc and vc-switching when creating the service

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

166

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 166 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Creating the S-PE aPipe Service

A:MLS2>config>service# A:MLS2>config>service# apipe apipe 200 200 vc-type vc-type atm-vcc atm-vcc customer customer 11 create create config>service>apipe$ description “Distributed config>service>apipe$ description “Distributed apipe apipe for for 3G 3G ATM ATM Services" Services" config>service>apipe$ endpoint SAP create config>service>apipe$ endpoint SAP create config>service>apipe>endpoint$ config>service>apipe>endpoint$ back back config>service>apipe$ config>service>apipe$ endpoint endpoint SPOKE SPOKE create create config>service>apipe>endpoint$ config>service>apipe>endpoint$ back back config>service>apipe$ config>service>apipe$ sap sap aps-1:200/10 aps-1:200/10 endpoint endpoint SAP SAP create create config>service>epipe>sap$ back config>service>epipe>sap$ back config>service>apipe$ config>service>apipe$ spoke-sdp spoke-sdp 3:200 3:200 endpoint endpoint SAP SAP icb icb create create config>service>apipe>spoke-sdp$ config>service>apipe>spoke-sdp$ back back config>service>apipe$ config>service>apipe$ spoke-sdp spoke-sdp 1:200 1:200 endpoint endpoint SPOKE SPOKE create create config>service>apipe>spoke-sdp$ config>service>apipe>spoke-sdp$ back back config>service>apipe4 config>service>apipe4 spoke-sdp spoke-sdp 3:201 3:201 endpoint endpoint SPOKE SPOKE icb icb create create config>service>epipe>spoke-sdp$ config>service>epipe>spoke-sdp$ back back config>service>apipe$ config>service>apipe$ no no shutdown shutdown

 APS group in SAP  ICB-PW to provide path of last resort to active SONET/SDH link Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

167

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 167 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Creating the MLS router ICB-PW aPipe Service

View the MLS1 aPipe Status =============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 200 Vpn :: 00 Service Id Id 200 Vpn Id Id Service :: Apipe VLL :: ATMVCC Service Type Type Apipe VLL Type Type ATMVCC Name :: (Not Name (Not Specified) Specified) Description :: Distributed Description Distributed apipe apipe for for 3G 3G ATM ATM Services Services Customer :: 11 Customer Id Id ... ... Admin :: Up Oper :: Up Admin State State Up Oper State State Up MTU :: 1508 MTU 1508 Vc :: False Vc Switching Switching False SAP :: 11 SDP :: 33 SAP Count Count SDP Bind Bind Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:aps-1:200/10 atm 1524 1524 Up Up sap:aps-1:200/10 atm 1524 1524 Up Up sdp:1:200 Spok 00 1550 Up Up sdp:1:200 S(192.0.2.2) S(192.0.2.2) Spok 1550 Up Up sdp:3:200 Spok 00 1550 Up Up sdp:3:200 S(192.0.2.1) S(192.0.2.1) Spok 1550 Up Up sdp:3:201 Spok 00 1550 Up Up sdp:3:201 S(192.0.2.1) S(192.0.2.1) Spok 1550 Up Up =============================================================================== ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

168

All rights reserved © 2012 Alcatel-Lucent

View the MLS1 aPipe Status A: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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 168 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show service service id id 200 200 base base

View the CSA aPipe Status =============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 200 Service Id Id 200 Service :: Apipe VLL :: ATMVCC Service Type Type Apipe VLL Type Type ATMVCC Description :: (Not Description (Not Specified) Specified) Customer :: 11 Customer Id Id Last Last Status Status Change: Change: 08/31/2011 08/31/2011 13:51:56 13:51:56 Last Last Mgmt Mgmt Change Change :: 08/30/2011 08/30/2011 15:12:28 15:12:28 Admin :: Up Oper :: Up Admin State State Up Oper State State Up MTU :: 1508 MTU 1508 Vc :: False Vc Switching Switching False SAP :: 11 SDP :: 22 SAP Count Count SDP Bind Bind Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:bundle-ima-1/1.1:200/10 atm 1524 1524 Up Up sap:bundle-ima-1/1.1:200/10 atm 1524 1524 Up Up sdp:1:200 n/a 00 1550 Up Up sdp:1:200 S(192.0.2.0) S(192.0.2.0) n/a 1550 Up Up sdp:2:200 n/a 00 1550 Up Up sdp:2:200 S(192.0.2.1) S(192.0.2.1) n/a 1550 Up Up =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

169

All rights reserved © 2012 Alcatel-Lucent

View the CSA2 aPipe Status A: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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 169 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA1# A:CSA1# show show service service id id 200 200 base base

A:MLS1# A:MLS1# show show service service id id 200 200 endpoint endpoint =============================================================================== =============================================================================== Service Service 200 200 endpoints endpoints =============================================================================== =============================================================================== ... ... =============================================================================== =============================================================================== Endpoint :: SPOKE Endpoint name name SPOKE Description :: (Not Description (Not Specified) Specified) Revert time : 0 Revert time : 0 Act :: 00 Act Hold Hold Delay Delay Tx Active (SDP) :: 2:200 Tx Active (SDP) 2:200 Tx :: 0d Tx Active Active Up Up Time Time 0d 00:53:25 00:53:25 Revert :: N/A Revert Time Time Count Count Down Down N/A Tx :: 11 Tx Active Active Change Change Count Count Last Tx Active Change : Last Tx Active Change : 08/31/2011 08/31/2011 12:57:12 12:57:12 ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 2:200 2:200 Prec:4 Prec:4 Oper Status: Status: Up Up Spoke-sdp: 3:200 Prec:4 (icb) Oper Status: Spoke-sdp: 3:200 Prec:4 (icb) Oper Status: Up Up =============================================================================== =============================================================================== =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

170

All rights reserved © 2012 Alcatel-Lucent

View the MLS1 SPOKE Endpoint Status – Normal operations A: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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 170 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the MLS SPOKE endpoint status – Normal operations

A:MLS1# A:MLS1# show show service service id id 200 200 endpoint endpoint =============================================================================== =============================================================================== Service Service 200 200 endpoints endpoints =============================================================================== =============================================================================== ... ... =============================================================================== =============================================================================== Endpoint :: SPOKE Endpoint name name SPOKE Description :: (Not Description (Not Specified) Specified) Revert time : 0 Revert time : 0 Act :: 00 Act Hold Hold Delay Delay Tx Active (SDP) :: 3:200 Tx Active (SDP) 3:200 Tx :: 0d Tx Active Active Up Up Time Time 0d 00:00:26 00:00:26 Revert :: N/A Revert Time Time Count Count Down Down N/A Tx :: 33 Tx Active Active Change Change Count Count Last Tx Active Change : Last Tx Active Change : 08/31/2011 08/31/2011 13:55:54 13:55:54 ------------------------------------------------------------------------------------------------------------------------------------------------------------Members Members ------------------------------------------------------------------------------------------------------------------------------------------------------------Spoke-sdp: Oper Spoke-sdp: 2:200 2:200 Prec:4 Prec:4 Oper Status: Status: Down Down Spoke-sdp: 3:200 Prec:4 (icb) Oper Status: Spoke-sdp: 3:200 Prec:4 (icb) Oper Status: Up Up =============================================================================== =============================================================================== =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

171

All rights reserved © 2012 Alcatel-Lucent

View the MLS1 SPOKE Endpoint Status – Primary Spoke SDP failed A: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 Status The 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: Down Spoke-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: Up Spoke-sdp: 3:201 Prec:4 (icb) Oper Status: Up ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 171 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

View the MLS SPOKE endpoint status – Primary Spoke SDP failed

View MC-APS on MLS1

=============================================================================== =============================================================================== APS APS Group Group Info Info =============================================================================== =============================================================================== Interface Tx/Rx Interface Admin/Oper Admin/Oper MC-Ctl MC-Ctl Work|Work1 Work|Work1 Prot|Work2 Prot|Work2 Active Active Tx/Rx State State Circuit Circuit Circuit K1 State State Circuit Circuit Circuit K1 Byte Byte ------------------------------------------------------------------------------------------------------------------------------------------------------------aps-1 Up/Up Up 1/2/4 N/A 1/2/4 N/A aps-1 Up/Up Up 1/2/4 N/A 1/2/4 N/A =============================================================================== =============================================================================== Interface Interface -- aps- aps- [] [] -- applies applies to to APS APS Annex Annex BB only: only: LL -- lockout lockout Circuit -- // Circuit // [] [] -- applies applies to to APS APS Annex Annex BB only: only: PP -- primary UU -- up primary up SS -- secondary DD -- down secondary down =============================================================================== ===============================================================================

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

172

All rights reserved © 2012 Alcatel-Lucent

Model 1 – Verifying APS A:NodeA# show aps aps-1  •MC-Ctl State: - Indicates the MCS is up. •Work|Work1 Circuit – Indicates the working circuit ID. •Prot|Work2 Circuit – Indicates the physical port that acts as the protection circuit ID. •Active Circuit – Indicates the current active circuit. MLS1 currently hosts the active circuit. •Tx/Rx K1 Byte – This is the value of the SONET/SDH K1 byte received or transmitted on the protection circuit.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 172 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show aps aps aps-1 aps-1

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

173

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 173 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 Legacy Services – aPipe Detailed View

.5 Hour Lab Objectives:  On the CSA routers, provision redundant aPipe spoke SDPs and NodeB/BTS facing SAPs  On the MLS routers, provision PW switching for the aPipe service  On the CR router, provision the aPipe spoke SDPs and NC SAPs  Verify service operation with SROS OAM tools Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

174

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 174 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Lab 8 : Configure 3G Voice aPipe Service

Module 3 — Implementing Mobile Backhaul Transport Services

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

2G cPipes

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 175 | All rights reserved © 2012 Alcatel-Lucent

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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

176

All rights reserved © 2012 Alcatel-Lucent

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. Router-Specific Configurations  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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 176 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 Legacy Services – cPipe Overview

 Synchronous channel based  Each station gets a fixed-length slot  Unused slots are idle – transmitted without data  For example: T1, SONET

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

177

All rights reserved © 2012 Alcatel-Lucent

Review: Time Division Multiplexing Each host PC sends information to the switch. The switch then transmits a frame to the router at a constant data rate (for example, 1.5 Mb/s). This frame is then divided into many fixed time slots (24), each containing 64 kbits. Each host can occupy one or more time slots per frame. Each host PC is assigned a fixed data rate. If the host uses one time slot, then its transmission is 64 kbits in that slot. Because the pipe rate is 1.5 Mb/s, the host will have to supply their next 64 kbits in the next frame. In this slide, each host PC transmits its characteristic frame (grey, yellow, purple). The frames that are transmitted from the switch contain several timeslots. Within each of these frames three of the timeslots are used by the respective host PCs.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 177 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Review: Time Division Multiplexing

Time Division Multiplexing (TDM) – DS1

 1.544 Mb/s Framing Rate  24 subchannels (DS0) each 8 bits sampled at 8000 times per second + 1 framing bit

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

178

All rights reserved © 2012 Alcatel-Lucent

Time Division Multiplexing (TDM) – DS1 Time Division Multiplexing (TDM) is a digital technology where individual signals are interleaved into a composite multiplexed signal. Recurring fixed-length time slots are created such that each individual signal is represented by one channel or by multiple channels. The total transmission bandwidth is split among the time slots. The total composite signal includes the payload bits for the composing channels and overhead bits. The frame structures of the DS1 [ANSI95b] signal is shown above. The DS1 signal consists of 24 payload channels plus overhead. The basic frame of each of these signals repeats every 125 µs, that is, 8000 times per second. With 8 bits carried in each channel, this gives rise to a basic data rate of 64 kb/s for each channel. The requirement for this data rate stems from the need to sample the analog telephony signal 8000 times per second and encoding each sample in 8 bits. A DS-1 frame contains 24 channels, each consisting of 8 bits, plus 1 framing/overhead bit, leading to a total of 193 bits. Because the frame repeats every 125 µs (or 8000 times a second), the total bit rate of the DS1 signal is 1.544 Mb/s. Similarly, the total bit rate of the E1 signal is 2.048 Mb/s (32 channels of 8 bits, repeating every 125 µs).  Widely used signaling examples: • DS1/T1, E1, DS3, E3, OC3/STM-1, OC12/STM-4  Other signaling examples: • DS3 that uses 28 DS1 or 7 DS2 or 1 DS3 = 45 M • OC3 that uses 3 DS3

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 178 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

DS1/T1

E1  2048Kb/s framing rate  32 subchannels each 8 bits sampled at 8000 times per second

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

179

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 179 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Time Division Multiplexing (TDM) – E1

SROS cPipe Overview

 Support both local cross-connect and remote connect.  Support both structured and unstructured frames

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

180

All rights reserved © 2012 Alcatel-Lucent

SROS cPipe Overview CES VPWSs (cPipe) provide a point-to-point TDM service between users connected to 7750 SR nodes on an IP/MPLS network. Users are either directly connected to a 7750 PE or through an TDM access network. In both cases, the SROS PE provides a TDM cross connect. This feature supports both distributed services and local cross-connects where users are attached to the same node. On the 7750 SR, a CES (circuit emulation service) MDA is required, on the 7705 SAR, a channelized DSx MDA is required. The transport network is Ethernet based. CES VPWS (Cpipe) is a point-to-point VPN services emulating a TDM leased line. Two PE routers connected to the customer sites through the local attachment circuit receives native TDM traffic, perform VPN (PW) encapsulation and transport tunnel encapsulation, then send the traffic through packet switched network (PSN, usually IP/MPLS) to reach the remote site.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 180 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 cPipe provides a bi-directional layer 2 TDM service connection over the IP/MPLS transport

   

DS1/E1 traffic received on service SAP Bits read into packetization buffer at BS transmit clock rate PW control word, VC label, and transport label added De-jitter buffer emptied at local clock rate

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

181

All rights reserved © 2012 Alcatel-Lucent

cPipe Data Plane Encapsulation The illustration above shows the encapsulated TDM traffic carried over the MPLS transport. Service Ingress The ingress PE receives the customer traffic on the service SAP. It reads the incoming bit stream at the BS clock rate into a packetization buffer. The packetization buffer holds the TDM frame octets while the router builds the payload. The payload size depends on the DS1 or E1 circuit configuration, which influences the 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 181 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

cPipe Data Plane Encapsulation

Structured - CESoPSN : Circuit Emulation Service Over PSN.  RFC 5086 – The PE is aware of the individual DS1/E1 timeslots  Structured mode is supported for n*64kbps circuits  Allows timeslot selection and suppression to avoid transmitting unused timeslots  The transported DS1 and E1 circuits specify channel-groups with timeslots from 1-24 for DS1 or 1-32 for E1 Unstructured - SAToP : Structure Agnostic Transport Over PSN.

 RFC 4553 - Transports an unstructured (clear channel) DS1 or E1 frame for ATM or MLPPP traffic  Efficiently transports the full DS1/E1 frame  DS1 and E1 unstructured circuits can be set to unframed, so that when channel-group 1 is configured it contains all 24 or 32 channels

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

182

All rights reserved © 2012 Alcatel-Lucent

cPipe Delivery Options Structured – TDM Circuit Emulation over Packet Switched Networks (CESoPSN) RFC 5086 Structured emulation (also called CESoPSN) makes use of the TDM framing structure, where each frame comprises a sequence of timeslots. The IWF (Inter-Working Function) strips the framing structure (for example, the F bit in a DS1) from the data stream. It then places the sequence of timeslots from the first frame into the packet payload, followed by the same timeslots from the next frame, and so on, until the payload is complete. A packet header is then added, and the packet is sent through the transport network to the PE at the other end. On the egress, the PE recreates the TDM data stream. Unstructured – Structure-agnostic TDM over Packet (SAToP) Unstructured emulation (also called SAToP) disregards the TDM framing structure and treats the TDM data simply as a stream of consecutive octets. The number of octets that comprise each PSN packet payload is independent of the number of timeslots in each TDM frame, thus any alignment of these octets with the underlying timeslots is coincidental and not guaranteed. The payload length is typically chosen to make a packet formation time of approximately 1msec. For a T1 circuit, this length is 193 octets.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 182 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

cPipe – Delivery Options

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

183

All rights reserved © 2012 Alcatel-Lucent

cPipe Encapsulation The pseudowire encapsulation performed on the TDM traffic in Cpipe service with two types of format are similar. The only difference is the control word field. For CESoPSN, see RFC 5086, Stucture-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN); For SAToP, see RFC4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet [SAToP].

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 183 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

cPipe Encapsulation

 Bits 0-3 – Set to 000 according to RFC 4385  L (Local TDM Failure) – set to 1 if the attachment circuit experiences LOS, LOF, or AIS  R (Remote Loss of Frames) – set to 1 if the local CE-bound inter-working function (IWF) is in packet loss state  M (Modifier) – 00 for SAToP. CESoPSN according to RFC 5086, see notes section  FRG – CESoPSN sets to 00  LEN – length of CESoPSN packet (header plus payload) if > 64 bytes, otherwise 0  Sequence number – for lost packet detection and resequencing

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

184

All rights reserved © 2012 Alcatel-Lucent

cPipe Control Word  L – (Local TDM Failure) is set to 1 when some abnormal condition of the attachment circuit such as Loss of Sync (LOS), Loss of Frame (LOF) or Alarm Indication Signal (AIS) has been detected and TDM data carried in the payload is invalid. L bit is cleared back to 0 when fault is rectified.  R – (Remote Loss of Frames indication) Set to 1 if the local CE-bound IWF is in the packet loss state, i.e. has lost a pre-configured number of consecutive packets and cannot reproduce the TDM stream. The R bit is cleared once its local CE-bound IWF has exited the packet loss state, i.e. has received a pre-configured number of consecutive packets.  M - 2-bit modifier field. Set to 00 for SAToP as per RFC4553. For CESoPSN, M is set according to RFC 5086, as shown below: • When L bit = 0, and M = 00 – Normal conditions M = 01 – Reserved for future use M = 10 – Remote Defect Indicator (RDI) condition for the attachment circuit (AC) M = 11 – Reserved for CESoPSN • When L bit = 1, and M = 00 – TDM data is invalid M = 01 – Reserved for future use M = 10 – Reserved for future use M = 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 184 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

cPipe Control Word

Packet size is user-configurable in bytes. It must be a multiple of the number of timeslots by T1/E1 frame (N)  Minimum packet size will be based on 8 frames (T1/E1) per packet  Maximum number for packet size is 1514 bytes With a smaller packet size, the packetization latency is reduced, however this results in higher overhead as a percentage of the traffic

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

185

All rights reserved © 2012 Alcatel-Lucent

Payload Size vs. Packetization Delay The payload size is calculated by the formula S=NxF where S is the payload size, N is the number of timeslots collected per frame, and F is the number of frames accumulated in each packet. Each timeslot is 8 bits, or 1 byte. Assuming a E1 channel group containing all 32 timeslots, and the service collects 8 frames, the payload size is 32 timeslots (bytes) x 8 = 256 octets Packetization Delay A DS1 or E1 frame arrives at the SAP 8000 times per second, or every 125us. The packetization delay is calculated by the formula D = frame delivery time x the number of frames accumulated In the example above, D = 125us/frame x 8 frames = 1ms, the packetization delay imposed by this service. Number of Frames Per Packet, Structured The SROS sets the default number of frames per packet by the number of timeslots in the received DS1 or E1. The default values are set by the operating system as follows, where N = the number of timeslots: • for N = 1, the default is 64 frames/packet • for 2 ≤ N ≤ 4, the default is 32 frames/packet • for 5 ≤ N ≤ 15, the default is 16 frames/packet • for N ≥ 16, the default is 8 frames/packet Number of Frames per Packet, Unstructured • DS1, 192 bytes • E1, 256 bytes Minimum and Maximum Payload Sizes The SROS minimum payload size is 2 bytes and the maximum is 1514 bytes. Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 185 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Packet Size vs. Packet Latency

 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

186

All rights reserved © 2012 Alcatel-Lucent

Jitter Buffer Several network impairments prevent IP networks from carrying emulated circuit-switched traffic such as a T1 (1.544 Mb/s signal). A T1 line delivers a constant bit rate stream from node A to some node B on the other side of the network. As packets travel through the network, delay accumulates at each intermediary node. In order to compensate for this delay, node B must use a jitter buffer to further delay packets in order to guarantee that there will always be a packet ready to be transmitted out. Where problems start to arise, however, is that each packet arrives with a different delay. The range of delay in which packets arrive is known as time delay variation (TDV) or jitter. Typically, with a large enough jitter buffer, packets will arrive in time to be useful. In the extreme case, a packet may be discarded if the time delay variation exceeds the maximum the jitter buffer can accommodate.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 186 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Jitter Buffer

Jitter Buffer (cont)

 The jitter buffer must be set to a minimum of 3 times the packetization delay and should be greater than the maximum network jitter  SROS plays out the buffer once it is 50% full

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

187

All rights reserved © 2012 Alcatel-Lucent

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 port>tdm# config>port>tdm# e1 e1 config>port>tdm>e1# config>port>tdm>e1# framing framing e1-unframed e1-unframed config>port>tdm>e1# channel-group config>port>tdm>e1# channel-group 11 config>port>tdm>e1>channel-group# config>port>tdm>e1>channel-group# encap-type encap-type cem cem config>port>tdm>e1>channel-group# config>port>tdm>e1>channel-group# no no shutdown shutdown config>port>tdm>e1>channel-group# config>port>tdm>e1>channel-group# back back config>port>tdm>e1# config>port>tdm>e1# no no shutdown shutdown config>port>tdm>e1# config>port>tdm>e1# back back config>port>tdm# config>port>tdm# back back config>port# config>port# no no shutdown shutdown

 Set the port to e1-unframed  Configure the channel group to CEM encapsulation  The default mode is access and all 32 timeslots are used Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

189

All rights reserved © 2012 Alcatel-Lucent

Configuring the CSA1 E1 Port Port timing Each OC-3/STM-1 port can be independently loop or node timed. Each port can be a timing source for the node. Each DS-1 or E-1 channel without CAS signaling enabled can be independently configured to be loop-timed, nodetimed, adaptive-timed or differential-timed. Each DS-1 or E-1 channel with CAS signaling enabled can be independently configured to be loop-timed or node-timed. Adaptive timed and differential-timed are not supported on DS-1 or E-1 channels with CAS signaling enabled. A CES 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.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 189 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA2>config# A:CSA2>config# port port 1/1/1 1/1/1 config>port# config>port# description description “E1 “E1 tdm tdm link link towards towards BTS10 BTS10 port port 1" 1"

Configuring the MLS Path and Payload – STM-1

config>port# config>port# sonet-sdh sonet-sdh config>port>sonet-sdh# config>port>sonet-sdh# path path sts3 sts3 config>port>sonet-sdh>path# config>port>sonet-sdh>path# no no shutdown shutdown config>port>sonet-sdh>path# config>port>sonet-sdh>path# back back config>port>sonet-sdh# config>port>sonet-sdh# group group tug3-1 tug3-1 payload payload vt2 vt2 config>port>sonet-sdh# path vt2-1.1.1 config>port>sonet-sdh# path vt2-1.1.1 config>port>sonet-sdh>path# config>port>sonet-sdh>path# no no shutdown shutdown config>port>sonet-sdh>path# back config>port>sonet-sdh>path# back

vt2-tug3-1.tug2-1.vt2-1

config>port>sonet-sdh# config>port>sonet-sdh# back back config>port# config>port# tdm tdm config>port>tdm# config>port>tdm# e1 e1 1.1.1 1.1.1 config>port>tdm>e1# config>port>tdm>e1# framing framing e1-unframed e1-unframed config>port>tdm>e1# config>port>tdm>e1# channel-group channel-group 11 config>port>tdm>e1>channel-group$ config>port>tdm>e1>channel-group$ no no shutdown shutdown config>port>tdm>e1>channel-group# config>port>tdm>e1>channel-group# back back config>port>tdm>e1# config>port>tdm>e1# no no shutdown shutdown config>port>tdm# config>port>tdm# back back config>port# config>port# no no shutdown shutdown Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

190

All rights reserved © 2012 Alcatel-Lucent

Configuring the MLS2 Path and Payload On the CEM MDAs, the default channel group mode is access and encapsulation type is CEM. As we learned in Module 2, you must build out the TUGs before you can configure the E1s.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 190 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1>config# A:MLS1>config# port port aps-2 aps-2 config>port# config>port# description description “To “To BSC1 BSC1 over over SDH" SDH"

Creating the CSA cPipe Service

config>service>cpipe$ config>service>cpipe$ sap sap 1/1/1.1 1/1/1.1 create create config>service>cpipe>sap$ cem config>service>cpipe>sap$ cem config>service>cpipe>sap>cem$ config>service>cpipe>sap>cem$ back back config>service>cpipe>sap$ config>service>cpipe>sap$ back back config>service>cpipe# config>service>cpipe# endpoint endpoint “BTS_20_port_1" “BTS_20_port_1" create create config>service>cpipe>endpoint# config>service>cpipe>endpoint# back back config>service>cpipe# config>service>cpipe# spoke-sdp spoke-sdp 1:300 1:300 endpoint endpoint "BTS_20_port_1" "BTS_20_port_1" create create config>service>cpipe>spoke-sdp$ config>service>cpipe>spoke-sdp$ precedence precedence primary primary config>service>cpipe>spoke-sdp$ config>service>cpipe>spoke-sdp$ back back config>service>cpipe# config>service>cpipe# spoke-sdp spoke-sdp 2:300 2:300 endpoint endpoint "BTS_20_port_1" "BTS_20_port_1" create create config>service>cpipe>spoke-sdp$ back config>service>cpipe>spoke-sdp$ back config>service>cpipe# config>service>cpipe# no no shutdown shutdown

 Use vc-type satop-e1 for unstructured E1, cem on the SAP  Redundant pseudowires terminate on POC3 routers  Uses default jitter buffer and payload size if not specified on SAP Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

191

All rights reserved © 2012 Alcatel-Lucent

Creating the CSA cPipe Service You must specify when you create the service the type of service, structured or unstructured, it will provide. A:NodeA>config# service cpipe vc-type {satop-e1|satopt1|cesopsn|cesopsn-cas} customer create  vc-type  satop-e1 – Unstructured E1 CES  satop-t1 – Unstructured DS1 CES Unstructured CES is configured by choosing vc-type satop-t1 or satop-e1 as the when creating a Cpipe service. For DS1 and E1 unstructured circuit emulation, the framing parameter of the port must be set to ds1unframed or e1-unframed (respectively) because SAToP service ignores the underlying framing. Additionally, channel group 1 must contain all 24 or 32 timeslots, which is configured automatically when channel group 1 is created.  cesopsn – Basic structured n*64 kb/s CES Structured CES without CAS is configured by choosing vc-type cesopsn when creating a Cpipe service. For n × 64 kb/s structured circuit emulation operation, the framing parameter of the port must be set to a framed setting (such as ESF for DS1). Each channel group contains n DS0s (timeslots), where n is between 1 and 24 timeslots for DS1 and between 1 and 31 timeslots for E1.  cesopsn-cas – Structured n*64 kb/s CES with signaling Structured CES with CAS service is configured by choosing vc-type cesopsn-cas when creating a Cpipe service. The DS1 or E1 service on the port associated with the Cpipe SAP should be configured to support CAS (via the signal-mode {cas} command) before configuring the Cpipe service to support DS1 or E1 with CAS. Refer to the 7705 SAR OS Interface Configuration Guide for information on configuring signal mode. CEM On the SAP you must set the cem context. This allows you to set the jitter buffer and payload size. If not set, the router uses for the number of timeslots defined on the E1 circuit to set the jitter buffer size.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 191 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA2>config>service# A:CSA2>config>service# cpipe cpipe 300 300 vc-type vc-type satop-e1 satop-e1 customer customer 11 create create config>service>cpipe$ description “Distributed config>service>cpipe$ description “Distributed cpipe cpipe for for 2G 2G BTS BTS Services" Services"

A:POC3>config>service# A:POC3>config>service# cpipe cpipe 300 300 vc-type vc-type satop-e1 satop-e1 vc-switching vc-switching customer customer 11 create create config>service>cpipe$ config>service>cpipe$ description description “Distributed “Distributed cpipe cpipe for for for for 2G 2G BTS BTS Services" Services" config>service>cpipe$ config>service>cpipe$ spoke-sdp spoke-sdp 2:300 2:300 create create config>service>cpipe>spoke-sdp$ back config>service>cpipe>spoke-sdp$ back config>service>cpipe$ config>service>cpipe$ spoke-sdp spoke-sdp 4:300 4:300 create create config>service>cpipe>spoke-sdp$ back config>service>cpipe>spoke-sdp$ back config>service>cpipe$ config>service>cpipe$ no no shutdown shutdown

 POC3 is the S-PE  Use vc-type satop-e1 and vc-switching when creating the service

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

192

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 192 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Creating the S-PE cPipe Service

A:MLS1>config>service# A:MLS1>config>service# cpipe cpipe 300 300 vc-type vc-type satop-e1 satop-e1 customer customer 11 create create config>service>cpipe$ description “Distributed config>service>cpipe$ description “Distributed for for 2G 2G BTS BTS Services Services "" config>service>cpipe$ config>service>cpipe$ endpoint endpoint SAP SAP create create config>service>cpipe>endpoint$ config>service>cpipe>endpoint$ back back config>service>cpipe$ config>service>cpipe$ endpoint endpoint SPOKE SPOKE create create config>service>cpipe>endpoint$ config>service>cpipe>endpoint$ back back config>service>cpipe$ config>service>cpipe$ sap sap aps-2.1.1.1.1 aps-2.1.1.1.1 endpoint endpoint SAP SAP create create config>service>cpipe>sap$ cem config>service>cpipe>sap$ cem aps-2.tug3-1.tug2-1.vt2-1.channel-group 1 config>service>cpipe>sap>cem$ config>service>cpipe>sap>cem$ back back config>service>cpipe>sap$ config>service>cpipe>sap$ back back config>service>cpipe$ config>service>cpipe$ spoke-sdp spoke-sdp 3:300 3:300 endpoint endpoint SAP SAP icb icb create create config>service>cpipe>spoke-sdp$ config>service>cpipe>spoke-sdp$ back back config>service>cpipe$ config>service>cpipe$ spoke-sdp spoke-sdp 1:300 1:300 endpoint endpoint SPOKE SPOKE create create config>service>cpipe>spoke-sdp$ config>service>cpipe>spoke-sdp$ back back config>service>cpipe$ config>service>cpipe$ spoke-sdp spoke-sdp 3:301 3:301 endpoint endpoint SPOKE SPOKE icb icb create create config>service>cpipe>spoke-sdp$ config>service>cpipe>spoke-sdp$ back back config>service>cpipe$ config>service>cpipe$ no no shutdown shutdown

 APS group in SAP, aps-2.tug3-1.tug1-1.vt2-1.channel-group 1  ICB-PW to provide path of last resort to active SONET/SDH link  If not specified on the SAP, the service uses default jitter buffer and payload Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

193

All rights reserved © 2012 Alcatel-Lucent

Creating the MLS router ICB-PW cPipe Service Configure Jitter Buffer and Payload Size Under the sap>cem context, set the jitter buffer and payload size. Below are the defaults for an E1 SAP: A:NodeA>config>service>cpipe>sap>cem# info detail ---------------------------------------------packet jitter-buffer 5 payload-size 256 report-alarm stray malformed pktloss overrun underrun no report-alarm rpktloss rfault rrdi no rtp-header ----------------------------------------------

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 193 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Creating the MLS router ICB-PW cPipe Service

View the CSA cPipe Status =============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 300 Service Id Id 300 Service :: Cpipe VLL :: SAToPE1 Service Type Type Cpipe VLL Type Type SAToPE1 Description :: Distributed Description Distributed cpipe cpipe for for for for 2G 2G BTS BTS Services Services Customer :: 11 Customer Id Id Last Last Status Status Change: Change: 09/02/2011 09/02/2011 10:06:46 10:06:46 Last Last Mgmt Mgmt Change Change :: 09/02/2011 09/02/2011 09:54:53 09:54:53 Admin :: Up Oper :: Up Admin State State Up Oper State State Up MTU :: 1514 MTU 1514 Vc :: False Vc Switching Switching False SAP :: 11 SDP :: 22 SAP Count Count SDP Bind Bind Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:1/1/1.1 cem 1514 1514 Up Up sap:1/1/1.1 cem 1514 1514 Up Up sdp:1:300 n/a 00 1550 Up Up sdp:1:300 S(192.0.2.0) S(192.0.2.0) n/a 1550 Up Up sdp:2:300 n/a 00 1550 Up Up sdp:2:300 S(192.0.2.1) S(192.0.2.1) n/a 1550 Up Up =============================================================================== =============================================================================== Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

194

All rights reserved © 2012 Alcatel-Lucent

View the CSA aPipe Status A:NodeA# show service id 300 base  •VLL Type: - SAToPE1 – Structure agnostic E1 service

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 194 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:CSA2# A:CSA2# show show service service id id 300 300 base base

View the MLS cPipe Status =============================================================================== =============================================================================== Service Service Basic Basic Information Information =============================================================================== =============================================================================== Service :: 300 Vpn :: 00 Service Id Id 300 Vpn Id Id Service :: Cpipe VLL :: SAToPE1 Service Type Type Cpipe VLL Type Type SAToPE1 Name :: (Not Name (Not Specified) Specified) Description :: (Not Description (Not Specified) Specified) Customer :: 11 Customer Id Id Last Last Status Status Change: Change: 09/02/2011 09/02/2011 13:51:05 13:51:05 Last Last Mgmt Mgmt Change Change :: 09/02/2011 09/02/2011 13:51:12 13:51:12 Admin :: Up Oper :: Up Admin State State Up Oper State State Up MTU :: 1514 MTU 1514 Vc :: False Vc Switching Switching False SAP :: 11 SDP :: 33 SAP Count Count SDP Bind Bind Count Count ------------------------------------------------------------------------------------------------------------------------------------------------------------Service Service Access Access && Destination Destination Points Points ------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier Type AdmMTU Identifier Type AdmMTU OprMTU OprMTU Adm Adm Opr Opr ------------------------------------------------------------------------------------------------------------------------------------------------------------sap:aps-2.1.1.1.1 cem 1578 1578 Up Up sap:aps-2.1.1.1.1 cem 1578 1578 Up Up sdp:1:300 Spok 00 1550 Up Up sdp:1:300 S(192.0.2.3) S(192.0.2.3) Spok 1550 Up Up sdp:3:300 Spok 00 1550 Up Up sdp:3:300 S(192.0.2.1) S(192.0.2.1) Spok 1550 Up Up sdp:3:301 Spok 00 1550 Up Up sdp:3:301 S(192.0.2.1) S(192.0.2.1) Spok 1550 Up Up Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0 Module 3 | 195 All rights reserved © 2012 Alcatel-Lucent =============================================================================== ===============================================================================

View the MLS aPipe Status A: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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 195 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:MLS1# A:MLS1# show show service service id id 300 300 base base

CES Packet Loss

 Re-ordering is corrected in the jitter buffer on egress  Lost packet data (L bit=1) must be replaced to ensure proper TDM operation and prevent underruns  Typically the egress router inserts all ones, but any defined byte pattern may be used  Alternatively, the last frame received can be inserted

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

196

All rights reserved © 2012 Alcatel-Lucent

cPipe Packet Loss The CE-bound interworking function (IWF) uses the sequence numbers in the control word to detect lost and incorrectly ordered packets. Incorrectly ordered packets that cannot be reordered are discarded. For unstructured CES, the payload of received packets with the L bit set is replaced with an all-ones pattern. For structured CES, the payload of received packets with the L bit set is replaced with an all-ones or a userconfigurable bit pattern. This is configured using the idle-payload-fill command. For structured CES with CAS, the signaling bits are replaced with an all-ones or a user-configurable bit pattern. This is configured using the idle-signal-fill command. All circuit emulation services can have a status of up, loss of packets (LOP) or admin down, and any jitter buffer overruns or underruns are logged.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 196 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Packet loss or re-ordering is detected through packet sequence numbers in control word

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

197

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 197 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Model 2 Legacy Services – cPipe Detailed View

.5 Hour Lab Objectives:  On the CSA routers, provision redundant cPipe spoke SDPs and BTS facing SAPs  On the MLS routers, provision PW switching for the cPipe service  On the CR router, provision the cPipe spoke SDPs and NC SAPs  Verify service operation with SROS OAM tools Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

198

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 198 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Lab 9 : Configure 2G Voice cPipe Service

Section Review In this section, we:

 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

199

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 199 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

 Reviewed the Model 2 Legacy (ATM and TDM) 2 and 3G voice, data, and control traffic paths and services

Module Summary

 The components needed to build local and distributed Model 1 and Model 2 network services  Pseudowire redundancy protects the distributed VPWS services from the CSA to the POC3 and POC1 routers  Duplicated services at the POC3 and POC1 routers ensure that the BS has a path for traffic to and from the NC elements  A CCAG configured on a set of VSMs provides bidirectional logical links between L2 and L3 services on a local router  VRRP protects the NC element gateway interface with a virtual router instance  A management VPLS runs RSTP on behalf of a set of VLANs identified in a SAP’s managed-vlan-list

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

200

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 200 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

In this Module, we learned:

Module Summary (cont)

 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 Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

201

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 201 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

In this Module, we learned:

Module Summary (cont)

 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

202

All rights reserved © 2012 Alcatel-Lucent

Module 3 - Page 202 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

In this Module, we learned:

Module Review Questions

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

203

All rights reserved © 2012 Alcatel-Lucent

Answers: 1. A, D 2. c

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 203 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.)

Module Review Questions (cont)

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

204

All rights reserved © 2012 Alcatel-Lucent

Answers: 3. D 4. D

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 204 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

3. How many spoke SDP objects can be associated with a single explicit endpoint?

Module Review Questions (cont)

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

205

All rights reserved © 2012 Alcatel-Lucent

Answers: 5. A, B, D 6. B

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 205 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

5. What three options are available in the SROS for cross connecting a local L2 service to a local L3 service? (Choose three.)

Module Review Questions (cont)

_________________________________________________________ 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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

206

All rights reserved © 2012 Alcatel-Lucent

Answers: 7. A:NodeA>config>service>epipe>endpoint# standby-signaling-master 8. A:NodeA>config>service>epipe>endpoint# revert-time infinite 9. a, b

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 206 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

7. What command would you use on a VPWS endpoint to control the far-end PE’s active interface choice?

Module Review Questions (cont) 10.How might the NC element learn the VRRP virtual router MAC address? b) ARP request c) Master announcement message d) VRRP initialization message 11.What command in a management VPLS context identifies the VLANs the service protects? _________________________________________________________ 12.In an iPipe service, how does the service verify which ARP requests to answer and which to ignore? _________________________________________________________

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

207

All rights reserved © 2012 Alcatel-Lucent

Answers: 10. b 11. managed-vlan-list range 12. It ignores requests for any but the far-end ce-address MAC, and answers only those with the local SAP ceaddress as the source IP address

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 207 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

a) Forwarding database update

Module Review Questions (cont)

_________________________________________________________ 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? _________________________________________________________

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

208

All rights reserved © 2012 Alcatel-Lucent

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

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 208 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

13.On an iPipe SAP configured for PPP, what protocol passes the BTS IP address?

Module Review Questions (cont)

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? _________________________________________________________

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

209

All rights reserved © 2012 Alcatel-Lucent

Answers: 18. d. 19. configure service epipe 1 customer 1 vc-switching create 20. 0x26, pseudowire in standby, remote SAP down

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 209 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

18.Which statement best describes the S-PE function in a PW switched VPWS?

Module Review Questions (cont)

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? _________________________________________________________

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

210

All rights reserved © 2012 Alcatel-Lucent

Answers: 21. a, b 22. 0x20, PW forwarding standby 23. K1 and K2 bytes, on the protection facility

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 210 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

21.ICB-PW protected services require what configuration components to provide a last-resort path to the MC-protected SAP? (choose two.)

Module Review Questions (cont)

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? ____________________________________________________________ Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

211

All rights reserved © 2012 Alcatel-Lucent

Answers: 24. show aps aps-1 25. atm-vcc 26. 4, one per profile 27.satop-e1 or satop-t1 28.8x24=192 bytes

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 211 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

_______________________________________________________

Module Review Questions (cont)

a) 1ms b) 3ms c) 5ms d) 10ms 30.To carry a unchannelized E1 circuit in a structure agonostic cPipe service, how must the 7705 SAR TDM port be configured? a) framing cem b) framing e1-framed c) framing e1-unframed d) framing satop-e1

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

212

All rights reserved © 2012 Alcatel-Lucent

Answers: 29. b, 3 x the packetization delay, d = 125us/frame x 8 frames = 1ms 30. c

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 - Page 212 | All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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?

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Module 3 |

TTP36002 Edition 1

214

All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Appendix A — References

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Appendix A – Page 1| All rights reserved © 2012 Alcatel-Lucent

[1] Scott Larrigan, Alcatel-Lucent Product Marketing Manager. (2011, March). Faster, Smarter, Better: Converged All-IP Backhaul, Mobile World Congress 2011, Barcelona. Available: https://all1.us.alcatellucent.com/projects/SolutionDemos/Wiki%20Pages/Home.aspx [2] 3GPPTM home page. (2011, March 21). Available: www.3gpp.org [3] 3GPP2 home page. (2011, March 21). Available: www.3gpp2.org [4] About ITU. (2011, March 22). Available: www.itu.int/net/about/index.aspx [5] The Internet Engineering Task Force (IETF). (2011, March 22). Available: www.ietf.org [6] MEF home page. (2011, March 22). Available: metroethernetforum.org/index.php [7] IEEE home page. (2011, March 22). Available: www.ieee.org/index.html [8] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect – IP/MPLS MBH. (2010, November 16). LTE Solutions Key Topics – MBH1-MBH3 (Mobile Backhaul for IP/MPLS oriented MSP and BTP – R1.0) MBH1&3 R1.0. Available: TBD [9] Kevin English and Robert Castellano, Alcatel-Lucent Mobile Backhaul Solutions. (2009, November). Mobile Backhaul Blueprint Solution Customer Requirements Document, Baseline Version 1.0. Available: TBD [10] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2011, February 17). InterRegional Line Up on MBH. Available: https://sps.eu.alcatel-lucent.com/sites/Wireline.bell/default.aspx [11] Joseph Veltri, Alcatel-Lucent. (2009, March 13) APXLIB – d50989, EBH Transport Design Document for EV-DO and 3G1x EBH.R33.3.0. Available: TBD [12] Jorge Rabadan, Alcatel-Lucent. (2011, Q2) Vodafone Global IMATE Architecture, High Level Design Version 0.4. Draft. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe ll%2fShared%20Documents%2fCustomer%20Project%20Information%2fVodafone%2fVF%20Global%2fBEP1%2dIMATE% 2dFMC&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d [13] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2009, September). Solution Blueprint MBH 1/3: IP Mobile Backhaul High Level Design R1.0 Architect document – part 1a. Available: http://ct.web.alcatel-lucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100ABAA&root=ALU2010&selector=custom&custom_section=sol_collateral_view [14] Alcatel-Lucent white paper “Transforming to a Sustainable Wireless Business Model”. [15] D. Chislow, Alcatel-Lucent. (2008, July 11) SR/ESS PRD Synchronization PRD Revision: 1.3. Alcatel-Lucent Internal Use only. [16] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. Mobile Backhaul Challenges/Solutions R0.1. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe ll%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul%2fMBH%20Pr esentations%20%2d%20technology%20independent&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA 3%7d [17] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2010, April 12). MBH1/3 R1.0 HLD Documentation. Concepts, structure, and how to use. Available: http://ct.web.alcatel-lucent.com/prp/cgibin/public/ProductPortal.cgi?number=3MM-001010001&root=ALU2010&selector=custom&custom_section=sol_collateral_view [18] Alcatel-Lucent. Technology White Paper. IP/MPLS Transport in the Evolving GSM/UMTS Mobile Radio Access Network. Available: http://all.alcatellucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLt4x39A7QL8h2VAQAT8ihFw!!?LMSG_CA BINET=Solution_Product_Catalog&LMSG_CONTENT_FILE=Products/Product_Detail_000426.xml#tabAnchor4 [19] Alcatel-Lucent University. (2008) TER 36035 - 7705 SAR 3.0 IP/Ethernet Backhaul. Available: https://all1.us.alcatel-lucent.com/teams/ALUUOTTAWA/My%20Wiki%20Library/IPD_Lead_House.aspx [20] Adam Kasim. (2008) Delivering Carrier Ethernet: Extending Ethernet Beyond the LAN. Available: http://books.google.com/books?id=cznVxJ4QSnUC&pg=PA306&lpg=PA306&dq=sonet+vcg&source=bl&ots=K72f06G Z2b&sig=eVhE7j56ucLwBau0CXOJyrFPfaA&hl=en&ei=XeSxTa6HA8jx0gGsheXfBA&sa=X&oi=book_result&ct=result&r esnum=4&ved=0CDQQ6AEwAw#v=onepage&q=sonet%20vcg&f=false [21] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2009, September). MBH1/3 R1.0 HLD Documentation. Architecture document – part 2a v1.0. Available: http://ct.web.alcatellucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-001010001&root=ALU2010&selector=custom&custom_section=sol_collateral_view

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Appendix A – Page 2| All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

References

[22] Alcatel-Lucent University. (2008) IPBH w/VPRN and 7705. Available: https://all1.us.alcatellucent.com/teams/ALUUOTTAWA/My%20Wiki%20Library/IPD_Lead_House.aspx [23] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2010, November 16). LTE Solutions Key Topics – MBH1-MBH3 (Mobile Backhaul for IP/MPLS oriented MSP and BTP – R1.0) MBH1&3 R1.0 Available: http://___ KeyTopicsMBH1-3-LTE-20101115FINAL.ppt [24] ITU-T Recommendation G.824. (2000, March). Series G: Transmissions Systems and Media, Digital Systems and Networks, Digital transmission systems – Digital networks – Quality and availability targets. The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy. Available: http://www.itu.int [25] Anthony Magee, ADVA Optical Networking. (2010, October). IEEE Communications Magazine. Carrier Scale Ethernet, Synchronization in Next-Generation Mobile Backhaul Networks. Available: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05594685&tp=?ALU=LU1024572&tag=1 [26] Juniper Networks. (2011). White Paper. Synchronization Deployment Considerations for IP RAN Backhaul Operators. Juniper Networks TCA Series Timing Appliances Address the Complex Timing and Synchronization Requirements of 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-inCellular-Backhaul-Networks.pdf [28] Fred Davant, Alcatel-Lucent PLM LTE. (2007) LTE Transport, Synchronization and Security. Available: http:// [29] Pierre El-Haddad, Alcatel-Lucent. (2010, November) LTE Mobile Backhaul Reference Architectures. Available: http:// [30] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2010, May). Solution Blueprint MBH 1/3: IP Mobile Backhaul High Level Design R1.0 TDM service delivery. Available: http://ct.web.alcatellucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100ABAA&root=ALU2010&selector=custom&custom_section=sol_collateral_view [31] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH. (2009, September). Solution Blueprint MBH 1/3: IP Mobile Backhaul High Level Design v1.0 Synchronization. Available: http://ct.web.alcatellucent.com/prp/cgi-bin/public/ProductPortal.cgi?number=3MM-00100ABAA&root=ALU2010&selector=custom&custom_section=sol_collateral_view [32] D. Chislow, Alcatel-Lucent IPD Division. (2008, July 11) SR/ESS PRD Synchronization PRD. [33] US Government. Emerging Wireless Technologies. Enhanced 911 – Enhanced Wireless Emergency Communications. Available: http://www.safecomprogram.gov/NR/rdonlyres/D8BFF5A9-47A7-4496-AB93611DD043C3E0/0/emerging_wireless_technologies_enhanced_911.pdf [34] ITU-T Recommendation G.813. (1996, August). Series G: Transmissions Systems and Media, Digital transmission systems – Digital networks – Design objectives for digital networks. Timing characteristics of SDH equipment slave clocks (SEC). Available: http://www.itu.int [35] ITU-T Recommendation G.8262/Y.1362. (2010, July). Series G: Transmissions Systems and Media, Digital systems and networks – Quality and availability targets. Series Y: Global information infrastructure, Internet protocol aspects and next-generation networks. Internet protocol aspects - Transport. Timing characteristics of Synchronous Ethernet equipment slave clock (EEC). Available: http://www.itu.int [36] ITU-T Recommendation G.8262/Y.1362. (2008, October). Series G: Transmissions Systems and Media, Digital systems and networks – Quality and availability targets. Series Y: Global information infrastructure, Internet protocol aspects and next-generation networks. Internet protocol aspects - Transport. Distribution of timing information through packet networks. Available: http://www.itu.int [37] ITU-T Recommendation G.781. (2008, September). Series G: Transmissions Systems and Media, Digital systems and networks – Digital terminal equipments – Principle characteristics of multiplexing equipment for the synchronous digital hierarchy. Synchronization layer functions. Available: http://www.itu.int [38] IEEE 802.3-2008. (2008, December 26) IEEE Standard for Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements. Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and Physical Layer specifications. Annex 57A. Available: http:// www.ieee.org/index.html [39] Alcatel-Lucent. (2010, February). 2.2. 7705 SAR Synchronization Status Messages. Issued v1.0. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=% 2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d1 91A%2d473D%2d9199%2dD03A1C45808C%7d [40] P. Roberts. Alcatel-Lucent. (2011, April 6). PTPv2_Freq_PRD, 7x50_PRD_ptp1588_Freq_v1.4.doc. Alcatel Lucent Internal Use Only.

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Appendix A – Page 3| All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

References

References

[42] IEEE Instrumentation and Measurement Society. (2008, July 24) IEEE Std 1588-2008. IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. Available: http:// www.ieee.org/index.html [43] Andre Ethier, Alcatel-Lucent Wireless Division. (2011, March 18). LTE Synchronization Solutions for Claro Brazil. Available: http://www.alcatel-lucent.com [44] Jean-Loup Ferrant, et al. (2010, October). Development of the First IEEE 1588 Telecom Profile to Address Mobile Backhaul Needs. IEEE Communications Magazine, October 2010. available: http://ieee.org. [45] A. Vainshtein, et al. (2007, December). Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN). IETF Network Working Group Informational RFC. Available: http://tools.ietf.org/html/rfc5086 [46] Alcatel-Lucent University. (2005). Alcatel 3600+ MainStreet Bandwidth Manager Core Functions R9.0 Ver 1 [47] Tektonix, Inc. SDH Telecommunications Standard Primer. Available: http://www.tek.com/Measurement/App_Notes/sdhprimer/2RX_11694_2.pdf [48] Havard University. An Introduction to SDH and SONET. Available: http://people.seas.harvard.edu/~jones/cscie129/nu_lectures/lecture12/sonet/sonet.html [49] Cisco, Inc. A Brief Overview of SONET Technology. Available: http://www.cisco.com/en/US/tech/tk482/tk607/technologies_tech_note09186a0080094313.shtml [50] Wayne Jones Jnr. Chapter 17. SONET/SDH. Available: http://www.slideshare.net/WayneJonesJnr/ch173361668 [51] Alcatel-Lucent University. (2001, July). 1631 SX LMC Operations and Maintenance Student Guide. 1631LM310250. Issue 3.00. Available: http://www.alcatel-lucent.com [52] Alcatel-Lucent. (2008, May). 3.4 7705 SAR Synchronization R1.0 v1.0. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=% 2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d1 91A%2d473D%2d9199%2dD03A1C45808C% [53] TechFest.com. SONET/SDH Technical Summary. Available: http://www.techfest.com/networking/wan/sonet.htm [54] Telecommunication Research Associates. (2000) The Pocket Network Guide. Alcatel. Version 1.0. Available: http://www.tra.com [55] Silvana Rodriques, IDT. Sebastian Jobert, France Telecom. IDT. (2009, November) IEEE-1588 Profiles. Presentation to ITSF-09, Rome, November 3 to 5, 2009. Available: http://www.telecomsync.com/pdf/2009/Day1/IDT%20IEEE-1588%20Profiles.pdf [56] Craig Preuss, PE. Engineering Manager, Black & Veatch Corp. (Date unknown) Perfect Timing – How IEEE Standard PC37.238 Impacts Substation Automation. Available: http://ewh.ieee.org/cmte/substations/scm0/Chicago%20Meeting/Conference%20PDFs/tutorial%20handouts/Coll oquium/Impact%20of%20Time%20Synch%20on%20Sub%20Automation%20-%20Preuss.pdf

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Appendix A – Page 4| All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

[41] Christian Hublet, Alcatel-Lucent IP DBC Solution Architect - – IP/MPLS MBH./Peter Roberts. Alcatel-Lucent. (2011, April) Alcatel-Lucent PTP Design Guidelines (Draft), Issue 1. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=% 2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d1 91A%2d473D%2d9199%2dD03A1C45808C%7d

References [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.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe ll%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul&View=%7bE7 F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d [59] Alcatel-Lucent. (2011, March). 7750 SR OS Router Configuration Guide. Software Version: 7750 SR OS 9.0R1. Document Part Number: 93-0073-08-01. Available: https://market.alcatellucent.com/release/jsp/sso/login.jsp?TYPE=33554433&REALMOID=06-3cffeb57-8088-001e-00006f4900006f49&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$Vs%2fCwDSWZ8BOHkVOoewB7IvXS BgFCYcdLKauGuwzsJHsPRgrWps%2f0Exm%2fL%2bHbAmU&TARGET=$SM$https%3a%2f%2fwww1%2ealcatellucent%2ecom%2fosds%2f%3f_requestid%3d23167 [60] Walter Goralski. (2002). SONET/SDH. Third Edition. ISBN 0-07-222524-6. McGraw-Hill/Osborne. 2600 Tenth Street, Berkely, California, 94710. [61] William Pacino. (Date unknown.) Telecommunications Standards Primer. What is SDH? Available: http://users.rcn.com/wpacino/sdh_2pri.htm [61] Juniper Networks. (Date unknown). Configuring Multilink PPP – Overview. Available: http://www.juniper.net/techpubs/software/erx/junose72/swconfig-link/html/mlppp-config2.html [62] Paul Reid, Alcatel-Lucent. (2009, November). 7705 Service Aggregation Router. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/SROS%20Workshops%20and%20config%20notes/Forms/AllItems.aspx?RootFolder=% 2fsites%2fWireline%2ebell%2fSROS%20Workshops%20and%20config%20notes%2fWorkshops&View=%7b2939F1A8%2d1 91A%2d473D%2d9199%2dD03A1C45808C% [63] Dr. Yaakov Stein, Chief Scientist, RAD Communications. (2006, August) RAD Data Communications White Paper. TDM Timing. Available: http://www.dspcsp.com/RAD/tdm_timing_wp.pdf [64] Alcatel-Lucent. (2011, March). 7750 SR OS Services Guide. Software Version: 7750 SR OS 9.0 r1. Available: http://www.alcatel-lucent.com. [65] Alcatel-Lucent. (2011, April). Alcatel-Lucent Services Architecture. Version 3.1. Student Guide. Available: http://www.alcatel-lucent.com/src. [66] Zhuo (Frank) Xu, Alcatel-Lucent. (2010). Designing and Implementing IP/MPLS-Based Ethernet Layer 2 VPN Services – An Advanced Guide for VPLS and VLL. Available: http://www.alcatel-lucent.com/src. [67] L. Martini, Cisco Systems, Inc. (2006, April). Network Working Group. Request for Comments: 4446. IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). Available: http://ietf.org [68] Praveen Muley and Mustapha Aissaoui, ed. (2011, March 11). Network Working Group. Internet Draft. draftietf-pwe3-redundancy-bit-04.txt. Pseudowire Preferential Forwarding Status Bit. Available: http://ietf.org. [69] Alcatel-Lucent. (2010). Alcatel-Lucent Virtual Private LAN Services. Version 2.0. Student Guide. Available: http://www.alcatel-lucent.com/src. [70] Alcatel-Lucent. (2009) Alcatel LIghtspeed TAC Overview. 3FL30501. Edition 4. Available: http://www.alcatel-lucent.com [71] Lyn Rees, EMEA Qual Assur and Cust Care. Alcatel-Lucent. (February 24, 2009). Mobile Backhaul MCAPS/PWE3 Redundancy. MC-APS/PWE3 Redundancy – Configuration. Available: https://sps.eu.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe ll%2fShared%20Documents%2fSolution%20info%2fCDMA&View=%7bE7F1A86E%2d0058%2d495F%2dBC65%2d5AD94F72 3DA3%7d

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Appendix A – Page 5| All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

[57] Microsoft. (Date unknown) TechNet Library, IPv6 Identifiers. Available: http://technet.microsoft.com/enus/library/cc736439%28WS.10%29.aspx.

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.alcatellucent.com/sites/Wireline.bell/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fWireline%2ebe ll%2fShared%20Documents%2fSolution%2dMarketing%2demea%2dinfrastructure%2fMobile%20Backhaul&View=%7bE7 F1A86E%2d0058%2d495F%2dBC65%2d5AD94F723DA3%7d [73] Alcatel-Lucent. (2011, March). 7750 SR OS Interfaces Guide. Software Version: 7750 SR OS 9.0 r1. Available: http://www.alcatel-lucent.com. [74] Anthony Peres, Keith Allan, PLM. (2003) 7x50 Product Briefing for Release 3.0. Available: http://www.alcatel-lucent.com [75] Gerwyn Frowen, Alcatel-Lucent EMEA QA and Customer Care. (2009, October 19). 7705 SAR 2.1 1588v2 Client. Issued 1.1. (Split from r2.1 Update Presentation) Available: http://www.alcatel-lucent.com. [76] NGMN Alliance. (2011, July). ngmn LTE backhauling deployment scenarios by NGMN Alliance. v1.4.2. FINAL. Editor/Submitter: Miguel Angel Alvarez, Frederic Jounay, Tamas Major, Paolo Volpato. Avaible: www.ngmn.org

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport v1.0

Appendix A – Page 6| All rights reserved © 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

.

TTP36002 Edition 1

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com