Design Guide

Design Guide JuNIper Networks uNIversal aCCess aND aGGreGatIoN MBH 1.0 DesIGN GuIDe Copyright © 2013, Juniper Networks, Inc. 1 Design Guide - Juniper Networks universal and aggregation MBH 1.0 this product includes the envoy sNMp engine, developed by epilogue technology, an Integrated systems Company. Copyright © 1986-1997, epilogue technology Corporation. all rights reserved. this program and its documentation were developed at private expense, and no part of them is in the public domain. this product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, university of toronto. this product includes FreeBsD software developed by the university of California, Berkeley, and its contributors. all of the documentation and software included in the 4.4BsD and 4.4BsD-lite releases is copyrighted by the regents of the university of California. Copyright ©1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. the regents of the university of California. all rights reserved. GateD software copyright © 1995, the regents of the university. all rights reserved. Gate Daemon was originated and developed through release 3.0 by Cornell university and its collaborators. Gated is based on kirton’s eGp, uC Berkeley’s routing daemon (routed), and DCN’s Hello routing protocol. Development of Gated has been supported in part by the National science Foundation. portions of the GateD software copyright © 1988, regents of the university of California. all rights reserved. portions of the GateD software copyright © 1991, D.l. s. associates. this product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc. Juniper Networks, Junos, steel-Belted radius, Netscreen, and screenos are registered trademarks of Juniper Networks, Inc. in the united states and other countries. the Juniper Networks logo, the Junos logo, and Junose are trademarks of Juniper Networks, Inc. all other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: u.s. patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785. Juniper Networks Universal Access and Aggregation MBH Design Guide release 1.0 Copyright © 2013, Juniper Networks, Inc. all rights reserved. revision History september 2013—Initial release the information in this document is current as of the date on the title page. END USER LICENSE AGREEMENT the Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. use of such software is subject to the terms and conditions of the end user license agreement (“eula”) posted at http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions 2 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Table of Contents eND user lICeNse aGreeMeNt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 part 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 overview of the universal access and aggregation Domain and Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 universal access and aggregation Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Market segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 MBH use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 what is MBH? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 types of MBH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 MBH Network and service architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 MBH Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 access segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 preaggregation and aggregation segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Core segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 MBH Network layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 end-to-end timing and synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 end-to-end Mpls-Based services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 end-to-end Mpls transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 seamless Mpls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 type of Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 end-to-end Hierarchical lsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Decoupling services and transport with seamless Mpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Mobile service profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2G service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3G service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Hspa service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4G lte service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 MBH service architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 solution value proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Juniper Networks solution portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 part 2: Design and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Design Considerations workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Gathering end-to-end service requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Copyright © 2013, Juniper Networks, Inc. 3 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Designing the Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 planning the Network topology and regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Deciding on the platforms to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Defining the MBH Network service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Designing the Mpls service architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Designing uNI properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Designing NNI Cos profiles and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Designing the Ip and Mpls transport layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Designing timing and synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 verifying the Network and product scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Considering the Network Management system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 topology Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 planning the Network segment and regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 access segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 preaggregation and aggregation segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Core segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Number of Nodes in the access and preaggregation segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 sizing the MBH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 MBH service profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4G lte service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Defining the Cos attribute at the uNI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Hspa service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 end-to-end layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 layer 2 vpN to layer 3 vpN termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 end-to-end Hierarchical vpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3G and 2G service profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Cos planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 timing and synchronization planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 synchronous ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Ieee 1588v2 precision timing protocol (ptp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 ordinary Clock Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 ordinary Clock slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 synchronization Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 end-to-end Ieee 1588v2 with a Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 end-to-end Ieee 1588v2 with an ordinary Clock in the access segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 synchronous ethernet scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 end-to-end Ip/Mpls transport Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Implementing routing regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Intradomain Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 IGp protocol Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 using Is-Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 using ospF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Intradomain lsp signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Deciding on the lsp topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Interdomain lsp signaling with BGp-labeled unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Mpls services Design for the 4G lte profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 end-to-end layer 3 vpN Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 vrF Import and export policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 u-turn layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Ip/Mpls transport and service Full picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Mpls service Design for the Hspa service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 layer 2 vpN to layer 3 vpN termination scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Hierarchical vpls for Iub over ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Mpls service Design for the 3G service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Mpls service Design for the 2G service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 oaM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Intrasegment oaM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Intersegment oaM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 High availability and resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Correcting a Convergence event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Detecting Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Flooding the Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Finding an alternate path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 updating the Forwarding table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Components of a Complete Convergence solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 local repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Intrasegment transport protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Intersegment transport protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 end-to-end protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 layer 3 vpN end-to-end protection for 4G lte profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Copyright © 2013, Juniper Networks, Inc. 5 Design Guide - Juniper Networks universal and aggregation MBH 1.0 pseudowire redundancy for the Hspa service profile (layer 3 vpN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 pseudowire redundancy for the Hspa service (H-vpls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 providing transport services for Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 MBH Network Management system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 Design Consistency and scalability verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 sample MBH Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Cell site router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 rIB and FIB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Mpls label FIB (l-FIB) scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Csr scaling analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 aG 1 router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 rIB and FIB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Mpls label FIB (l-FIB) scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 aG 1 router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 aG 2 router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 rIB and FIB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Mpls label FIB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 aG 3 router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 rIB and FIB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Mpls label FIB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 part 3: Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 recommendations for IGp region Numbering and Network addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 loopback and Infrastructure Ip addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 uNI addressing and layer 3 vpN Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Management (fxp0) Interface addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Network topology overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Hardware Inventory output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Configuring Ip and Mpls transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Configuring the Network segments and Is-Is protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Configuring Intrasegment Mpls transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Configuring Intrasegment oaM (rsvp lsp oaM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Configuring Intersegment Mpls transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Configuring end-to-end layer 3 vpN services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 6 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring Mp-BGp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Configuring the routing Instance for the layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 Configuring layer 2 vpN to layer 3 vpN termination services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Configuring layer 2 pseudowires in the access segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152 Configuring Inter-as layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Configuring a layer 2 pseudowire to layer 3 vpN termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Configuring a layer 2 vpN to vpls termination service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Configuring a pseudowire in the access segment (vpls spoke) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Configuring a vpls Hub in the preaggregation segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Configuring end-to-end Inter-autonomous system vpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Configuring atM pseudowire and satop/CesopsN services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Configuring atM and tDM transport pseudowire end-to-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Configuring timing and synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Configuring ptp timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Configuring synchronous ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Configuring Class of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Configuring Class of service on Cell site routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Configuring Class of service on aG 1, aG 2, and aG 3 routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Copyright © 2013, Juniper Networks, Inc. 7 Design Guide - Juniper Networks universal and aggregation MBH 1.0 List of Figures Figure 1: universal access solution extends universal edge Intelligence to the access Domain . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 2: universal access and aggregation Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 3: architectural transformation of Mobile service profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Figure 4: MBH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Figure 5: MBH Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 6: MBH Network layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figure 7: seamless Mpls Functional elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 8: Multiregion Network within one autonomous system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 9: Multiregion Network with Numerous autonomous systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 10: seamless Mpls Functions in a 4G lte Backhaul Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 11: seamless Mpls Functions in an Hspa Backhaul Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 12: MBH service profiles and Deployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 13: Juniper Networks platforms in the MBH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Figure 14: ring topology in an access segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figure 15: Hub-and-spoke topology in the access segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 16: large-scale MBH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 17: Network segment sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Figure 18: recommended service architecture for 4G lte service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 19: Hspa service profile with end-to-end layer 3vpN and pseudowire in the access segment . . . . . . . . . . . . . . . . 44 Figure 20: Hspa service profile with end-to-end vpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 21: 3G and 2G Networks with atM and tDM Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 22: Cos Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 23: 802.1p and DsCp to eXp rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 24: Ieee 1588v2 end-to-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Figure 25: Ieee 1588v2 end-to-end with Boundary Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Figure 26: Ieee 1588v2 and synchronous ethernet Combined scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Figure 27: Ieee 1588v2, synchronous ethernet, and BIts Combined scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Figure 28: semi-Independent access Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figure 29: IGp lsa Boundaries within the access segment and semi-Independent Domain . . . . . . . . . . . . . . . . . . . . . . . . . 59 Figure 30: routing Information Isolation with the Is-Is protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Figure 31: routing Information Isolation with the ospF protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Figure 32: establishing an Inter-as lsp with BGp-lu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Figure 33: layer 3 vpN Design for the 4G lte service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figure 34: end-to-end layer 3 vpN Deployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 35: layer 3 vpNs with a Full Mesh topology – vpN-s1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figure 36: layer 3 vpNs with a Full Mesh topology – vpN-X2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figure 37: vrF Import and export policies for s1 layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Figure 38: using vrF Import and export policies for X2 layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 8 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Figure 39: end-to-end layer 3 vrF Deployment scenarios with u-turn vrF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Figure 40: end-to-end layer 3 vpN and Data Flow for eNodeB to 4G epC Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Figure 41: end-to-end layer 3 vpN and Data Flow for eNodeB to eNodeB Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Figure 42: layer 2 vpN termination into layer 3 vpN for the Hspa service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 43: end-to-end layer 3 vpN with layer 2 vpN termination Deployment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figure 44: H-vpls service Model for the Hspa service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Figure 45: end-to-end H-vpls Deployment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Figure 46 Mpls pseudowire for Iub over atM (3G service profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figure 47: end-to-end atM and tDM pseudowire Deployment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Figure 48: Mpls pseudowire for abis over tDM for the 2G service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Figure 49: Mpls pseudowire for abis over tDM (2G service profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Figure 50: oaM in the MBH solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Figure 51: Intrasegment Facility link and link-Node protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Figure 52: Intrasegment Facility protection with lDp tunneling over rsvp in the access segment . . . . . . . . . . . . . . . . . . . 85 Figure 53: Intrasegment path protection with lDp tunneling over an rsvp lsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Figure 54: Intersegment transport protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure 55: end-to-end protection for end-to-end layer 3 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Figure 56: end-to-end protection for layer 2 vpN to layer 3 vpN termination scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Figure 57: Maintaining traffic path Consistency for layer 2 vpN termination to layer 3 vpN. . . . . . . . . . . . . . . . . . . . . . . . . 89 Figure 58: end-to-end protection for Hspa service profile (H-vpls Deployment scenario) . . . . . . . . . . . . . . . . . . . . . . . . 90 Figure 59: MBH Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Figure 60: regional large-scale MBH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Figure 61: Format for Is-Is area Number addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Figure 62: sample MBH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Figure 63: sample Network topology with Ip addressing, Is-Is, and BGp autonomous systems . . . . . . . . . . . . . . . . . . . . . 114 Figure 64: Intrasegment Mpls Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Figure 65: Intersegment Mpls Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Figure 66: Mp-BGp Deployment for layer 3 vpN services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 Figure 67: end-to-end layer 3 vpN Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 Figure 68: layer 2 vpN to layer 3 vpN termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Figure 69: Deployment scenario of layer 2 vpN to layer 3 vpN termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152 Figure 70: layer 2 vpN to vpls termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Figure 71: Deployment scenario of layer 2 vpN to vpls termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Figure 72: Deployment of satop and CesopsN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Figure 73: ptp Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Figure 74: synchronous ethernet Deployment topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Figure 75: topology for Cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 Copyright © 2013, Juniper Networks, Inc. 9 Design Guide - Juniper Networks universal and aggregation MBH 1.0 List of Tables table 1: terms and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 table 2: Mobile Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 table 3: Mobile Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 table 4: Mpls service types across the MBH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 table 5: Juniper Networks platforms Included in the universal access and aggregation MBH solution . . . . . . . . . . . . . . . 30 table 6: requirements for MBH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 table 8 4G lte Qos Class Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 table 9: MBH Cos with six Forwarding Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 table 10: Mobile Network service Mapping to Cos priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 table 11: Mobile Network services Mapping to MBH Cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 table 12: Node Functions and IGp protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 table 13: Mpls service for the 4G lte service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 table 14: Mpls service for the Hspa service profile—Iub over Ip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 table 15: Hspa services - Iub over ethernet layer 2 vpN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 table 16: 3G services on Iub over atM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 table 17: services on 2G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 table 18: sample Network segment size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 table 19: sample Network services and service locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 table 20: scaling analysis and verification for the Csr FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 table 21: Cell site router scaling analysis for the l-FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 table 22: Cell site router scaling analysis for service labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 table 23: Cell site router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 table 24: aG 1 router scaling analysis for the FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 table 25: aG 1 router scaling analysis for the l-FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 table 26: aG 1 router scaling analysis for service labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 table 27: aG 1 router scaling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 table 28: aG 2 router scaling analysis for the FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 table 29: aG 2 router scaling analysis for the l-FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 table 30: aG 2 router scaling analysis for service labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 table 31: aG 3 router scaling analysis for the FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 table 32: aG 3 router scaling analysis for the l-FIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 table 33: aG 3 router scaling analysis for service labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 table 34: Ipv4 addressing and IGp region Numbering schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 table 35: layer 3 vpN attribute Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 table 36: Hardware Components for the Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 table 37: sample MBH Network Ip-addressing schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 10 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Part 1: Introduction this part includes the following topics: • overview of the universal access and aggregation Domain and Mobile Backhaul • MBH Network and service architecture • Juniper Networks solution portfolio Overview of the Universal Access and Aggregation Domain and Mobile Backhaul this guide provides the information you need to design a mobile backhaul (MBH) network solution in the access and aggregation domain (often referred to as just the access domain in this document) based on Juniper Networks software and hardware platforms. the universal access domain extends from the customer in the mobile, residential, or business—Carrier ethernet services (Ces) and Carrier ethernet transport (Cet)—segment to the universal edge. the focus of this guide is the mobile backhaul (MBH) network for customers in the mobile segment. Customers are eager to learn about Juniper Networks MBH solutions for large and small networks. solutions based on seamless end-to-end Mpls, and the aCX series and MX series routers allow Juniper Networks to deliver MBH solutions that address the legacy and evolution needs of the MBH, combining operational intelligence and capital cost savings. this document serves as a guide to all aspects of designing Juniper Networks MBH networks. the guide introduces key concepts related to the access and aggregation network and to MBH, and includes working conigurations. the advantages of the Junos os together with the aCX series and MX series routers are covered in detail with various use cases and deployment scenarios. Connected to the MX series routers, we use the tCa timing servers to provide highly accurate timing that is critical for mobile networks. this document is updated with the latest Juniper Networks MBH solutions. Audience the primary audience for this guide consists of: • Network architects—responsible for creating the overall design of the network architecture that supports their company’s business objectives. • sales engineers—responsible for working with architects, planners, and operations engineers to design and implement the network solution. the secondary audience for this guide consists of: • Network operations engineers—responsible for creating the coniguration that implements the overall design. also responsible for deploying the implementation and actively monitoring the network. Terminology table 1 lists the terms, acronyms, and abbreviations used in this guide. Table 1: Terms and Acronyms Term Description 2G second generation 3G third generation 3Gpp third-Generation partnership project 4G lte fourth-generation long term evolution (refers to 4G wireless broadband technology) abis Interface between the Bts and the BsC aBr area border router aN access node apN access point name arp address resolution protocol as autonomous system atM asynchronous transfer Mode Ba behavior aggregate (classiiers) BBF Broadband Forum BCD binary-coded decimal Copyright © 2013, Juniper Networks, Inc. 11 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Term 12 Description BFD Bidirectional Forwarding Detection (protocol) BGp Border Gateway protocol BGp-lu BGp-labeled unicast BIr bit error rate BN border node Bs base station BsC base station controller Bts base transceiver station Capex capital expenditure Ce customer entity or customer edge, depending on the context Ces Carrier ethernet services CesopsN Circuit emulation service over packet-switched Network Cet Carrier ethernet transport CFM connectivity fault management CIr committed information rate ClI command-line interface Co central oice Cos class of service CsG cell site gateway Csr cell site router DHCp Dynamic Host Coniguration protocol DlCI data-link connection identiier DsCp Diferentiated services code point eBGp external BGp eeC ethernet equipment Clock eNodeB enhanced NodeB epC evolved packet core esMC ethernet synchronization Messaging Channel ev-Do evolution-Data optimized eXp bit Mpls code point FCaps fault, coniguration, accounting, performance, and security management FDD frequency-division duplex FeC forwarding equivalence class FIB forwarding information base Frr fast reroute (Mpls) Gbps Gigabits per second GGsN Gateway Gprs support Node GM grandmaster GNss Global Navigation satellite system Gprs General packet radio service GsM Global system for Mobile Communications Hlr Home location register Hspa high-speed packet access H-vpls hierarchical vpls IBGp internal BGp Ieee Institute of electrical and electronics engineers IGp interior gateway protocol IMa inverse multiplexing for atM Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Term Description Ip Internet protocol Is-Is Intermediate system-to-Intermediate system Issu in-service sotware upgrade Itu International telecommunication union Iub Interface uMts branch—Interface between the rNC and the Node B laN local area network lDp label Distribution protocol lDp-DoD lDp downstream on demand lFa loop-free alternate l-FIB label forwarding information base lFM link fault management lIu line interface unit lol loss of light lsa link-state advertisement lsI label-switched interface lsp label-switched path (Mpls) lsr label-switched router lte long term evolution lte-tDD long term evolution – time Division Duplex MBH mobile backhaul MC-laG multichassis link aggregation group MeF Metro ethernet Forum MF multiield (classiiers) MMe mobility management entity Mp-BGp multiprotocol-BGp Mpls Multiprotocol label switching MsC Mobile switching Center Msp managed services provider Mttr mean-time-to-resolution NlrI network layer reachability information NMs network management system NNI network-to-network interface Nsr nonstop routing Ntp Network time protocol oaM operation, administration, and Management opex operational expenditure os operating system osI open systems Interconnection ospF open shortest path First pCu packet Control unit pDsN packet data serving node pDu protocol data unit pe provider edge pGw packet Data Network Gateway plr point of local repair pop point of presence pps packets per second prC primary reference clock Copyright © 2013, Juniper Networks, Inc. 13 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Term Description psN packet-switched network pstN public switched telephone network (or telecom network) ptp precision timing protocol pwe3 IetF pseudowire emulation edge to edge Qoe quality of experience Qos quality of service raN radio access Network re routing engine rIB routing information base, also known as routing table rNC radio network controller rsvp resource reservation protocol s1 Interface between the eNodeB and the sGw saFI subsequent address family identiier satop structure-agnostic time Division Multiplexing (tDM) over packet sGsN serving Gprs support Node sGw serving Gateway sH service helper sla service-level agreement sMs short message service sN service node spF shortest path irst tD-CDMa time division-code-division multiple access tDD time division duplex tDM time-division multiplexing tD-sCDMa time-division–synchronous code-division multiple access t-lDp targeted-lDp tN transport node uMts universal mobile telecommunications system uNI user-to-network interface utraN uMts terrestrial radio access Network vCI virtual circuit identiier vlaN virtual laN voD video on demand vpI virtual path identiier vpls virtual private laN service vpN virtual private network vrF vpN routing and forwarding (table) vrrp virtual router redundancy protocol wCDMa wideband Code Division Multiple access X2 Interface between eNodeBs, or between eNodeB and the MMe Universal Access and Aggregation Domain the universal access and aggregation domain (often referred to as just the access domain in this document) is composed of the network that extends from the customer in the mobile, residential, or business—Carrier ethernet services (Ces) and Carrier ethernet transport (Cet)—segment to the universal edge. the focus of this guide is the mobile backhaul (MBH) network for customers in the mobile segment. universal access is the means by which disparate technologies developed for mobile, residential, and business purposes converge into an integrated network architecture. the disparate technologies have evolved over time from circuit switched to packet switched, from time-division multiplexing (tDM) to Ip and ethernet, and from wireline to wireless. 14 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the universal edge is the means by which service providers deliver services to the customer—services such as overthe-top video, Iptv, high-speed Internet, video on demand (voD), and transactional services. the converged universal access network complements the universal edge with a seamless end-to-end service delivery system. (see Figure 1.) UNIVERSAL ACCESS UNIVERSAL EDGE DATA CENTERS Mobile IP / INTERNET IP/MPLS ACX Series Residential Backbone Business (CES/CET) Single OS Single Control Plane Seamless End-to-end Service Operational Simplicity and Scale Financial Viability Figure 1: Universal Access Solution Extends Universal Edge Intelligence to the Access Domain DOMAIN the access and aggregation domain is divided into three use cases: mobile or MBH, business or Ces/Cet, and residential (see Figure 2). each use case is further divided into various service profiles, depending on the underlying media, service provisioning, topology, and transport technology. Common to all use cases is the need to provide an end-to-end network and service delivery, timing, synchronization, and network management. the focus of this design guide is the MBH use case. SERVICE PROFILES USE CASES ACCESS & AGGREGATION 

 2G 3G HSPA SIDENTIAL
  4G LTE E-LINE E-LAN E-TREE ACCESS Legacy Transport Migration Different Service Delivery Models Foundation Technologies (Seamless MPLS, End-to-End Service Restoration, Timing and Sync) Network Management Figure 2: Universal Access and Aggregation Domain Copyright © 2013, Juniper Networks, Inc. 15 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the mobile backhaul (MBH) use case covers the technologies that must be deployed to connect mobile service provider cell sites (base stations) to the regional mobile controller site (BsC/rNC) or mobile packet core (sGw/pGw/MMe). this use case presents complexity due to the need to support various legacy and next-generation technologies. Mobile service providers must continue to support legacy service profiles that enable 2G and 3G service as well as newer and next-generation service profiles that support Hspa and 4G lte services. each service profile adds potential complexity and management overhead to the network. the service provider must deal with various transports required to support these service profiles while also working to reduce capital and operational expenditures (Capex/opex) of the MBH network. Mobile operators also seek to increase the average revenue per user through a focus on implementing a flexible architecture that can easily change to allow for the integration of enhanced and future services. Market Segments one of the main market factors fueling a movement toward a unified and consolidated network is the rising cost of MBH. Combine this cost increase with the ongoing exponential increase in mobile bandwidth consumption and the introduction and rapid migration to 4G lte, and the cost problem is further exacerbated. the subscriber’s consumption of high-bandwidth, delay-sensitive content such as video chat, multiplayer real-time gaming, and mobile video largely fuels the increasing demand for bandwidth. another factor to consider is the security of the underlying infrastructure that protects the packet core and access network. all these factors converge into a formula that makes it difficult for mobile operators to reduce Capex and opex. the increasing complexity of the network makes these goals harder to achieve; this makes the drive to increase average revenue per user a much more difficult proposition. Given the challenges in this market segment, an ideal MBH network is one that is designed with a focus on consolidation and optimization. this focus allows for more eicient installation, service provisioning, and operation of the network. MBH Us as the MBH use case described in this guide includes four service profiles for the different generations of wireless technologies—2G, 3G, Hspa, and 4G long term evolution (lte). each service profile represents a fundamental change in the nature of the cellular wireless service in terms of transport technology, protocols, and access infrastructure. the changes include a move from voice-oriented time-division multiplexing (tDM) technology toward data center-oriented Ip/ethernet and the presence of many generations of mobile equipment, including 2G and 3G legacy as well as 4G lte adoption. Because the MBH solution supports any generation of mobile infrastructure, it is possible to design a smooth migration to 4G using the information in this guide. (see Figure 3.) INTERNET INTERNET IP HOSTED SERVICES IP OFF-NET SERVICE PSTN ON-NET SERVICE PCRF PCRF GGSN MME SGW Hierarchical to Flat GW/MSC SGSN Hub-Spoke to Fully HLR Meshed PGW 3GPP Evolved Packet Core HSS TDM/ATM to ALL-IP ATM/IP IP RNC/BSC TDM/ATM UTRAN Node B Node B Enhanced Node B (eNodeB) Figure 3: Architectural Transformation of Mobile Service Profiles 16 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Problem Statement the fundamental problem with the MBH segment is the inherent complexity introduced by the various network elements needed to properly support the multiple generations of technology required to operate a complete MBH network. this complexity conflicts with the provider’s ability to provide increased average revenue per user. Increasing margin per user can be achieved by decreasing the overall cost of the network infrastructure, but how? as users demand more bandwidth and higher quality services, the traditional answer has been “more bandwidth.” to increase average margin per user, a service provider has to either charge more per subscriber or lower the cost of the network. the ability to lower network cost, from an implementation, ongoing operational, and lifecycle perspective is the focus of the MBH solution. the Juniper Networks MBH solution collapses the various MBH technologies into a converged network designed to support the current footprint of access technologies while reducing complexity and enabling simpler, more cost-effective network operation and management. this optimization enables easier adoption of future technologies and new services aimed at enhancing the subscriber experience. the service provider can achieve Capex and opex reduction and facilitate higher average revenue per user by focusing on three key areas: implementing high-performance transport, lowering the total cost of ownership of the network, and enabling deployment flexibility. providers have become used to the relative simplicity and reliability of legacy tDM networks: a packet-based network should provide similar reliability and operational simplicity and flexibility. additional challenges are emerging that place further emphasis on the need for high-performance transport. Flat subscriber fees combined with an exponential increase in demand for a high-quality user experience (measured by increased data and reliability) demand that new, more flexible business models be implemented to ensure the carrier’s ongoing ability to provide this user experience. lowering the total cost of ownership of the MBH network is at direct odds with the need for high-performance transport. the operating expense associated with MBH is increasing due not only to the growth in user data but also the increasing cost of space, power, cooling, and hardware to support new technologies (as well as maintaining existing infrastructure to support legacy services). as more sites are provisioned, and as the network complexity increases, the need to deploy support to a wider footprint of infrastructure further erodes the carrier’s ability to decease the total cost of ownership of the network. Finally, deployment flexibility is a concern as the carrier’s move more into packet-based networks. the ability of a service provider to meet strict service-level agreements (slas) requires deployment of new technologies to monitor and account for network performance. the addition of a wider array of management platforms also decreases the service provider’s ability to increase the average margin per user of the MBH network. the Juniper Networks universal access MBH solution is the first fully integrated end-to-end network architecture that combines operational intelligence with capital cost savings. It is based on end-to-end Ip and Mpls combined with high-performance Juniper Networks infrastructure, which allows operators to have universal access and extend the edge network and its capabilities to the customer, whether the customer is a cell tower, a multitenant unit, or a residential aggregation point. this creates a seamless network architecture that is critical to delivering the benefits of fourth-generation (4G) radio and packet core evolution with minimal truck rolls, paving the way for new revenue, new business models, and a more flexible and efficient network. addressing the challenges faced in the access network by mobile service providers, this document describes the Juniper Networks universal access MBH solution that addresses the legacy and evolution needs of the mobile network. the solution describes design considerations and deployment choices across multiple segments of the network. It also provides implementation guidelines to support services that can accommodate today’s mobile network needs and support legacy services on 2G and 3G networks and provide a migration path to lte-based services. although this guide provides directions on how to design an MBH network for 2G, 3G, Hspa, and 4G lte with concrete examples, the major focus is the more strategic plans for a fully converged access, aggregation and edge network infrastructure. this infrastructure provides end-to-end services to all types of consumers, including business and residential subscribers in agreement with industry standards and recommendations that come from the Broadband Forum (BBF), Metro ethernet Forum (MeF), and 3rd Generation partnership project (3Gpp) working groups. What is MBH? the backhaul is the portion of the network that connects the base station (Bs) and the air interface to the base station controllers (BsCs) and the mobile core network. the backhaul consists of a group of cell sites that are aggregated at a series of hub sites. Figure 4 shows a high-level representation of mobile backhaul (MBH). the cell site consists of either a single Bs that is connected to the aggregation device or a collection of aggregated Bss. Copyright © 2013, Juniper Networks, Inc. 17 Design Guide - Juniper Networks universal and aggregation MBH 1.0 4G EPC eNodeB MOBILE BACKHAUL NodeB 3G RNC BTS 2G BSC Figure 4: MBH the MBH network provides transport services and connectivity between network components of the mobile operator network. Depending on the mobile network type, the mobile network might include a number of components that require connectivity by means of a variety of data-level and network-level protocols. (see table 2.) Table 2: Mobile Network Elements Mobile Network Generation Technology Network Element Function 2G GsM Bts Communication between air interface and the base station controller (BsC) BsC Controls multiple base stations (Bss) MsC Handles voice calls and short message service (sMs) Bts Communication between air interface and BsC sGsN Mobility management, data delivery to and from mobile user devices GGsN Gateway to external data network packets BsC+pCu Controls multiple Bss and processes data Bts Communication between the air interface and radio network controller (rNC) rNC Call processing and handofs, communication with packet data serving node (pDsN) pDsN Gateway to external network NodeB performs functions similar to base transceiver station (Bts) rNC performs functions similar to BsC MsC Handles voice calls and short message service (sMs) sGsN Mobility management, data delivery to and from mobile user devices GGsN Gateway to external data network packets eNodeB performs functions similar to Bts and radio resource management sGw routing and forwarding of user data, mobility anchoring MMe tracking idle user devices, handof management pGw Gateway to the external data network 2.5G 3G Gprs ev-Do utraN 4G lte Types of MBH the connectivity type offered by the backhaul network is influenced by the technology used in the radio access Network (raN) and by factors such as the geographical location of the cell site, bandwidth requirements, and local regulations. For instance, remote cell sites that cannot be connected over physical links use a microwave backhaul to connect to the base station controller (BsC) and mobile core network. the amount of available frequency spectrum and spectral efficiency of the air interface influence the bandwidth requirements of a cell site. Hence, the backhaul 18 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 network can consist of one or a combination of physical media and transport mechanisms. selecting among the available options depends upon the type of radio technology, the applications in use, and the transport mechanism. table 3 lists the technologies and the interfaces that support those technologies. Table 3: Mobile Network Interfaces Mobile Network Generation Mobile Technology Radio Node to BSC, RNC, or EPC Interface Interface provided by MBH 2G/2.5G GsM/Gprs/CDMa abis Channelized tDM Hspa uMts Iub Ip/ethernet 3G uMts Iub atM 4G lte s1/X2 Ip/ethernet the four connectivity types in the fourth column define the four different service profiles that we configure in the MBH network. MBH Network and Service Architecture the mobile backhaul (MBH) network and service architecture can be divided into various segments—access, preaggregation, aggregation, edge, and core. the access, preaggregation, and aggregation segments can each be a combination of several different physical topologies, depending on the scale and resiliency needs of the individual segment. You can build each segment by using one of the following topologies—hub-and-spoke, ring, and partial mesh, or using a combination of these topologies. Mobile operators can also begin with a hub-and-spoke topology and convert to a ring topology as the scale of the network grows. the key is to have an MBH network and service architecture that supports multiple service models—2G, 3G, Hspa, and 4G lte—to meet legacy and evolutionary needs. legacy networks have relied on backhauling layer 2 technologies and carrying traffic over ethernet vlaNs, Frame relay data-link connection identifiers (DlCIs), tDM circuits, and atM virtual circuits. the use of several technologies for any given service results in tighter coupling of service provisioning with the underlying network topology and limits the flexibility of operations. a unified network infrastructure is an important requirement and challenge for the next-generation access network. this challenge is not new for the telecommunications industry and has been solved in the past by enabling Mpls technology, which provides reliable transport and supports a variety of packet-based and circuit-based services. For both wireline and mobile networks, Mpls has become the protocol of choice for packet transport and carrier ethernet, and the underlying protocol for service delivery. some operators, having taken Mpls beyond the core to the aggregation and metro area networks, also want to deploy Mpls in the access network to reap some of the benefits that Mpls has provided in the core. with Mpls in the access network, operators can have added flexibility in service provisioning. they can define the services topology independently of the transport layer and in line with the evolutionary changes brought on by lte. the service topology itself can have multiple components through the various segments of the network. For example, the service can be initiated as a point-to-point layer 2 pseudowire from the access network and be mapped to a multipoint virtual private laN service (vpls) or a multipoint layer 3 Mpls vpN in the aggregation or edge layer. However, taking Mpls to the access segment and making Mpls the packet forwarding technology end-to-end across the MBH network raises new challenges in comparison with Mpls deployment in the core—challenges such as: • Cost eiciency and scaling • out-of-band synchronization the new network requires cost-effective access networks that consist of tens of thousands of Mpls routers. Juniper Networks has addressed this challenge by producing a new series of routers—aCX series specifically built for use in the access and aggregation segments of the Mpls-enabled network. to meet requirements for out-of-band synchronization, we built into the new aCX series and existing MX series routers a wide range of hardware-enabled technologies. Cost efficiency and scaling require small Csrs with robust Mpls features. these devices have much less scalable control planes. thus, using the devices in large Ip/Mpls networks requires special tools and techniques that segment the network into smaller parts and preserve end-to-end seamless Mpls transport with no touch points in the middle. Mpls has been a widely successful connection-oriented packet transport technology for more than a decade. However, it requires a few enhancements to provide functionality and manageability that is equivalent to the current circuitswitched transport networks. this set of enhancements is called Mpls transport profile (Mpls-tp). Mpls-tp extends Copyright © 2013, Juniper Networks, Inc. 19 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the already rich Mpls and Generalized Mpls (GMpls) protocol suite to serve transport and service networks with enhancements to the data plane, such as framing, forwarding, encapsulation, oaM, and resiliency. Mpls-tp is planned for inclusion as part of seamless Mpls in future versions of the access and aggregation solution. seamless Mpls addresses the requirements for extending Mpls to the access network and significantly influences the architectural framework for building scalable and resilient Mpls networks with a flexible services delivery model. the topic “seamless Mpls” describes the benefits and requirements for seamless Mpls, along with the features and functionality supported by our Juniper Networks comprehensive Mpls portfolio, which delivers a complete and flexible solution for MBH. the MBH network and services architecture can be viewed in two dimensions—the infrastructure of the network and the different layers of the network. MBH Network Infrastructure the first dimension of the MBH network architecture we represent by the network infrastructure, which is defined by tr-221, Technical Specification for MPLS in the MBH Networks, of the Broadband Forum. tr-221 defines the use of Mpls in the MBH access and aggregation network and provides solutions for the transport of traffic in 2G, 3G, Hspa, and 4G lte mobile networks. the main elements of the infrastructure are the segments that appear in Figure 5: • access—Includes Csrs • preaggregation • aggregation • Core—Includes service edge and remote service edge routers RAN ACCESS PREAGGREGATION AGGREGATION CORE NETWORK 4G EPC MME HSS Service Edge CSRs MPLS Remote Service Edge SGW/ PGW PCRF Figure 5: MBH Network Infrastructure this document describes deployment scenarios for the access, preaggregation, aggregation, and core segments. the core segment is, of course, an essential part of the solution. the raN and evolved packet core (epC) segments are included in Figure 5 for completeness. our solution leverages the Mpls core and extends core capabilities into the access and aggregation segments. However, in most cases, the operator already has an Ip and Mpls core, so this document does not describe the details of the core segment. It does, instead, describe some functional requirements for the provider edge (pe) service routers, which are a part of the core segment. Access Segment the access segment consists of the Csr, which is typically deployed at the cell site and connects the Bs to the packet network. several Csrs can be connected in a ring or hub-and-spoke topology to the upstream preaggregation and aggregation routers. key requirements of a Csr include: • support for tDM and ethernet interfaces to meet multigeneration needs (2G, 3G, Hspa, and 4G lte) • timing and synchronization support for voice and tDM traic • performance and bandwidth to meet growing service needs • sotware features to deliver an enhanced quality of experience (Qoe)—class of service, network resiliency, and operation, administration, and management (oaM) 20 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Preaggregation and Aggregation Segments the aggregation and preaggregation segments comprise multiple access networks typically connected to an upstream preaggregation and/or aggregation network in the metro areas before the traffic is handed off to regional points of presence (pops). the key features needed at the preaggregation and aggregation segments include: • High-density ethernet • termination of tDM interfaces, soNet, and atM • support for versatile layer 2 and layer 3 carrier ethernet and Mpls features • oaM and network resiliency features • Inline timing and synchronization support for voice and tDM applications Core Segment the key components of the core segment for the end-to-end MBH solution are pe service routers, which typically separate the access and aggregation layers from the service provider core. the core segment is often complex in a provider network because it has the highest demand for control plane and service plane scalability. It is the network segment where diverse access and aggregation networks converge. the remote multiservice provider edge routers usually interconnect with such mobile network elements as rNC, BsC, and epC. key requirements include: • High-density ethernet • soNet and tDM interfaces for legacy applications • scale for control plane, service plane, and data plane • system redundancy and network resiliency features • extensive layer 2 and layer 3 Ip and Mpls features to support diverse applications • layer 2 and layer 3 virtualization support (pseudowire, virtual private laN service, layer 3 vpN) • ability to receive timing from the grandmaster and to transmit it out to the slave routers in the aggregation and access networks • Inline timing and synchronization support for voice and tDM applications MBH Network Layering the second dimension of the MBH network we represent by the three vertical layers of the access and aggregation segments. (see Figure 6.) Dimension 1: Network Infrastructure Dimension 2: Network Layering RAN ACCESS PREAGGREGATION AGGREGATION CORE NETWORK 4G EPC MME HSS Service Edge CSRs MPLS Remote Service Edge SGW/ PGW PCRF End-to-End MPLS Transport Plane End-to-End MPLS Service Plane End-to-End Timing and Synchronization Plane LSP LSP Figure 6: MBH Network Layering Copyright © 2013, Juniper Networks, Inc. 21 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the three layers of the MBH network infrastructure include: • end-to-end timing and synchronization • end-to-end Mpls-based services • end-to-end Mpls transport End-to-End Timing and Synchronization typically, mobile networks utilize soNet or sDH technologies to backhaul voice and data traffic, and use native support for frequency of soNet or sDH to synchronize their radio network. unless you synchronize the two ends of a circuit, the target device cannot decode the data encoded by the source device. when you emulate the circuit over an Ip-based or packet-based network, the continuity of the circuit clock is lost. the fundamental difference between typical native support for synchronization and an emulated circuit in the Ip-based or packet-based network is that typical native support is synchronous while the emulated circuit has traditionally been asynchronous. this disparity means that a timing and synchronization solution must be employed when performing circuit emulation over the Mpls backbone. Clock synchronization in an MBH network is an essential requirement for handoff support, voice quality, and low interference. loss of timing synchronization can result in poor user experience, service disruptions, and waste of frequency spectrum. a base-station clock needs to be within certain limits of the central radio controller to ensure seamless handover between different base stations. wireless technologies based on frequency-division duplex (FDD)—such as 2G GsM or 3G uMts, wiMaX FDD, lte-FDD, and w-CDMa—require only frequency synchronization to the reference clock. However, wireless technologies based on time-division duplex (tDD)—such as tD-CDMa/ CDMa2000, tD-sCDMa, and lte-tDD—require both frequency and time (phase and time-of-day) synchronization to the reference clock. there are multiple ways of distributing the timing information across the MBH network: • traditional tDM-based timing distribution • Ieee 1588v2 precision timing protocol (ptp) • synchronous ethernet over the physical layer • Network time protocol (Ntp)v3 and Ntpv4 • Gps or BIts that is external to the Ip-packet based network Juniper Networks supports multiple timing synchronization options because a single timing solution does not fit all network types or requirements. For synchronization distribution across the MBH network we use two main methods: physical layer-based synchronous ethernet (G.8261, and so on) and packet-based precision timing protocol (ptp), standardized in Ieee 1588-2008. Both methods are complementary to each other and are a versatile fit for Ip/ ethernet-based MBH because they are topology agnostic and support frequency (synchronous ethernet) and phase (Ieee 1588v2). In addition, when applying class-of-service (Cos) rules, we classify packets carrying timing information into the high-priority, low-latency queue. End-to-End MPLS-Based Services Many types of network services are based on Mpls vpNs, which offer end-to-end connectivity between sites over a shared Ip/Mpls network. vpNs are classified as either layer 2 or layer 3. In a layer 2 vpN, the provider network offers only transport services between customer edge (Ce) devices over the vpN. the routing and peering take place between Ces; the Ip addressing and routing of customer traffic are passed over layer 2 and are encapsulated, becoming essentially transparent to the provider network. this type of vpN is also known as the overlay model. legacy layer 2 vpNs include Frame relay, atM, or time-division multiplexing (tDM) networks. Modern layer 2 vpNs use Ip and Mpls across the provider network. the simplest example of a layer 2 vpN, which is widely used in the Juniper Networks MBH solution, is a pseudowire connection. the pseudowire connection begins and terminates at the physical port or logical interface where traffic enters the pe router. within each layer 2 vpN or service, we configure several pseudowires to carry layer 2 traffic. the IetF pseudowire emulation edge to edge (pwe3) standards define how layer 2 traffic is carried across the network. In contrast, we configure layer 3 vpNs with peering between Ce and pe devices, and the carrier or provider network routing customer traffic over the vpN. the provider network can present each customer’s logical network with route distribution and transport services, which we refer to as the peer model. one problem in a traditional carrier network, which includes multiple network segments such as access, aggregation, and core, is the number of touch points that you need to provision to activate new services. this introduces additional and unnecessary complexity into an already complex network environment. In the traditional multisegment network, 22 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 you must interconnect disparate vpNs into an end-to-end service topology with discrete service activation points at the segment edge of each vpN service tier. this configuration can potentially add operational overhead. when service providers add a new service, they must provision that service at the network edge, as well as at each segment edge. this model is operationally inefficient because of the need to touch each segment edge when you provision new services. a solution to this operational challenge is the emergence of seamless Mpls. seamless Mpls enables a true end-to-end service plane from the access segment to the pe service routers in the core, without any service touch points in the middle. End-to-End MPLS Transport In end-to-end Mpls transport, when the pe router receives vpN data from a Ce router that belongs to different vpNs, the pe router encapsulates the vpN data with labels for forwarding over transport tunnels. these transport tunnels are called Mpls label-switched paths (lsps). an lsp carries traffic between pes. a separate lsp between each pair of pes can carry traffic for multiple vpNs, or there can be a separate lsp for each vpN. two levels of labels are appended to the vpN data coming into the provider network: • an inner vpN label that helps identify the service vpN to which the data belongs • an outer transport label that identiies the lsp to the outgoing pe to which the data is sent any router in the middle of the Mpls network is not required to detect the service and provides pure packet forwarding on the basis of the outer labels (transport), preserving the inner label (services) throughout the network until it is delivered to the pe on the opposite network end. these labels are removed before being sent to the Ce at the egress. this two-level label stack provides the basis on which decoupling of service and transport capabilities is possible in an Mpls network. Seamless MPLS a seamless Mpls network is one in which all forwarding packets within the network, from the time a packet enters the network until it leaves the network, are based on Mpls. seamless Mpls introduces a systematic way of enabling Mpls end-to-end across all segments—access, preaggregation, aggregation, and core. In a seamless Mpls network, there are effectively no boundaries, which allows very flexible models of service delivery and decoupling of network and service architectures, which in turn can present a scaling challenge. seamless Mpls can require scaling Mpls to up to 100,000 nodes. one way of achieving this is to build a single, large IGp area. However, as simple as that may seem, it is very hard to scale. another approach is to divide the network into regions with service origination and termination at access nodes. (see Figure 7.) SEAMLESS MPLS NETWORK SH SH SN EN AN TN TN SN BN Metro-1 Region TN TN WAN Backbone Region BN TN TN AN EN Metro-2 Region Figure 7: Seamless MPLS Functional Elements Type of Nodes several different types of nodes appear in an Mpls network, each with a different function. a physical device can combine several of these functions. Conversely, a single function can require multiple physical devices for its execution. Figure 7 illustrates the following types of nodes: • Access node (AN)—the first (and last) nodes that process customer packets at layer 2 or higher. Border node (BN) —Nodes that enable inter-region packet transport (similar to area border routers and autonomous system [as] boundary routers). • End node (EN)—Nodes that are outside the network, and represent a network customer. • Service helper (SH)—Nodes that enable or scale the service control plane. service helpers do not forward customer data. For example, service route relectors. Copyright © 2013, Juniper Networks, Inc. 23 Design Guide - Juniper Networks universal and aggregation MBH 1.0 • Service node (SN)—Nodes that apply services to customer packets. examples include layer 2 pe routers, layer 3 pe routers, and soNet Clock Generators (sCGs). • Transport node (TN)—Nodes that connect access nodes to service nodes, and service nodes to service nodes. Ideally, transport nodes do not have a customer-speciic or service-speciic coniguration. a physical device can, of course, play multiple roles. For example, an access node can also be a service node, or a service node can double as a transport node. service helpers can be embedded in service nodes. It is often useful to virtualize a physical device that plays multiple roles (using the notion of logical routers) to minimize the impact of one role on another, both from a control plane and a management point of view. Regions a region is an independent, manageable entity. large, global networks can have as many as 200 to 300 regions. regions are an important concept in seamless Mpls because they address many of the challenges inherent in large routed networks. the primary challenge is that IGp and rsvp with lDp do not scale well in an MBH network that consists of one flat IGp region with tens of thousands of nodes. In such a flat network, there are too many nodes, too many peering sessions, too many routes, and too many transit lsps, which all slow down the convergence time. By dividing the network into regions, service providers can increase the scale of their networks and improve convergence times. (see Figure 8 and Figure 9.) Inter-Region Service Plane Within One AS Inter-Region Transport LSP Inter-Region Transport LSP Local IGP Local Transport LSP PE 1 Inter-Region Transport LSP Local IGP Local Transport LSP P1 ABR 1 Local IGP Local Transport LSP ABR 2 P2 P3 PE 2 Edge Region 1 Transport Region Edge Region 2 AS Y AS Y AS Y Figure 8: Multiregion Network within One Autonomous System Inter-Region and Inter-AS Service Plane Inter-Region Transport LSP Local IGP Local Transport LSP PE 1 P1 ASBR 1 Inter-Region Transport LSP Local IGP Local Transport LSP ASBR 2 P2 ASBR 3 Inter-Region Transport LSP Local IGP Local Transport LSP ASBR 4 P3 Edge Region 1 Transport Region Edge Region 2 AS X AS Y AS Z PE 2 Figure 9: Multiregion Network with Numerous Autonomous Systems 24 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Figure 8 and Figure 9 show two examples of inter-region networks consisting of three regions covering the edge and transport regions—edge regions 1 and 2, and the transport region. this approach segments the end-to-end connectivity problem into inter-region and intraregion connectivity and introduces a hierarchical topology that is a key component in the design of seamless Mpls, allowing network to scale well. (For the benefits of seamless Mpls, see the topic “solution value proposition.”) From the control plane perspective, regions can be of different types: • Interior gateway protocol (IGp) region—traditional multiarea/multilevel IGp design, with multiple area border routers (aBrs) connecting the areas and regions. • IGp instance—separate IGp instance for each region, with multiple border routers connecting the regions. • BGp as—separate BGp as for each area, with multiple pairs of boundary routers connecting the regions. the characteristics of a multiregion network are quite similar to a multiarea ospF network, multilevel Is-Is network, or BGp as, but the regions do not exchange routing information as would a typical area or level. IGp routing information, lDp signaling, or rsvp signaling is not exchanged between regions. End-to-End Hierarchical LSP although regions add scale, they establish explicit boundaries and cut end-to-end transport into a few separate lsps per region. to alleviate this problem, lsps can be stitched between regions, extending the Mpls network over multiple regions in the MBH network. these lsps are hierarchical end-to-end lsps. Inside each region, hierarchical lsps are built on the metrics of existing control plane functionality using the ospF or Is-Is and rsvp or lDp protocols. Meanwhile all inter-region control plane information is shared with BGp-labeled unicast (BGp-lu). sharing allows the distribution of labeled routes for the service node’s loopback interface across all regions, providing end-to-end Mpls tunneling. transit routers within each region are not required to detect or participate in BGp-lu—one of the reasons BGp-lu scales so well. Decoupling Services and Transport with Seamless MPLS the following 4G lte and Hspa scenarios illustrate how the typical MBH architecture fits seamless Mpls in terms of defined functions, transport lsps, and decoupling of the services plane from the underlying topology and transport plane. Figure 10 shows the functional roles of different network nodes for a 4G lte deployment scenario. BN SN TN SN BN TN SH SH BN BN EN SH AN EN RAN PREAGGREGATION ACCESS AGGREGATION CORE NETWORK 4G EPC MME HSS Service Edge CSRs MPLS Remote Service Edge SGW/ PGW L3 VPN LSP LSP PCRF L3 VPN Seamless MPLS Network of a Mobile Operator Figure 10: Seamless MPLS Functions in a 4G LTE Backhaul Network Copyright © 2013, Juniper Networks, Inc. 25 Design Guide - Juniper Networks universal and aggregation MBH 1.0 In this example, the Csr in the access segment plays the role of the access node (aN) and service node (sN), originates the layer 3 vpN service, and interconnects with raN. routers in the preaggregation segment function as BGp route reflectors, corresponding to the service helper (sH) function and serve as area border routers between the preaggregation and access segments, corresponding to the border node (BN) function. some access and preaggregation routers can have a pure transport node (tN) role as label-switching routers (lsrs). aggregation routers have a border node (BN) function because they act as autonomous system (as) boundary routers (asBrs) or area border routers (aBrs) between the aggregation segment and the core segment, peering with the pe service router. In the core network, the remote service edge router acts as the service node (sN), connecting the epC elements to the core network. at the same time, the edge router can be an asBr and a route reflector, which correspond to BN and sN functions respectively. Figure 11 illustrates the decoupling of the service and transport planes across different deployment scenarios. BN SN TN TN AN SN SN BN BN TN SH SN BN TN SN function moves from CSRs to preaggregation routers and from remote PE routers to aggregation routers BN EN SH EN RAN ACCESS PREAGGREGATION AGGREGATION CORE NETWORK 4G EPC MME HSS IP/MPLS CSRs 3G RNC SGW/ PGW LSP LSP PCRF LSP VPLS PW PW Termination into VPLS Instance VPLS service moves from CSRs to preaggregation routers and from remote PE routers to aggregation routers without any changes to the MPLS LSP configuration Seamless MPLS Network of a Mobile Operator Figure 11: Seamless MPLS Functions in an HSPA Backhaul Network Figure 11 illustrates the decoupling of different services from each other and decoupling of the services plane from the transport plane. this example uses the same network topology as in the 4G lte example, but this Hspa example uses layer 2 connectivity (instead of layer 3) between mobile network segments. In the access segment, the Csr has a pure access node (aN) function, acts as a vpls spoke, and originates a pseudowire, which is terminated at the aggregation router. the aggregation router is a vpls hub with an explicitly assigned service node (sN) function. Because the Hspa radio network controller (rNC) is located closer to the mobile raN, the service node function moves from the remote edge to the aggregation router at one end, and from the Csr to the preaggregation router at the other end. all the changes to the service plane happen independently from the transport plane, which is agnostic to changes in the service functions. In networks of different sizes, service node (sN), service helper (sH), or border node (BN) functions move across the MBH infrastructure. at the same time, some infrastructure functions for the preaggregation, aggregation, and service edge can be collapsed and deployed on the same device. However, after the functions have been defined, the decoupling of the services plane from the transport plane works independently of the network size. 26 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Mobile Service Profiles positioned in the access and aggregation domain, the MBH use case described in this guide includes four service profiles for the different generations of wireless technologies—2G, 3G, Hspa, and 4G lte. each service profile includes examples of a variety of deployment scenarios. (see Figure 12.) SERVICE PROFILE Deployment Scenarios ATM PW H-VPLS HSPA L3 VPN with PW in Access 4G LTE L3 VPN Hub and Spoke 3G MBH TOPOLOGY Ring Topology SAToP IS-IS, RSVP, BGP-LU, LDP-DOD CESoPSN 2G SYNC & TIME 1588 v2 IP/MPLS TRANSPORT SyncE SERVICES OSPF, RSVP (Aggregation and Core), BGP-LU, LDP-DOD, OSPF LFA USE CASE Figure 12: MBH Service Profiles and Deployment Scenarios the deployment scenarios for each service profile include different services. Common to all service profiles are the Ip/ Mpls transport, synchronization and timing, and topology elements. that is, all service profiles and services are based on a common Ip/Mpls transport infrastructure, common synchronization and timing, and a common network topology. the Ip/Mpls transport infrastructure can be Is-Is or ospF-based, synchronization can be synchronous ethernet, Ieee 1588v2, or a combination of the two, and the topology can be ring or hub-and-spoke, depending on the example. the deployment scenarios represent separate building blocks that can be deployed alone or combined with each other. 2G Service Profile the 2G service profile examples include the following features: • end-to-end tDM Circuit emulation service over packet-switched Network (CesopsN)—a CesopsN bundle represents an Ip circuit emulation low. with CesopsN bundles, you can group multiple Ds0s on one Ip circuit, and you can have more than one circuit emulation Ip low created from a single physical interface. For example, some Ds0 channels from a t1 interface can go in an Ip low to destination a, and other Ds0 channels from that same t1 interface can go to destination B. this feature allows for payload optimization. CesopsN bundles comply with rFC 5086, structure-aware time Division Multiplexed (tDM) Circuit emulation service over packet switched Network (CesopsN). • structure-agnostic time Division Multiplexing (tDM) over packet (satop)—satop bundles use a standards-based transport mechanism for t1/e1 circuits that allows them to interoperate with other satop-compliant equipment. satop bundles comply with rFC 4553 to provide pseudowire encapsulation. pseudowire emulation edge to edge (pwe3) for tDM bit streams (t1, e1, t3, e3) disregards any structure that might be imposed on these streams, in particular the structure imposed by the standard tDM framing. 3G Service Profile the 3G universal mobile telecommunications system (uMts) service profile example includes edge-to-edge asynchronous transfer Mode (atM) pseudowires as described in rFC 4717. atM pseudowires (a simulated wired connection that emulates a dedicated end-to-end wire) are used to carry atM cells over an Mpls network, enabling service providers to offer emulated atM services over existing Mpls networks. HSPA Service Profile the Hspa service profile examples include a combination of a layer 2 virtual private network (vpN) signaled with lDp (rFC 4905) and lDp-signaled virtual private laN service (vpls). a layer 2 vpN enables transport of the protocol data unit (pDu) of layer 2 protocols such as Frame relay, atM aal5, and ethernet, and providing a circuit emulation Copyright © 2013, Juniper Networks, Inc. 27 Design Guide - Juniper Networks universal and aggregation MBH 1.0 service across an Mpls network. the lDp-signaled vpls is a tunneling service that creates an emulated laN segment restricted to a set of users. the lDp-signaled tunneling service acts as a layer 2 broadcast domain that learns and forwards ethernet MaC addresses, and that is limited to a designated set of users. 4G LTE Service Profile the 4G lte service profile examples include a layer 3 vpN (rFC4364/2547bis). rFC 4364 defines a mechanism by which service providers can use their Ip backbones to provide vpN services to their customers. a layer 3 vpN is a set of sites that share common routing information and whose connectivity is controlled by a collection of policies. the sites that make up a layer 3 vpN are connected over a provider’s existing public Internet backbone. rFC 4364 vpNs are also known as BGp/Mpls vpNs because BGp is used to distribute vpN routing information across the provider’s backbone, and Mpls is used to forward vpN traffic across the backbone to remote vpN sites. Topology the topology plays an important role in the overall design planning process. For example, the topology influences the deployment scenario for the network layer and choice of IGp (Is-Is or ospF) and the Mpls protocol stack. each service profile example is deployed using one or both of the topologies in the access segment: ring or hub-and-spoke. MBH Service Architecture the four service profiles—2G, 3G, Hspa, and 4G lte—define the overall service architecture of the Juniper Networks solution for the MBH network. table 4 summarizes, at a high level, the service architecture of the solution. the MBH service architecture in table 4 combines a type of user-to-network interface (uNI) with an Mpls service and an Mpls service topology with stitching points, and assigns service node functions to the MBH network nodes across different segments. Table 4: MPLS Service Types Across the MBH Network MBH Network Node Service Profile Mobile Network Element MBH Network UNI MPLS Service Type Csr 2G Bts G.703 CesopsN or satop 3G NodeB atM atM pwe3 Hspa NodeB ethernet layer 2 vpN (ethernet pseudowire) 4G eNodeB ethernet ethernet/Ip layer 2 vpN (ethernet pseudowire) layer 3 vpN preaggregation Hspa 4G N/a lsI tunnel (lt) interface/Ip loopback (lo0)/Ip layer 2 to vpls termination layer 2 to layer 3 vpN termination layer 3 vpN hub aggregation 2G BsC stM1 CesopsN or satop sGsN G703/stM1 CesopsN or satop (remote) provider service edge 3G rNC atM atM pseudowire (pw3) Hspa rNC ethernet/Ip vpls or layer 3 vpN sGsN ethernet/Ip layer 3 vpN sGw ethernet/Ip layer 3 vpN MMe ethernet/Ip layer 3 vpN 4G lte Solution Value Proposition over the last few years, the industry has seen a growing investment in ethernet as the transport infrastructure and in Mpls as the packet-switching technology. our advanced MBH solution with aCX series routers helps managed service providers (Msps) move to an all Ip/Mpls packet network, and addresses the growing services needs of increasing bandwidth and enhanced quality of experience (Qoe). Further, recent studies indicate that use of Mpls in the access network results in better network economics over traditional layer 2 ethernet networks. (see pietro Belotti, Comparison of MPLS and Ethernet Networks at the Access-Aggregation Level (http://myweb.clemson.edu/~pbelott/papers/ comparison-eth-mpls.pdf). 28 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Juniper Networks provides an industry-leading solution to deliver a services architecture that moves Mpls from the core and aggregation layers into the access layer, providing the necessary functionality and performance needed to build highly resilient, large-scale, modern day networks. the key benefits of building an end-to-end Mpls network for wireless services include: • supporting multiple types of transport infrastructure—Mpls can eiciently carry both packet and nonpacket application traic over a hybrid underlying infrastructure that includes tDM, atM, and ethernet. • Decoupling the underlying infrastructure—services can be initiated as Mpls pseudowires or Mpls layer 3 vpNs at the cell site and can be lexibly mapped to Mpls services at the aggregation and edge nodes farther upstream in the network. In contrast, traditional networks have relied on backhauling layer 2 technologies and carrying traic over ethernet vlaNs, Frame relay data-link connection identiier (DlCI), or atM virtual circuits. this approach of dealing with several technologies for any given service has resulted in tighter coupling of service provisioning to the underlying topology and limited lexibility in operations. • simplifying the service provisioning model and minimizing the number of provisioning touch points—Mpls in the transport network results in faster deployment of services and simpler operations. • streamlining operations at the cell site with Mpls services originating at the cell site—For example, when reparenting of cell sites is needed, it is much easier and more cost-efective to move Mpls layer 3 services than to reconigure hardprovisioned Frame relay DlCI or atM virtual circuits. • redirecting traic in the event of network node or link failures and maximizing the use of network resources in stable conditions with end-to-end label-switched paths (lsps)—an Mpls portfolio of comprehensive oaM tools can facilitate speedy detection of failures, as well as the necessary service restoration to ensure sub-second convergence to deliver carrier-class functionality. • Meeting the scaling needs of the largest modern day networks—Mpls systematically deployed throughout the network can support large-scale networks of the order of 100,000 nodes. key features such as BGp-labeled unicast (BGp-lu) and lDp downstream on demand (lDp-DoD; see rFC 5036) can be used to enable and extend the correct level of service and operational intelligence in several layers of the network. • Deploying and integrating multimarket services with Mpls tends to be easier than other protocols—For example, MBH, carrier ethernet services and residential access service can be addressed with the same Mpls transport infrastructure. with the topological independence that Mpls creates at the service layer, services such as wi-Fi oload, access point name (apN), or support for multiple Msps on one cell site can easily be accommodated with the virtualization provided by Mpls layer 3 vpNs. In the presence of strict service-level agreements, downtime can result in significant financial losses. service downtime for the subscriber can also have a negative impact on the brand and cause permanent loss of business. Juniper Networks hardware redundancy and software reliability and stability ensure that the network is up all of the time. the following Junos os features maximize service availability: • Comprehensive link, node, path, and service-level resiliency provided by Ip and Mpls fast reroute(Frr)—sub-50 millisecond failover • Nonstop routing (Nsr) • Best-in-class uniied in-service sotware upgrade (Issu) • virtual chassis • Multichassis link aggregation group (MC-laG) • ethernet ring protection (G.8032) • Multihoming • pseudowire redundancy the modular operating system architecture of Junos os provides security and reliability through microkernel and protected memory for processes. this architecture ensures that the entire platform does not restart because of a minor fault in one process, further ensuring the highest levels of service continuity. Copyright © 2013, Juniper Networks, Inc. 29 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Juniper Networks Solution Portfolio the Juniper Networks universal access and aggregation solution portfolio includes the following components: • aCX series universal access routers • MX series 3D universal edge routers • Junos space • Junos os sotware the Juniper Networks vision of one network, many services is supported by the our aCX series cost-optimized, purpose-built universal access routers, which provide a single access infrastructure for many services in the last mile for fixed and mobile access. the aCX series routers bring simplicity and ease of provisioning for Mpls pseudowires, layer 2 vpNs, and layer 3 vpNs from the access node, while offering operational intelligence that separates traffic and steers it over specific Mpls tunnels, supports strict slas, and provides an enhanced end-user experience with precise timing and synchronization capabilities. aCX series universal access routers support rich Gigabit ethernet and 10-Gigabit ethernet capabilities for uplink, along with support for legacy interfaces and Gigabit ethernet interfaces for radio and NodeB connectivity in a compact form factor that is environmentally hardened and passively cooled. seamless Mpls, a common multiservice technology, can be used end-to-end to address legacy and emerging requirements of a converged network. to provide the foundation for the converged network, the same mobile backhaul (MBH) infrastructure can be used to carry mobile, business, or residential services. aCX series routers are the low-cost Csrs for backhauling mobile traffic from cell sites. MX series universal edge routers are the platforms of choice for building a transport network with uncontested bandwidth provisioning. Junos space is a suite of comprehensive, web-based tools for operational management and administration of Juniper Networks routers, including the aCX series and MX series platforms. Juniper Networks has extended Junos space with powerful new features that address the demanding requirements of MBH. the Juniper Networks MBH solution with the aCX series, MX series, and Junos space includes hardware (interface density and types) and software features that support different network topologies for efficient and scalable service delivery. with the cell site and aggregation routers all powered by one Junos os and comprehensive end-to-end ethernet and Mpls oaM features, operators can enjoy better network economics and cost optimize the total solution. with the unified Junos space network management system, network provisioning and operations can be streamlined. table 5 shows the details of each router, including the router’s role in the network, interface density and types, key functions, and software features. Table 5: Juniper Networks Platforms Included in the Universal Access and Aggregation MBH Solution 30 SKU Chassis Role in the Network Physical Connectivity Key Function aCX1000 aCX1100 Fixed (low cost) access 8xt1/e1 8xGe/rJ45 4xGe/sFp/rJ45 • • • • • • 60-Gbps platforms Circuit emulation timing oaM for MBH seamless Mpls Hardened fanless design aCX2000 aCX2100 Fixed access 16xt1/e1 6xGe/rJ45 2xGe/rJ45-poe 2xGe/sFp 2x10Ge/sFp+ • • • • • • • 60-Gbps platforms Circuit emulation timing oaM for MBH seamless Mpls Hardened fanless design 10Ge capable aCX4000 Modular access 8xGbe Combo 2xGbe sFp 2x10Gbe sFp+ 2 MIC slots: • 6xGbe Combo • 4xCHoC3/stM1/1xCHoC12/stM-4 • 16x t1/e1 • • • • • • 60-Gbps platforms Circuit emulation timing oaM for MBH seamless Mpls 10Ge capable Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 SKU Chassis Role in the Network Physical Connectivity Key Function MX5-t Fixed preaggregation 20xGbe sFp MX10-t Modular preaggregation and aggregation 20xGbe sFp 1xMIC slot options: • 2x10Gbe XFp • 20xGbe sFp • • • • • • • • • ethernet bridging Ipv4 Ipv6 routing seamless Mpls Mpls and multicast forwarding Hierarchical class of service oaM and network resiliency timing pay as you grow MX40-t Modular preaggregation and aggregation 20xGbe sFp 1xMIC slot options: • 2x10Gbe XFp • 20xGbe sFp MX80-t/p Modular (2 MIC slots) aggregation and edge 4x10Gbe XFp: 2xMIC slot options: • 20x1Gbe sFp • 2x10Ge/XFp • 40x1Ge rJ-45 • 100FX,100BX • 4xoC3/2xoC12-Ce • • • • • • • ethernet bridging Ipv4, Ipv6 routing seamless Mpls Mpls and multicast forwarding Class of service oaM and network resiliency Ieee 1588v2 precision timing protocol (ptp) MX-240/ MX-480/ MX-960 Modular (4/6/12 slots) edge and core up to 40xGbe sFp per slot up to 20x10Gbe per slot up to 2x100Gbe CFp per slot • • • • • • • ethernet bridging Ipv4 Ipv6 routing Mpls and multicast forwarding Class of service oaM and network resiliency up to 5.2 tbps overall performance Figure 13 shows how each platform is deployed in the network. Junos ACCESS Tower Site AGGREGATION Hub Location EDGE End Office Metro / Regional Office CE-STM1 CE-STM1 CE-STM1 ACX4000 Radio ACX Series ACX-1x00/2x00 Cell Site Router MX80/MX40/ MX10/MX5 MX480 MX240 MX960 TCA8500 1588v2 SyncE Figure 13: Juniper Networks Platforms in the MBH Copyright © 2013, Juniper Networks, Inc. 31 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the aCX1000, aCX2000, and aCX4000 routers are deployed at the cell site in the access network. aCX1000 and aCX 2000 series routers are designed according to the etsI 300 standard and have a hardened fanless design that allows installation in outdoor cabinets. For a more detailed platform description, see the “ACX Series Universal Access Routers” product datasheet. the aCX4000 and the smaller MX40 and MX80 series routers are deployed in the preaggregation or aggregation segments. For more detailed information about MX series routers, see the “MX series 3D universal edge routers for the Midrange” product datasheet. Depending on the network scale, the high-end MX240 or MX480 platforms can be deployed at the large consolidated central office (Co) in the aggregation segment of the MBH network. the larger capacity MX480 and MX 960 routers are deployed in the point of presence (pop) at the edge of the core network segment. For more detailed information about the high-end MX series routers, see the “MX series 3D universal edge routers” product datasheet. the tCa timing servers are primary reference sources, providing highly accurate timing that is critical for mobile networks. these servers are a crucial part of the Juniper Networks solution for timing and synchronization. they use Gps and a local oscillator to deliver stratum 1 timing reference and exceptional holdover. they serve as grandmaster clocks and are usually located at the Co or regional/Metro pop with direct connectivity to collocated MX-series routers. For more detailed information about tCa appliances, see the “tCa8000 and tCa85000 timing services” product datasheet. the Junos space network management solution provides a comprehensive fault, configuration, accounting, performance, and security (FCaps) end-to-end MBH network management and service provisioning. For more detailed information, see the “Junos space” product datasheet. 32 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Part 2: Design and Planning this part includes the following topics: • Design Considerations worklow • topology Considerations • MBH service proiles • Cos planning • timing and synchronization planning • end-to-end Ip/Mpls transport Design • Mpls services Design for the 4G lte proile • Mpls service Design for the Hspa service proile • Mpls service Design for the 3G service proile • Mpls service Design for the 2G service proile • oaM • High availability and resiliency • Network Management • Design Consistency and scalability veriication Design Considerations Workflow when you design an Ip/Mpls access and aggregation network, the variety of available technologies and features is very large. the variety can result in extremely complicated designs. Complexity is an important consideration because very often the mobile backhaul (MBH) network is operated by service providers that are not experienced with Ip and Mpls technologies and that want to keep the complexity of the solution as close as possible to the operational complexity of legacy access networks. this problem can be partly solved when you use automation and network management tools. In general, we recommend that you keep your design simple and add new features only if you cannot solve a problem by changing the topology or network architecture at the Ip/Mpls transport or service levels. Consider the following tasks as you approach the solution design: • Gather service requirements. • Check the physical topology. • Check the traic low topology. • Check the existing requirements of your particular network. For example, you may have operators more familiar with hub-and-spoke, which may inluence your topology decisions. • Decide on the design. In this guide, we recommend the following workflow for designing the MBH network: 1. Deine end-to-end service requirements. 2. Design the network topology and consider building blocks: a. Network topology: segment and number of nodes in each segment. b. type of the hardware and sotware platforms for each network segment. 3. Deine MBH network end-to-end services (or service proiles) a. Deine user-to-network interface (uNI) properties (tDM, atM, ethernet vlaNs, Ip addressing). b. Deine Ip and Mpls service architecture. c. Deine end-to-end class-of-service (Cos) requirements. 4. Design network-to-network (NNI) Cos proiles and rules. 5. Design the Ip/Mpls transport. 6. Design Ip and Mpls services. 7. Determine the timing and synchronization. Copyright © 2013, Juniper Networks, Inc. 33 Design Guide - Juniper Networks universal and aggregation MBH 1.0 8. Design network high availability and resiliency: a. platform high availability. b. transport layer resiliency. c. service layer resiliency. 9. verify network and product scalability with respect to your network requirements and design decisions. 10. reconsider your design if necessary. 11. Consider the network management system. Gathering End-to-End Service Requirements end-to-end service definition is the starting point. MBH networks provide transport services, which connect mobile network elements. the design of your network is affected by the requirements and properties of the type of connectivity. table 6 lists the requirements, possible options to select, and area of the design most affected by the various requirements. Table 6: Requirements for MBH Network Requirement Options Design Aspect Impacted by the Requirements Datalink and network layer encapsulation tDM , atM, ethernet, Ip platform capabilities, hardware coniguration, and Ip/Mpls service architecture. type of end-to-end connectivity point-to-point, point-to-multipoint, full mesh Ip/Mpls service architecture Delay and jitter per traic type Bandwidth restrictions at uNI Cos design at uNI and NNI levels restrict ingress and egress bandwidth. restrict per uNI or traic type restoration time in case of link or node failure traic policing and iltering at the uNI Ip/Mpls transport and service layer design timing and synchronization parameters Frequency, phase platform capabilities, network segmentation into regions, and physical topology overall bandwidth and number of end points connected to the network 2/10/100Mbps per cell site platform capabilities, network segmentation into regions, and physical topology Designing the Network Topology when you start to design your network topology, we recommend that you start by planning the network topology and regions. then decide on the platforms you want to use in the various segments of the design. Planning the Network Topology and Regions the network topology (especially in the access segment) dramatically affects the complexity of the design at other layers, so we strongly recommend that you plan carefully. often, the topology itself is dictated by other factors, such as the existing optical infrastructure, which can be difficult to change. You can plan the network segments (access, preaggregation, and aggregation) and the number of devices in each interior gateway protocol (IGp) region, taking into consideration restrictions on timing and synchronization, bandwidth requirements, and the overlaid transport layer. Deciding on the Platforms to Use Juniper Networks provides a broad portfolio of aCX series and MX series routers for the MBH solution, as shown in table 5. Note that the roles a router plays can be ambiguous. positioning a router in a role depends on factors that are uniquely defined within the context of a particular project only. For example: • Control and data plane scalability, which depends on the topology and the number of nodes in each access and preaggregation segment. • total platform throughput in terms of Gigabits per second (Gbps) and packets per second (pps). • port type and density. • Feature set—Juniper Networks is working on a consistent and uniied feature set across all platforms. However, you need to reconsider diferences in hardware and sotware features on the various platforms. • environmental requirements, for example, use of outdoor cabinets for access and preaggregation nodes. • Capital expenditure (Capex) and operational expenditure (opex) considerations. 34 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Defining the MBH Network Service Profile MBH service profiles are defined by uNI properties, by Ip/Mpls service architecture, and by Class of service (Cos) settings at the uNI. Juniper Networks service definitions are aligned with MeF 22.1, MBH Phase 2 Implementation Agreement specification, which contains detailed service definitions for MBH use cases. Designing the MPLS Service Architecture each service profile includes one end-to-end Mpls service or a combination of Mpls services with a stitching point somewhere in the middle of the MBH network. part of the design consideration process is the decision you make about the type of service and stitching point of the Mpls service. at this point, the design decision is driven by the initial requirements, end-to-end requirements for the MBH network services, and considerations of network scalability. to provide scalability, you must decide on the role of the service helper (for example, the Mp-BGp route reflector). when you use services like layer 3 vpN with a full mesh topology between access nodes, think about how to segment the network at the service level to restrict the number of vpN prefixes learned by each access router. as soon as you make a decision about scaling and put the transport level in place, defining services is straightforward. Consider network resiliency at the service layer after you make the decisions about scaling. Network resiliency is a complex task, which is solved at different layers and is discussed in High Availability and Resiliency. Designing UNI Properties user-to-network interface (uNI) definitions specify properties such as: • link layer encapsulation • service separation • Cos at the uNI Link Layer Encapsulation the choice of the link layer technology (tDM, atM, ethernet, or Ip) is dictated by the requirements of the raN network (2G, 3G, Hspa, 4G lte) and defines the service profile of the MBH solution. Service Separation service separation at the uNI level is automatically provided when you use satop or CesopsN for tDM-based service emulation at the physical or logical port level. assign atM virtual path identifiers (vpIs) and virtual circuit identifiers (vCIs) at each uNI per atM pseudowire service. vpI and vCI pairs are assigned globally and are preserved across the entire MBH network. when you use an ethernet interface and the uNI, service separation is provided by means of vlaNs. each vlaN represents a separate layer 2 broadcast domain, which carries a separate service. In the context of the MBH network, the vlaN numbering at the uNI level can be global or local. when the vlaN numbering is local, the vlaN number is not preserved across the MBH network. usually, not preserving the vlaN number gives the MBH service provider additional flexibility in managing and planning services. Juniper Networks aCX series and MX series routers support a choice of technology for setting up a vlaN. the choices are the Ieee 802.1Q standard and the Ieee 802.1ad standard. only the Ieee 802.1Q standard is part of the Juniper Networks MBH solution. In some lte deployment scenarios, one logical interface (with the same vlaN and Ip address) is used for all services. In this case, the raN and the epC of the mobile network are responsible for service separation at the network or high layers of the open systems Interconnection (osI) model (layer 4 – layer 7). Class of Service at the UNI when planning and designing class-of-service rules, consider the following factors: • the traic proile and requirements of granular classiication of traic streams within a forwarding class (in our solution we use a maximum of eight classes for each physical port with the proposed platform portfolio—aCX series and MX series routers). • a combination of multiield (MF) classiiers and behavior aggregate (Ba) classiiers (only Ba classiiers are used in this guide). • type of class-of-service marking, which can be DsCp or 802.1p, depending on whether a service is layer 2 or layer 3, and whether the incoming frames are vlaN tagged or not. Copyright © 2013, Juniper Networks, Inc. 35 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Designing NNI CoS Profiles and Rules after you define Cos profiles for the uNI, define consistent Cos rules across the entire MBH network for NNIs. keep in mind the following two points when you plan the Cos rules at the NNI: • use the Mpls code point (eXp bit) for traic classiication. • add new traic classes for network oaM protocols, network control protocols, and synchronization (Ieee 1588v2 ptp). Designing the IP and MPLS Transport Layer Designing the Ip and Mpls transport layer is the most complex part of the design process. However, if you follow our seamless Mpls architecture, you will be better prepared to make the correct decisions about mapping the network topology to the architectural segments. (see the topic “seamless Mpls.”) at the Ip and Mpls transport level, you determine which nodes perform the role of the area border router (aBr) or the autonomous system boundary router (asBr). after you designate the border routers, the roles of other nodes fall logically into place. Many protection mechanisms are deployed at the Ip and Mpls transport level and are included into the overall solution for MBH network resiliency. Designing Timing and Synchronization there are multiple ways to distribute timing information across the MBH network—traditional tDM-based timing distribution, Ieee 1588v2, synchronous ethernet, and Ntpv3 and v4. when applying Cos rules, you must highlight packets carrying timing information into a high-priority, low-latency queue. Juniper Networks supports multiple timing synchronization options because a single timing solution does not fit all network types or requirements. Ieee 1588v2 is a versatile fit for the Ip and ethernet-based MBH because it is topology agnostic and supports both frequency and phase. Verifying the Network and Product Scalability the design verification and consistency analysis are an important part of your design and planning process during which you make a final check of the feature consistency across platforms and across software releases, which can vary on different platforms. also, you should ensure consistency of platform and network scalability and assess how platform resources are used as the number of devices in the network increases. also assess how network parameters like timing and synchronization, resiliency, and time for network convergence after failure will evolve with the growing network infrastructure. sometimes, after such analysis, you have to reconsider some of your decisions. For example, you might need to replace a preaggregation platform with more powerful devices or even change the IGp protocols or how nodes are combined into the IGp regions in the network. Considering the Network Management System Network management is a separate process from all previous considerations. However, when we talk about deploying a network, which could potentially consist of hundreds of thousands of routers, the role of network management and automation plays an integral role in a carrier network. proposed designs and feature sets at all levels and across all platforms should be consistent with the network management system (NMs) and should make the NMs an integral part of any MBH solution. NMs tasks are as follows: • element management • Network management (Ip and Mpls transport provisioning) • service provisioning • Bulk service provisioning • Cos provisioning • oaM provisioning • Network monitoring • service-level agreement (sla) monitoring 36 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Topology Considerations Planning the Network Segment and Regions Decisions about network topology dramatically influence the design of the transport layer and can add complexity or allow you to create a straightforward transport infrastructure that can easily grow to practically any number of nodes. when you plan the network segment and regions, your main task is to define the correct balance between complexity, scalability, and failure resistance while you decide on the following parameters: • How the mobile backhaul (MBH) network nodes it into the MBH network segments: - access segment - preaggregation and aggregation segment - Core segment • the number of interior gateway protocol (IGp) regions • the optimal number of devices in each IGp region Access Segment the implementation scenarios in this document address two special cases for the access segment that fit into the above concepts and can be found in the deployments scenarios. these special cases in the access segment are: • ring topology • Hub-and-spoke topology Figure 14 illustrates ring-based access regions in the access segment where a pair of aG 1 routers and five Csrs build a complete 1-Gb ethernet ring and a 10-Gb ethernet ring. ACCESS PREAGGREGATION AGGREGATION CORE NETWORK EPC MME HSS AG 1.1 AG 1.2 AG 2.1 AG 1.3 AG 1.4 AG 2.2 AG 3.1 PE 1 Remote Service IP/MPLS Service Edge Edge AG 3.2 PE 2 SGW/ PGW PCRF ACCESS Figure 14: Ring Topology in an Access Segment Copyright © 2013, Juniper Networks, Inc. 37 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Figure 15 illustrates an alternative approach in which each cell site router (Csr) is dual homed to two aG 1 routers. ACCESS PREAGGREGATION AGGREGATION CORE NETWORK EPC MME HSS AG 1.1 AG 1.2 AG 1.3 AG 1.4 AG 2.1 AG 2.2 AG 3.1 PE 1.1 Remote Service IP/MPLS Service Edge Edge AG 3.2 PE 1.2 SGW/ PGW PCRF ACCESS Figure 15: Hub-and-Spoke Topology in the Access Segment the design and implementation of the service plane are the same for both topologies—ring and hub-and-spoke— because of the decoupling of the transport and service planes. although some transport designs work better with hub-and-spoke and some work better with access rings, this guide follows the principle of less complexity and more versatility. therefore, we recommend deployment scenarios that work well and are configured simply in both topologies. However, this can mean fewer resiliencies in some failure scenarios or longer paths for ring topologies. Most topology descriptions in this guide are shown for a ring topology with notes that describe the differences for a huband-spoke topology. Preaggregation and Aggregation Segments In Figure 14 and Figure 15, each aggregation segment has two aG 2 routers that are peers to aG 3 routers with direct 10-Gb ethernet links arranged in a full mesh. the implementation scenarios have two aG 2 routers in each aggregation segment. the aggregation segment has an internal hierarchy and connects to the preaggregation segment. so aG 2 routers connect a number of preaggregation aG 1-router rings together by means of 10-Gb ethernet links. aG 1 routers, in turn, connect to the access segment, which consists of multiple access regions. the number of aG 1 routers in an aggregation segment depends on the number of access regions they interconnect and the geographic characteristics of the topology. the total number of aG 1 and aG 2 routers in an aggregation domain should not exceed a reasonable figure, such as a maximum of 200 to 300 routers. the term reasonable is used here in the context of traditional Ip/Mpls networks that generally use a single flat ospF or Is-Is domain for the control plane to build the Mpls transport or data plane. the network topology at the preaggregation and aggregation level can have any configuration that provides at least two paths from any aG 1 router to an aG 2 router. 38 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Core Segment the core segment is the most straightforward from a topology perspective. the design of the Ip and Mpls core is out of the scope of this guide. However, the only core devices that participate in establishing an end-to-end MBH transport are the provider service edge routers (aG 3) and remote provider service edge router (pe 1) (Figure 15). a pair of aG 3 routers, located at the edge and usually connected to a number of independent regional metro segments, provide redundant connectivity from the MBH aggregation segment to the provider core segment. aG 3 routers are usually considered one way to connect to the mobile packet core. another way to connect is the central site (or a few central sites) with remote pe routers, which provide connectivity to the mobile packet core or evolved packet core (epC) segments. a pair of aG 3 routers serve as peering points with a number of independent aggregation segments. two aggregation segments are considered to be independent if they comprise a separate autonomous system and do not have back door connectivity between them. (this is not true in all production networks, but we have to make this assumption for the sake of simplicity). Number of Nodes in the Access and Preaggregation Segments the overall design for the MBH network in this guide allows tens of thousands of nodes in the access segment. each access segment consists of multiple isolated IGp access regions, and the real task is to calculate the number of access nodes that can be included into one IGp region. Note that the number of access nodes is influenced by restrictions in the access and preaggregation segments. the following restrictions and considerations influence decisions about the number of nodes in the access region: • Maximum number of nodes supported by the selected hardware platform in one IGp region • routing information base (rIB—also known as routing table) and forwarding information base (FIB) scaling of the selected hardware platform • Maximum number of ethernet or BFD oaM sessions supported on preaggregation nodes • Convergence time • Bandwidth restrictions • timing and synchronization restrictions Maximum Number of Nodes in an IS-IS IGP Region Supported by Platform Is-Is or ospF routing protocols use zones and areas respectively to designate a separate flat IGp region. aCX series routers support a maximum of 250 Is-Is or ospF peering neighbors. RIB and FIB Scaling of the Access Node the number of routing nodes that you include in a flat IGp region depends on the resources used to update the rIB and FIB tables by the routing engine and the packet Forwarding engine of each router. a large number of nodes can indirectly influence the convergence time during which the rIB and FIB tables must be updated in case of link or node failure. this guide describes scaling data for a sample topology based on the design in the “Design Consistency and scalability verification” topic. this data can be used to assess the possible scaling restrictions in different topology deployments. Note that as soon as your design of the network topology and segment hierarchy is close (in terms of the number of nodes per access region) to what we use for the sample network, your choices are prudent from the network scalability perspective. Maximum OAM Sessions Supported on a Preaggregation Node ethernet 802.1ag connectivity fault management (CFM) and Bidirectional Forwarding Detection (BFD) are the two oaM protocols used in this solution. each access node has a few oaM sessions established with each preaggregation node. the number of maximum oaM sessions supported on the preaggregation node could be a restriction to adding more nodes into the same access region to be peers with the same preaggregation node. For more information on oaM sessions, see the topic “Design Consistency and scalability verification.” Bandwidth Restriction Bandwidth utilization is important in lte networks where, in theory, one eNodeB can transit up to 150 Mbps of data traffic. pay attention to potential bottlenecks in very large access domains, which can include not only 1-Gb ethernet and 10-Gg ethernet links but also microwave links. Copyright © 2013, Juniper Networks, Inc. 39 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Timing and Synchronization Restrictions one of the methods widely used to distribute synchronization signaling across a network is the Ieee 1588v2 precision timing protocol (ptp). see the topic “timing and synchronization” for a discussion of this method in detail. at this point in the planning process, it is important to note that the number of hops between the Ieee 1588v2 grandmaster and the most distant slave node influences the accuracy of the clock and phase synchronization in the network. when planning your MBH network, calculate the number of nodes for the worst case scenario in which the network has one or two links down so that a ptp packet cannot use the shortest possible path. If a preaggregation node serves as an Ieee 1588v2 master for multiple nodes in the access region, take into consideration the maximum number of Ieee 1588v2 peers supported by the preaggregation router. Sizing the MBH Network MBH network sizing is the point at which you decide the number of access nodes and the size of the connections between the access nodes and the core network. even though seamless Mpls supports up to 100,000 devices in one network, most networks are smaller. each iteration of MBH must satisfy the requirements of the new mobile network and preserve backward compatibility with previous versions. In today’s network, lte dictates the size of the network and the number of nodes in each MBH region. the scenarios described in this guide are based on lte requirements and assume that from the geographical point of view and number of access nodes (and interfaces on the access nodes), the needs of 2G, 3G, and Hspa networks deployed in the same geographical area are covered. Figure 16 illustrates a large MBH network with a number of independent regional networks. EPC MME EPC REGIONAL NETWORK 3 MME SGW/ PGW EPC SGW/ PGW MME SGW/ PGW Remote PE REGIONAL NETWORK 4 AG 3 AG 3 EPC S1 S1 REGIONAL NETWORK 2 MME SGW/ PGW EPC S1 REGIONAL NETWORK 5 S1 MME SGW/ PGW NATIONAL CORE IP/MPLS AG 3 AG 3 AG 3 AG 3 REGIONAL NETWORK 1 REGIONAL NETWORK N Figure 16: Large-Scale MBH Network 40 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 each regional network connects to the national Ip and Mpls core through an aG 3 edge router. each regional network with 10,000 access nodes might or might not have its own directly connected epC. If an epC is not installed in a particular geographical region, then an epC at the remote provider edge point of presence (pop) is used for that region. the distribution and number of access nodes across a regional network segment—access, preaggregation, aggregation, or core—is represented in Figure 17. ACCESS CSR x5 x16 x16 PREAGGREGATION AGGREGATION CORE NETWORK EPC MME HSS AG 1.1 AG 1.2 AG 1x4 AG 1.3 AG 2.1 AG 3.1 AG 2x2 AG 1.4 AG 2.2 AG 3.2 SGW/ PGW PCRF ACCESS CSR x5 CSR x5 x4 Figure 17: Network Segment Sizing In Figure 17, sixteen pairs of aG 2 aggregation routers interconnect with edge routers aG 3.1 and aG 3.2 by means of direct 10-Gb ethernet links. on the other side, each aggregation router pair—aG 2.1 with aG 2.2 and aG 2.3 with aG 2.4, and so on—interconnects sixteen preaggregation semirings. each preaggregation semiring consists of four preaggregation (pre-aG G) routers (aG 1.1, aG 1.2, aG 1.3, aG 1.4, and so on) interconnected with 10-Gb ethernet links. Finally, each pair of preaggregation aG 1 routers interconnects four access rings with five Csrs in each access ring. Csrs within a ring are connected by optical Gigabit ethernet links or by microwave lines with a total capacity of 400 Mbps for each ring. table 7 shows the number of nodes of each type in each segment and the number of access nodes aggregated at each aggregation and preaggregation level. Copyright © 2013, Juniper Networks, Inc. 41 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Table 7: Sample Network Segment Size Network Segment AG 3 Nodes AG 2 Nodes AG 1 Nodes AN Nodes Total regional network 2 32 1024 10240 11,298 aG 3 ring - 32 1024 10240 11,296 aG 2 ring • - 2 64 640 706 aG 1 ring • - - 4 40 44 the total number of nodes in one regional network is 11,298. If the national MBH network has 10 regional networks, the total number of nodes equals approximately 100,000 nodes connected to the national Ip and Mpls core. after you define the infrastructure, node port density is derived automatically, providing the information that you need to decide the platforms to use in each network segment. the high-level topology is driven by lte network requirements. If the same network needs to serve 2G, 3G, and Hspa mobile networks, you must address additional considerations about the base station controller (BsC) and radio network controller (rNC). these nodes usually coincide with the locations of the aG 2 nodes, so they must be equipped with legacy interfaces to provide transport for tDM and atM circuits if necessary. 42 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 MBH Service Profiles we defined four service profiles (one per mobile network type—2G, 3G, Hspa and 4G lte) as subsets of the overall service architecture, which puts together a type of the user-to-network interface (uNI), a type of the Mpls service, and an Mpls service topology with stitching points, and assigns service node functions to the mobile backhaul (MBH) network nodes across segments. each profile can be planned, designed, and deployed independently. this topic describes in more detail the four service profiles—2G, 3G, Hspa, and 4G lte in relation to the MBH service architecture. 4G LTE Service Profile the 4G lte mobile network uses an Ipv4 infrastructure to interconnect its entities. providing Ipv4 over ethernet connectivity is the main objective of the MBH network in this case. a variety of physical interface types, such as 100Base/1000Base-t/lX/sX, can be used to interconnect eNodeB to the MBH Csr. the following three types of interfaces are defined within the 4G lte mobile infrastructure: • s1-u—an over-Ip interface that carries user data traic from eNodeB to the serving Gateway (sGw). sGw is an element of the evolved packet core (epC). • s1-MMe—an over-Ip interface between eNodeB and the mobility management entity (MMe) that carries control plane traic used to manage and control mobile entities. MMe is an element of the epC. • X2—an over-Ip interface between two eNodeBs that is used to manage and control mobile entities at the time of handover between eNodeBs. to provide connectivity between mobile network elements over an MBH network for these interfaces, you can use Mpls layer 2 or layer 3 services. Building a large-scale, full meshed Mpls layer 2 network is a very complex task, and we recommend avoiding it if possible. Instead, we recommend that you use Mpls layer 3 services. Figure 18 illustrates the recommended service architecture for a 4G lte service profile. a separate logical layer 2 and layer 3 interface between the eNodeB and the access node is used per mobile network interface (s1-MMe, s1-u, X2). each eNodeB connects the access node over a physical Gigabit ethernet port. at layer 2, vlaN tagging is implemented at the uNI to separate traffic between logical interfaces. at layer 3, you assign an Ip address to each logical interface and place it into a separate layer 3 Mpls vpN, which provides end-to-end connectivity between eNodeBs and epC elements across the MBH network and for each mobile network interface—s1-MMe, s1-u, and X2. In Figure 18, these layer 3 vpNs are s1-MMe, s1-u, and X2 services mapped to the mobile network interfaces s1-MMe, s1-u, and X2, respectively. If your eNodeB supports one Ip interface, you can use one vlaN and one logical interface in one vrF, instead of three Ip addresses, three vlaNs, and three vrFs, as in our example. 1588v2 Grandmaster 1588v2 on Separate VLAN in GRT VLAN S1-MME VLAN X2 eNode B VLAN S1-u 1588v2 S1-MME Logical Interface MME X2 VLAN S1-MME eNode B S1-MME AN Physical Port VLAN X2 VLAN S1-u EPC S1-u AN SN PE IP/MPLS MBH S1-u SGW/ PGW SN Timing L3 VPN for S1-MME L3 VPN for X2 L3 VPN for S1-u Figure 18: Recommended Service Architecture for 4G LTE Service Profile the dotted lines in Figure 18 show connectivity within the layer 3 vpNs. Copyright © 2013, Juniper Networks, Inc. 43 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Depending on the type of uplink and downlink separation technology used for the air interface, requirements are different. a 4G lte network with time-division duplex (tDD) lte at the air interface requires both frequency and phase synchronization. MBH can deliver both. synchronous ethernet is most commonly used to provide frequency synchronization and is a very reliable method because the synchronization signal is distributed at the physical layer. all platforms in the MBH network that stay on the path of signal distribution should support this feature. However, synchronous ethernet does not address the needs of the mobile network that requires phase synchronization. the Ieee 1588v2 precision timing protocol (ptp) is used to address this requirement. Both methods (synchronous ethernet and Ieee 1588v2) complement each other, and can be deployed simultaneously. the timing and synchronization distribution are shown in Figure 18 and Figure 19. the blue dotted lines in Figure 18 represent Ieee 1588v2, and the blue dotted lines in Figure 19 represent synchronous ethernet. Defining the CoS Attribute at the UNI Interface Class-of-service (Cos) attributes are an essential part of the MBH 4G lte service profile definition. traffic classification with regard to Cos can be defined as follows: • Behavior aggregate classiiers—Ieee 802.1p or Diferentiated services code point (DsCp) classiiers at the ingress uNI • logical interface classiiers—Mapped to a particular vlaN • Multiield classiier—Based on the Ip source preixes of the s1-u, s1-MMe, and X2 interfaces all the deployment scenarios in this guide use a Cos configuration in which all traffic is marked with the correct Cos attribute by eNodeB or epC before it arrives at the MBH uNI. after that, the Ba mechanism is used to map traffic to the forwarding class for Cos management throughout the network. HSPA Service Profile the Hspa service profile is defined for the Hspa universal mobile telecommunications system (uMts) mobile network, which is capable of using the Iub interface over an Ip or ethernet interface. this type of Iub interface is used to carry user data from an Hspa NodeB to an Hspa rNC over layer 3 services. NodeB or rNC is responsible for Iub encapsulation into the Ip interface with the MBH network access node by using Ipv4 over ethernet. You can use different types of ethernet ports to interconnect NodeB to the MBH network—100Base-t/lX/sX interfaces or 1000Base-t/lX/sX interfaces. there are three different deployment scenarios from the Mpls service architecture perspective: • end-to-end layer 3 vpN • layer 2 vpN to layer 3 vpN termination • layer 2 vpN to vpls termination (Hierarchical vpls) End-to-End Layer 3 VPN the design for end-to-end layer 3 vpN is identical to the design described for the 4G lte service profile in 4G LTE Service Profile. Layer 2 VPN to Layer 3 VPN Termination this deployment scenario uses layer 3 vpN, which transports Iub interface traffic defined in the third-Generation partnership project (3Gpp) standards for Iub over Ip infrastructure. the actual service node function can be located either on the Csr or somewhere in the preaggregation segment. (see Figure 19.) L2 PW to L3 VPN AN 3G PC Node B Iub IP Sync Ethernet Iub IP Node B IP/MPLS ACCESS Iub IP AG 1 IP/MPLS AGGREGATION PE RNC AN Serves as SN Timing VPLS L2 PW Figure 19: HSPA Service Profile with End-to-End Layer 3VPN and Pseudowire in the Access Segment 44 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 to extend service delivery from the service node, use a layer 2 circuit (layer 2 vpN) between the service node and the Csr or access node. usually the point of service delivery is placed somewhere at the border between segments and can be a preaggregation or aggregation router. the layer 2 pseudowire is terminated directly into the layer 3 vpN where a special stitching technique is used. the exact placement of the layer 3 service delivery point within the MBH network and the stitching technique become clearer after we discuss the network topology in the “Mpls service Design for the Hspa service profile” topic. usually 3G mobile networks require frequency synchronization only. In this example, we use synchronous ethernet to provide necessary functionality—the blue dotted line in Figure 19. Note that the timing and synchronization in the MBH network are independent of the service profile, so a combination of different techniques can be used. Class of service traffic marking is fulfilled on the basis of 802.1p at the cell site router in the Cos model. End-to-End Hierarchical VPLS Hierarchical vpls in the access and aggregation network represents another valuable scenario for Hspa networks that use Iub over ethernet. the service architecture is very similar to the architecture in the 4G lte and Hspa examples. a router in the preaggregation or aggregation segments serves as the service node (sN)—aG 1 with the vpls hub in Figure 20—with multiple Csrs as vpls spokes in the access segment extending service delivery to the physical and logical uNI with layer 2 pseudowires. each service is represented by a single physical or logical interface at the access router. L2 PW to VPLS AN 3G PC Node B Iub IP Sync Ethernet Iub IP Node B IP/MPLS ACCESS Iub IP AG 1 PE IP/MPLS AGGREGATION RNC AN Serves as SN Timing VPLS L2 PW Figure 20: HSPA Service Profile with End-to-End VPLS Class-of-service, timing, and synchronization requirements are the same as in the Hspa service profile scenario. 3G and 2G Service Profiles the 3G and 2G series of scenarios for transporting Iub and abis traffic for Hspa and 2G networks use legacy atM and tDM interfaces. MBH services are represented at both ends of the network by the physical interface and encapsulation type—on one side by NodeB and on Bts, on the other side by rNC and BsC. all traffic on the physical interface is encapsulated into an Mpls pseudowire (satop, CesopsN, or atM pseudowire [pw3]), mapped to a unique forwarding-class (usually strict-high), and transported though the MBH network. (see Figure 21.) 3G PC AN Sync over E1/T1 Node B Iub ATM/TDM Iub ATM/TDM Sync Ethernet Abis TDM SAToP/CESoP/ATM PW Sync over E1/T1 BTS AN IP/MPLS ACCESS IP/MPLS AGGREGATION 2G BSC AG Abis/TDM Timing L2 PW Figure 21: 3G and 2G Networks with ATM and TDM Interfaces Copyright © 2013, Juniper Networks, Inc. 45 Design Guide - Juniper Networks universal and aggregation MBH 1.0 to place the circuit emulation traffic into the appropriate forwarding class within the access node configuration, class of service rules are defined as a part of the Mpls service itself. (see the topic “Cos planning” for more details.) unlike legacy networks that commonly use in-band synchronization mechanisms within the same tDM circuit, in this scenario (as in the previous scenarios), you implement an out-of-band technique to distribute synchronization across the network and reset the circuit at the uNI level. we position synchronous ethernet as the primary method for delivering timing and synchronization to Csrs from the source connected at the aggregation network, as shown in Figure 21. Clocking for the NodeB or Bts is further provided from the Csr over the same e1 and t1 or dedicated interface. 46 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 CoS Planning each of the defined services can be assigned to a particular traffic class and prioritized. In general, mobile backhaul (MBH) consists of services signaling, user plane transport, and management traffic that can be classified, prioritized, and scheduled using Cos. the MBH network must recognize the Cos settings, re-mark packets if required, prioritize packets, and apply Cos rules to the traffic streams. at the same time, MBH carries a few more types of traffic: • Ieee 1588v2 precision timing protocol (ptp) • Network control traic (IGp, Mpls, rsvp, lDp control traic, and so on) • oaM (CFp, Y1731, and BFD) Figure 22 shows the types of Cos marking that differentiates the traffic streams. IP RAN CoS Scenarios 802.1p (Layer 2) DSCP (IP) EXP (MPLS) Figure 22: CoS Marking Backhaul networks must support the main traic types—voice, video, network signaling and management, and best-efort data. In addition, the network should provide low packet loss. For low packet loss, you must determine and maintain Cos deinitions at each node in the backhaul, so that the traic types can be prioritized through the network accordingly. traffic Cos marking at the uNI depends on the type of connectivity (that is, layer 2 and layer 3) and services offered. Figure 23 shows the classifiers used in the layer 2 portion of the sample network. ACCESS PREAGGREGATION AGGREGATION SERVICE EDGE 4G EPC MME HSS CORE NETWORK IP/MPLS SGW/ PGW eNode B 802.1p 802.1p Classifier on Ingress DSCP DSCP Classifier on Ingress EXP EXP EXP Rewrite on Egress EXP EXP EXP EXP EXP 802.1p 802.1p Rewrite on Egress EXP Classifier on Ingress EXP EXP PCRF EXP EXP EXP DSCP DSCP Rewrite on Egress Figure 23: 802.1p and DSCP to EXP Rewrite Copyright © 2013, Juniper Networks, Inc. 47 Design Guide - Juniper Networks universal and aggregation MBH 1.0 In Figure 23, we use 802.1p and DsCp classifiers when applying Cos to tagged or untagged frames. the cell site devices perform queuing, scheduling, and prioritization based on the 802.1p, DsCp, or both 802.1p and DsCp bit marking. when the frames need to be transported across the backhaul network using Mpls label-switched paths (lsps), eXp classifiers are used within the core to classify packets, and the 802.1p or DsCp Cos values need to be rewritten into eXp markings at the access node and transported over the lsps. typically, behavior aggregate (Ba) classifiers are used together with schedulers to achieve the required Cos guarantees in a network. However, using a combination of Ba and multifield (MF) classifiers introduces an extra level of granularity. You can prioritize traffic streams within a particular class on the basis of vlaN Ip source addressing. when you configure Cos classification and rewrite rules, you assign each packet to a particular forwarding class. In the deployment scenarios in this guide, each network node provides eight forwarding classes at each physical uNI and NNI port. each forwarding class is mapped to one of eight queues, and each queue can be assigned a priority. priority, in its turn, defines how traffic in the queue is scheduled. Higher-priority queues are serviced before lower-priority queues in a weighted round-robin fashion. MX series and aCX series routers have some differences in the way they assign and serve queue priorities. MX series routers use the following definitions: • strict-high—the highest possible priority level. traic in this queue does not have any bandwidth limitations and is restricted only by physical port bandwidth. this traic is always serviced before any other queue receives bandwidth. while there is traic in the queue, strict-high traic is serviced irst along with the in-contract high priority queues. only one strict-high priority queue can be assigned at one time. • High—this queue has the same priority level as strict-high. However, traic in this queue is restricted by the committed information rate (CIr). while traic load is below the conigured CIr bandwidth, it is served irst or in a weighted roundrobin fashion with strict-high and other high priority queues. • Medium high—the traic in this queue is serviced when it is below its CIr and there is not any traic in the queues with higher priorities. If there are multiple medium-high priority queues, they are served in a weighted round-robin fashion. • Medium low—the traic in this queue is serviced when it is below its CIr and there is not any traic in the queues with higher priorities. If there are multiple medium-high priority queues, they are served in a weighted round-robin fashion. • low—the traic in this queue is served when it is below its CIr and there is not any traic in the queues with higher priorities. If there are multiple medium-high priority queues, they are served in a weighted round-robin fashion. aCX series routers use the following definitions: • strict-high—the highest possible priority level. traic in this queue does not have any bandwidth limitations and is restricted only by physical port bandwidth. this traic is always serviced before any other queue. while there is traic in the queue, strict-high traic is serviced irst. Multiple queues can be conigured with strict-high priority at the same time. • High—although high, medium-high, medium-low, and low priority levels are not supported on aCX series routers, this behavior can be achieved by assigning a strict-high priority with a shaping rate. In this guide, we refer to such a coniguration on aCX series routers as a high priority. • weighted deicit round-robin scheduling queue—the traic in this queue is serviced when it is below its CIr and there is not any traic in the queues with higher priorities. although high, medium-high, medium-low, and low priority levels are not supported on aCX series routers, in this guide, we refer to this priority level as a low priority. Mobile technology standards define classes that can be used for traffic classification but do not mandate the number of these classes that are actually used. this number depends on the network implementation and traffic profile. In general, differentiation between the traffic types is done when you mark and prioritize packets as high, medium, or low. the prioritization depends on the traffic type. Four classes of traffic—background, interactive, streaming, and conversational—are defined for 3Gpp-based technologies, such as uMts. a system of nine Qos class identifier (QCI) are defined for 4G lte. 4 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Table 8 4G LTE QoS Class Identifiers QCI Priority Example Services 1 2 Conversational voice 2 4 Conversational video (live streaming) 3 3 real time Gaming 4 5 Non-Conversational video (Bufered streaming) 5 1 IMs signaling 6 6 video (Bufered streaming), tCp-based (e.g., www, e-mail, chat, tp, p2p ile, sharing, progressive video, etc.) 7 7 voice, video (live streaming), Interactive Gaming 8 8 video (Bufered streaming), tCp-based (e.g., www, e-mail, chat, tp, p2p ile these traffic classes can be shared between the wired and mobile traffic streams and are all prioritized based on their Cos marking. the classes can be spilt or aggregated at each node in the backhaul or core network. each hop in the network can classify the packet based on 802.1p or DsCp or eXp classifiers. additional levels of granularity can be added if you prioritize different traffic streams within a traffic class. the level of granularity depends on the type of Cos guarantees, whether the network spans multiple domains, complexity of implementation, and the capability of the network interfaces and equipment. table 9 shows an example of six forwarding classes defined in the MBH network in terms of corresponding DsCp, 802.1p, and eXp marking and queue priorities. Table 9: MBH CoS with Six Forwarding Classes Ingress Queue Parameters Code Points Forwarding class Network control LossPriority 802.1p IP DSCP MPLS EXP low High 7 6 Cs7 Cs6 7 6 Priority Queue Number Bandwidth Percent High 3 5% real time low 5 Cs5, eF 5 strict high 2 30% signaling and oaM low 4 Cs4, aF4x 4 low 4 5% Medium low High 3 2 Cs3, aF3x Cs2, aF2x 3 2 low 1 30% Best efort low High 1 0 Cs1, aF1x 1 low 0 remainder Depending on the particular deployment scenario, you can use additional DsCp values which are then added to the classification rules. table 10 summarizes the description for MBH services. services are described in terms of topology, bandwidth, forwarding class , and restoration time requirements. Table 10: Mobile Network Service Mapping to CoS Priorities Use Case lte Hspa Copyright © 2013, Juniper Networks, Inc. Mobile Network Interface Type of MPH Service Service Level Topology Bandwidth (Mbps) Forwarding Class Restoration time* (ms) s1-u layer 3 vpN Hub and spoke 150 see table 11 200 s1-MMe layer 3 vpN Hub and spoke 10 Medium signaling and oaM 200 X2-C layer 3 vpN partially mesh 10 real time 200 X2-u layer 3 vpN partially mesh 10 real time 200 Iub Ip layer 3 vpN Hub and spoke 10 see table 11 50 Iub ethernet layer 2 vpN point to point 10 see table 11 100 49 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Use Case Mobile Network Interface Type of MPH Service Service Level Topology Bandwidth (Mbps) Forwarding Class Restoration time* (ms) 3G Iub atM atM pseudowire point to point 10 real time 100 2G abis tDM CesopsN point to point 10 real time <50 abis tDM satop point to point 10 real time 50 * restoration time requirement values represent sample values and are not guaranteed by the solutions described in this guide, because they can significantly vary depending on the deployment in the field. table 11 lists the recommended mapping used in this guide between 3Gpp Cos classes and the MBH network forwarding classes. It also provides the classification preferences for mobile oaM traffic, MBH network control traffic, and packet synchronization. Table 11: Mobile Network Services Mapping to MBH CoS Type of Traffic Hspa 4G lte Forwarding Class Loss Priority Background Best efort low Conversational real time low streaming Medium low Interactive Medium High QCI 1 real time low QCI 2,QCI 3, QCI 4 Medium low QCI 5 signaling and oaM low QCI 6, QCI 7, QCI 8 Medium High QCI 9 Best efort low signaling and oaM low Mobile oaM time and synchronization Ieee 1588v2 Network control low Network control traic IGp, BGp, ospF, IsIs CFM, BFD, and so on Network control low For Cos planning, keep the following general principles in mind: • any type of voice or conversational, real-time traic (packet or circuit) is serviced by a forwarding class with a strict-high priority queue. • any user data traffic, depending on the type of traffic (real-time gaming, streaming, Internet) and the application requirements, is serviced within the medium forwarding class that has a loss priority higher than the mobility signaling traffic. • any mobility signaling traic is serviced within the medium forwarding class with a low loss priority. • If it is possible to diferentiate between s1 and X2 traic lows—for example, diferent logical interfaces used at the uNI for traic belonging to X2 and s2—then the X2 traic low is serviced as real-time traic. • any circuit-emulated traic is serviced as real-time traic with a strict-high priority queue. Network control protocols, MBH oaM protocols, and synchronization (Ieee 1588v2) are crucial for transport-level stability, fast failure detection, network convergence, and mobile network stability. all traffic types that are sensitive to delay and jitter and share the same high priority queue affect each other. pay attention to the way you design these forwarding classes in different MBH segments. For example, the amount of BFD traffic can be significantly different in access and aggregation segments, whereas synchronization can be represented by approximately the same amount of traffic across MBH segments. Ideally, the Ieee 1588v2 traffic should be placed into a separate queue. 5 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Timing and Synchronization Planning In mobile access networks including those with 2G and 3G base stations, there are stringent timing requirements for handover as mobile stations move from one cell to another. timing and synchronization are critical elements for maintaining good voice quality, reducing interference, and managing these call handovers. In a typical tDM network, the various entities are synchronized on a common primary reference source. as the industry moves to packet-based transport networks to distribute tDM services, the same level of synchronization is needed to avoid cutouts, lost handovers, and blocked or failed call setup. the Juniper Networks mobile backhaul (MBH) solution supports comprehensive timing and synchronization options, including synchronous ethernet, Ieee 1588v2 precision timing protocol (ptp), t1, e1, and BIts, and providing deployment flexibility to the operator. Juniper Networks Csrs can derive timing from multiple sources simultaneously to ensure that each mobile operator obtains timing from its own clock source and maintains accurate clock recovery. Compliance with the International telecommunication union (Itu) standard G.8261 ensures that the solution meets the stringent jitter and wander requirements demanded by mobile networks. Modularity of the timing module in Juniper Networks Csrs also save cost if alternative timing sources are deployed. the continuity of a circuit clock is lost when the circuit is transported over an Ip-based or packet-based network. the fundamental difference between the two is that the circuit is synchronous whereas the Ip network is asynchronous. Clock synchronization in an MBH network is an essential requirement for handoff support, voice quality, and low interference. loss of timing synchronization can result in poor user experience, service disruptions, and waste of frequency spectrum. Hence, you can distribute timing in a mobile network by using one of the following methods to maintain clock synchronization: • Gps or a legacy tDM network that is external to the Ip-packet based network • packet-based dedicated streams (Ieee 1588-based or Ntp-based ) • synchronous ethernet over the physical layer • Dsl clocking the accuracy for timing delivered at the base station should be at least 16 ppb according to G.8261. two main methods are used for synchronization distribution across the MBH network: • physical layer-based synchronous ethernet (for example, Itu-t standard G.8262) • packet-based precision timing protocol (ptp, standardized in Ieee 1588-2008) Synchronous Ethernet synchronous ethernet is defined by Itu-t with the three standards that define a complete hop-by-hop frequency distribution architecture that provides deterministic characteristics and bounded performance. • Itu-t G.8261—speciies network wander limits for synchronous ethernet interfaces • Itu-t G.8262—speciies ethernet equipment Clocks (eeC)—to be used within network elements • Itu-t G.8264—speciies ethernet synchronization Messaging Channel (esMC)—for managing synchronous ethernet links a reference timing signal traceable to a primary reference clock (prC) is embedded into an ethernet switch or router by means of an external clock port. the ethernet physical layer (pHY) interfaces of each adjacent node in the packet network recovers the frequency signal from the bit stream in a manner similar to a traditional soNet/sDH/pDH framer or line interface unit (lIu). Clock quality is independent of network loading. synchronous ethernet clock distribution can be considered as an extension of the current synchronization distribution network. synchronous ethernet delivers only the frequency, not the phase. the entire network must be based on synchronous ethernet in order to provide the end-to-end physical timing signal. IEEE 1588v2 Precision Timing Protocol (PTP) a time-division duplex (tDD) lte network requires both frequency and phase synchronization, and MBH delivers both by means of the ptp protocol (Ieee 1588v2). ptp is a packet-based synchronization method. the ptp protocol supports system-wide synchronization accuracy and precision in the sub-microsecond range. an Ieee 1588v2 master clock connecting to a prC source communicates with Ieee 1588v2 slaves via the ptp protocol messages over a packetswitched network (psN) to achieve synchronization for both frequency and time. It employs a two-way methodology, where packets are exchanged bidirectionally between the Ieee 1588v2 master clocks and clients or slaves. Ieee 1588v2 defines the following roles that a clock could play in a packet-based clocking synchronization solution. Copyright © 2013, Juniper Networks, Inc. 51 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Ordinary Clock Master Master clock operation is the role that sends the clients (slave and boundary) the necessary messages that allow the clients to establish their relative time distance and offset from this master’s clock or clock reference. the Ieee 1588v2 master clocks might have various sources for frequency and time information. typically, Global Navigation satellite systems (GNss) is used. the delivery mechanism to the clients is either unicast or multicast packets over ethernet or uDp. If multiple master clocks are available in a network segment, a grandmaster is elected by means of announce messages, and all the other clocks synchronize directly with the grandmaster. Ordinary Clock Slave a slave clock or ptp client performs frequency and phase recovery based on received and requested timestamps from the (grand) master. the recovery algorithm is one of the key differentiating factors between implementations of vendors and their performance. a slave implementation recovers frequency and phase or time of day, and presents both to the chassis and system on which it is running. the recovered clock can be distributed further with a variety of methods such as BIts, synchronous ethernet, soNet/sDH, and even Ieee 1588v2. the latter case is an example of a boundary clock, in which the slave and master clock functionality is found in one and the same node. Boundary Clock a boundary clock acts as an Ieee 1588v2 slave on one port and master on other ports. It synchronizes itself to a grandmaster clock through a slave port, and supports synchronization of slaves to it on master ports. Boundary clocks can improve the accuracy of the synchronization by reducing the number of Ieee 1588v2-unaware hops between the grandmaster and the slave. You can deploy boundary clocks to deliver better scale because they reduce the number of sessions and the number of packets per second on the master clock. Transparent Clock a transparent clock provides functionality to record the residence time in a single network node (that is, the time it took for this node to forward this packet) for the ptp packets. the slave can remove the packet delay variation caused by a node en route, delivering a higher precision clock. an added advantage of the transparent clock is that it does not have to maintain any sessions for the ptp packets. It does, however, require all the routers en route to support the capability of modifying the timing packets while forwarding them. the first three methods are currently supported on the following Juniper Networks platforms—aCX series, MX series, and the tCa series. Synchronization Design our comprehensive support for clocking on the aCX series and MX series platforms, combined with leading Junos os capabilities enables several use cases. the goal is to deliver frequency, time, phase, time of day, or all these features, from the network core to the customer edge (Ce). the following three use cases are described in this guide: • end-to-end Ieee 1588v2 with a boundary clock • end-to-end Ieee 1588v2 in combination with other methods such as GNss (10 MHz), BIts-t1 or e1, pps and synchronous ethernet • synchronous ethernet in combination with other methods, such as GNss (10 MHz), BIts-t1 or e1, ptp End-to-End IEEE 1588v2 with a Boundary Clock Figure 24 illustrates an Ieee 1588v2 scenario in which ptp provides synchronization from the grandmaster (GM), on the right, to the NodeB on the left through a direct ptp session or through a chain of boundary clocks. 52 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Option 1: Direct 1588v2 Session between GM and eNodeB M S eNode B S M S M S M M S IP/Ethernet IP/Ethernet 1588v2 1588v2 BC BC 1588v2 1588v2 BC BC 1588v2 Grandmaster MBH NETWORK Option 2: 1588v2 Sessions in a Chain of BC Nodes Timing Master M Slave Boundary Clock S BC Figure 24: IEEE 1588v2 End-to-End In the scenario in Figure 24, there are two options for Ieee 1588v2 clock recovery. the first option is that the grandmaster establishes a direct ptp session with each eNodeB, which requires synchronization signaling. In this case, the network in the middle is not required to detect the Ieee 1588v2 protocols. the network requires only Cos configuration to assign ptp packets to the low-latency strict-high priority queue. this approach might work in some cases, but it leads to a number of restrictions in the MBH design. • the irst restriction is a very strong limitation in the number of hops between the grandmaster and the end mobile entity—especially in a ring topology where the number of hops between aggregation and cell nodes can double as a result of link failure scenarios. • the second restriction can come from the grandmaster, which might need to scale to thousands of simultaneous ptp sessions. • the third restriction is that ptp clock recovery is very sensitive to the jitter parameter. Jitter itself can vary signiicantly on multihop distances if any other traic type (voice, video, or oaM) is placed in the same low-latency queue as the ptp packets. For microsecond or even nanosecond accuracy, we do not recommend this design. the second option, which we recommend (Figure 24), is the use of a chain of boundary clock nodes with ptp over Ipv4 unicast to provide the synchronization signaling. this option solves the restrictions mentioned above, and significantly improves accuracy. Next, consider grandmaster redundancy in different network failure scenarios. (see Figure 25.) Copyright © 2013, Juniper Networks, Inc. 53 Design Guide - Juniper Networks universal and aggregation MBH 1.0 RAN CSR BC PREAGGREGATION BC BC BC AGGREGATION BC S 1588v2 1588v2 1588v2 1588v2 1588v2 1588v2 Grandmaster 1588v2 S 1588v2 1588v2 1588v2 1588v2 1588v2 Boundary Clock Slave BC S Figure 25: IEEE 1588v2 End-to-End with Boundary Clocks In the sample deployment scenario in Figure 25, we configure only one uplink interface on each Csr as a ptp slave. one failure that brings the interface down could break the ptp session between any master-slave pair. In this case, we rely on the holdover process, which defines the length of time the oscillator of a network element can maintain accuracy after losing its primary reference clocking source. Holdover can be critical to keeping a Csr within operational tolerances. the importance of holdover is best illustrated with an example. Imagine a scenario where a timing server is providing timing packets to 200 timing clients located at cell towers that are geographically distributed. In a normal situation, the timing server is locked to a global reference such as Gps or to a master atomic clock. the timing clients are all locked to the timing server, and the synchronization signals generated by the timing clients meet 3Gpp and Itu-t specifications. assume now that during the course of routine maintenance, a technician inadvertently pulls out a cable from, or misconfigures, one of the routers in the network, thereby disconnecting the servers from the clients. the 200 timing clients now stop receiving timing packets and begin drifting in frequency and phase. In the absence of holdover, these clocks will exceed the Itu G.823 synchronization mask for phase accuracy in typically less than 15 minutes, and this will cause degraded performance in the entire geographic region. For longer outages, the accumulated drift can result in an accumulation of over 125 µs of delay difference resulting in a “frame slip.” However, if the 200 timing clients enter into a holdover state, they will continue to provide an acceptable timing signal while the problem in the network is diagnosed and resolved. a timing client with excellent holdover can then still provide frequency and phase during a network outage or “timing server unreachable” event without causing a service availability issue for up to 4 to 6 hours for the G.823 requirement and up to 3 days before a frame slip. therefore, holdover performance is a key to meeting service availability requirements. with the current Juniper Networks platforms, the holdover buffer can vary from a few hours to a few days depending on clocking accuracy requirements. the holdover situation applies to the ring topology in this guide and represents a minor limitation in most scenarios. 54 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 End-to-End IEEE 1588v2 with an Ordinary Clock in the Access Segment Figure 26 illustrates a slightly modified scenario from the first scenario described in the topic “end-to-end Ieee 1588v2 with a Boundary Clock.” RAN CSR PREAGGREGATION S S BC BC AGGREGATION BC 10MHz SyncE 1588v2 1588v2 1588v2 1588v2 1588v2 Grandmaster BITS 1588v2 E1/T1 PPS 1588v2 1588v2 1588v2 1588v2 Boundary Clock Slave BC S Figure 26: IEEE 1588v2 and Synchronous Ethernet Combined Scenario In the scenario shown in Figure 26, we combine different synchronization protocols—10 MHz, BIts, synchronous ethernet, pps, and e1 and t1 line clocking. the Ieee 1588v2 grandmaster acts as a clocking source using Ieee 1588v2 as the primary method. routers at the preaggregation and aggregation segments are configured with boundary clock settings and propagate synchronizations signaling down to the access segments. In this case, each Csr is configured with an ordinary clock mode with two slave ports to be peers with a pair of preaggregation provider service edge routers. this design provides the necessary redundancy and preserves the ptp session in case of link or node failure in the access ring. the flip side of this approach is the restriction on the number of nodes in one ring. each Csr acts as an ordinary slave clock and can use a number of different methods to provide frequency synchronization to the NodeB or the eNodeB (raN) on the left—10 MHz, BIts, synchronous ethernet, pps, and e1 and t1 line clocking. Copyright © 2013, Juniper Networks, Inc. 55 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Synchronous Ethernet Scenarios synchronous ethernet is the primary method of distributing timing and synchronization across the MBH when frequency synchronization is required. Figure 27 shows the way we use synchronous ethernet in our solution. RAN CSR M S PREAGGREGATION M S M S M S M S SyncE 10MHz AGGREGATION 1588v2 SyncE SyncE SyncE SyncE SyncE 10MHz BITS BITS Grandmaster E1/T1 E1/T1 SyncE SyncE SyncE SyncE Master M Slave S Figure 27: IEEE 1588v2, Synchronous Ethernet, and BITS Combined Scenario In Figure 27, the grandmaster (GM) in the aggregation segment on the right uses Ieee 1588v2 or any combination of other methods—synchronous ethernet, 10 MHz, BIts, or e1 and t1 line clocking—to distribute timing and synchronization to the raN. each router has slave ports explicitly configured to accept synchronization from the ethernet line. Both MX series and aCX series routers can have slave ports, and any port can simultaneously be configured as a master and a slave. this feature provides redundancy for the synchronous ethernet clock recovery mechanism in case of link or node failure. ptp traffic requires classification and placement into a forwarding class with strict-high priority. after placement into the highest possible queue, ptp traffic can still compete with other traffic types in the same forwarding class, so it is not possible to guarantee the timing accuracy in some types of topologies. therefore, in addition to the topology design considerations covered in Topology Considerations, you must always take into account timing and synchronization when planning a topology in the access and aggregation segments. 56 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 End-to-End IP/MPLS Transport Design this chapter provides guidelines for the Ip/Mpls transport deployment scenarios of the Juniper Networks mobile backhaul (MBH) solution. the guidelines include details for the segmentation of an MBH network from the routing protocols perspective, that is, how to set up intradomain and interdomain end-to-end label-switched paths (lsps). this chapter includes the following topics: • Implementing routing regions • Intradomain Connectivity • Intradomain lsp signaling • Interdomain lsp signaling with BGp-labeled unicast Implementing Routing Regions a closed interior gateway protocol (IGp) region is a network region where all routers use the same IGp to exchange and store routing information within the region and routing information is not sent across the region border router to the adjacent region by means of the IGp. the primary advantage of regions is to reduce the number of entries in the routing and forwarding tables of individual routers. this configuration simplifies the network, enabling greater scale and faster convergence. lDp and rsvp label-switched paths are contained within a region, so that across the network, the number of lDp sessions and rsvp states are reduced. this reduction in the amount of resources required by each node prolongs the lifespan of each node as the network continues to grow. regions also simplify network integration and troubleshooting. with multiregions, network integration and expansion do not require compatible IGps or compatible lDp and rsvp implementations between networks. In addition, troubleshooting a multiregion network is simplified because problems are more likely to be contained within a single region rather than spread across multiple regions. the set of infrastructure control plane protocols for intraregion connectivity includes: • IGp—Is-Is or ospF to distribute router loopback addresses and compute the shortest path irst (spF) within each region • Mpls—lDp or rsvp traic engineering to signal Mpls label-switched paths (lsps) within each region regions are connected by and communicate with BGp-labeled unicast (BGp-lu). In a multiregion network, BGplu enables inter-region, end-to-end routing by providing communication and connectivity between regions. Defined in rFC 3107, Carrying Label Information in BGP-4, BGp-lu enables BGp to distribute router loopback addresses with associated Mpls labels between the regions and signals hierarchical Mpls lsps. to accomplish this, BGp-lu leverages multiprotocol-BGp (Mp-BGp) and the subsequent address family identifier (saFI) 4, indicating that network layer reachability information (NlrI) contains label mapping. BGp-lu has long been used for inter-autonomous system (as) vpN services, such as carrier’s carrier, and is now being applied to intra-as in a similar way to achieve massive scaling. the nodes at each layer of the MBH hierarchy perform various functions depending on the design and the protocols that are implemented. table 12 lists common characteristics that each layer of nodes at the access, preaggregation, aggregation, and service edge might have. Table 12: Node Functions and IGP Protocols Access Preaggregation Aggregation Service Edge • Customer services peering • ospF single area router • ospF as boundary router (asBr) • Is-Is level 1 router • BGp route relector client • Ingress/egress labelswitched router (lsr) • vpN provider edge router • layer 2/layer 3 edge aggregation • ospF area border router (aBr) • Is-Is level 1/ level 2 router • BGp route relector • BGp route relector client • Ingress/egress/transit lsr • • • • • • • • • • • Copyright © 2013, Juniper Networks, Inc. ospF area 0 router ospF asBr Is-Is layer 2 level router BGp route relector transit lsr BGp asBr ospF asBr Is-Is level 1/ level 2 BGp asBr Ingress/egress/transit lsr vpN provider edge router 57 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Intradomain Connectivity Interior gateway protocols (IGps) establish a control plane to signal label-switched paths within a closed IGp region. this topic discusses segmenting the access and aggregation network to optimize IGp deployment in the MBH network and the points you should consider when choosing a particular IGp. IGP Protocol Consideration In the MBH solution, we place the access and aggregation segments in a common BGp autonomous system that is divided into IGp regions using Is-Is or ospF as the IGp. the Juniper Networks solution supports Is-Is and ospF as the IGp of choice. However, in very large implementations with complex topologies in the access segment, we recommend the use of Is-Is. In simpler cases in the access segment, ospF offers better routing information isolation between different ospF areas than Is-Is offers between different Is-Is levels. to understand this difference between ospF areas and Is-Is levels, it is necessary to define two new terms with regard to two types of topology at the access segment: access region and semi-independent domain. Semi-independent Domains and Access Regions an access region is a region in which two access nodes can establish connectivity to each other at the network (Ip) level without traffic passing though the aG 1 node. two access regions belong to the same semi-independent access domain if any two access nodes in the regions can establish connectivity to each other at the network level with traffic passing through the same aG 1 router. (see Figure 28.) SEMI-INDEPENDENT ACCESS DOMAIN 1 SEMI-INDEPENDENT ACCESS DOMAIN 2 Access Region 1 Access Region 1 AG 1.1 AG 1.2 AG 1.3 AG 1.7 AG 1.4 AG 1.6 Access Region 2 AG 1.5 Aggregation Region Access Region 2 Figure 28: Semi-Independent Access Domains Figure 28 illustrates an aggregation region that interconnects four access regions in two semi-independent access domains—1 and 2. any two access nodes from two different semi-independent access domains can establish connectivity at the network level with traffic passing through two or more aG 1 nodes. In this example, we assume that there is no back door connectivity between two semi-independent access domains. one access region or one semi-independent access domain forms an independent closed ospF or Is-Is domain. although platforms that serve as access nodes in the MBH network are still capable of serving in a broad IGp region with 250 access nodes, it is not a reasonable arrangement. as the number of prefixes in the access node routing table increases, more time is required for the IGp protocol to converge after planned topology changes or after changes due to a failure. Route Information Isolation in OSPF and IS-IS Protocols In contrast with Is-Is, the minimal size of a closed IGp region with ospF is only one access region. with Is-Is, a semiindependent access domain made up of a number of access regions becomes the minimal size for the closed IGp region. (see Figure 29.) 58 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 SEMI-INDEPENDENT DOMAIN OSPF Area 2 IS-IS Area 0001 L1 LSA Exchange L1 L1 OSPF Area 1 IS-IS Area 0002 L1/L2 ABR L2 OSPF Area 0 L1/L2 ABR L1 L1 L1 LSA Exchange L1 L1 OSPF Area 3 IS-IS Area 0003 Figure 29: IGP LSA Boundaries within the Access Segment and Semi-Independent Domain one important factor that determines the choice of IGp protocol is the ospF and Is-Is link-state advertisement (lsa) flooding boundaries. In a multiarea design, ospF area border routers (aBrs) participate in routing for a few separate ospF areas and support separate instances of topology databases for each area. lsa distribution is restricted to a particular area. when using Is-Is, each level 1 and level 1/level 2 router (analogous to the ospF aBr) has only two link state databases, one for each Is-Is level. lsa distribution is restricted by Is-Is level, adding the concept of Is-Is area (which is defined as part of the Is-Is address; see the topic “loopback and Infrastructure Ip addressing”). In the example in Figure 29, all Is-Is routers in the same semi-independent domain contain the full topology for all access regions that make up the semi-independent domain. Using IS-IS when you use Is-Is, the preaggregation and aggregation levels belong to Is-Is level 2, and access rings belong to Is-Is level 1. areas and area identifiers can be used in conjunction with Is-Is levels to enable scaling and the desired routing behavior. (see Figure 30.) AS X L1 IS-IS Area 49.000a ACCESS AS Y L2 IS-IS 49.0001 PREAGGREGATION AGGREGATION SERVICE EDGE 4G EPC MME HSS CORE NETWORK IP/MPLS eNodeB SGW/ PGW Ignore Attached Bit PCRF No L1 to L2 Export Figure 30: Routing Information Isolation with the IS-IS Protocol Copyright © 2013, Juniper Networks, Inc. 59 Design Guide - Juniper Networks universal and aggregation MBH 1.0 we recommend that you configure each region with a unique Is-Is area ID. level 1 routers use level 1/level 2 routers as the next hop for the default route—0.0.0.0/0. the level 1/level 2 routers do not advertise a default route. Instead, the level 1/level 2 routers set the attached bit. this bit is advertised to the level 1 router and causes the level 1 router to install a default route with the level 1/level 2 router as the next hop. there may be times, such as during a denial-ofservice (D0s) attack that you might need to prevent a default route from being installed. In that case, you can use the tt statement to block the installation of the Is-Is default route. i e cedi In addition, a default route is not installed on a level 1 router when a level 1/level 2 router does not have a level 2 adjacency to a different area. the level 1/level 2 router does not set the attached bit, which results in the level 1 router not installing a default route. You can also prevent default route installation by using a single Is-Is area ID that causes the level 1/level 2 router to not set the attached bit. should the need arise for a default route, it is much easier to delete the tt statement than it is to renumber the Is-Is area IDs or to create a routing policy that explicitly advertises a default route. For these reasons, we recommend using a unique Is-Is area ID for each region in conjunction with the tt statement. i e ci i e ci By default, Is-Is level 1 internal routes are installed into the level 2 database–an exchange of routing information between levels that must be prevented in multiregion networks. to prevent level 1 internal routes from being installed into the level 2 database, you must configure an Is-Is export policy on the level 1/level 2 router to reject level 1 routes. level 1 external routes are not installed into the level 2 database by default, and Is-Is level 2 internal routes are not installed into the level 1 database. (see Figure 30.) Using OSPF when you use ospF, aggregation and preaggregation routers reside in a backbone ospF area—0.0.0.0. You configure the Csrs into separate ospF areas with preaggregation routers as ospF aBrs. You configure in the same area Csrs whose rings tap the same pair of preaggregation routers. to prevent the exchange of routing information between ospF areas, you configure the non-backbone areas as totally stub areas. totally stub areas do not receive summary link-state advertisements (lsas) or a default route from the aBr. (see Figure 31.) AS X AS Y OSPF Area 0.0.0.N OSPF Area 0.0.0.1 ACCESS OSPF Area 0.0.0.0 PREAGGREGATION AGGREGATION SERVICE EDGE 4G EPC MME HSS CORE NETWORK IP/MPLS eNodeB SGW/ PGW PCRF Figure 31: Routing Information Isolation with the OSPF Protocol In Figure 31, the backbone area (0.0.0.0) and non-backbone areas (0.0.0.1) are in the one autonomous system (as), while the service edge router is in a separate as, which usually belongs to a core network as that separates the regional aggregation and access segments from the service provider core network. unlike Is-Is, ospF areas can be combined in different ways. For example: • one ospF area to one access region (ring) • one ospF area to multiple access regions • one ospF area to one semi-independent domain In this version of the guide, we do not include ospF in the solution. rather, we present ospF here for completeness. 6 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Intradomain LSP Signaling to signal Mpls label-switched paths (lsps) within a domain, you can use rsvp or lDp. taking into account strict requirements for MBH network resiliency, we strongly recommend that you use rsvp as the universal solution for any topology in the access and aggregation segments. rsvp provides protection for transport lsps and rapid convergence in case of a failure. lDp provides a simple way of setting up a full meshed lsp topology within the IGp region. You can use lDp in some limited cases. For example, in a hub-and-spoke topology, you might use lDp with ospF loop-free alternates (lFas) to provide protection in the event of a failure. However, this technique does not work for resiliency in ring and partially meshed topologies. Deciding on the LSP Topology In the preaggregation segment, a full mesh label-switched path (lsp) topology is the natural choice within the backbone IGp region—ospF backbone area 0.0.0.0 or Is-Is level 2. However, in the access segment and within the IGp access region, you can use a full mesh topology, but you need to take into account the potential complexity and scalability issues that might arise. You have two possible options for the lsp topology: • a fully meshed rsvp lsp topology • a hub-and-spoke rsvp lsp topology a fully meshed lsp topology in the access region uses lte mobile networks where Ip connectivity between eNodeBs is required to enable X2 interface communication. a full mesh establishes a continuous lsp protected by Mpls fast reroute (Frr) and link-node protection between any two nodes within the IGp region. In contrast, the hub-and-spoke rsvp lsp topology provides better protection against preaggregation (aG1) node failure and the shortest connectivity path between two eNodeBs to minimize the delay in packet delivery. the relative complexity of a fully meshed lsp topology can require support of as many as 2*N*(N-1) lsps in an IGp region that must be provisioned at zero time implementation. (Here N stands for the number of access nodes in one IGp region.) You can try to address the problem of complexity by using the rsvp automesh configuration feature or by using bulk rsvp configuration within the network management system. this approach has not been tested and is not included as part of this solution. scalability can also be an issue with a fully meshed lsp topology. the total number of labels supported by aCX series routers that serve as access nodes is 3000 labels per router. Depending on the exact topology and number of nodes in one IGp region, it is possible to reach this number. You should carefully calculate transport labels for ingress, egress, and transit lsps—including lsps to remote service edge routers, and service level labels for Mpls vpNs. a full mesh lsp topology creates many transit states on Csrs. these transit lsp states exhaust resources, reduce the scalability of the topology, and restrict the number of Csrs in one IGp region. to avoid all this complexity and potential scalability issues, we recommend the hub-and-spoke rsvp lsp topology. In this kind of topology we build one rsvp lsp from each Csr to some aggregation routers, specifically router aG 1.1 and router aG 1.2. Interdomain LSP Signaling with BGP-labeled unicast after you have defined the regions and roles for each router, the regions need a way to create end-to-end connectivity and enable inter-region communication. Because regions are not configured to share IGp routing information, you introduce an additional protocol—BGp-lu—to handle interdomain lsp signaling so that pe routers can reach remote pe routers in other regions. For inter-region reachability of access nodes, seamless Mpls introduces BGp-labeled unicast (BGp-lu) (rFC 3107) and hierarchical lsps. BGp-lu is the label signaling and routing protocol that provides edge-to-edge or pe-to-pe reachability. the hops of the BGp-lu label-switched path (lsp) do not need to be adjacent, just as two neighbors that form a unicast internal BGp (IBGp) session do not need to be adjacent. rather, the BGp-lu lsp hops are those routers that participate in BGp-lu and are in the forwarding path. transit routers within each region are not required to detect or participate in BGp-lu—one of the reasons BGp-lu scales so well. (see Figure 32.) Copyright © 2013, Juniper Networks, Inc. 61 Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L1 IS-IS Area 49.000a ACCESS CSR 1.2 CSR 1.1 AS Y L2 IS-IS Area 49.0001 PREAGGREGATION AG 1.1 AGGREGATION AG 1.3 AG 2.1 SERVICE EDGE AG 3.1 4G EPC PE 1 MME HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB CSR 1.4 CSR 1.5 AG 1.2 AG 2.2 AG 1.4 IS-IS Level 1 IS-IS Level 2 RSVP Full Mesh RSVP AG 3.2 PE 2 SGW/ PGW PCRF Core IGP Domain Physical Connectivity RSVP/LDP EBGP-LU BGP-LU Copy CSR’s loopbacks to inet.3 and redistribute to BGP-LU protocol BGP-LU Copy local loopback to inet.3 and redistribute to BGP-LU protocol RR (RFC 3107) BGP-LU LSP HUB & SPOKE LSP HUB & SPOKE LSP HUB & SPOKE LSP Figure 32: Establishing an Inter-AS LSP with BGP-LU Figure 32 illustrates an inter-as lsp with Is-Is as the IGp. the aG 1 routers and the aG 2.1 and aG 2.2 routers form IBGp-lu peering sessions. the aG 2.1 and aG 2.2 routers act as route reflectors, and the aG 1 routers act as route reflector clients. the aG 1 routers redistribute the Csr loopback addresses into BGp-lu, and advertise them to the local route reflectors, which in turn reflect them to aG 1 routers in other preaggregation rings. (see Figure 17.) when the route reflector readvertises BGp-lu routes, the route reflector does not change the BGp next hop, which is the default behavior for IBGp route reflection. at the same time, the aG 2.1 and aG 2.2 routers serve as a asBrs and are peers with multiservice edge routers aG 3.1 and aG 3.2. to establish peering, you use eBGp. routes are advertised from the preaggregation segment to the core IGp region, with the next hop pointing to the aG 2.1 and aG 2.2 routers (next-hop-self)—the default behavior for eBGp. In the access segment, you do not use BGp-lu. the aG 1 routers have routes to the loopback address of all the Csrs from IGp advertisements. so to make the Csrs reachable from multiservice edge routers aG 3.1 and aG 3.2, two things must happen on the aG 1 routers. First, you must configure the aG 1 routers to copy the Csr loopback addresses from the inet.0 to the inet.3 routing table, so that these loopback addresses are advertised as Mpls-labeled routes. second, the aG 1 routers must redistribute these Mpls-labeled routes into BGp-lu. the routers that participate in BGp-lu peering—aG 2, aG 3.1 and aG 3.2, pe 1 and pe 2—must be configured in a similar way. these routers must redistribute their local loopback addresses into BGp-lu. this approach makes the aG 2 routers, aG 3 routers, and pe routers allocate an Mpls label for each BGp-lu Mpls forwarding equivalence class (FeC) that the aG 1 routers advertise in the local aggregation region, creating the required end-to-end lsp hierarchy. 62 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 MPLS Services Design for the 4G LTE Profile this chapter includes detailed descriptions of the Mpls services design for the mobile backhaul (MBH) network. the design of the Mpls services meets the requirements for each of the service profiles—4G and Hspa. End-to-End Layer 3 VPN Design the service model for the 4G lte mobile network uses a layer 3 vpN, which meets all service requirements and provides the necessary connectivity between eNodeBs and the mobile evolved packet core (epC). In this example, you set up end-to-end layer 3 vpN services between each access node and remote provider edge (pe) service router using s1-u, s1-MMe, and X2 interfaces. (see Figure 33.) EPC eNode B VLAN S1-MME VLAN X2 VLAN S1-u eNode B Logical Interface MME X2 Physical Port VLAN S1-MME VLAN X2 VLAN S1-u S1-MME S1-MME AN S1-u IP/MPLS MBH PE S1-u SGW/ PGW AN SN SN L3 VPN for S1-MME L3 VPN for X2 L3 VPN for S1-u Figure 33: Layer 3 VPN Design for the 4G LTE Service Profile In addition, provide any-to-any connectivity between access nodes within the same layer 3 vpN. at the uNI, you can represent a service through the physical interface, but more commonly you would use a vlaN-tagged logical interface. to connect an eNodeB to an access node or an epC to a pe router, you can use an arbitrary unique vlaN number within the 1 through 4095 range. the vlaN number has a local meaning within the port of each service node, so you do not need to synchronize the vlaN number across the MBH network. service nodes at both ends use logical interfaces with Ipv4 addresses assigned to provide necessary connectivity with the mobile network elements at the network layer. these logical interfaces are placed into separate routing instances within a service node and, in this guide, are referred to as vpN routing and forwarding (vrF) or vrF table. vrF tables have a local meaning and provide necessary traffic and routing information separation between services within one service node. You assign each vrF table to one layer 3 vpN. a layer 3 vpN has a global meaning across the MBH network that you define with two characteristics: • service label—provides separation of traic belonging to diferent services or vpNs when the logical interface transfers traic through the MBH network. • vrF route target—unique vpN identiier advertised as an Mp-BGp extended community. the vrF route target manipulates routing information advertised to and from service nodes and places vrF preixes into the correct vrF table. In the sample topologies, we use one common layer 3 vpN for all lte traffic types. this layer 3 vpN is easily adapted to multiple vrFs (one per s1-u, s1-MMe, X2, eNodeB). Figure 34 shows a detailed diagram of the BGp peering sessions between routers in the MBH network. In this example, we use Mp-BGp to signal layer 3 vpN service labels across the MBH network from the Csrs to the pe routers. to provide necessary scalability in terms of the number of BGp sessions that the Csr, aG 1, and aG 2 routers need, a hierarchy of BGp route reflectors is used. aG 1 routers serve as BGp route reflectors for Csrs in the directly connect access regions, and aG 2 routers serve as BGp route reflectors for the aG 1 routers in the corresponding preaggregation regions. (see Figure 34.) Copyright © 2013, Juniper Networks, Inc. 63 Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X AS Y Remote PE L1 IS-IS Area 49.000a ACCESS CSR 1.2 CSR 1.1 L2 IS-IS Area 49.0001 PREAGGREGATION AG 1.1 AGGREGATION AG 1.3 AG 2.1 SERVICE EDGE AG 3.1 4G EPC MME PE 1 HSS CORE Service NETWORK Edge IP/MPLS CSR 1.3 eNodeB CSR 1.4 CSR 1.5 AG 1.2 AG 1.4 AG 2.2 AG 3.2 PE 2 SGW/ PGW PCRF Remote PE LSP LSP IS-IS Level 1 IS-IS Level 2 MP-IBGP MP-EBGP (RFC 4364) Direct Connection Core IGP Domain MP-IBGP RR (RFC 2547) RR (RFC 2547) L3 VPN L3 VPN Figure 34: End-to-End Layer 3 VPN Deployment Scenarios In Figure 34, the following mechanisms are used to signal layer 3 vpN service labels and vrF prefixes from the access node to the opposite end of the network. this end could be either a remote pe router (to provide s1-connectivity) or another Csr that has eNodeB connected within the same vrF (to provide X2-connectivity), as shown in Figure 33. 1. the Csr announces a service label and vrF preixes to the adjacent aG 1 route relectors with the next hop pointing to its own loopback address. 2. an aG 1 route relector readvertises the Csr announcement: • among other Csrs in the same access ring. • among other Csrs in adjacent access rings. there is only one access ring depicted in Figure 34, but in an actual network there are multiple access rings. (see Figure 17.) • to the aG 2.1 and aG 2.2 routers in the Mp-IBGp session. • to the service edge pe 1 and pe 2 routers in the Mp-eBGp (rFC 4364) session. this announcement changes the next hop to its own loopback address, which is the default behavior for eBGp. using similar mechanisms, pe routers distribute vrF prefixes and layer 3 vpN service labels across the MBH network to Csrs. 1. a pe router announces a service label and vrF preixes to the aG 1 route relectors in Mp-eBGp (rFC 4364), with the next hop pointing to its own loopback address. 2. an aG 1 route relector readvertises this announcement to the adjacent Csrs in the Mp-IBGp session and changes the next hop to its own loopback address, which is the default behavior for announcements received through eBGp. at this point, pe routers signal vpN labels in both directions and distribute vrF prefixes from one end of the network to the other end and vice versa. 64 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Depending on the particular service profile, two separate layer 3 vpNs for s1 and X2 interfaces are required. we refer to these two vpNs as vpN-s1 and vpN-X2. In this example, you configure each Csr with two vrFs. You map each vrF to the layer 3 vpN with a route target represented by its BGp community. In Figure 35 and Figure 36, these BGp communities are s1-rt and X2-rt. the shadow zones in the figures show the layer 3 vpN with full mesh connectivity at the service level. VPN-S1 Route Target: S1-RT EPC Route Target: S1-RT CSR 1 PE 1 MME eNodeB HSS eNodeB CSR 2 Remote CORE IP/MPLS Service Edge S1 IP Prefix: A.B.C.1/30 IP: A.B.C.2/30 eNodeB MBH ACCESS & AGGREGATION IP/MPLS PE 2 VLAN: K SGW/ PGW CSR n PCRF Route Target: S1-RT Figure 35: Layer 3 VPNs with a Full Mesh Topology – VPN-S1 VPN-X2 Route Target: X2-RT CSR 2 Route Target: X2-RT CSR 1 eNodeB eNodeB eNodeB CSR 3 MBH ACCESS & AGGREGATION IP/MPLS IP: X.Y.Z.0/30 eNodeB VLAN: YY eNodeB CSR 4 Route Target: X2-RT CSR n Route Target: X2-RT Figure 36: Layer 3 VPNs with a Full Mesh Topology – VPN-X2 this layer 3 vpN with full mesh connectivity at the service level distributes vrF information in the correct way. each router within vpN-s1 has a full list of eNodeB s1 interface Ip prefixes and epC s1 Ip prefixes in the rIB. vpN-s1 allows any-to-any or full mesh connectivity for s1 interfaces. each Csr within vpN-X2 has a full list of eNodeB X2 interface Ip prefixes. vpN-X2 allows any-to-any or full mesh connectivity for X2 interfaces. at this point, MBH provides all requirements for lte mobile network connectivity; however, each Csr contains more routing information than necessary. For example, within vpN-s1, the Csr must provide connectivity from eNodeB to the epC only, and is not required to provide eNodeB to eNodeB connectivity. within vpN-X2, Csrs must provide full mesh connectivity for groups of eNodeBs, but not between all eNodeBs in the network. to further optimize the usage of rIB resources on the small cost-optimized Csr, you must configure vrF import and export policies. VRF Import and Export Policies to restrict the number of vrF prefixes in the rIB of service nodes across the MBH network, you can use an import and export policy on the basis of the extended route target community. Manipulating the size of the rIB with this technique helps to optimize vpN for s1 and X2 route installation. with vpN-s1, you define two route target communities instead of one, s1-aCCess and s1-pe. (see Figure 37.) Copyright © 2013, Juniper Networks, Inc. 65 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Import Community: S1-PE Export Community: S1-Access VPN-S1 EPC Import Community: S-Access Export Community: S1-PE CSR 1 PE 1 MME HSS eNodeB eNodeB CSR 2 MBH ACCESS & AGGREGATION IP/MPLS CORE IP/MPLS Remote Service Edge IP: A.B.C.0/30 eNodeB PE 2 VLAN: K SGW/ PGW CSR n PCRF Import Community: S1-PE Export Community: S1-Access Figure 37: VRF Import and Export Policies for S1 Layer 3 VPN In Figure 37, each Csr and pe router advertises vrF prefixes and installs BGp routes in different ways. each Csr advertises vrF prefixes with the s1-aCCess BGp community, and installs only the BGp routes received with the s1pe community into its vrF table. In contrast, each pe router advertises vrF prefixes with the s1-pe BGp community and installs only BGp routes received with the s1-aCCess community into its s1 vrF-table. thus, we build a point-tomultipoint layer 3 vpN topology where Csrs contain only s1 prefixes from the pe router and the pe router has a full list of all s1 prefixes from all Csrs. the three shadow zones in Figure 37 show the layer 3 vpN-s1 with hub-and-spoke connectivity at the service level. with vpN X2, which is somewhat different from the vpN-s1 service, you use the same import and export policies based on the extended route target community. However, you map the community name to a geographical location or to the indexing group of an eNodeB. the eNodeB defines the group of eNodeBs requiring X2 connectivity from one eNodeB to another. (see Figure 38.) VPN-X2 CSR 2 CSR 1 eNodeB eNodeB eNodeB CSR 3 MBH ACCESS & AGGREGATION IP/MPLS IP: X.Y.Z.0/30 eNodeB VLAN: YY eNodeB CSR 4 CSR n Import Community: X2-ZONE-A Export Community: X2-ZONE-A Import Community: X2-ZONE-B Export Community: X2-ZONE-B Figure 38: Using VRF Import and Export Policies for X2 Layer 3 VPN 66 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 In Figure 38, the two Csrs at the top use the same community to import and export routes—X2-ZoNe-a. those two Csrs belong to the vpN of the X2-ZoNe-a only. another group of Csrs at the bottom of the diagram uses the same community to import and export routes—X2-ZoNe-B, and belong to the X2-ZoNe-B vpN only. the Csr in the middle uses both communities for advertised and received BGp routes and belongs to both X2 vpNs—ZoNe-a and ZoNe-B. the two separate vpNs (X2-ZoNe-a and X2-ZoNe-B) split the number of prefixes that each Csr needs to discover and satisfies the requirements to have all necessary connectivity for X2 interfaces between eNodeBs of the same geographical location. this example—setting up end-to-end vpNs with optimized route information distribution—represents one of the possible scenarios for providing backhaul services for 4G lte networks, with the assumption that any service node has a valid end-to-end lsp to every other service node—that is, Csr-to-Csr, or Csr-to-pe router. a full list of possible Mpls services that might need to be created to satisfy 4G lte profile requirements is listed in table 13. Table 13: MPLS Service for the 4G LTE Service Profile Profile Mobile Network Interface Type of MPH Service Service Topology 4G lte s1-user plane layer 3vpN Hub and spoke s1-MMe layer 3vpN Hub and spoke X2-signaling layer 3vpN partially mesh X2-user plane layer 3vpN partially mesh eNodeB management layer 3vpN Hub and spoke at this point, each end of the network (for example, the access router and the epC router) knows which service label and which next hop (loopback address within the Mp-BGp advertisements) should be used to reach a particular vrF prefix—for example, the epC Ip address for the s1 interface or the eNodeB address for the X2 interface. the service routers—Csrs and pe routers—use a route target community to determine whether the received BGp vrF prefix belongs to that particular vrF or not. Before the service router installs the vrF prefix into the routing information base (rIB) and then into the forwarding information base (FIB), the service router performs additional verification. More specifically, the service router checks for a valid labeled path to the next hop (loopback address of another service router), which it obtains from the MB-BGp announcement for the vrF prefix. Consequently, the service routers signal end-to-end Mpls lsps between any: • two Csrs to provide connectivity within vpN-X2 (Figure 38) • Csrs and pe routers to provide connectivity within vpN-s1 (Figure 37) In the topic “Deciding on the lsp topology,” our recommendation in the access segment is to use a hub-and-spoke lsp topology with an inter-region BGp-lu lsp between aG 1 routers and to the pe routers in the core segment. to establish end-to-end layer 3 vpNs, such as vpN-X2 and vpN-s1, you have two choices: • In the access segment, change the lsp topology to a full mesh, and extend BGp-lu down to the access segment. • In the preaggregation segment, set up a u-turn layer 3 vpN between aG 1routers. In the design of the Mpls transport layer, you can use a full mesh lsp topology, but it might not scale well. (see the topic “Deciding on the lsp topology.”) set up BGp-lu in the access segment with care because it leads to further utilization of l-FIB resources. we recommend the design for Ip and Mpls as described in the topic “end-to-end Ip/ Mpls transport Design,” with the additional configuration of a u-turn layer 3 vpN in the preaggregation segment. U-Turn Layer 3 VPN to avoid a full mesh lsp topology in this example, you must make some modifications to the service level. In this example, the transport level includes only hub-and-spoke rsvp lsps, which means that no direct Mpls transport is available between two Csrs even within the same access ring. Copyright © 2013, Juniper Networks, Inc. 67 Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L1 IS-IS Area 49.000a ACCESS CSR 1.2 AS Y L2 IS-IS Area 49.0001 PREAGGREGATION CSR 1.1 AGGREGATION AG 1.3 AG 1.1 AG 2.1 SERVICE EDGE AG 3.1 4G EPC MME PE 1 HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB CSR 1.4 CSR 1.5 AG 1.4 AG 1.2 AG 2.2 H&S RSVP LSP AG 3.2 PE 2 BGP-LU LSP IS-IS Level 1 IS-IS Level 2 Direct Connection SGW/ PGW PCRF LSP INFRASTRUCTURE Core IGP Domain Default NHS MP-IBGP RR (RFC 2547) MP-EBGP U-turn L3 VRF SERVICE LAYER L3 VPN VRF IP-lookup L3 VPN Figure 39: End-to-End Layer 3 VRF Deployment Scenarios with U-Turn VRF to overcome this obstacle, you configure a special u-turn vrF (with the same route target) on the loopback interface of the aG 1 routers. (see Figure 39.) In addition, you configure the aG 1 route reflector to slightly modify the MpBGp behavior so that no actual reflection happens within the access region. Instead, you configure the next-hopself attribute so that a default vrF route is announced by the aG 1 routers to the Csrs. this modification results in significant reduction of used label and prefix spaces in the rIB and FIB tables of the Csrs and leads eventually to faster convergence during link or node failure in the access region. IP/MPLS Transport and Service Full Picture For the sake of completeness, note how the full protocol stack looks after we put together the Mpls transport and service portions of the solution. there are two possible scenarios: Csr-to-pe router connectivity and Csr-to-Csr connectivity. (see Figure 40 and Figure 41, respectively.) Figure 40 illustrates the full protocol stack and actions taken with Mpls labels when a Csr forwards an Mpls packet and that packet travels across the network to a pe router (Csr-to-pe router). 68 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L2 IS-IS Area 49.0001 L1 IS-IS Area 49.000a ACCESS CSR 1.2 AS Y PREAGGREGATION CSR 1.1 AG 1.1 AGGREGATION SERVICE EDGE AG 2.1 AG 1.3 AG 3.1 4G EPC MME PE 1 HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB CSR 1.4 CSR 1.5 AG 1.2 AG 2.2 AG 1.4 PE 2 IS-IS Level 1 IS-IS Level 2 RSVP Full Mesh RSVP Physical Connectivity RSVP / LDP BGP-LU EBGP-LU BGP-LU Copy CSR’s Io.0 address to inet 3 and redistribute to BGP-LU protocol SGW/ PGW PCRF Core IGP Domain Copy local Io.0 address to inet 3 and redistribute to BGP-LU protocol RR (RFC 3107) Default NHS MP-IBGP MP-EBGP RR (RFC 2547) L3 VPN AG 3.2 U-turn L3 VRF H&S RSVP LSP BGP-LU LSP L3 VPN VRF IP-lookup push L3 VPN L3 VPN pop/ push L3 VPN L3 VPN L3 VPN L3 VPN L3 VPN push RSVP-L pop RSVP-L push BGP-L BGP-L swap BGP-L swap BGP-L BGP-L push RSVP-L pop RSVP-L push RSVP-L swap RSVP-L L3 VPN pop pop L3 VPN BGP-L pop RSVP-L DATA FLOW Figure 40: End-to-End Layer 3 VPN and Data Flow for eNodeB to 4G EPC Connectivity In Figure 40, the Csr must push a minimum of two labels—a layer 3 vpN service label (l3 vpN) and a transport label (rsvp-l) for the intraregion lsp. the layer 3 vpN service label defines the endpoints across the access, aggregation, and core network, and routers do not swap this label unless the packet reaches the next service router. the rsvp transport label defines packet forwarding within the IGp routing region. service routers and region boundary routers push or pop the rsvp transport label. transport nodes swap the rsvp transport label. the BGp-lu label provides reachability between routing regions, domains, and autonomous systems. It is pushed or popped at the service node and swapped at the aBr/asBr nodes. Figure 41 illustrates the full protocol stack and actions taken with Mpls labels when a Csr forwards an Mpls packet and that packet travels across the network to another Csr belonging to a different preaggregation region across an end-to-end layer 3 vpN-X2 connection (Csr to Csr). Copyright © 2013, Juniper Networks, Inc. 69 Design Guide - Juniper Networks universal and aggregation MBH 1.0 L1 IS-IS Area 49.000a ACCESS CSR 1.2 L1 IS-IS Area 49.000b PREAGGREGATION CSR 1.1 AG 1.1 ACCESS AG 1.3 CSR 1 CSR 1.3 eNodeB CSR 1.4 CSR 3 CSR 1.5 AG 1.2 AG 1.4 LSP CSR 5 LSP IS-IS Level 1 Area N IS-IS Level 2 Area G MP-IBGP MP-IBGP RR (RFC 2547) L3 VPN CSR 2 U-turn L3 VRF CSR 4 eNodeB LSP IS-IS Level 1 Area H MP-IBGP RR (RFC 2547) L3 VPN VRF IP-lookup push L3 VPN L3 VPN push RSVP-L pop RSVP-L pop/ push L3 VPN pop/ push L3 VPN L3 VPN push RSVP-L pop RSVP-L pop L3 VPN DATA FLOW Figure 41: End-to-End Layer 3 VPN and Data Flow for eNodeB to eNodeB Connectivity 7 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 MPLS Service Design for the HSPA Service Profile this chapter discusses design details for two deployment scenarios: • layer 2 vpN to layer 3 vpN termination scenario • Hierarchical vpls for Iub over ethernet Layer 2 VPN to Layer 3 VPN Termination Scenario Ip transport in the utraN was first introduced as a part of the 3Gpp release 5 standard in which NodeBs use the Iub interface over Ip over ethernet to communicate with the rNC. as in the 4G lte service profile, the Hspa service profile must be provisioned with layer 3 vpNs across the mobile backhaul (MBH) network. However, the requirements of the Hspa network are more straightforward because Hspa does not require any-to-any connectivity between NodeBs or creation of multiple vrFs on a Csr. table 14 represents the list of Mpls services that you might need to configure to satisfy Hspa service profile requirements. Table 14: MPLS Service for the HSPA Service Profile—Iub over IP Service Profile Mobile Network Interface Type of MPH Service Topology Hspa Iub over Ip layer 2 vpN + layer 3 vpN Hub and spoke NodeB management (optional) layer 2 vpN + layer 3 vpN Hub and spoke the uNI physically located on Csrs and represented by the physical port or vlaN targeted logical tunnel (lt) interface is extended by layer 2 vpNs or pseudowires (as defined by rFC 4905) to the corresponding pair of aG 1 routers. (see Figure 42.) Logical Tunnel (lt) Interface with VRRP Virtual IP ACCESS PREAGGREGATION AGGREGATION AG 1.1 AG 3.1 3G MP-EBGP RNC Iub IP Iub IP NodeB Iub IP CSR 1.n MP-EBGP AG 1.2 AG 3.2 L3 VPN L2 VPN Traffic Flow Connection at the Service Level Active PW Backup PW (not in hot standby) Figure 42: Layer 2 VPN Termination into Layer 3 VPN for the HSPA Service Profile the vlaN number on the uNI can be an arbitrary number from 1 through 4096. this number has a local meaning on the physical port and is not synchronized across the MBH network. the key focus of the Hspa service profile design is that the access pseudowires are terminated directly into the layer 3 vpN service instances without any intermittent breakout into layer1, layer 2, or vlaN connections. (see Figure 43.) Copyright © 2013, Juniper Networks, Inc. 71 Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L2 IS-IS Area 49.0001 L1 IS-IS Area 49.000a ACCESS CSR 1.2 AS Y PREAGGREGATION CSR 1.1 AG 1.1 AGGREGATION AG 1.3 AG 2.1 SERVICE EDGE AG 3.1 3G PACKET CORE RNC PE 1 HLR CORE NETWORK IP/MPLS CSR 1.3 CSR 1.4 NodeB CSR 1.5 AG 1.4 AG 1.2 AG 2.2 AG 3.2 PE 2 PCRF GGSN/ SGSN Remote PE H&S RSVP LSP BGP-LU LSP IS-IS Level 1 Area N IS-IS Level 2 Area N Targeted LDP MP-EBGP PW LSP INFRASTRUCTURE Core IGP Domain L3VPN SERVICE LAYER L3 VPN Logical Tunnel (lt) Interface PW Termination in L3 VRF push L2 VPN L2 VPN push RSVP-L pop RSVP-L pop L2 VPN push L3 VPN L3 VPN L3 VPN L3 VPN push BGP-L BGP-L swap BGP-L swap BGP-L pop push RSVP-L pop RSVP-L push RSVP-L pop RSVP-L L3 VPN pop L3 VPN BGP-L DATA FLOW Figure 43: End-to-End Layer 3 VPN with Layer 2 VPN Termination Deployment Scenario the service node function (layer 3 vpN) is moved to a preaggregation node (aG 1). the number of pseudowires (pws) terminated in a single layer 3 vpN on each aG 1 router equals the number of NodeBs connected to all cell site routers (Csrs) in an access ring. In the sample network (Figure 17), we connect up to 16 access rings to a pair of aG 1 routers. one hundred pseudowires at a time were verified as part of the solution verification process for the scenarios in this guide. also, you need to consider this number when making a decision about the size of the access region in your network. a special logical tunnel interface purposely created and associated with a particular forwarding engine on an aG 1 router is necessary to provide tunneling of pseudowires to the layer 3 routing instance (vrF). each Csr establishes one active pseudowire (for example, aG 1.1) and one backup pseudowire (to aG 1.2). If the remote service edge pe router is located in the core as both aG 1 routers establish an Mp-eBGp session with this pe router to signal the layer 3 vpN in the same manner as in the 4G lte service profile. Figure 43 illustrates the actions taken with Mpls labels (including transport labels) when an Mpls packet is forwarded end-to-end from a Csr to the rNC connected to the remote pe router. the Csr pushes two labels—the layer 2 vpN service label and the transport label for the intraregion lsp. the service label defines the endpoints across the access 72 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 region. aG 1 routers apply a pop action to the layer 2 vpN service label, push the new layer 3 vpN service label, and send the packet end-to-end through the interdomain lsp signaled with BGp-lu. Finally, the layer 3 vpN service label is popped by the remote pe router, and the native Ip packet is forwarded to the mobile network rNC or packet core. although this scenario is positioned for the Hspa service profile, it can easily be expanded for 4G lte networks. within the existing set of features, each of the 4G lte services must be placed into a separate layer 3 vpN and carried with a separate pseudowire. However, inconvenience in the number of pseudowires provisioned for each aG 1 router is such that we do not recommend this method for the primary scenario of the 4G lte service profile. Hierarchical VPLS for Iub over Ethernet the service architecture of hierarchical vpls over Iub for the Hspa mobile network—uMts terrestrial radio access Network (utraN) over ethernet—is similar to what was described in the Hspa Iub over Ip scenarios. However, inter-as layer 3 vpN is changed to inter as vpls. table 15 summarizes the Mpls services that you need to configure to satisfy the requirements of the Hspa service profile. Table 15: HSPA Services - Iub over Ethernet Layer 2 VPN Service Profile Mobile Network Interface Type of MPH Service Topology Hspa Iub over ethernet H-vpls Hub and spoke the uNI physically located on Csrs and represented by the physical port or vlaN targeted logical interface, is extended by layer 2 vpNs or pseudowires to the corresponding pair of aG 1 routers. (see draft-martini-l2circuit-encapmpls.11.txt. also, see Figure 44.) ACCESS PREAGGREGATION CORE AG 1.1 AG 3.1 3G T-LDP RNC Iub Ethernet Iub Ethernet Iub Ethernet T-LDP NodeB AG 1.2 VPLS Hub with Mesh Groups AG 3.2 Active PW Backup PW (Standby) L2 VPN VPLS Instance Traffic Flow Connection at the Service Level Figure 44: H-VPLS Service Model for the HSPA Service Profile the vlaN number on the uNI can be an arbitrary number from 1 through 4096. this number has a local meaning on the physical port and is not synchronized across the MBH network. the key focus of this design is that the access pseudowires are terminated directly into the vpls service instances without any intermittent breakout at the physical layer or data link layer, or at vlaN connections. a vpls instance is a concept similar to a layer 3 routing instance (vrF) defined in the topic “end-to-end layer 3 vpN Design.” a vpls instance is treated as a virtual bridge domain or a virtual switch with its own layer 2 forwarding table within a service node to provide a necessary service separation within the node. vlaN-tagged logical interfaces (uNI) and layer 2 pseudowires (NNI) represent the interfaces of this virtual switch. Copyright © 2013, Juniper Networks, Inc. 73 Design Guide - Juniper Networks universal and aggregation MBH 1.0 For vpls instances on the service node—the aG 1 or aG 3 routers (Figure 45)—we assign a unique vpls ID. this ID can be signaled by targeted lDp protocols between service nodes. as soon as service nodes have a vpls instance configured with the same vpls ID, they are joined into a global vpls instance by means of a layer 2 pseudowire; and they establish a distributed layer 2 vpls domain, which acts as a distributed layer 2 ethernet switch. to provide loop-free layer 2 frame forwarding, vpls requires a full mesh pseudowire topology between service nodes and restriction to the forwarding of traffic back to the NNI. this is especially true when the traffic is received from another core facing NNI (split horizon rule). one obstacle to deploying such vpls services is that, in general, when any-to-any connectivity is required, the number of pseudowires increases as N*(N-1), where N is the number of service nodes in the network. the concept of hierarchical vpls (H-vpls) was introduced to overcome this scaling issue. H-vpls defines two types of nodes—hub and spoke. a spoke node has a number of logical interfaces in the vpls instance and one or two (in case of redundancy requirements) pseudowires to interconnect with the spoke node. spoke nodes have a full meshed connectivity to each other and act as regular vpls nodes with only one exception: spoke nodes forward traffic to spoke pseudowires that they obtain from other NNIs. Figure 45 illustrates the end-to-end H-vpls deployment scenario where Csrs 1.1 through 1.5 act as vpls spokes and aG 1 routers act as vpls hubs. AS X AS Y L2 IS-IS Area 49.0001 L1 Is-Is Area 49.000a ACCESS CSR 1.2 PREAGGREGATION CSR 1.1 AGGREGATION SERVICE EDGE 3G AG 1.1 AG 1.3 AG 2.1 AG 3.1 RNC AG 1.2 AG 1.4 AG 2.2 AG 3.2 SGSN CSR 1.3 CSR 1.4 NodeB CSR 1.5 LSP LSP IS-IS Level 1 Area N LSP INFRASTRUCTURE IS-IS Level 2 Area N Targeted LDP Targeted LDP VPLS PW SERVICE LAYER PW Termination into VPLS Instance push L2 VPN L2 VPN push RSVP-L pop RSVP-L VPLS pop L2 VPN VPLS push VPLS VPLS push BGP-L BGP-L push RSVP-L L2 VPN pop pop VPLS BGP-L pop RSVP-L DATA FLOW Figure 45: End-to-End H-VPLS Deployment Scenario 74 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 In Figure 45, we configure targeted lDp to signal the pseudowire service labels and the vpls ID. each Csr establishes one active pseudowire to router aG 1.1 and one backup standby pseudowire to router aG 1.2. the number of pseudowires terminated in a single vpls on each aG 1 router equals the number of NodeBs in each access region connected to the corresponding aG 1 router, plus pseudowires from remote pe routers. Because there is no traffic between the aG 1 routers, there is no need to signal pseudowires between the aG 1 routers—except for pairs of aG 1 routers connected to the same access regions. this exception leads to another level of hierarchy represented by pe routers that act as hub nodes, with the aG 1 routers as spokes. unlike layer 3 vpNs, no tunneling is required to terminate pseudowires in a vpls instance for those deployment scenarios, because a special type of label-switched interface (lsI) is used instead of the logical tunnel interface. to set up H-vpls, mesh groups within the vpls instance configuration on aG 1 and aG 3 routers are used. the consistency of the switching path across the network is provided by the pseudowire backup protocol on the one hand and the MaC learning process on the other hand. as soon as an active pseudowire goes down, the label-switched interface (lsI) within a vpls instance goes down and triggers the MaC flush event. this event is advertised to adjacent vpls routers by means of a flush type, length, and value (tlv) frame. at the next moment, traffic switches over to the second aG 1 router based on the MaC relearning process discussed in more detail in the “pseudowire redundancy for the Hspa service” topic. Figure 45 also illustrates actions taken with Mpls labels (including transport labels) when an Mpls packet is forwarded end-to-end from an access to the rNC connected to the remote pe router. the Csr pushes two labels: the layer 2 vpN service label and the transport label for the intraregion lsp. the service label defines the end-points across the access region. an aG 1 router applies a pop action to the layer 2 vpN service label, pushes a new vpls service label, and sends the packet end-to-end through the interdomain lsp signaled with BGp-lu. Finally, the vpls service label is popped by the remote pe router, and a native ethernet frame is forwarded to the mobile network rNC or packet core. In general, this deployment scenario applies to the 4G lte service profile. we do not recommend that you use endto-end H-vpls as the primary backhaul service for lte traffic. However, if you are interested in H-vpls in your 4G lte network, add the following steps to your Mpls service level design: • activate local switching on the vpls hub to allow connectivity between eNodeBs over the X2 interface. • add additional pseudowires for X2 connectivity from the Csrs to the aG 1 routers if necessary. Copyright © 2013, Juniper Networks, Inc. 75 Design Guide - Juniper Networks universal and aggregation MBH 1.0 MPLS Service Design for the 3G Service Profile to provide connectivity between mobile network elements for the 3G uMts service profile, which uses atM as the transport environment for Iub-based interfaces, you need to use a special set of circuit emulations over the Ip/Mpls network. this Mpls service design uses end-to-end pseudowires to transport atM over Mpls (as described in rFC 4717). table 16 summarizes the Mpls services that you must configure in the mobile backhaul (MBH) network to satisfy the requirements of the 3G service profile. Table 16: 3G Services on Iub over ATM Service Profile Mobile Network Interface Type of MPH Service Topology 3G Iub over atM atM pseudowire point-to-point to provide physical connectivity to the mobile network entities, service nodes—Csrs, aG 2 routers, and pe routers— must be equipped with interfaces that support atM emulation services over Ip and Mpls. (see Figure 46.) CSR 1 Iub ATM RNC ATM PW IP/MPLS ACCESS Iub ATM Node B 3G AG 2 Iub ATM IP/MPLS AGGREGATION CSR 2 Figure 46 MPLS Pseudowire for Iub over ATM (3G Service Profile) From the service configuration perspective at the port and interface level, point-to-point circuit emulation services require the same settings on the remote pe routers and on the Csrs. traditionally, the rNC and BsC nodes of the 3G and 2G mobile network infrastructures are more geographically distributed in comparison to the epC of 4G lte networks. the possible points of rNC connectivity to the MBH network might be through aG 2 routers. so it might be necessary to establish both inter-as and intra-as pseudowire services. Figure 47 illustrates the establishment of an intra-as pseudowire, targeted lDp (t-lDp) used to signal the pseudowire between the Csrs and the aG 2 routers, and an end-to-end continuous label-switched path (lsp) used at the transport layer. 76 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 L1 Is-Is Area 49.000a ACCESS CSR 1.2 L2 IS-IS Area 49.0001 PREAGGREGATION CSR 1.1 AG 1.1 AGGREGATION AG 1.3 3G AG 2.1 RNC CSR 1.3 NodeB CSR 1.4 CSR 1.5 AG 1.4 AG 1.2 AG 2.2 LSP LDP Tunneling LSP IS-IS Level 1 Area N IS-IS Level 2 Area G LSP INFRASTRUCTURE Targeted LDP LDP-DOD ATM ATM ATM PW3 SERVICE LAYER push L2 VPN push LDP-DOD push RSVP-L L2 VPN LDP-DOD pop RSVP-L L2 VPN L2 VPN swap BGP-L pop push RSVP-L pop RSVP-L pop L2 VPN BGP-L DATA FLOW Figure 47: End-to-End ATM and TDM Pseudowire Deployment Scenario to provide a true end-to-end lsp, lDp downstream-on-demand is used (lDp DoD rFC 5036). lDp DoD is configured on the Csrs and aG 1 routers, enabling the Csr to resolve the loopback address of the remote edge service router with a labeled path. the Csr requests a transport label for the loopback address of only those service routers to which the 3G rNC is connected—the aG 2 router in our example, so preserving the scalability of the Csrs. By design, the Csrs in the access segment do not have routing information to reach routers in other segments. (see the topic “using ospF.”) However, this information is required to establish t-lDp sessions with aG 2 routers and to install an end-to-end transport lsp into the forwarding table of the Csr. this restriction can be overcome by the addition, on the Csr, of a static route that points to the loopback address of the aG 2 router. Note: Do not use a default or summarized route on the Csr, because lDp-DoD does not install an end-to-end lsp using those types of routes. Figure 47 illustrates actions taken with Mpls labels (including transport labels) when an Mpls packet is forwarded end-to-end from a Csr to the rNC connected to the remote pe router. the Csr pushes three labels—the atM pseudowire service label, the transport label for the intraregion lsp, and the transport label for the interdomain lsp. the service level label is preserved along the entire lsp and popped only at the service provider edge router. the rsvp transport label defines packet forwarding within the IGp routing region and is pushed or popped at the service router or at the region boundary and swapped at the transport node. the lDp-DoD label provides reachability between routing regions, domains, and autonomous systems. the Csr pushes or pops the lDp-DoD label. the aBr or asBr nodes (aG 1 routers) swap the lDp-DoD label with the BGp-lu transport label. Copyright © 2013, Juniper Networks, Inc. 77 Design Guide - Juniper Networks universal and aggregation MBH 1.0 MPLS Service Design for the 2G Service Profile this Mpls service design addresses the needs of 2G and Gprs networks, which use the abis interface to communicate between Btss and BsC/pCu over tDM channels. this design uses end-to-end pseudowires to transport tDM over Mpls (as described in rFC 5086 and rFC 4553 for CesopsN and satop services). table 17 summarizes the Mpls services you must configure in the mobile backhaul (MBH) network to satisfy the requirements of the 2G service profile. Table 17: Services on 2G Service Profile Mobile Network Interface Type of MPH Service Topology 2G abis over tDM satop pseudowire point to point 2G abis over tDM CesopsN pseudowire point to point the scenarios in table 17 are almost identical to the scenarios described in MPLS Service Design for the 3G Service Profile. the only difference is the way in which we define the service at the uNI from the link layer encapsulation point of view. Currently Juniper Networks supports two types of encapsulation: • structure agnostic tDM over packet (satop) • Circuit emulation service over packet switched Network (CesopsN) CSR 1 N x ds0 with the E1/T1 Abis ATM E1/T1 IP/MPLS ACCESS BSC CESoPSN PW Abis TDM SAToP PW STM1 BTS BTS 2G AG 1 or AG 2 Abis ATM IP/MPLS AGGREGATION CSR 2 Circuit Emulation Flow Figure 48: MPLS Pseudowire for Abis over TDM for the 2G Service Profile a CesopsN bundle represents an Ip circuit emulation flow. with CesopsN bundles, you can group multiple Ds0s on one Ip circuit, and you can have more than one circuit emulation Ip flow created from a single physical interface. For example, some Ds0 channels from a t1 interface can go in an Ip flow to destination a, and other Ds0 channels from that same t1 interface can go to destination B. this feature allows for payload optimization. CesopsN bundles comply with rFC 5086, Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN). satop bundles use a standards-based transport mechanism for t1 and e1 circuits that allows them to interoperate with other satop-compliant equipment. satop bundles comply with rFC 4553 to provide pseudowire encapsulation (pwe3) for tDM bit streams (t1, e1, t3, e3) that disregards any structure that can be imposed on these streams, in particular the structure imposed by standard tDM framing. the possible points of BsC connectivity to the MBH network might be through either the aG 1 or the aG 2 routers. so it might be necessary to establish both inter-as and intra-as pseudowire services. Figure 49 illustrates the case for establishing an intra-as pseudowire. 78 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 L1 Is-Is Area 49.000a ACCESS CSR 1.2 L2 IS-IS Area 49.0001 PREAGGREGATION CSR 1.1 AG 1.1 AGGREGATION 3G AG 2.1 AG 1.3 RNC CSR 1.3 NodeB CSR 1.4 CSR 1.5 AG 1.4 AG 1.2 AG 2.2 LSP LDP Tunneling LSP IS-IS Level 1 Area N LSP INFRASTRUCTURE IS-IS Level 2 Area G LDP-DOD Targeted LDP ATM ATM ATM PW3 SERVICE LAYER push L2 VPN L2 VPN push LDP-DOD LDP-DOD push RSVP-L pop RSVP-L L2 VPN L2 VPN swap BGP-L pop push RSVP-L pop RSVP-L pop L2 VPN BGP-L DATA FLOW Figure 49: MPLS Pseudowire for Abis over TDM (2G Service Profile) all considerations about using lDp-DoD and lDp tunneling described in the topic “Mpls service Design for the 3G service profile” are applicable to the satop and CesopsN scenarios. Copyright © 2013, Juniper Networks, Inc. 79 Design Guide - Juniper Networks universal and aggregation MBH 1.0 OAM the transport layer for operation, administration, and Maintenance (oaM) depends on ethernet-based and Mplsbased oaM tools. the purpose of oaM tools is twofold: to determine the fault in the network, and to isolate and diagnose faults so that corrective action can be taken; for example, redirecting the traffic from a failed path to a backup path and repairing any faults after they have been isolated. oaM tools and management entities can be deployed at various points in the transport network. a failure can be defined in relation to the requirements, which might be a complete loss of connectivity or partial loss, such as a one way failure. also, the failure could be that connection quality drops below a certain threshold. In this topic, we discuss oaM for active monitoring of active paths in each segment and across each segment in the network. the following list includes the full set of oaM instruments in the mobile backhaul (MBH) network and maps them to a particular level of the network architecture. • segment (access, preaggregation, aggregation, and service edge). - Intrasegment oaM - Intersegment oaM • Network layers (transport and service) - ethernet lFM/CFM - Mpls - BGp - service level oaM (layer 2 vpN) Intrasegment OAM the intrasegment of the transport network uses link level oaM to detect failure within a segment. Because all the links in the transport network are ethernet, Ip, or Mpls, you can use either CFM or BFD to monitor and measure the network performance. Both CFM and BFD provide aggressive timers, which detect failure in less than a second. BFD or CFM session connectivity verification can trigger rsvp traffic engineering or lDp failover. the CFM suite provides advanced capabilities, such as packet loss and delay measurement, to determine the health of the link. (see Figure 50.) 8 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X AS Y L2 IS-IS Area 49.0001 L1 Is-Is Area 49.000a ACCESS CSR 1.2 PREAGGREGATION CSR 1.1 AG 1.1 AGGREGATION AG 1.3 SERVICE EDGE AG 2.1 AG 3.1 4G EPC PE 1 MME HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB CSR 1.4 CSR 1.5 AG 1.2 AG 1.4 AG 2.2 AG 3.2 PE 2 Core IGP Domain !"# sical and Datalink OAM 802.3ah 802.1ag 802.1ag 802.1ag 802.1ag 802.1ag OSPF and IS-IS OAM BFD BFD BFD BFD Physical Connectivity BFD BFD MPLS/RSVP Transport BFD Multihop BFD BGP-LU Transport MP-BGP Service Level Multihop BFD L2 VPN Service Level 802.1ag SGW/ PGW PCRF 802.1ag BFD Multihop BFD Multihop BFD Multihop BFD Figure 50: OAM in the MBH Solution In Figure 50, we use CFM (Ieee standard 802.1ag) to check the physical layer and the data link layer oaM. For completeness in Figure 50, we have included link fault management (lFM; standard 802.3ah) to show that you can use lFM when your network includes copper links instead of optical links, or when an aCX series router is connected to a microwave transmission system. In this case, lFM provides fast link failure detection, which is not provided by other techniques. (Note that lFM is not verified as part of the solution.) at the IGp, transport, and service levels, we use BFD for intrasegment oaM because it provides a single mechanism for detection of forwarding plane-to-forwarding plane connectivity (including links, interfaces, tunnels, and so on). the single mechanism is independent of media, routing protocol, and data protocol; provides fast convergence of routing protocols—particularly on share media (ethernet); detects one-way link failures; and does not require changes to existing protocols. $n%ersegment OAM Intersegment oaM detects faults in the remote part of the network to redirect traffic as soon as possible and close to the source, using multihop BFD to monitor remote BGp peers. In the event of a BFD session failure, the alternate BGp peer is used. end-to-end oaM is used to detect the operational capability of remote access devices, and the best way to do so is by using BFD over the lsp. If the BFD session goes down, either the remote Csr has failed or a path to the device through the transport network does not exist. BFD over an lsp provides approximately subsecond failure detection. Copyright © 2013, Juniper Networks, Inc.  Design Guide - Juniper Networks universal and aggregation MBH 1.0 High Availability and Resiliency the time it takes for a network to converge following a link or node failure can vary dramatically based on a number of factors, including network size, the protocols used, and network design. However, although each particular convergence event is different, the process of convergence is essentially consistent. Co&&'(t)*g + ,o*v'&g'*(' -v'*t Four basic stages are involved in a network convergence event, which typically occur in the following order: 1. Detecting the failure 2. Flooding the information 3. Finding the alternate path 4. updating the forwarding table Detecting Failure Different types of network events can cause failures—link failure, line card failure, router failure, administrative link removal, cost change, and so on. regardless of the cause, the first step in any convergence event is detecting the failure. Many failure detection mechanisms are available; some work at the link-layer level, some are embedded in protocols, and others work independent of protocols. the best results are achieved when you use a combination of multiple mechanisms. using link-layer detection mechanisms such as loss of light (lol) and bit error rate (Ber) alarms is by far the fastest. the interrupt-driven nature of interface events in Junos os software keeps detection time as low as a few milliseconds. However, not all failures can be detected at the link-layer level. Indirect link failures or unidirectional link issues that rely on interior gateway protocol (IGp) timers for failure detection can lead to significant network downtime. this is the very place where different operation, administration, and Maintenance (oaM) tools such as BFD for IGp, BFD, lsp failure detection, and ethernet oaM can help speed up failure detection. Flooding the Information after a router detects link failures or topology changes, it needs to send important topology change updates to its neighbors, and it needs to react to the topology change updates that it receives from its neighbors in turn. these updates are sent through the network at the speed of light, plus any processing time required at each hop in order to decide where to forward the message. so the time taken for devices in the network to receive updates depends on the network diameter and how close a particular device is located to the failure. Finding an Alternate Path after being notified of a failure event, devices on the network must process the information and calculate an alternate path. For link state protocols such as Is-Is and ospF, this means running a new shortest-path-first (spF) calculation. For BGp, it means a new path calculation based on criteria such as weights, local preferences, and as path. the control plane for the access and aggregation network is based on Ip. Ip provides scalable any-to-any connectivity in the larger network and, in general, relies on IGp convergence. a common misconception is that spF calculations add a significant amount of time to the convergence process. However, because of the advances in processor technology, this is no longer the case. with Juniper Networks latest routing engines a full spF calculation—even with thousands of routers—can be performed in a few milliseconds. the deployment scenarios described in this guide rely on this mechanism. Updating the Forwarding Table after the spF calculation finds an alternate path, the router updates its forwarding table—commonly known as the forwarding information base (FIB)—with the new next hop for all affected prefixes. traditionally, the time this process consumes is directly related to the number of routes in the network and is bound to the memory access time. In other words, the more prefixes that need updating, the longer the process takes. a core link failure might result in IGp reconvergence, which can affect tens or hundreds of thousands of BGp or layer 3 vpN routes. FIB updates in some large-scale networks can be very time consuming. to reduce the time taken to install the new paths in the routing table, we use prefix-independent convergence. Note: In this guide, the spF calculation is used to find an alternative path in case of network failure, and we use global repair mechanism to refer to further forwarding plane update. 82 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 C0120393:s of a Complete Convergence Solution achieving sub-50-ms convergence is relatively easy in small networks, but many individual components of convergence begin to slow rapidly as the network scales. specifically, geographically large networks face challenges from propagation delays, and networks with a large number of nodes (regardless of geographic characteristics) are slowed by the number of route updates that must be processed. thus, the goal of rapid convergence can be attained only with a solution that enables fast convergence independent of network size. some in the industry promote prefix-independent convergence, which delivers fast convergence regardless of the number of BGp prefixes in the network. although this is certainly an important part of a complete convergence solution, it is only one aspect. Fast convergence that also relies on speeding up both IGp and BGp convergence must work for all services, and must accelerate all the processes outlined above. the Juniper Networks complete convergence solution ensures both fast IGp and BGp convergence, and also extends fast convergence with techniques such as local repair and loop-free alternate routes. Local Repair one way to speed convergence is to create a solution that implements a repair before all the routers in the network have been notified and had their forwarding tables updated. this is known as a local repair (in contrast to the global repair mechanism described in the topic “Finding an alternate path”). local repairs are implemented immediately upon failure detection, while the routing software continues to recalculate the entire network topology. local repair and global repair are complementary. local repair enables traffic to continue to be routed by using a backup path until global repair is able to calculate a new optimal route. eventually the entire network converges with the recalculated topology; but because the local repair is implemented immediately, disruption to traffic can be kept well under 50 ms. For local repair to be possible, the following conditions need to occur: • the forwarding table must be prepopulated with a viable backup path. • there must be a shortcut path for forwarding table updates for backup-path switching. to provide 50-ms resiliency for any single failure in the network, you must provide support for both the head-end and mid-point Mpls fast reroute (Frr) point of local repair (plr) functionality. transport plane protection is a little more complex and must be handled carefully because multiple segments stitch the Mpls lsp across the access, aggregation, and core segments. the goal of the protection scheme is to provide resilience in the network so that traffic disruptions, due to a link or a node failure, can be avoided. the transport plane is built by the “divide and conquer” approach, which means that the transport network is divided into different segments so that the control plane and data plane can scale given the size of the network. each segment has protection schemes to recover from faults within that segment. to provide subsecond end-to-end failover due to any failure in the network, a mechanism to detect and repair faults across the segments is required at the following three levels: • Intrasegment—fast reroute, facility protection, and path protection • Intersegment—IGp and BGp convergence with BFD enabled • end-to-end service level: - end-to-end layer 3 vpN—BGp convergence with BFD enabled - layer 2 to layer 3 vpN termination—pseudowire redundancy and BGp convergence with BFD enabled - H-vpls—pseudowire redundancy and MaC address learning Intrasegment Transport Protection this section describes the protection scheme within one IGp region or area in all deployment scenarios covered in this guide. each scheme in a segment or area depends on the protocol used in that segment. the protection is handled in each segment independently. to provide fast convergence, we use a combination of local and global repair mechanisms. the protection mechanisms used in the access segment for local repair vary depending on the particular topology. the Csr can be directly connected or not directly connected to the aggregation node. a directly connected Csr, as in dual homing, can protect against aggregation node failure—for example, by means of an IGp loop free alternate (lFa). In the scenarios in this guide, the access nodes are not directly connected to the aggregation nodes. thus, we use rsvp traffic engineering with facility protection or one-to-one fast reroute protection with one dedicated backup detour that protects one lsp. to decrease the amount of time needed to calculate the alternative path for global repair, we use primary and secondary paths. Copyright © 2013, Juniper Networks, Inc. ./ Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L2 IS-IS Area 49.0001 L1 Is-Is Area 49.000a ACCESS CSR 1.2 = > CSR 1.1 AS Y PREAGGREGATION ? AG 1.1 ; < AGGREGATION SERVICE EDGE 4G EPC 6 AG 1.3 AG 2.1 AG 3.1 PE 1 MME HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB CSR 1.4 AG 1.2 CSR 1.5 AG 2.2 AG 1.4 AG 3.2 PE 2 Core IGP Domain = > ? U-turn L3 VRF ; < SGW/ PGW PCRF 6 LSP L3 VPN L3 VPN Link-Node Protection Tunnel push L2 VPN L2 VPN push RSVP-L BGP-L push FP FRR-L swap RSVP-L push FP FRR-L Figure 51: Intrasegment Facility Link and Link-Node Protection Figure 51 shows many-to-one protection (facility backup), which we configure based on interface rather than on lsp. although fast reroute protects interfaces or nodes along the entire path of an lsp, many-to-one protection can be applied on interfaces as needed. In Figure 51, a bypass path is set up around the links to be protected (failures 1, 3, 4, and 6) using an alternate interface to forward traffic. the bypass path is shared by all protected lsps traversing the failed link (many lsps protected by one bypass path). In this guide, six failure scenarios in the access and aggregation segments are addressed by intrasegment transport protection. Figure 51 shows the following failure scenarios: 1. Between Csrs 2. at the Csr 3. Between the Csr and the preaggregation router 4. Between preaggregation routers 5. at the preaggregation router 6. Between the preaggregation and aggregation routers to overcome issues with rsvp traffic engineering scalability in the access segment, we recommend a scheme with huband-spoke rsvp lsps between Csrs acting as spokes and the aggregation routers (aG 1 routers) acting as hubs. In a ring topology, rsvp creates a lot of transit states on Csrs. these transit states exhaust resources, reduce the scalability of the topology, and restrict the number of Csrs in one IGp region. (see the topic “Deciding on the lsp topology.”) the recommended approach offers a necessary level of flexibility and can be used in any kind of access topology. the aggregation and core network uses rsvp traffic engineering with link protection or node protection, which scales rsvp well. 84 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 You can use the link or link-node failure protection algorithm for all deployment scenarios except the 3G and 2G service profiles where end-to-end CesopsN and satop pseudowires are used. In failure scenarios 1, 2, and 3 in Figure 51, an additional Mpls transport level in the access segment is represented by lDp-DoD. using facility protection can lead to a situation in which a Csr must push four Mpls labels in a row, as shown in Figure 52. the fourth label is a result of the establishment of the fast reroute facility (link and link-node) protection tunnel. ACCESS AGGREGATION LDP-DOD LSP LSP ANY PW LSP ANY PW Link-Node Protection Tunnel push L2 VPN 4 x labels in case of failure push LDP-DOD L2 VPN BGP-L push RSVP-L swap RSVP-L push FP FRR-L push FP FRR-L Figure 52: Intrasegment Facility Protection with LDP Tunneling over RSVP in the Access Segment Figure 52 illustrates the number of Mpls labels used to build a facility protection tunnel in case of failure. In the lDpDoD access segment deployment scenario, the total number of Mpls labels in the packet header equals 4. Because an aCX series Csr can push only 3 labels at one time instead of using facility backup, you must use rsvp one-to-one fast reroute combined with primary and secondary paths to protect the network against link-node failure in the access segment. the main advantages of this approach are control over where the traffic goes after a failure and minimum packet loss. (see Figure 53.) ACCESS AGGREGATION LDP-DOD LSP Primary LSP Secondary ANY PW ANY PW push 3 x labels in case of failure L2 VPN push LDP-DOD push Secondary Path-L L2 VPN BGP-L swap RSVP-L push FP FRR-L Figure 53: Intrasegment Path Protection with LDP Tunneling over an RSVP LSP In Figure 53, the initial Mpls transport configuration for each Csr includes provisioning of two rsvp lsps between the access and aggregation segments with two preprovisioned paths (primary and secondary) over the access ring. only three Mpls labels are used at any given time along both paths. In case of link or node failure along the primary path, traffic is switched to the detour backup for the primary path (part of the local repair mechanism). the failure is then signaled back by rsvp to the lsp head-end, which then switches traffic to the secondary path. In this example, the status of the lsp is controlled by the rsvp control plane. You can also use BFD to control the end-to-end status of the lsp. BFD enables rapid detection of communication failures between adjacent systems. the BFD protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. a neighbor failure is detected when the router stops receiving Copyright © 2013, Juniper Networks, Inc. 85 Design Guide - Juniper Networks universal and aggregation MBH 1.0 a reply after a specified interval. BFD works with a wide variety of network environments and topologies. the failure detection timers for BFD have shorter time limits than the failure detection mechanisms of static routes, providing faster detection. Intersegment Transport Protection Intersegment transport protection covers failure scenarios in which area border routers (aBrs)—aG 1 and aG 3 routers—are involved. this guide predominantly covers aG 1 and aG 3 router failures. these routers play the roles of lsp head-ends and lsp stitching points, which define the specific intersegment failure scenarios—7 and 8. to protect the network against failure scenarios 7 and 8, IGp and BGp convergence is enabled by a few techniques that optimize the whole convergence process. (see Figure 54.) AS X L1 Is-Is Area 49.000a ACCESS CSR 1.2 CSR 1.1 AS Y L2 IS-IS Area 49.0001 PREAGGREGATION @ AG 1.1 AGGREGATION A AG 1.3 AG 2.1 SERVICE EDGE AG 3.1 4G EPC PE 1 MME HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB RSVP LSP CSR 1.4 CSR 1.5 AG 1.2 LDP Tunneling AG 1.4 AG 2.2 AG 3.2 BGP-LU LSP @ PE 2 SGW/ PGW PCRF RSVP LSP A RSVP LSP Figure 54: Intersegment Transport Protection after notification of a failure event (for example, aG 1.1 is down), devices on the access segment must process the information and calculate an alternate path. For link state protocols such as Is-Is and ospF, this means running a new shortest-path-first (spF) calculation. For BGp, it means a new labeled path calculation based on criteria such as weights, local preferences, as path, and so on. the spF calculation finds a new labeled path; the router updates its FIB with the next hop for all affected prefixes. FIB update is a vendor-specific implementation and can be optimized to cut a significant amount of convergence time. Juniper Networks implements hierarchical FIB and prefix independent convergence to decrease FIB update time to 10 ms. Moreover, some decisions about the IGp and BGp design help keep the size of the FIB and rIB tables on the Csrs as small as possible, which allows the exclusion of unnecessary control plane processor time usage, in conjunction with BFD to control IGp and BGp sessions. the IGp and BGp design leads to a deterministic and rather small convergence period, which is in accordance with MBH resiliency requirements for most use cases. You can use inter-area and inter-as rsvp traffic engineering but that is complex and not scalable, so we do not recommend it. End-to-End Protection end-to-end protection provides network resiliency against any failure in the entire path from the access node to the provider service edge router. when you run intersegment and intrasegment protection for the transport Mpls lsp, you provide faster recovery in scenarios where an end-to-end lsp is used—satop and CesopsN for the 2G service profile, and an atM pseudowire (pw3) for the 3G service profile. 86 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 In this guide, three deployment scenarios (end-to-end layer 3 vpN, layer 2 vpN to layer 3 vpN termination, and H-vpls) do not include end-to-end lsp transport. these scenarios use stitching at the Mpls service level, which requires some service level intelligence to redirect the traffic to a secondary stitching point in case of primary stitching point failure. the following deployment scenarios use protection at the service level: • end-to-end layer 3 vpN • layer 2 vpN to layer 3 vpN termination • end-to-end Hierarchical vpls Layer 3 VPN End-to-End Protection for 4G LTE Profile an essential aspect of the end-to-end layer 3 vpN scenario is the u-turn vrF, which is located at preaggregation nodes and serves for better scalability of the solution in the access level in various topologies. each access region is dual-homed to two aG 1 routers. Both router aG 1.1 and router aG 1.2 participate in the u-turn vrF and represent a primary and secondary stitching point at the layer 3 vpN service level. (see Figure 55.) AS X L1 Is-Is Area 49.000a ACCESS CSR 1.2 CSR 1.1 AS Y L2 IS-IS Area 49.0001 PREAGGREGATION B AG 1.1 AG 1.3 AGGREGATION AG 2.1 SERVICE EDGE AG 3.1 4G EPC PE 1 MME HSS CORE NETWORK IP/MPLS CSR 1.3 eNodeB CSR 1.4 CSR 1.5 AG 1.2 AG 1.4 B U-turn L3 VRF AG 2.2 AG 3.2 L3 VPN PE 2 SGW/ PGW PCRF L3 VPN Figure 55: End-to-End Protection for End-to-End Layer 3 VPN Figure 55 illustrates a failure at router aG 1.1. restoration of the failure in the access segment depends on the IGp and Mp-IBGp convergence time, whereas end-to-end restoration between the aG 1.2 router and the aG 3 routers is based on BGp-lu and Mp-eBGp convergence. Pseudowire Redundancy for the HSPA Service Profile (Layer 3 VPN) layer 2 vpN to layer 3 vpN termination scenarios use active and backup pseudowires for the stitching point (aG 1 routers) failure protection at the service level in the access segment. pseudowires are terminated on logical tunnel interfaces, which in turn are placed into layer 3 vpNs on both the aG 1.1 and aG 1.2 routers. (see Figure 56.) Copyright © 2013, Juniper Networks, Inc. 87 Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L1 Is-Is Area 49.000a ACCESS CSR 1.2 CSR 1.1 AS Y L2 IS-IS Area 49.0001 PREAGGREGATION EF AG 1.1 AG 1.3 AGGREGATION AG 2.1 SERVICE EDGE AG 3.1 3G PE 1 RNC CORE NETWORK IP/MPLS CSR 1.3 NodeB CSR 1.4 CSR 1.5 AG 1.2 EF AG 1.4 AG 2.2 AG 3.2 PE 2 U-turn L3 VRF VRRP Virtual IP and MAC Address L3 VPN L2 VPN Active PW Backup PW Figure 56: End-to-End Protection for Layer 2 VPN to Layer 3 VPN Termination Scenarios In Figure 56, to ensure that the system maintains a consistent end-to-end traffic forwarding path during a failure of router aG 1.1 or router aG 1.2, we use the following configuration: 1. Hot-standby mode for the backup pseudowire is switched of, as shown in Figure 57. with this mode, the area border router (aBr) follows the status of the active and backup pseudowire according to the status of the logical tunnel interface (up or down), so that only one aBr is announcing vrF routes to connected Csr preixes at any given time. 2. logical tunnel interfaces on both router aG 1.1 and router aG 1.2 are conigured with vrrp groups with the same virtual Ip address. thus both aG 1 routers use the same virtual MaC address to forward traic from and to NodeB. In a steady situation in the access segment, traic from NodeB to router aG 1.1 and router aG 1.2 is forwarded to a destination MaC address that is the same for aG 1.1 and aG 1.2 . therefore, if one of the aG 1 routers goes down, the Csr with pseudowire redundancy conigured, automatically forwards traic to the other aG 1 router. Maintaining the same vrrp MaC address for both aG 1 routers avoids signiicant traic loss from NodeB to the rNC in case of a failure at either of the aG 1 routers. Note that Figure 56 illustrates a failure at router aG 1.1. DD Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Logical Tunnel (lt) Interface with VRRP Virtual IP ACCESS PREAGGREGATION AGGREGATION AG 1.1 AG 3.1 3G MP-EBGP RNC Iub IP NodeB Iub IP CSR 1.n MP-EBGP Iub IP AG 1.2 AG 3.2 L3 VPN L2 VPN Traffic Flow Connection at the Service Level Active PW Backup PW (not in hot standby) Figure 57: Maintaining Traic Path Consistency for Layer 2 VPN Termination to Layer 3 VPN In the access segment, the failure scenarios are worked out by the pseudowire control plane, which in this case installs a backup pseudowire into the FIB only after pe failure detection. In Figure 57, restoration at both ends is consistent between pseudowire redundancy and Mp-eBGp. the blue arrow that extends from NodeB to the rNC represents a consistent flow of traffic. we configured the Csr with a layer 2 vpN pseudowire (red circle and red dashed line); the aG 1 routers with a layer 2 vpN and layer 3 vpN (red circle within a green circle); and the aG 3 routers with only a layer 3 vpN (green circle). when router aG 1.1 goes down, the backup pseudowire comes up. then the logical tunnel interfaces on aG 1.2 come up, and aG 1.2 announces itself as an active node for the layer 3 vpN. In this situation, both Mp-eBGp and the configured backup pseudowire determine that aG 1.1 is down and traffic is forwarded across the layer 3 vpN. end-to-end restoration between router aG 1.2 and the aG 3 routers is based on BGp-lu and Mp-eBGp convergence. It is possible that the Hspa rNC is located closer to NodeB than to the aG 2 routers, which can play the role of the edge service pe to interconnect the MBH network to the rNC. In this case, restoration time for traffic forwarding between the aG 1 routers and the aG 2 routers relies on Mp-IBGp and the IGp protocols. Pseudowire Redundancy for the HSPA Service (H-VPLS) In the access segments, layer 2 vpN to vpls termination (or H-vpls) scenarios use active and backup pseudowires for stitching-point (router aG 1.1 and router aG 1.2) failure protection at the service level. pseudowires are terminated on the label-switched interfaces (lsIs), which in turn are placed into a vpls on both router aG 1.1 and router aG 1.2. the lsI interface does not require any configuration. Instead of configuring the lsI, we configure a mesh group in a routing instance. (see Figure 58.) Copyright © 2013, Juniper Networks, Inc. GJ Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS X L1 Is-Is Area 49.000a ACCESS CSR 1.2 CSR 1.1 AS Y L2 IS-IS Area 49.0001 PREAGGREGATION KK AG 1.1 AG 1.3 AGGREGATION AG 2.1 SERVICE EDGE AG 3.1 3G PE 1 RNC CORE NETWORK IP/MPLS CSR 1.3 NodeB CSR 1.4 CSR 1.5 AG 1.2 KK AG 1.4 AG 2.2 AG 3.2 PE 2 VPLS Hub LSI Interface VPLS L2 VPN Active PW Backup PW Figure 58: End-to-End Protection for HSPA Service Profile (H-VPLS Deployment Scenario) In Figure 58, hot stand-by mode for active and backup pseudowires in conjunction with the regular MaC learning process allows consistent and rapid service restoration in case of failure on the aG 1 routers. the following event sequence shows the restoration process after router aG 1.1 fails: 1. router aG 1.1 goes down. 2. traic lows from NodeB to the rNC undergo the following process: a. the Csr detects that the active pseudowire is down and switches traic forwarding to the presignaled backup pseudowire. b. router aG 1.2 receives a packet from the Csr, learns the NodeB MaC address, puts the MaC address into its MaC learning table, and broadcasts the packet to vpls neighbors as an unknown unicast packet. c. the remote provider edge routers (pe 1 and pe 2) receive the packet from router aG 1.2 and relearn the MaC address of NodeB; then the pe routers map the NodeB MaC address to router aG 1.2 in their MaC learning tables. 3. traic lows from the rNC to NodeB undergo the following process: a. the rNC sends the packet to the NodeB MaC address. b. traic from the rNC goes to one of the remote provider edge routers, such as pe 1. c. router pe 1 forwards traic to router aG 1.2 based on updated records in the MaC learning table. d. router aG 1.2 receives packets, learns the rNC MaC address, puts it into the MaC learning table, and forwards packets to the Csr over the secondary pseudowire. 4. a consistent traic path is installed in both directions. 90 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Network Management You need to consider two tasks when designing Network Management for the mobile backhaul (MBH) network. the first task is to provide transport services for the MBH. the second task is to build a complete set of network management solutions that manage and control the MBH network itself. according to fault, configuration, accounting, performance, and security (FCaps) as defined by the Iso network management model or some pieces of it, the ideal solution is to integrate these two tasks into one management solution. NOQvRSRTU VOWTsport Services for Network Management to separate customer and provider traffic, the various nodes in the network can be connected to the management entity by an out-of-band network, an in-band network using vlaN technology, and an Mpls pseudowire. If the Mpls pseudowire or vlaN approach is not scalable, then vrF-lite-based connectivity can also be used. we recommend that you use a separate management layer 3 vrF routing instance type that scales well and provides separation between the customer and the provider management planes. From the network service point of view, any of these techniques—end-to-end layer 3 vpN, pseudowire termination to layer 3 vpN, and pseudowire termination to vpls—can be used for the management planes and in most cases depends on customer preferences. MBH Network Management System provisioning is a difficult topic to address in the service provider network because each customer has unique challenges and requirements. some service providers use a network management system (NMs) for complete network discovery and provisioning, and others use a hybrid model of control plane and NMs. within the proposed solution, the Junos space NMs can serve as an ideal candidate for the MBH network NMs. the Junos os by itself also provides a comprehensive user command-line interface (ClI) to achieve network management. the biggest advantage that the Junos os brings is that all platforms in the access and aggregation network have a common uniform ClI for static provisioning, which makes maintaining the network straightforward. the Junos space comprehensive fault, configuration, accounting, performance, and security (FCaps) toolkit simplifies network and service deployment and management tasks. the Network activate application provisions vpNs up to 10 times faster than manual configuration. the service Now application reduces mean-time-to-resolution (Mttr) up to 30 times by transmitting the details of the network to a Juniper Networks support site even before the customer calls. route Insight provides remarkable visibility into the network and also allows the simulation of network changes before they are committed. Below is an outline of the Junos space functional role within the MBH solution. • Ip/Mpls transport provisioning (transport activate) • service provisioning (network activate) • Cos provisioning (Cos design) • synchronization design • oaM insight • Monitoring • Fault management • Zero touch deployment • apI to easily integrate into existing NMs or oss/Bss deployments Copyright © 2013, Juniper Networks, Inc. LM Design Guide - Juniper Networks universal and aggregation MBH 1.0 Design Consistency and Scalability Verification Here we provide an example of network scaling analysis and verification on the basis of the sample topology defined in “sizing the MBH Network” and the transport and service layer design described in this guide. If your implementation of the design leads to numbers that exceed the maximum scaling numbers for the platforms used and breaks the consistency of the solution, you probably need to reconsider some parts of the design or try to reposition different platforms in a particular segment of the network. the parameters under consideration include: • Number of preixes in the router rIB and FIB • supported length of the Mpls label stack • Ingress, egress, and transit lsps • BGp and ospF peers • BFD performance Sample MBH Network Topology Figure 59 and table 18 describe the size of the sample network. ACCESS CSR x5 x16 PRE-AGG Planes x16 AGG Planes PREAGGREGATION AGGREGATION nn CORE NETWORK EPC MME HSS AG 1.1 AG 1.2 AG 1x4 AG 1.3 AG 3.1 AG 2.1 AG 2x2 AG 1.4 AG 2.2 AG 3.2 SGW/ PGW PCRF All PRE-AGG/AGG planes belong to IS-IS Level 2 zone or OSPF area 0.0.0.0 ACCESS x4 Access Planes CSR x5 CSR x5 Each access plane is Level 1 IS-IS zone or OSPF area BGP AS 645xx Core Network BGP AS Figure 59: MBH Network Topology 92 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Table 18: Sample Network Segment Size Number of Nodes AG 3 Nodes AG 2 Nodes AG 1 Nodes ANs Nodes per regional network 2 32 1024 10240 per aG 3 router - 32 1024 10240 per aG 2 ring - 2 64 640 per aG 1 ring - - 4 40 Assumptions Before proceeding, we must make some assumptions about the service profiles that are in the topology. 1. all four service proiles—4G lte, Hspa, 3G, and 2G—are conigured in the network, and each cell site router (Csr) connects to at least one radio access network (raN) cell of each service generation. table 19 summarizes this assumption. For example: • X2, s1-u, and s1-MMe connectivity is provided by three separate end-to-end layer 3 vpNs. • eNodeBs are connected to Csrs by Gigabit ethernet. • vlaN tagging is used for service separation on the link. • epC is connected to router aG 3.1 and router aG 3.2. 2. an ethernet-based epC and rNC are connected to provider service edge routers and legacy-based controllers connected to router aG 2.1 and router aG 2.2, leading to 16 diferent BsCs (tDM) and rNCs (atM), respectively. (see table 19.) Table 19: Sample Network Services and Service Locations Service Profile RAN Type Port/VLAN Type of Mobile Network interface Service Deployment Scenario EPC/RNC/ BSC Router Location 4G lte eNodeB ge-0/0/1.1 vlan-id 1 X2 end-to-end layer 3 vpN - eNodeB ge-0/0/1.2 vlan-id 2 s1 user plane end-to-end layer 3 vpN aG 3.1/aG 3.2 eNodeB ge-0/0/1.3 vlan-id 3 s1-MMe end-to-end layer 3 vpN aG 3.1/aG 3.2 Hspa NodeB ge-0/0/2.5 vlan-id 5 Iub over Ip layer 2 vpN to layer 3 vpN termination aG 3.1/aG 3.2 Hspa NodeB ge-0/0/3.0 Iub over ethernet H-vpls aG 3.1/aG 3.2 3G NodeB at-0/0/16 Iub over atM atM pseudowire (pw3) aG 2.1.n/aG 2.2.n n=1…16 2G Bts e1-0/0/1 abis over tDM satop aG 2.1.n/aG 2.2.n n=1…16 - eNodeB ge-0/0/1.4 vlan-id 4 Mobile network management end-to-end layer 3 vpN management aG 3.1/aG 3.2 3. any-to-any layer 3 connectivity between eNodeBs is required: • within the 4G lte service proile for X2 layer 3 vpN only . • Between eNodeBs that belong to any three adjacent aG 2 segments. 4. Ip preix of /30 is used on the interface between eNodeB and the Csr. 5. Is-Is is chosen for interior gateway protocol (IGp) routing. 6. the design of IGp regions and Mpls transport is described in the following topics: • end-to-end Ip/Mpls transport Design • Intradomain lsp signaling • Interdomain lsp signaling with BGp-labeled unicast 7. the coniguration of all aG 1 routers with a u-turn vrF is described in the following topics: • end-to-end layer 3 vpN Design • layer 2 vpN to layer 3 vpN termination scenario Copyright © 2013, Juniper Networks, Inc. 93 Design Guide - Juniper Networks universal and aggregation MBH 1.0 8. the coniguration of all service proiles is described in the following topics: • end-to-end layer 3 vpN Design • layer 2 vpN to layer 3 vpN termination scenario • Hierarchical vpls for Iub over ethernet • Mpls service Design for the 3G service proile • Mpls service Design for the 2G service proile Cell Site Router Scaling Analysis RIB and FIB Scaling In Juniper Networks Solution Portfolio, aCX series routers are situated in the access segment. Being a cost-optimized platform, aCX series routers have less scaling than MX series routers. In addition, the aCX series routers have specific restrictions that you must be take into account and that require attention to scaling. the size of the routing information base (rIB) and the forwarding information base (FIB) is an essential parameter of any routing platform. In this guide, we pay attention to decreasing the amount of routing intelligence needed in Csrs. table 20 summarizes the number of records in the rIB and the FIB for Csrs, and is in line with the design and services presented in this guide. Table 20: Scaling Analysis and Verification for the CSR FIB Node Protocol IP Prefixes RIB FIB Notes Csr IGp (Is-Is) routes Loopback/32 5*4 + 2 rIB*2 = 44 Multiplier four (*4) stands for four IGp access regions. (see the topic “Intradomain lsp signaling” and Figure 59.) Multiplier two (*2) stands for two paths in a ring. Infrastructure/30 7*4 rIB*2 = 28 static routes to aG 1 routers 2 2 1+1+1 rIB*2 = 6 layer 3 vpN X2 1+1+1 rIB*2 = 6 layer 3 vpN s1 user plane Mp-BGp 1+1+1 rIB*2 = 6 layer 3 vpN s1-MMe Mp-BGp 1+1+1 rIB*2 = 6 layer 3 vpN management Directly connected Mp-BGp Mp-BGp VRF prefixes/30, plus lo0.1/32, plus summarized routes from AG 1 routers total routes installed in the FIB 98 MPLS Label FIB (L-FIB) Scaling aCX series routers have platform-specific limitations for the Mpls forwarding plane in relation to the number of Mpls labels that can be programmed into the Mpls l-FIB of the network processor. the following three types of labels are counted: 1. advertised labels to establish the egress lsp (out labels) 2. received labels to establish the ingress lsp (in label bundled with the next hop) 3. service labels for the layer 3 vpN, layer 2 vpN, atM, and tDM pseudowires, and for vpls table 21 contains data for the transport of ingress and egress lsps. table 22 shows the number of service labels on a Csr. Table 21: Cell Site Router Scaling Analysis for the L-FIB Node Protocol LSP L-FIB Out/In Notes Csr rsvp Csr to router aG 1.1 and router aG 1.2 4/4 take into account the primary and secondary paths conigured for each lsp. transit lsps 16/16 BGp-lu N/a lDp-DoD over rsvp Csr to router aG 2.1 and router aG 2.2 1*2/2*2 Transit 0/0 tunnel used by atM and tDM pseudowires. Multiplier two (*2) stands for Csrs dual homed to router aG 1.1 and router aG 1.2. total routes installed in the FIB 94 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Table 22: Cell Site Router Scaling Analysis for Service Labels Node Protocol MPLS VPN Service Labels Out/In Service Profile out/In service proile pseudowires from Csrs to router aG 1.1 and router aG 1.2 2/2 layer 2 vpN to layer 3 vpN for Hspa t-lDp pseudowires from Csrs to router aG 1.1 and router aG 1.2 2/2 layer 2 vpN to vpls for Hspa t-lDp pseudowires from Csrs to router aG 1.1 and router aG 1.2 2/2 atM pseudowire t-lDp pseudowires from Csrs to router aG 1.1 and router aG 1.2 2/2 tDM pseudowire Mp-BGp layer 3 vpN X2 2/2 Mp-BGp layer 3 vpN s1 user plane 2/2 layer 3 vpN s1 user plane Mp-BGp layer 3 vpN s1-MMe 2/2 layer 3 vpN s1-MMe Mp-BGp layer 3 vpN management 2/2 layer 3 vpN management total number of service labels 16/16 another important parameter, with regard to Mpls, is the size of the label stack in the Mpls packet header. For aCX series routers, the maximum number of labels that can be simultaneously popped, pushed, or swapped is 3 labels. this subject is discussed in detail in the topic “Intrasegment transport protection.” CSR Scaling Analysis table 23 summarizes values for the most critical parameters of Csrs that might require attention during the design, planning, and verification phases of the solution. Table 23: Cell Site Router Scaling Analysis Parameter Description Value by Design ACX Series Maximum Value (Junos 12.3) Ipv4 entries per router 98 20,000 • Ipv4 entries 74 20,000 • Ipv4 entries per vrF instance 24 20,000 Network routers per Is-Is area 7 250 Is-Is adjacencies per router 2 250 Network routers per ospF area 7 250 ospF adjacencies per router 2 250 vrF table per router 4 64 BGp adjacencies per router 2 256 lDp adjacencies per router 2 100 rsvp adjacencies per router 2 2,000 total number of transport labels 46 3,000 Maximum depth of the label stack 3 3 total service Mpls labels: 32 1,000 • vrF table per router 8 64 • CesopsN pseudowire (pwe3) 2 496 • atM pseudowire (pwe3) 2 1,000 • ethernet pseudowire (pwe3) 4 1,000 total number of BFD sessions: 30@10 ms 256@100 ms • BFD for IGp 2 @ 10 ms • BFD for rsvp 4 @ 100 ms total number of slaves for an Ieee 1588v2 boundary clock 512 @ 128 mps Copyright © 2013, Juniper Networks, Inc. 512 @ 128 mps 95 Design Guide - Juniper Networks universal and aggregation MBH 1.0 AG 1 Router Scaling Analysis RIB and FIB Scaling the aG 1 routers are the aggregation routers that connect the access segment to the aggregation segment. the MX80-p router is qualified in this position. table 24 summarizes the number of records in the rIB and the FIB for aG 1 routers, and is in line with the design and services presented in this guide. Table 24: AG 1 Router Scaling Analysis for the FIB Node Protocol IP Prefixes RIB FIB Notes aG 1 IGp (Is-Is) routes loopback/32 2 + 64 + 640 = 706 rIB*2 = 1412 Infrastructure/30 16*5 = 80 rIB*2 = 160 static routes to aG 1 routers 5 5 Multiplier two (*2) stands for two paths in a ring. Multiplier ive (*5) stands for ive paths in a ring. Mp-BGp Csr vrF routes/30, plus Csr lo0.1/32, plus local lo0.1/32 3*640+ 3*640+ 3*64 rIB*2 = 8064 layer 3 vpN X2. Multiplier two (*2) stands for BGp multipath. Multiplier three (*3) stands for three neighboring areas for X2 connectivity. MB-BGp Csr vrF routes/30, plus Csr lo0.1/32, plus local lo0.1/32, plus aG 3 vrF routes/24, plus aG 3 lo0.1/32 20+ 20+ 1+ 5+ 2 rIB*2 = 94 layer 3 vpN s1 user plane MB-BGp same as for layer 3 vpN s1 47 rIB*2 = 94 layer 3 vpN s1-MMe 47 rIB*2 = 94 layer 3 vpN Hspa 47 rIB*2 = 94 layer 3 vpN management Total IGP routes installed in the FIB 1577 Total VRF routes 8440 MPLS Label FIB (L-FIB) Scaling aCX series routers have platform-specific limitations for the Mpls forwarding plane in relation to the number of Mpls labels that can be programmed into the Mpls label-forwarding information base (l-FIB) of the network processor. the following three types of labels are counted: 1. advertised labels to establish the egress lsp (out labels). 2. received labels to establish the ingress lsp (in label bundled with the next hop). 3. service labels for the layer 3 vpN, layer 2 vpN, atM, and tDM pseudowires, and for vpls. table 25 contains data for the transport of ingress and egress lsps. table 26 shows the number of service labels on an aG 1 router. Table 25: AG 1 Router Scaling Analysis for the L-FIB Node Protocol LSP L-FIB Out/In Notes aG 1 rsvp aG 1 routers to aG 1 and aG 2 routers 65/65 Full mesh lsp in the Is-Is level 2 region. transit aG 1 routers to aG 1 routers and aG 2 routers (4 - 1)*65/135 aG 1 routers to Csrs 40/40 transit aG 1 routers to Csrs 40/40 announced aG 1 and Csrs loopback addresses 21/0 received loopback addresses from aG 1 routers, aG 2 routers, and aG 3 routers1 0/64*2*2 BGp-lu 96 Hub-and-spoke lsp within the Is-Is level 1 region. the irst multiplier two (*2) is used to provide X2 connectivity to two adjacent aG 2 areas. the second multiplier (*2) stands for dual-homing peering to router aG 2.1 and router aG 2.2. Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Node Protocol lDp-DoD over rsvp LSP L-FIB Out/In Notes received loopbacks from router aG 3.1 and router aG 3.21 0/2*2 used to provide s1-u, s1-MMe, and management layer 3 vpN connectivity. the two multipliers (*2*2) stand for dual-homing peering to router aG 2.1 and router aG 2.2. received loopback addresses from aG 2.1 and aG 2.21 0/2 used to provide atM and tDM pseudowires. aG 1 routers to Csrs 2/20 transit 0 Total transport labels in the L-FIB 303/562 NOTE : the superscript 1 is used to calculate the total number of BGp-lu labeled routes that are distributed in the sample regional network and equals the total number of routers in this network (11298 loopback addresses). However, only labels that are used for forwarding within the Mpls vpN are populated into the l-FIB. table 25 contains figures for only that type of active route. Table 26: AG 1 Router Scaling Analysis for Service Labels Node Protocol MPLS VPN Service Labels Out/In Service Profile aG 1 t-lDp pseudowires from Csrs to router aG 1.1 and router aG 1.2 20/20 layer 2 vpN to layer 3 vpN t-lDp pseudowires from Csrs to router aG 1.1 and router aG 1.2 20/20 layer 2 vpN to vpls t-lDp pseudowires from aG 1 routers to aG 3 routers 2/2 vpls Mp-BGp layer 3 vpN X2 1/2 end-to-end layer 3 vpN Mp-BGp layer 3 vpN s1 user plane 1/2 end-to-end layer 3 vpN Mp-BGp layer 3 vpN s1-MMe 1/2 end-to-end layer 3 vpN Mp-BGp layer 3 vpN Hspa 1/2 layer 2 vpN to layer 3 vpN Mp-BGp layer 3 vpN management 1/2 end-to-end layer 3 vpN Total Service labels 52 AG 1 Router Scaling Analysis table 27 summarizes values for the most critical parameters of the aG 1 routers that might require attention during the design, planning, and verification phases of the solution. Table 27: AG 1 Router Scaling Analysis Parameter Description Value by Design ACX4000 Router Maximum Value (Junos 13.1) MX Series Maximum Value (Junos 12.3) up to 1 M—MX80 up to 2.5 M—MX960, MX480, and MX240 with MpC Ipv4 entries per router (FIB) 10017 20,000 • Ipv4 entries 1577 20,000 20,000 • Ipv4 entries per vrF instance 8440 routers per Is-Is area 66 250 N/a Is-Is adjacencies per router 4 250 300—MX80 500—MX960, MX480, and MX240 routers per ospF area 66 250 N/a ospF adjacencies per router 4 250 up to 2,500 vrF per router 4 64 up to 2,000—MX80 up to 10,000—MX960, MX480, MX240 with re-1800-X4 16-G BGp adjacencies per router 2 256 up to 4,000 lDp adjacencies per router 20 100 up to 1,500 Copyright © 2013, Juniper Networks, Inc. 97 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Parameter Description Value by Design ACX4000 Router Maximum Value (Junos 13.1) MX Series Maximum Value (Junos 12.3) up to 50,000 rsvp adjacencies per router 2 2,000 Number of transport labels 46 3,000 N/a Maximum depth of the label stack 3 or 4 3 4 2,000 up to 50,000 total service Mpls labels 16 1,000 N/a • vrF per router 8 64 Mpls lsp per router • CesopsN pseudowire (pwe3) 2 496 • atM pseudowire (pwe3) 2 1,000 • ethernet pseudowire (pwe3) 4 1,000 total number of BFD sessions • BFD for the IGp 30@10 ms 256@100 ms 4 @ 10 ms • BFD for rsvp 172 @ 100 ms total number of slaves for an Ieee 1588v2 boundary clock 20 @ 128 mps 512 @ 128 mps 20 @ 128 mps Note: the maximum values are not guaranteed and depend on various factors, such as the network configuration and conditions, and should not be taken literally. these values are provided as a comparison to the values required for the sample solution. AG 2 Router Scaling Analysis RIB and FIB Scaling the aG 2 routers are the aggregation routers that aggregate the aG 1 rings (16 rings with four aG 1 routers per ring) and connect the aggregation segment to the core segment. MX240 and MX480 platforms are qualified in this position. table 28 summarizes the number of records in the rIB and the FIB for aG 2 routers, and is in line with the design and services presented in this guide. Table 28: AG 2 Router Scaling Analysis for the FIB Node Protocol IP Prefixes RIB FIB Notes aG 2 IGp (Is-Is) routes loopback/32 2 + 64 + 640 = 706 rIB*2 = 1412 Infrastructure/30 80 rIB*2 = 160 Multiplier two (*2) stands for two paths in a ring Total routes installed in the FIB 1572 MPLS Label FIB Scaling table 29 contains data for the transport of ingress and egress lsps. table 30 shows the number of service labels on the aG 2 routers. Table 29: AG 2 Router Scaling Analysis for the L-FIB 98 Node Protocol aG 2 rsvp label MPLS Labels L-FIB Out/In Notes Full mesh in the Is-Is level 2 region. (64* aG 1, 2*aG 2). advertised/received 65/65 transit 4096/4096 BGp-lu received aG 1 loopback addresses from router aG 3.1 and router aG 1.21 0/64*2*2 the irst multiplier two (*2) is used to provide X2 connectivity to two adjacent aG 2 areas. the second multiplier (*2) stands for dual-homing peering to router aG 3.1 and router aG 3.2. BGp-lu received aG 1 loopback addresses from the aG 1 ring1 0/64*2 used to provide X2 connectivity to two adjacent aG 2 areas. the multiplier (*2) stands for two paths in a ring from the aG 2 routers to the aG 1 routers. Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Node Protocol MPLS Labels L-FIB Out/In Notes BGp-lu advertised loopback addresses to the aG 1 ring1 64 + 1/0 used to provide X2 connectivity to two adjacent aG 2 areas. BGp-lu advertised loopback addresses to the aG 31 routers 64 + 1/0 used to provide X2 connectivity BGp-lu received aG 3 loopback address from router aG 3.1 and router aG 3.31 2/0 used to provide s1-u, s1-MMe, and management layer 3 vpN connectivity. BGp-lu received Csr loopback addresses from the aG 1 ring1 2*640 = 1280/0 used to provide atM and tDM pseudowires. Total transport labels in the L-FIB 5573/4545 Note: the superscript 1 is used to calculate the total number of BGp-lu labeled routes that are distributed in the example regional network and equals the total number of loopback addresses in this network (11298 loopback addresses). However, only labels for the used routes are populated into the l-FIB. table 29 contains figures for only used routes. However, only labels that are used for forwarding within the Mpls vpN are populated into the l-FIB. table 29 contains figures for only that type of active route. Table 30: AG 2 Router Scaling Analysis for Service Labels Node Protocol MPLS VPN Service Labels Out/In Service Profiles aG 2 t-lDp pseudowires from Csrs to router aG 2.1 and routeraG 2.2 640/640 atM pseudowire—pw3 t-lDp pseudowires from Csrs to router aG 2.1 and router aG 2.2 640/640 satop Total service labels 1280/1280 AG 3 Router Scaling Analysis RIB and FIB Scaling IGp protocols deployed on router aG 3.1 and router aG 3.2 are part of the service provider core network, a reasonable number of loopback/32 and infrastructure/30 routes must be added to the results in the table below. table 31 summarizes the number of records in the rIB and the FIB for aG 3 routers, and is in line with the design and services presented in this guide. Table 31: AG 3 Router Scaling Analysis for the FIB Node Protocol IP Prefixes RIB FIB Notes aG 3 Mp-BGp Csr vrF routes /24, plus Csr lo0.1/32, plus the aG 1 routers lo0.1/32, and the router aG 3.1 and router aG 3./2 lo0.1/32 4*10240+ 4*10240+ 4*640+ 4*2 rIB*2 = 21762 Multiplier four (4*) stands for the number of layer 3 vpNs Multiplier two (*2) stands for BGp multipath loopback/32 2 10 Infrastructure/30 8 IGp Total IGP routes installed in the FIB 10+ Total VRF routes 21762 Copyright © 2013, Juniper Networks, Inc. 99 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Z[\] \abel FIB Scaling table 32 contains data for the transport of ingress and egress lsps. table 33 shows the number of service labels on the aG 3 routers. Table 32: AG 3 Router Scaling Analysis for the L-FIB Node Protocol MPLS Labels L-FIB Out/In Notes aG 3 BGp-lu receives and advertises the loopback addresses of the aG 1 routers to the aG 2 router peers. 2*1024/2*1024 used to provide X2 connectivity advertised own loopback 1/0 Total transport labels in the L-FIB Multiplier two (2*) stands for BGp multipath 2049/2048 Note: the superscript 1 is used to calculate the total number of BGp-lu labeled routes that are distributed in the example regional network and equals the total number of routers in this network (11298 loopback addresses). However, only labels for the used routes are populated into the l-FIB. table 32 contains figures for only those routes. However, only labels that are used for forwarding within the Mpls vpN are populated into the l-FIB. table 32 contains figures for only that type of active route. Table 33: AG 3 Router Scaling Analysis for Service Labels Node Protocol MPLS Labels Service Labels Out/In Notes aG 3 t-lDp pseudowires from the aG 1 routers to router aG 3.1 and router aG 3.2 1024/1024 H-vpls Mp-BGp advertised and received 4/4096 4/4096 4/4096 4/4096 layer 3 vpN s1 user plane layer 3 vpN s1-MMe layer 3 vpN Hspa layer 3 vpN management Total service labels XYY 1040/16384 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Part 3: Implementation this part of the guide describes how to configure a mobile backhaul (MBH) network based on the various scenarios presented in part 2 and focused on Juniper Networks hardware and software platforms as the building blocks. the part contains the following overview topics and sample configurations: • recommendations for IGp region Numbering and Network addressing • Network topology overview • Coniguring Ip and Mpls transport • Coniguring end-to-end layer 3 vpN services • Coniguring layer 2 vpN to layer 3 vpN termination services • Coniguring a layer 2 vpN to vpls termination service • Coniguring atM pseudowire and satop/CesopsN services • Coniguring timing and synchronization • Coniguring Class of service all the sample configurations use a ring topology and Is-Is as the interior gateway protocol (IGp). the configurations were tested as part of a complex solution with all the necessary protocols configured simultaneously within the sample network topology and verified against different failure scenarios. Copyright © 2013, Juniper Networks, Inc. ^_^ Design Guide - Juniper Networks universal and aggregation MBH 1.0 Recommendations for IGP Region Numbering and Network Addressing these IGp region numbering and network addressing recommendations can easily be adapted to most larger scale deployments. the recommendations are for network addressing, interior gateway protocol (IGp) regions, and BGp autonomous system (as) numbering, and are covered in the following topics: • loopback and Infrastructure Ip addressing • uNI addressing and layer 3 vpN Identiier • Management (fxp0) Interface addressing to illustrate the basic principles of designing IGp numbering and network addressing, see the topic “sizing the MBH Network” for an example of a large-scale network. (see Figure 60.) ACCESS CSR x5 x16 PRE-AGG Planes x16 AGG Planes PREAGGREGATION AGGREGATION nn CORE NETWORK EPC MME HSS AG 1.1 AG 1.2 AG 1x4 AG 1.3 AG 2.1 AG 3.1 AG 2x2 AG 1.4 AG 2.2 AG 3.2 SGW/ PGW PCRF PRE-AGG/AGG planes belong to IS-IS Level 2 zone or OSPF area 0.0.0.0 ACCESS x4 Access Planes CSR x5 CSR x5 Each access plane is Level 1 IS-IS zone or OSPF area BGP AS 645xx Core Network BGP AS Figure 60: Regional Large-Scale MBH Network In Figure 60, we have 16 independent aggregation (aG G) planes defined by 16 pairs of aG 2.1 and aG 2.2 routers. the access, preaggregation, and aggregation segments correspond to one aggregation (aG G) plane and belong to one BGp as 645xx, while the core segment belongs to a different core network as. You can select the as number from the private range of as numbers that extend from 64512 through 65535. we recommend that you reserve a small subrange of 10-20 as numbers per regional network. `bf Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 to optimize the IGp routing process, you must implement the correct Ipv4 addressing schema. there are at least four different types of interfaces and corresponding Ipv4 addressing schemas: • Infrastructure interface addressing—used on router interfaces to provide network-level connectivity between directly connected routers and to establish IGp adjacencies. • loopback interface addressing—used for loopback interfaces. loopback addresses have a /32 bit preix length and are used to establish BGp adjacencies between any two routers and to act as a reference for the endpoint of an Mpls labeled-switched path (lsp). • uNI addressing—used to set up network level connectivity between mobile network elements (eNodeBs, NodeBs, rNC, sGw/pwG, MMe, and so on). • Management (fxp0) interface addressing—used for the management interface (fxp0) on each routing engine (re) of a Juniper Networks router. these addresses are used for out-of-band router management access. lmmpquvw uxy zx{|ustructure IP Addressing according to the topology in Figure 60, each aG G plane with its lower regions at the access and preaggregation segments is a separate closed IGp region. In this region, all aG x routers are placed into one backbone area (for ospF area 0.0.0.0 and for Is-Is level 2), and each of the access planes with five Csrs (Csr) combines a separate IGp region. table 34 lists the possible schemas of network addressing for one of sixteen closed IGp region for infrastructure and loopback interfaces, including our proposal for IGp region numbering. we use a private network address for the Ip class a network 10.0.0.0 for both schemas. Table 34: IPv4 Addressing and IGP Region Numbering Schemas BGP AS IGP Region Number nn* IPv4 Subnetworks Reserved for Interfaces in Each Area IGP Region IS-IS Level and Area OSPF Area Loopback Infrastructure level 2 nn.0000 0.0.0.0 10.nn.1.0/25 10.1nn.0.0/24 level 1 nn.0001 0.0.nn.1 level1 nn.0002 0.0.nn.2 10.nn.10.0/26 interface preix: /32 10.1nn.1.0/24 interface preix: /30 level1 nn.0003 0.0.nn.3 level1 nn.0004 0.0.nn.4 level1 nn.0005 0.0.nn.5 level1 nn.0006 0.0.nn.6 level1 nn.0007 0.0.nn.7 10.nn.10.64/26 interface preix: /32 10.1nn.2.0/24 interface preix: /30 level1 nn.0008 0.0.nn.8 … … level1 nn.0125 0.0.nn.125 level1 nn.0126 0.0.nn.126 level1 nn.0127 0.0.nn.127 10.nn.18.192/26 interface preix: /32 10.1nn.32.0/24 interface preix: /30 level1 nn.0128 0.0.nn.128 *nn - corresponds to aG G-plane number from 1 to 16. loopback interfaces should also be assigned an Is-Is address. we recommend synchronizing the Ipv4 protocol family (inet) and the Iso (iso) family addressing used by Ip and Is-Is protocols, respectively, with the following format: Loopback Interface IPv4 Address: Loopback Interface ISO Address: 0 1 0.0 n n .0 1 0.0 65 n n .0 0 0 5 .0 1 0 0. n n 0 1 .0 0 65 .0 0 IS-IS Area Number Figure 61: Format for IS-IS Area Number Addressing Copyright © 2013, Juniper Networks, Inc. hjk Design Guide - Juniper Networks universal and aggregation MBH 1.0 the first part of the loopback iso family address is the Is-Is area number, which is a variable number from 1 to 13 bytes. the first byte of the area number—nn—is the authority and format indicator (aFI). the next bytes are the assigned area identifiers and can be from 0 to 12 bytes. In the example, 0005 is the area identifier. the next 6 bytes are the system identifier and can be any 6 bytes unique throughout the entire domain. For the system identifier we use an Ipv4 address expressed in binary-coded decimal (BCD) format, as shown in the example above. table 34 represents a recommended approach for network address planning. In an actual deployment, the proposed numbering and addressing might overlap with already existing addressing schemas, or the network topology might be different in scale. so you need to correct the topology accordingly. UNI Addressing and Layer 3 VPN Identifier the Ipv4 addressing schema for user-to-network interfaces (uNIs) uses addressing principles defined by the mobile network infrastructure and depends on the type of mobile service generation—Hspa and 4G lte. this addressing belongs to the service layer 3 vpN and does not affect the transport capabilities of the MBH network. You can use any addressing schema that does not contradict the general Ipv4 routing framework for dedicated layer 3 vpNs. uNI addressing allows overlapping of Ip subnetworks that belong to different layer 3 vpNs. to distinguish between vpNs and uNI subnetworks that belong to a particular vpN, you implement two types of identifiers: • route distinguisher—a unique vrF identiier • route target—a layer 3 vpN identiier any Ip address assigned to a uNI within an MBH network as <uNI-Ip-aDDress:rD> (rD = route distinguisher) has local significance within each service router—Csr 1.1 through Csr 1.5, aG 1.1, aG 1.2, aG 3.1, and aG 3.2. a route target helps uniquely and globally map routes to a layer 3 vpN. we propose the schema shown in table 35 for route distinguisher and route target numbering. Table 35: Layer 3 VPN Attribute Numbering Identifier Assignment 1 route distinguisher <lo0.0-Ip-aDDress>:<l3 servICe ID> route target <as number>:<l3 servICe ID> Alternate Assignment <as number>:<INDeX Group> In the alternate assignment column on the right, <INDeX-Group> represents direct X2 interface connectivity over the MBH network between eNodeBs for the X2 layer 3 vpN, where a special identifier used in the lte radio access Network (raN) to the eNodeB group requires direct X2 interface connectivity. (see the topic “Mpls services Design for the 4G lte profile.”) Management (fxp0) Interface Addressing the management (fxp0) interface is an out-of-band interface that is configured to connect to the router through the management port on the front of the router. where network planners do not have their own regulations for the management of Ip addressing of the management port, we recommend that, for each MBH node, you reserve a dedicated Ipv4 subnet with a /29 bit prefix length for the management (fxp0) interface. this addressing scheme is regarded as best practice because, in general, any node that has two routing engines will require three Ip addresses for the management (fxp0) interface. 104 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Network Topology Overview this topic includes the following topics: • requirements • Network topology • Hardware Inventory output Requirements this example uses the following hardware and software components: • Junos os release 12.3 or later • Five aCX series universal access routers • eight MX series universal edge routers Table 36: Hardware Components for the Network Topology Position in the topology Router Description Csr 1.1 aCX1000 8xGbe copper and 4xGbe combination (copper or sFp); optics sold separately Csr 1.2 aCX2000 16xt1/e1, 2x10Gbe sFp+, 8xGbe copper with poe++ on two ports, 2xGbe sFp; optics sold separately Csr 1.3 aCX2000 16xt1/e1, 2x10Gbe sFp+, 8xGbe copper with poe++ on two ports, 2xGbe sFp; optics sold separately Csr 1.4 aCX1000 8xt1/e1, 8xGbe copper, 4xGbe combination (copper or sFp); optics sold separately Csr 1.5 aCX1000 8xt1/e1, 8xGbe copper, 4xGbe combination (copper or sFp); optics sold separately aG 1.1 MX80-p 2 MICs and four ixed 10Gbe interfaces (no DpC/MpC slots), ptp (Ieee 1588v2) support aG 1.2 MX80-p 2 MICs and four ixed 10Gbe interfaces (no DpC/MpC slots), ptp (Ieee 1588v2) support aG 1.3 MX80-p 2 MICs and four ixed 10Gbe interfaces (no DpC/MpC slots), ptp (Ieee 1588v2) support aG 1.4 MX80-p 2 MICs and four ixed 10Gbe interfaces (no DpC/MpC slots), ptp (Ieee 1588v2) support aG 2.1 MX80 2 MICs and four ixed 10Gbe interfaces (no DpC/MpC slots) aG 2.2 MX80 2 MICs and four ixed 10Gbe interfaces (no DpC/MpC slots) aG 3.1 MX240 MpC3 with support for 100Gbe, 40Gbe, and 10Gbe interfaces, l2.5 features; optics sold separately; 40x1Gbe enhanced queuing DpC for MX series with l2/l3 features and vlaN-HQos aG 3.2 MX240 2xtrio Chipset MpC, port queuing; includes full-scale l2/l2.5 and reduced-scale l3 features; 40x1Gbe l2/l3 capable Copyright © 2013, Juniper Networks, Inc. 105 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Network Topology Figure 62 shows the physical topology and network connections used to verify all deployment scenarios in this guide. the sample network topology includes all the architectural elements defined in parts 1 and 2, such as the network infrastructure, network layering, and network sizing. see the topics “MBH Network Infrastructure”, “MBH Network layering,” and “sizing the MBH Network.” PREAGGREGATION ACCESS AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/1/0 at-0/0/16 ds-0/0/0:1 el-0/0/1 el-0/0/10 ge-0/1/0 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/1 10.21.0.2/24 ge-0/2/0 10.21.2.1/24 ge-1/0/2 10.21.2.2/24 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 ds-0/0/3:1 el-0/0/1 el-0/0/10 ge-0/1/0 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.2.2/24 ds-1/2/5:1 el-1/2/10 el-1/2/6 ge-0/2/0 10.21.0.1/24 ge-0/2/0 10.21.6.1/24 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0.1 10.21.3.1/24 xe-0/0/0.2 10.22.0.1/24 xe-0/0/0.1 10.21.3.2/24 xe-0/0/0.2 10.22.0.2/24 ge-1/0/2 10.21.4.1/24 CSR 1.4 CSR 1.5 Io0:1.1.7.1/32 Io0:1.1.6.1/32 RNC/ BSC xe-0/0/3 10.23.1.1/24 xe-1/1/3 10.23.2.2/24 xe-1/0/0 10.23.4.1/24 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.2/24 xe-0/0/1 10.22.3.2/24 xe-0/0/2 10.22.5.1/24 Io0:1.1.5.1/32 ge-2/0/0 xe-0/0/1 10.22.3.1/24 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.2/24 AG 1.2 xe-1/0/2 10.23.3.2/24 at-1/2/0 ds-1/2/0:1 el-1/2/10 el-1/2/1 ge-0/2/1 10.21.4.2/24 xe-0/0/2 10.23.3.1/24 AG 1.4 xe-0/0/0 10.22.4.1/24 Io0:1.1.9.1/32 EPC ge-2/0/0 xe-0/0/2 10.23.5.1/24 AG 2.2 xe-1/1/3 10.23.5.2/24 Io0:1.1.11.1/32 AG 3.2 Io0:1.1.14.1/32 Figure 62: Sample MBH Network the overall goal of this network is to provide transport services for all mobile network generations (4G lte, 3G, Hspa, and 2G) with subsecond service restoration. In this example, the router being configured is identified by the following command prompts: • CSR 1.x identiies cell site routers 1 through to 5 • AG 1.x identiies preaggregation routers 1 through 4 • AG 2.x identiies the aggregation routers • AG 3.x identiies the provider edge routers In the sample network, there are three segments—access, aggregation (preaggregation and aggregation), and core: • the access segment consists of ive aCX series routers (Csr 1.1 through Csr 1.5) connected with Gigabit ethernet optical links in a ring topology to two routers (aG 1.1 and aG 1.2) in the preaggregation segment. - router Csr 1.2, router Csr 1.3, and router Csr 1.4 use one Gigabit ethernet interface (ge-0/1/0) to connect with emulated radio access Network (raN) elements, such as the 4G lte eNodeB and Hspa NodeB. - router Csr 1.3 uses a virtual atM interface (at-0/0/16) to emulate connection to the 3G NodeB. - router Csr 1.3 and router Csr 1.4 use virtual tDM interfaces—ds-0/0/0:1, e1-0/0/1, e1-0/0/10 (Csr 1.3), and ds0/0/3:1, e1-0/0/1, e1-0/0/10 (Csr 1.4)—to emulate connection to a 2-G base transceiver station (Bts). • the preaggregation segment consists of four MX series routers (aG 1.1 through aG 1.4) connected with 10-Gb ethernet optical links in a ring topology to two routers (aG 2.1 and aG 2.2) in the aggregation segment. - router aG 1.1 and router aG 1.2 use virtual tDM interfaces—ds-1/2/5:1, e1-1/2/10, e1-1/2/6 (aG 1.1), and ds-1/2/0:1, e11/2/1, e1-1/2/10 (aG 1.2)—to emulate connection to the 2-G base station controller (BsC). • the aggregation segment consists of two MX series routers (aG 2.1 and aG 2.2) connected with 10-Gb ethernet optical links in a full mesh topology with two routers (aG 3.1 and aG 3.2) of the core segment. - router aG 2.1 uses an atM interface (at-1/2/0) to emulate connection to the 3G radio network controller (rNC). • the core segment consists of two MX series routers (aG 3.1 and aG 3.2). - router aG 3.1 and router aG 3.2 use a Gigabit ethernet interface (ge-2/0/0) to emulate connection to the 4G lte evolved packet core (epC). 106 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 table 37 includes the sample MBH network Ip-addressing schema. Table 37: Sample MBH Network IP-Addressing Schema Segment Loopback Interface (lo0.0) Infrastructure Interfaces access 1.1.a.b/32 10.21.x.y/24 preaggregation and aggregation 1.1.a.b/32 10.22.x.y/24 Core 1.1.a.b/32 10.23.x.y/24 Hardware Inventory Output the following output is for each router in the sample network using the show chassis hardware command. the show chassis hardware command displays information about the hardware installed on the router, including a list of all Flexible pIC Concentrators (FpCs) and pICs, and including the version level and serial number. CSR Ring Routers the following output from the show chassis hardware command is for the five Csrs in the access ring: user@csr1.1> show chassis Hardware inventory: Item Version Chassis Midplane REV 00 Routing Engine FEB 0 Processor FPC 0 MIC 0 PIC 0 MIC 1 PIC 1 MIC 2 PIC 2 Xcvr 0 REV 01 Xcvr 1 REV 01 Xcvr 2 REV 01 Xcvr 3 REV 01 user@csr1.2> show chassis Hardware inventory: Item Version Chassis Midplane REV 09 Routing Engine FEB 0 Processor FPC 0 MIC 0 PIC 0 MIC 1 PIC 1 MIC 2 PIC 2 Xcvr 0 REV 01 Xcvr 1 REV 01 Copyright © 2013, Juniper Networks, Inc. hardware Part number Serial number 650-037056 BUILTIN BUILTIN HT0211471669 BUILTIN BUILTIN Description ACX1000 ACX1000 Routing Engine Forwarding Engine BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN 740-011782 740-031851 740-011782 740-031851 BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN P9C2AB8 PMF2XUK P9C29KY PN343ZP FPC BUILTIN 8x CHE1T1, RJ48 8x CHE1T1, RJ48 8x 1GE(LAN) RJ45 8x 1GE(LAN) RJ45 4x 1GE(LAN) SFP, RJ45 4x 1GE(LAN) SFP, RJ45 SFP-SX SFP-SX SFP-SX SFP-SX 650-037055 BUILTIN BUILTIN Serial number HS0212110006 HS0212110006 BUILTIN BUILTIN Description ACX2000 ACX2000 Routing Engine Forwarding Engine BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN 740-011782 740-011782 BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN PCL3U1N PCL3U9J FPC BUILTIN 16x CHE1T1, 16x CHE1T1, 8x 1GE(LAN) 8x 1GE(LAN) 2x 1GE(LAN) 2x 1GE(LAN) SFP-SX SFP-SX hardware Part number RJ48 RJ48 RJ45 RJ45 SFP SFP 107 Design Guide - Juniper Networks universal and aggregation MBH 1.0 MIC 3 PIC 3 Xcvr 0 Xcvr 1 REV 01 REV 01 user@csr1.3> show chassis Hardware inventory: Item Version Chassis Midplane REV 00 Routing Engine FEB 0 Processor FPC 0 MIC 0 PIC 0 MIC 1 PIC 1 MIC 2 PIC 2 Xcvr 0 REV 02 Xcvr 1 REV 02 MIC 3 PIC 3 Xcvr 1 REV 01 user@csr1.4> show chassis Hardware inventory: Item Version Chassis Midplane REV 09 Routing Engine FEB 0 Processor FPC 0 MIC 0 PIC 0 MIC 1 PIC 1 MIC 2 PIC 2 Xcvr 0 REV 01 Xcvr 1 REV 01 Xcvr 2 REV 01 Xcvr 3 REV 01 user@csr1.5> show chassis Hardware inventory: Item Version Chassis Midplane REV 09 Routing Engine FEB 0 Processor FPC 0 MIC 0 PIC 0 }~ BUILTIN BUILTIN 740-031851 740-031851 BUILTIN BUILTIN PM30KX2 PMF26VG 2x 10GE(LAN) SFP+ 2x 10GE(LAN) SFP+ SFP-SX SFP-SX Part number Serial number 650-037055 BUILTIN BUILTIN HS0211455197 BUILTIN BUILTIN Description ACX2000 ACX2000 Routing Engine Forwarding Engine BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN 740-011613 740-011613 BUILTIN BUILTIN 740-011613 BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN PJH4SVC PH10QAE BUILTIN BUILTIN PD82CZJ FPC BUILTIN 16x CHE1T1, RJ48 16x CHE1T1, RJ48 8x 1GE(LAN) RJ45 8x 1GE(LAN) RJ45 2x 1GE(LAN) SFP 2x 1GE(LAN) SFP SFP-SX SFP-SX 2x 10GE(LAN) SFP+ 2x 10GE(LAN) SFP+ SFP-SX 650-037056 BUILTIN BUILTIN Serial number HT0212110019 HT0212110019 BUILTIN BUILTIN Description ACX1000 ACX1000 Routing Engine Forwarding Engine BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN 740-031851 740-031851 740-011613 740-031851 BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN PMF15ME PMF2Y0U PDG0UTQ PM30D61 FPC BUILTIN 8x CHE1T1, RJ48 8x CHE1T1, RJ48 8x 1GE(LAN) RJ45 8x 1GE(LAN) RJ45 4x 1GE(LAN) SFP, RJ45 4x 1GE(LAN) SFP, RJ45 SFP-SX SFP-SX SFP-SX SFP-SX 650-037056 BUILTIN BUILTIN Serial number HT0212110014 HT0212110014 BUILTIN BUILTIN Description ACX1000 ACX1000 Routing Engine Forwarding Engine BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN FPC BUILTIN 8x CHE1T1, RJ48 8x CHE1T1, RJ48 hardware hardware Part number hardware Part number Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 MIC 1 PIC 1 MIC 2 PIC 2 Xcvr Xcvr Xcvr Xcvr 0 1 2 3 REV REV REV REV 02 01 01 01 BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN BUILTIN 740-011613 PHS1LLE 740-031851 PLG071F 740-011782 PCL3U65 740-031851 PMF15WS 8x 1GE(LAN) RJ45 8x 1GE(LAN) RJ45 4x 1GE(LAN) SFP, RJ45 4x 1GE(LAN) SFP, RJ45 SFP-SX SFP-SX SFP-SX SFP-SX Preaggregation Routers the following output from the show chassis hardware command is for the four routers in the preaggregation ring: user@ag1.1> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 01 711-044315 PEM 0 Rev 04 740-028288 Routing Engine BUILTIN TFEB 0 BUILTIN Processor QXM 0 REV 06 711-028408 FPC 0 BUILTIN MIC 0 BUILTIN PIC 0 BUILTIN Xcvr 0 REV 03 740-014289 Xcvr 2 REV 03 740-014289 Xcvr 3 REV 03 740-014289 FPC 1 BUILTIN MIC 0 REV 26 750-028392 PIC 0 BUILTIN Xcvr 1 REV 01 740-031851 Xcvr 2 REV 01 740-031851 Xcvr 7 REV 01 740-031851 Xcvr 9 REV 01 740-031851 PIC 1 BUILTIN Xcvr 0 REV 01 740-011614 Xcvr 1 REV 01 740-031850 Xcvr 2 REV 01 740-031851 Xcvr 7 REV 01 740-031851 Xcvr 8 REV 01 740-031851 MIC 1 REV 02 750-047733 PIC 2 BUILTIN Fan Tray user@ag1.2> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 01 711-044315 PEM 0 Rev 04 740-028288 Routing Engine BUILTIN TFEB 0 BUILTIN Processor QXM 0 REV 06 711-028408 Copyright © 2013, Juniper Networks, Inc. Serial number G0861 CAAN0073 VL11397 BUILTIN BUILTIN ZW8261 BUILTIN BUILTIN BUILTIN 1ZT805000128 T10C90685 CB24BQ05Y BUILTIN ZX2146 BUILTIN PND6YP9 PMF2Z61 PLG32AG PM75T03 BUILTIN PFA2NRK 0YT459605723 PND6YT7 PM753AD PM30FKH CAAN7015 BUILTIN Description MX80-P MX80-P AC Power Entry Module Routing Engine Forwarding Engine MPC QXM MPC BUILTIN 4x 10GE XFP 4x 10GE XFP XFP-10G-SR XFP-10G-SR XFP-10G-SR MPC BUILTIN 3D 20x 1GE(LAN) SFP 10x 1GE(LAN) SFP SFP-SX SFP-SX SFP-SX SFP-SX 10x 1GE(LAN) SFP SFP-LX10 SFP-LX10 SFP-SX SFP-SX SFP-SX 16x CHE1T1, RJ48 16x CHE1T1, RJ48 Fan Tray Serial number G0872 CAAN2503 VL12102 BUILTIN BUILTIN Description MX80-P MX80-P AC Power Entry Module Routing Engine Forwarding Engine ZX8495 MPC QXM €09 Design Guide - Juniper Networks universal and aggregation MBH 1.0 FPC 0 MIC 0 PIC 0 Xcvr Xcvr FPC 1 MIC 0 PIC 0 Xcvr Xcvr Xcvr Xcvr Xcvr PIC 1 Xcvr Xcvr Xcvr MIC 1 PIC 2 Fan Tray 0 2 REV 03 REV 01 REV 26 0 1 2 5 7 REV REV REV REV REV 01 01 01 02 01 2 7 8 REV REV REV REV 01 02 01 02 BUILTIN BUILTIN BUILTIN 740-014289 740-014289 BUILTIN 750-028392 BUILTIN 740-031851 740-031851 740-031851 740-011613 740-031851 BUILTIN 740-031851 740-011613 740-031851 750-047733 BUILTIN user@ag1.3> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 01 711-044315 PEM 0 Rev 03 740-029712 Routing Engine BUILTIN TFEB 0 BUILTIN Processor QXM 0 REV 06 711-028408 FPC 0 BUILTIN MIC 0 BUILTIN PIC 0 BUILTIN Xcvr 0 REV 01 740-031833 Xcvr 1 NON-JNPR Xcvr 2 NON-JNPR Xcvr 3 REV 03 740-014289 FPC 1 BUILTIN Fan Tray user@ag1.4> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 01 711-044315 PEM 0 Rev 03 740-029712 Routing Engine BUILTIN TFEB 0 BUILTIN Processor QXM 0 REV 06 711-028408 FPC 0 BUILTIN MIC 0 BUILTIN PIC 0 BUILTIN Xcvr 0 REV 03 740-014289 Xcvr 1 REV 03 740-014289 Xcvr 2 NON-JNPR Xcvr 3 NON-JNPR ‚ BUILTIN BUILTIN BUILTIN T10C90668 T08J10393 BUILTIN CAAA4398 BUILTIN PND6YSW PND6VDT PLG09F0 PH20NKJ PM30FHN BUILTIN PMF2Y3C PFP3EMK PM1260B CAAN7018 BUILTIN MPC BUILTIN 4x 10GE XFP 4x 10GE XFP XFP-10G-SR XFP-10G-SR MPC BUILTIN 3D 20x 1GE(LAN) SFP 10x 1GE(LAN) SFP SFP-SX SFP-SX SFP-SX SFP-SX SFP-SX 10x 1GE(LAN) SFP SFP-SX SFP-SX SFP-SX 16x CHE1T1, RJ48 16x CHE1T1, RJ48 Fan Tray Serial number G0893 CAAN2294 VKA4502 BUILTIN BUILTIN Description MX80-P MX80-P DC Power Entry Module Routing Engine Forwarding Engine ZX8413 BUILTIN BUILTIN BUILTIN 0ZT670101018 T09L25737 T09L25529 CC27BQ0BW BUILTIN MPC QXM MPC BUILTIN 4x 10GE XFP 4x 10GE XFP XFP-10G-LR XFP-10G-SR XFP-10G-SR XFP-10G-SR MPC BUILTIN Fan Tray Serial number G0756 CAAN2498 VKA4310 BUILTIN BUILTIN Description MX80-P MX80-P DC Power Entry Module Routing Engine Forwarding Engine ZY0293 BUILTIN BUILTIN BUILTIN CB24BQ057 1ZT805000116 CB39BK06V CB47BK0BU MPC QXM MPC BUILTIN 4x 10GE XFP 4x 10GE XFP XFP-10G-SR XFP-10G-SR XFP-10G-SR XFP-10G-SR Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 FPC 1 MIC 0 PIC 0 Xcvr 0 PIC 1 Xcvr 0 Fan Tray REV 24 REV 02 REV 01 BUILTIN 750-028392 BUILTIN 740-011613 BUILTIN 740-031851 BUILTIN ZC6179 BUILTIN PH261Y7 BUILTIN PMA3J4Y MPC BUILTIN 3D 20x 1GE(LAN) SFP 10x 1GE(LAN) SFP SFP-SX 10x 1GE(LAN) SFP SFP-SX Fan Tray Aggregation Routers the following output from the show chassis hardware command is for the two aggregation routers: user@ag2.1> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 09 711-031594 PEM 0 Rev 03 740-029712 Routing Engine BUILTIN TFEB 0 BUILTIN Processor QXM 0 REV 06 711-028408 FPC 0 BUILTIN MIC 0 BUILTIN PIC 0 BUILTIN Xcvr 0 NON-JNPR Xcvr 1 REV 01 740-014289 Xcvr 2 NON-JNPR Xcvr 3 NON-JNPR FPC 1 BUILTIN MIC 0 REV 26 750-028392 PIC 0 BUILTIN Xcvr 0 REV 01 740-031851 Xcvr 1 REV 01 740-031851 Xcvr 2 REV 01 740-011783 Xcvr 4 REV 01 740-031851 PIC 1 BUILTIN Xcvr 0 REV 01 740-011613 Xcvr 1 REV 01 740-031851 MIC 1 REV 02 750-047733 PIC 2 BUILTIN Fan Tray user@ag2.2> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 09 711-031594 PEM 0 Rev 03 740-029712 Routing Engine BUILTIN TFEB 0 BUILTIN Processor QXM 0 REV 06 711-028408 FPC 0 BUILTIN MIC 0 BUILTIN PIC 0 BUILTIN Copyright © 2013, Juniper Networks, Inc. Serial number F0402 CAAB2290 VJA4171 BUILTIN BUILTIN ZW8237 BUILTIN BUILTIN BUILTIN AA0823N1YK2 AD0953M00L0 CB39BK01D CB47BK08G BUILTIN CAAA4668 BUILTIN PLG0936 PLG3357 PAJ22NL PND6YT1 BUILTIN PFN20PW PM20BBQ CAAN7028 BUILTIN Description MX80 MX80 DC Power Entry Module Routing Engine Forwarding Engine MPC QXM MPC BUILTIN 4x 10GE XFP 4x 10GE XFP XFP-10G-LR XFP-10G-SR XFP-10G-SR XFP-10G-SR MPC BUILTIN 3D 20x 1GE(LAN) SFP 10x 1GE(LAN) SFP SFP-SX SFP-SX SFP-LX10 SFP-SX 10x 1GE(LAN) SFP SFP-SX SFP-SX 16x CHE1T1, RJ48 16x CHE1T1, RJ48 Fan Tray Serial number F0401 CAAB2292 VKA4399 BUILTIN BUILTIN Description MX80 MX80 DC Power Entry Module Routing Engine Forwarding Engine ZY0573 BUILTIN BUILTIN BUILTIN MPC QXM MPC BUILTIN 4x 10GE XFP 4x 10GE XFP ƒƒƒ Design Guide - Juniper Networks universal and aggregation MBH 1.0 Xcvr Xcvr Xcvr Xcvr 0 1 2 3 FPC 1 MIC 0 PIC 0 Xcvr 0 Xcvr 1 PIC 1 Fan Tray REV REV REV REV 03 01 01 03 REV 24 REV 01 REV 01 740-014289 740-014289 740-014279 740-014289 BUILTIN 750-028392 BUILTIN 740-031851 740-031851 BUILTIN CB03BQ0C1 C803XU01Q 7Z3019B00634 1ZT805000174 BUILTIN YZ0947 BUILTIN PM30KZ0 PKS51E2 BUILTIN XFP-10G-SR XFP-10G-SR XFP-10G-LR XFP-10G-SR MPC BUILTIN 3D 20x 1GE(LAN) SFP 10x 1GE(LAN) SFP SFP-SX SFP-SX 10x 1GE(LAN) SFP Fan Tray Provider Edge Routers the following output from the show chassis hardware command is for the two provider service edge routers: user@ag3.1> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 07 760-021404 FPM Board REV 03 760-021392 PEM 0 Rev 01 740-022697 AC in PEM 2 Rev 01 740-022697 AC in Routing Engine 0 REV 09 740-015113 Routing Engine 1 REV 06 740-031116 CB 0 REV 07 710-021523 FPC 1 REV 27 750-033205 CPU REV 07 711-035209 MIC 0 REV 20 750-028380 PIC 0 BUILTIN Xcvr 0 NON-JNPR PIC 1 BUILTIN Xcvr 0 NON-JNPR MIC 1 REV 21 750-028380 PIC 2 BUILTIN Xcvr 0 NON-JNPR PIC 3 BUILTIN Xcvr 0 REV 01 740-014289 FPC 2 REV 28 750-016670 CPU REV 07 710-013713 PIC 0 BUILTIN Xcvr 0 REV 02 740-013111 Xcvr 2 REV 01 740-031851 Xcvr 4 REV 02 740-013111 PIC 1 BUILTIN PIC 2 BUILTIN Xcvr 2 REV 01 740-031851 PIC 3 BUILTIN Fan Tray 0 REV 01 710-021113 „„ Serial number JN114A71BAFC ABAA2971 XW2705 QCS0946C08S Description MX240 MX240 Backplane Front Panel Display PS 1.2-1.7kW; 100-240V QCS0946C090 PS 1.2-1.7kW; 100-240V 9009020019 9009104444 XY9409 ZR0349 ZM3745 YV4634 BUILTIN CC14BK0E4 BUILTIN CC14BK0BX ZJ6356 BUILTIN CC14BK089 BUILTIN T08J10452 XJ2544 XG8605 BUILTIN B133478 PMF2ZBD B211673 BUILTIN BUILTIN PL177CJ BUILTIN XM4707 RE-S-1300 RE-S-1800x4 MX SCB MPCE Type 3 3D HMPC PMB 2G 3D 2x 10GE XFP 1x 10GE XFP XFP-10G-SR 1x 10GE XFP XFP-10G-SR 3D 2x 10GE XFP 1x 10GE XFP XFP-10G-SR 1x 10GE XFP XFP-10G-SR DPCE 40x 1GE R EQ DPC PMB 10x 1GE(LAN) EQ SFP-T SFP-SX SFP-T 10x 1GE(LAN) EQ 10x 1GE(LAN) EQ SFP-SX 10x 1GE(LAN) EQ MX240 Fan Tray Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 user@ag3.2> show chassis hardware Hardware inventory: Item Version Part number Chassis Midplane REV 07 760-021404 FPM Board REV 04 760-021392 PEM 0 Rev 01 740-022697 AC in PEM 2 Rev 01 740-022697 AC in Routing Engine 0 REV 09 740-015113 Routing Engine 1 REV 09 740-015113 CB 0 REV 07 710-021523 CB 1 REV 03 710-021523 FPC 1 REV 17 750-031089 CPU REV 06 711-030884 MIC 0 REV 24 750-028387 PIC 0 BUILTIN Xcvr 0 NON-JNPR Xcvr 1 NON-JNPR PIC 1 BUILTIN Xcvr 0 REV 01 740-014279 Xcvr 1 REV 03 740-014289 MIC 1 REV 21 750-028380 PIC 2 BUILTIN Xcvr 0 NON-JNPR PIC 3 BUILTIN Xcvr 0 NON-JNPR FPC 2 REV 12 750-021679 CPU REV 03 710-022351 PIC 0 BUILTIN Xcvr 0 REV 02 740-013111 PIC 1 BUILTIN Xcvr 1 REV 01 740-031851 PIC 2 BUILTIN Xcvr 1 REV 01 740-013111 PIC 3 BUILTIN Fan Tray 0 REV 01 710-021113 Copyright © 2013, Juniper Networks, Inc. Serial number JN1194255AFC ABAA8658 YA0369 QCS1004C062 Description MX240 MX240 Backplane Front Panel Display PS 1.2-1.7kW; 100-240V QCS1004C05P PS 1.2-1.7kW; 100-240V 9009023694 9009020019 XZ9398 XC9314 YZ6247 YX4120 YC3247 BUILTIN CB47BK05U CC14BK05S BUILTIN T08D87316 21T805000059 CAAE6986 BUILTIN CC14BK069 BUILTIN CB42BK04D WY3644 WY2863 BUILTIN B211675 BUILTIN PMF1622 BUILTIN 62362044 BUILTIN XX9503 RE-S-1300 RE-S-1300 MX SCB MX SCB MPC Type 2 3D MPC PMB 2G 3D 4x 10GE XFP 2x 10GE XFP XFP-10G-SR XFP-10G-SR 2x 10GE XFP XFP-10G-LR XFP-10G-SR 3D 2x 10GE XFP 1x 10GE XFP XFP-10G-SR 1x 10GE XFP XFP-10G-SR DPCE 40x 1GE R DPC PMB 10x 1GE(LAN) SFP-T 10x 1GE(LAN) SFP-SX 10x 1GE(LAN) SFP-T 10x 1GE(LAN) MX240 Fan Tray ††‡ Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring IP and MPLS Transport the configuration of Ip and Mpls transport in this topic can be used across all service profiles—4G lte, Hspa, 3G, and 2G. this chapter includes the following topic: • Coniguring the Network segments and Is-Is protocol • Coniguring Intrasegment Mpls transport • Coniguring Intrasegment oaM (rsvp lsp oaM) • Coniguring Intersegment Mpls transport ‰onfiguring the Network Segments and IS-IS Protocol You can configure the sample mobile backhaul (MBH) network with either Intermediate system-to-Intermediate system (Is-Is) or open shortest path First (ospF) as the interior gateway protocol (IGp). the sample network in Figure 5 is configured with Is-Is. to configure ospF, see the Junos OS Routing Protocols Configuration Guide and consider the guidelines in the topic “using ospF.” when you configure Is-Is as the IGp, you must enable Is-Is on the router, configure Iso addressing, and enable Is-Is on all router interfaces. the sample network is configured with Is-Is as follows: 1. all Csrs, all aG 1 routers, and all aG 2 routers belong to autonomous system (as) 64501. 2. all aG 3 routers belong to as 64502. 3. the Csr ring routers belong to Is-Is level 1. 4. all aG 1 and aG 2 routers belong to Is-Is level 2. 5. all aG 1 routers receive all loopback routes from adjacent rings. 6. all aG 2 routers receive all loopback routes from all the Csrs and all the aG 1 routers. the physical topology and Is-Is levels are shown in Figure 63. AS 64501 ACCESS PRE-AGGREGATION Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 CSR 1.2 CSR 1.1 AG 1.1 ge-0/2/1 10.21.0.2/24 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 AS 64502 ge-0/2/0 10.21.2.1/24 ge-1/0/2 21.0.2.2/24 VLAN 1 xe-0/0/0.1 21.0.3.1/24 AGGREGATION CORE Io0:1.1.10.1/32 Io0:1.1.13.1/32 AG 2.1 AG 3.1 Io0:1.1.8.1/32 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 AG 1.3 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.2.2/24 xe-0/0/2 10.23.3.1/24 xe-1/0/2 10.23.3.2/24 VLAN 2 xe-0/0/0.2 10.22.0.1/24 xe-0/0/1 10.22.3.1/24 VLAN 2 xe-0/0/1 10.22.3.2/24 xe-0/0/3 10.23.1.1/24 xe-1/1/3 10.23.2.2/24 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.1/24 ge-0/2/0 10.21.0.1/24 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 VLAN 1 xe-0/0/0.1 21.0.3.2/24 ge-0/2/0 10.21.6.1/24 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.4.2/24 xe-0/0/2 10.22.5.2/24 ge-1/0/2 10.21.4.1/24 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.1/24 CSR 1.4 CSR 1.5 AG 1.2 Io0:1.1.7.1/32 Io0:1.1.6.1/32 Io0:1.1.5.1/32 xe-0/0/0 10.22.4.1/24 AG 1.4 Io0:1.1.9.1/32 xe-1/0/0 10.23.4.2/24 xe-0/0/2 10.23.5.1/24 xe-1/1/3 10.23.5.2/24 AG 2.2 AG 3.2 Io0:1.1.11.1/32 Io0:1.1.14.1/32 No IS-IS L1 to L2 Route Export IS-IS Level 1 BFD IS-IS Level 2 BFD BFD BFD IS-IS OAM Figure 63: Sample Network Topology with IP Addressing, IS-IS, and BGP Autonomous Systems ˆ14 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 In Figure 5, all the Csrs (Csr 1.1 through to Csr 1.5) are in Is-Is level 1. the following Ip addressing is used for interfaces: • access segment interface addresses are from the 10.21.x.y/24 block • aggregation and preaggregation segment interface addresses are from the 10.22.x.y/24 block • Core to aggregation interconnect interface addresses are from the 10.23.x.y/24 block • loopback (lo0) interfaces are assigned addresses from the 1.1.x.1/32 block • aG 1.1 and aG 1.2 router interfaces are conigured with 802.1q vlaN tags 1 and 2, which are conigured for Is-Is level 1 and level 2, respectively. to set up Is-Is adjacencies: 1. Coniguring Is-Is on the Csrs in the access ring. 2. Coniguring Is-Is in the preaggregation ring. 3. Coniguring Is-Is in the aggregation ring—Conigure Is-Is on the aG 1 routers with an export policy to isolate Is-Is level 1 from level 2, and to ilter preixes so that only loopback (lo0) interfaces are advertised. Configuring IS-IS on the CSRs in the Access Ring this example illustrates how to configure interfaces and the Is-Is protocol on a Csr based on the topology in Figure 63. Interfaces are configured with Ip addressing, and the Iso and Mpls family protocols. In addition, the loopback (lo0) address is configured with Iso addressing. the Is-Is protocol is configured with Bidirectional Forwarding Detection (BFD), which is a simple hello mechanism that detects failures in a network. level 2 is disabled for Is-Is and for the loopback (lo0) interface. Note: all the following configuration snippets show the routing options, interfaces, and protocol configurations for router Csr 1.1 and router Csr 1.2. You can use these configuration snippets as the basis for the routing options, interfaces, and protocol configurations of all other Csrs—Csr 1.3, Csr 1.4, and Csr 1.5. However, you must change the router-specific details to match a particular Csr. the following configuration snippet shows the routing-options configuration for router Csr 1.1: [edit] routing-options { router-id 1.1.3.1; autonomous-system 64501; } } the following configuration snippet shows the interface configuration for router Csr 1.1: [edit] interfaces { ge-0/2/1 { description “connected to CSR1.2”; unit 0 { family inet { address 10.21.1.2/24; } family iso; family mpls; } } ge-0/2/0 { description “connected AG1.1”; unit 0 { family inet { address 10.21.2.1/24; } family iso; Copyright © 2013, Juniper Networks, Inc. 115 Design Guide - Juniper Networks universal and aggregation MBH 1.0 family mpls; } } lo0 { unit 0 { family inet { address 1.1.3.1/32; } family iso { address 47.0005.0010.0100.3001.00; } } } } the following configuration snippet shows the Is-Is protocol configuration for router Csr 1.1. the BFD liveness detection values allow a failure detection time of 30 ms. even though Is-Is session failure must be detected as quickly as possible, there are scalability issues, resulting in the minimum interval verified with our solution as 10 ms. [edit] protocols { isis { level 2 disable; interface ge-0/2/0.0 { bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } level 2 disable; } interface ge-0/2/1.0 { bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } level 2 disable; } interface lo0.0 { passive; level 2 disable; } } } the following configuration snippet shows the routing-options configuration for router Csr 1.2: [edit] routing-options { router-id 1.1.2.1; autonomous-system 64501; } } 116 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the interface configuration for router Csr 1.2: [edit] interfaces { ge-0/2/0 { description “connected CSR1.1”; unit 0 { family inet { address 10.21.1.1/24; } family iso; family mpls; } } ge-0/2/1 { description “connected to CSR1.3”; enable; unit 0 { family inet { address 10.21.0.2/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 1.1.2.1/32; } family iso { address 47.0005.0010.0100.2001.00; } } } } the following configuration snippet shows the Is-Is protocol configuration for router Csr 1.2: [edit] protocols { isis { level 2 disable; interface ge-0/2/0.0 { bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } interface ge-0/2/1.0 { bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } Copyright © 2013, Juniper Networks, Inc. Š17 Design Guide - Juniper Networks universal and aggregation MBH 1.0 interface lo0.0 { passive; } } } Configuring IS-IS in the Preaggregation Ring this example illustrates how to configure interfaces, the Is-Is protocol, and policies on a preaggregation router based on the topology in Figure 63. Interfaces are configured with Ip addressing and on the Iso and Mpls family protocols. the interfaces between router aG 1.1 and router aG 1.2 are configured with flexible vlaN tagging and flexible ethernet services encapsulation, which allows the configuration of two logical interfaces with two different vlaN tags. to provide optimal Is-Is routing, we recommend that you assign a logical interface with the vlaN tag 1 to Is-Is level 1 and a logical interface with the vlaN tag 2 to Is-Is level 2. the Is-Is protocol configuration includes the application of an export policy to export routes from the routing table into Is-Is, and Bidirectional Forwarding Detection (BFD), which is a simple hello mechanism that detects failures in a network. Is-Is level 1 or level 2 is disabled, depending on the interface. In addition, the export policy that was applied in the Is-Is protocol configuration is defined with a routing policy, which allows you to control the flow of routing information to and from the routing table. Ž‘ all the following configuration snippets show the interface, protocol, and policy option configurations for router aG 1.1. You can use these configuration snippets as the basis for the interface, protocol, and policy option configurations of all other aG 1 routers—aG 1.2, aG 1.3, and aG 1.4. However, you must change the router-specific details to match a particular aG 1 router. the following configuration snippet shows the interface configuration for router aG 1.1: [edit] interfaces { ge-1/0/2 { description “connected to CSR1.1”; enable; unit 0 { family inet { address 10.21.2.2/24; } family iso; family mpls; } } xe-0/0/0 { description “connected AG1.2”; lexible-vlan-tagging; encapsulation lexible-ethernet-services; unit 1 { vlan-id 1; family inet { address 10.21.3.1/24; } family iso; family mpls; } unit 2 { vlan-id 2; family inet { address 10.22.0.1/24; } ‹‹Œ Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 family iso; family mpls; } } xe-0/0/2 { description “connected AG1.3”; unit 0 { family inet { address 10.22.1.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 1.1.4.1/32; } family iso { address 47.0005.0010.0100.4001.00; } } } } the following configuration snippet shows the Is-Is protocol configuration for router aG 1.1: [edit] protocols { isis { export isis-export; interface ge-1/0/2.0 { bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } level 2 disable; } interface xe-0/0/0.1 { level 2 disable; bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } interface xe-0/0/0.2 { level 1 disable; bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } Copyright © 2013, Juniper Networks, Inc. ’19 Design Guide - Juniper Networks universal and aggregation MBH 1.0 interface xe-0/0/2.0 { level 1 disable; bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } interface lo0.0 { passive; } } } the following configuration snippet shows the policy-option configuration for router aG 1.1: [edit] policy-options { policy-statement isis-export { term t1 { from level 1; to level 2; then reject; } term t2 { from { protocol direct; route-ilter 10.21.4.0/24 exact; route-ilter 10.21.3.0/24 exact; } to level 2; then reject; } } } Configuring IS-IS in the Aggregation Ring this example illustrates how to configure interfaces and the Is-Is protocol on an aggregation router based on the topology in Figure 63. the interfaces between router aG 2.1 and router aG 2.2 are configured with flexible vlaN tagging and flexible ethernet services encapsulation, which allows the configuration of logical interfaces with different vlaN tags. the configured logical interface with vlaN tag 1 is assigned to the Is-Is level 2 zone. we recommend that you use a configuration with vlaN-tagged interfaces between the router aG 2.1 and router aG 2.2 to allow connection to different IGp regions (possibly with different IGp protocols) without disturbing the configuration of existing IGp regions. the Is-Is protocol is configured with Bidirectional Forwarding Detection (BFD), which is a simple hello mechanism that detects failures in a network. Is-Is level 1 is disabled. Note: all the following configuration snippets show the interface and protocol configuration for router aG 2.1 and can be used as the basis for the interface and protocol configuration on router aG 2.2. However, you must change the router-specific details to match router aG 2.2. “”• Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 this configuration snippet shows the interface configuration for router aG 2.1: [edit] interfaces { xe-0/0/0 { description “connected to AG1.3”; enable; unit 0 { family inet { address 10.22.2.2/24; } family iso; family mpls; } } xe-0/0/1 { description “connected to AG2.2”; lexible-vlan-tagging; encapsulation lexible-ethernet-services; unit 1 { vlan-id 1; family inet { address 10.22.3.1/24; } family iso; family mpls; } } xe-0/0/2 { description “connected to AG3.1”; unit 0 { family inet { address 10.23.3.1/24; } family iso; family mpls; } } xe-0/0/3 { description “connected to AG3.2”; unit 0 { family inet { address 10.23.1.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 1.1.10.1/32; } family iso { address 47.0005.0010.0101.0001.00; } } } } Copyright © 2013, Juniper Networks, Inc. –—– Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the protocol configuration for router aG 2.1: [edit] protocols { isis { level 1 disable; interface xe-0/0/0.0 { bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } interface xe-0/0/1.1 { bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } } interface lo0.0 { passive; } } } to verify the Is-Is setup: 1. verify that Is-Is adjacencies are established; issue the show isis adjacency command. 2. verify that routes adhere to the level 1 and level 2 zones on the Csr, aG 1, and aG 2 routers; issue the show route terse command to check the routing table. a. Check that Csrs contain routes only to the loopback address of all other Csrs. b. Check that aG 1 routers contain routes to the loopback address of all other Csr, aG 1, and aG 2 routers. c. Check that aG 2 routers contain routes only to the loopback address of all other aG 1 and aG 2 routers. 3. verify that each router is reachable from other routers within each Is-Is zone; issue the ping host command. specify the loopback address of each remote router for the host option. Configuring Routers in the Core Segment this example illustrates how to configure interfaces on edge routers—aG 3.1 and aG 3.2—based on the topology in Figure 63. Note: all the following configuration snippets show the interface and routing-option configuration for router aG 3.1 and can be used as the basis for the configuration on router aG 3.2. However, you must change the router-specific details to match router aG 3.2. ˜™™ Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 [edit] interfaces { xe-1/0/0 { unit 0 { family inet { address 10.23.4.1/24; } family iso; family mpls; } } xe-1/0/2 { unit 0 { family inet { address 10.23.3.2/24; } family iso; family mpls; } } xe-1/1/3 { unit 0 { family inet { address 10.23.2.2/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 1.1.13.1/32; } family iso { address 47.0006.0010.0101.3001.00; } family mpls; } } } [edit] routing-options { router-id 1.1.13.1; autonomous-system 64502; } Copyright © 2013, Juniper Networks, Inc. š›œ Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring Intrasegment MPLS Transport this example illustrates how to configure end-to-end Mpls transport on routers in different segments of the MBH network, including the configuration of rsvp, Mpls label-switched paths, Mpls fast reroute (Frr), primary, and secondary paths as shown in Figure 64. AS 64501 ACCESS AS 64502 PRE-AGGREGATION AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0: 1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/1 10.21.0.2/24 Primary Path ge-0/2/0 10.21.2.1/24 ge-1/0/2 10.21.2.2/24 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.2.2/24 xe-0/0/2 10.23.3.1/24 xe-1/0/2 10.23.3.2/24 xe-1/0/0 10.23.4.1/24 VLAN 1 VLAN 2 xe-0/0/0.1 xe-0/0/0.2 10.21.3.1/24 10.22.0.1/24 xe-0/0/1 10.22.3.1/24 ge-0/2/0 10.21.0.1/24 xe-0/0/3 10.23.1.1/24 xe-1/1/3 10.23.2.2/24 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 xe-0/0/1 10.22.3.2/24 VLAN 1 VLAN 2 Secondary Path ge-0/2/0 10.21.6.1/24 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 xe-0/0/0.1 xe-0/0/0.2 21.0.3.2/24 10.22.0.2/24 CSR 1.5 CSR 1.4 ge-0/2/1 10.21.4.2/24 ge-1/0/2 10.21.4.1/24 Io0:1.1.6.1/32 Io0:1.1.7.1/32 xe-0/0/2 10.22.5.2/24 AG 1.2 xe-0/0/2 10.22.5.1/24 MPLS Fast Reroute BFD xe-1/0/0 10.23.4.2/24 xe-0/0/2 10.23.5.1/24 xe-1/1/3 10.23.5.2/24 AG 2.2 Io0:1.1.9.1/32 Io0:1.1.5.1/32 Partial Mesh RSVP BFD AG 1.4 xe-0/0/0 10.22.4.2/24 xe-0/0/0 10.22.4.1/24 Io0:1.1.11.1/32 AG 3.2 Io0:1.1.14.1/32 Full Mesh RSVP BFD BFD RSVP LSP (Primary Path) RSVP LSP (Primary Path) RSVP LSP (Secondary Path) RSVP LSP (Secondary Path) MPLS OAM MPLS Fast Reroute Figure 64: Intrasegment MPLS Deployment to configure an intrasegment rsvp lsp and an intersegment lsp based on the topology in Figure 64: 1. Conigure an rsvp lsp between each Csr and router aG 1.1 and router aG 1.2: a. Conigure two rsvp lsps from each Csr to router aG 1.1 and router aG 1.2 and vice versa. b. Conigure path protection with the primary path going in one direction and the secondary path going in the opposite direction. c. Conigure the secondary path as the standby path. d. Conigure lDp tunneling. e. Conigure the BFD protocol for fast end-to-end lsp failure detection. 2. Conigure an rsvp lsp between each aG 1 and aG 2 router: a. Conigure rsvp lsps between each aG 1 and aG 2 router. b. Conigure path protection with the primary path going in one direction and the secondary path going in the opposite direction. c. Conigure the secondary path as the standby path. 3. Conigure per-packet load balancing on all routers. all the following configuration snippets for the Csr, aG 1, and aG 2 routers are the result of steps 1 through 3 of Configuring Intrasegment MPLS Transport. 24 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Note: the following configuration snippets show the Mpls configuration for router Csr 1.1 and router Csr 1.2. You can use these configuration snippets as the basis for the Mpls configuration of all other Csrs—Csr 1.3, Csr 1.4, and Csr 1.5. However, you must change the router-specific details to match a particular Csr. the following configuration snippet shows the Mpls configuration for router Csr 1.1: [edit] protocols { rsvp { interface ge-0/2/1.0; interface ge-0/2/0.0; } mpls { label-switched-path csr1.1_to_ag1.1 { from 1.1.3.1; to 1.1.4.1; ldp-tunneling; fast-reroute; primary via-ag1.1; secondary via-csr1.2; } label-switched-path csr1.1_to_ag1.2 { from 1.1.3.1; to 1.1.5.1; ldp-tunneling; fast-reroute; primary via-ag1.1; secondary via-csr1.2; } path via-ag1.1 { 10.21.2.2 strict; } path via-csr1.2 { 10.21.1.1 strict; } interface ge-0/2/1.0; interface ge-0/2/0.0; interface lo0.0; } ldp { interface lo0.0; } } the following configuration snippet shows the Mpls configuration for router Csr 1.2: [edit] protocols { rsvp { interface ge-0/2/1.0; interface ge-0/2/0.0; } mpls { label-switched-path csr1.2_to_ag1.1 { from 1.1.2.1; to 1.1.4.1; ldp-tunneling; fast-reroute; primary via_csr1.1; Copyright © 2013, Juniper Networks, Inc. 125 Design Guide - Juniper Networks universal and aggregation MBH 1.0 secondary via_csr1.3; } label-switched-path csr1.2_to_ag1.2 { from 1.1.2.1; to 1.1.5.1; ldp-tunneling; fast-reroute; primary via_csr1.1; secondary via_csr1.3; } path via_csr1.1 { 10.21.1.2 strict; } path via_csr1.3 { 10.21.0.1 strict; } interface ge-0/2/1.0; interface ge-0/2/0.0; } } Note: the following configuration snippets show the Mpls configurations for router aG 1.1 and router aG 1.2. You can use these configuration snippets as the basis for the Mpls configuration of all other aG 1 routers—aG 1.3 and aG 1.4. However, you must change the router-specific details to match a particular aG 1 router. the following configuration snippet shows the Mpls configuration for router aG 1.1: [edit] protocols { rsvp { interface ge-1/0/2.0; interface xe-0/0/0.1; interface xe-0/0/2.0; interface xe-0/0/0.2; } mpls { label-switched-path ag1.1_to_csr1.1 { from 1.1.4.1; to 1.1.3.1; ldp-tunneling; fast-reroute; primary via_csr1.1; secondary via_ag1.2_1; } label-switched-path ag1.1_to_csr1.2 { from 1.1.4.1; to 1.1.2.1; ldp-tunneling; fast-reroute; primary via_csr1.1; secondary via_ag1.2_1; } label-switched-path ag1.1_to_ag2.1 { from 1.1.4.1; to 1.1.10.1; fast-reroute; primary via_ag1.3; secondary via_ag1.2_2; 126 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 } label-switched-path ag1.1_to_ag2.2 { from 1.1.4.1; to 1.1.11.1; fast-reroute; primary via_ag1.2_2; secondary via_ag1.3; } label-switched-path ag1.1_to_csr1.3 { from 1.1.4.1; to 1.1.1.1; ldp-tunneling; fast-reroute; primary via_csr1.1; secondary via_ag1.2_1; } label-switched-path ag1.1_to_csr1.4 { from 1.1.4.1; to 1.1.7.1; ldp-tunneling; fast-reroute; primary via_csr1.1; secondary via_ag1.2_1; } label-switched-path ag1.1_to_csr1.5 { from 1.1.4.1; to 1.1.6.1; ldp-tunneling; fast-reroute; primary via_csr1.1; secondary via_ag1.2_1; } label-switched-path ag1.1_to_ag1.2 { from 1.1.4.1; to 1.1.5.1; fast-reroute; primary via_ag1.2_2; secondary via_csr1.1; } path via_csr1.1 { 10.21.2.1 strict; } path via_ag1.2_1 { 10.21.3.2 strict; } path via_ag1.3 { 10.22.1.2 strict; } path via_ag1.2_2 { 10.22.0.2 strict; } interface ge-1/0/2.0; interface xe-0/0/0.1; interface xe-0/0/2.0; interface xe-0/0/0.2; interface lo0.0; } } Copyright © 2013, Juniper Networks, Inc. ž27 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the Mpls configuration for router aG 1.2: [edit] protocols { rsvp { interface xe-0/0/0.1; interface ge-1/0/2.0; interface xe-0/0/0.2; interface xe-0/0/2.0; } mpls { label-switched-path ag1.2_to_csr1.1 { from 1.1.5.1; to 1.1.3.1; fast-reroute; primary via_csr1.5; secondary via_ag1.2_1; } label-switched-path ag1.2_to_csr1.2 { from 1.1.5.1; to 1.1.2.1; fast-reroute; primary via_csr1.5; secondary via_ag1.2_1; } label-switched-path ag1.2_to_csr1.3 { from 1.1.5.1; to 1.1.1.1; fast-reroute; primary via_csr1.5; secondary via_ag1.2_1; } label-switched-path ag1.2_to_csr1.4 { from 1.1.5.1; to 1.1.7.1; fast-reroute; primary via_csr1.5; secondary via_ag1.2_1; } label-switched-path ag1.2_to_csr1.5 { from 1.1.5.1; to 1.1.6.1; fast-reroute; primary via_csr1.5; secondary via_ag1.2_1; } label-switched-path ag1.2_to_ag2.1 { from 1.1.5.1; to 1.1.10.1; fast-reroute; primary via_ag1.2_2; secondary via_ag1.4; } label-switched-path ag1.2_to_ag2.2 { from 1.1.5.1; to 1.1.11.1; fast-reroute; primary via_ag1.4; Ÿ¡ Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 secondary via_ag1.2_2; } label-switched-path ag1.2_to_ag1.1 { from 1.1.5.1; to 1.1.4.1; fast-reroute; primary via_ag1.2_2; secondary via_csr1.5; } path via_csr1.5 { 10.21.4.2 strict; } path via_ag1.2_1 { 10.21.3.1 strict; } path via_ag1.4 { 10.22.5.1 strict; } path via_ag1.2_2 { 10.22.0.1 strict; } interface xe-0/0/0.1; interface ge-1/0/2.0; interface xe-0/0/2.0; interface xe-0/0/0.2; interface lo0.0; } ldp { interface lo0.0; } } Note: the following configuration snippet shows the Mpls configuration for router aG 2.1. You can use this configuration snippet as the basis for the Mpls configuration of router aG 2.2. However, you must change the routerspecific details to match router aG 2.2. the following configuration snippet shows the Mpls configuration for router aG 2.1: [edit] protocols { rsvp { interface xe-0/0/1.1; interface xe-0/0/0.0; } mpls { label-switched-path ag2.1_to_ag1.1 { from 1.1.10.1; to 1.1.4.1; fast-reroute; primary via_ag1.3; secondary via_ag2.2; } label-switched-path ag2.1_to_ag1.2 { from 1.1.10.1; to 1.1.5.1; fast-reroute; primary via_ag1.3; Copyright © 2013, Juniper Networks, Inc. ¢29 Design Guide - Juniper Networks universal and aggregation MBH 1.0 secondary via_ag2.2; } path via_ag2.2 { 10.22.3.2 strict; } path via_ag1.3 { 10.22.2.1 strict; } interface xe-0/0/0.0; interface xe-0/0/1.1; } } the following configuration snippet shows the routing policy configuration for all routers in the sample network: [edit} policy-options { policy-statement pplb { then { load-balance per-packet; } } } [...Output truncated...] [edit] routing-options { forwarding-table { export pplb; } } to verify the intrasegment Mpls lsp configuration: 1. verify the status of conigured lsps on each device; issue the show mpls lsp name name ingress detail command. specify the name of the lsp for the name option. the ingress option shows the sessions that originate from the router on which the command is run. Check that the following paths and status in the output are up and working as expected: a. rsvp lsp. b. primary path. c. secondary path. d. standby status. e. Fast reroute status. Configuring Intrasegment OAM (RSVP LSP OAM) this example illustrates how to configure an rsvp label-switched path (lsp) with operation, administration, and Maintenance (oaM) on a cell site or aggregation router to control the status of Mpls lsps and to track failure events at this level. the BFD protocol is used on each rsvp lsp. this configuration is based on the topology in Figure 64. to configure an rsvp lsp with oaM: • Conigure all routers (Csr 1.1 through Csr 1-5, aG 1.1 through aG 1.4, aG 2.1, and aG 2.2) with the BFD protocol on each rsvp lsp. set the BFD timer to 100 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. (see the topic “Design Consistency and scalability veriication.”) Note: the following configuration snippet shows the rsvp lsp with oaM configurations for router Csr 1.2. You can use this configuration snippet as the basis for the rsvp lsp configuration of the following routers—Csr 1.1 through Csr 1.5, aG 1.1 through aG 1.4, aG 2.1 and aG 2.1. However, you must change the router-specific details to match a particular Csr , aG 1, and aG 2 router. £¤¥ Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the rsvp lsp with oaM configuration for router Csr 1.2 to router aG 1.1: [edit] protocols { rsvp { interface ge-0/2/1.0; interface ge-0/2/0.0; } mpls { label-switched-path csr1.2_to_ag1.1 { from 1.1.2.1; to 1.1.4.1; fast-reroute; oam { bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } } primary via_csr1.1; secondary via_csr1.3; } } } to verify your rsvp lsp with oaM configuration, issue the show bfd session address and show bfd session detail commands. specify the loopback address of the BFD peer for the address option. Check the following status and output fields: 1. verify that all the BFD sessions are established and up. 2. Check that the timers negotiated relect the timers that are conigured. 3. Check the BFD statistics. Configuring Intersegment MPLS Transport BGp-labeled unicast (BGp-lu) is used to advertise route information between routers in different IGp regions. By providing connectivity and communication between regions, BpG-lu enables you to massively scale the number of Mpls-enabled routers on your networks. this example illustrates how to configure Mpls transport on preaggregation and aggregation routers based on the topology in Figure 65. For Csrs to resolve the loopback address of the provider edge routers (aG 3.1 and aG 3.2) with a labeled path, you must configure lDp downstream-on-demand (lDp-DoD; rFC 5036) on the Csrs. the Csr uses lDp-DoD to request a transport label for every remote provider edge router loopback address. to preserve resiliency at the access region, lDp-DoD is tunneled over the rsvp lsp. together lDp-DoD and BGp-lu establish an end-to-end continuous labeledswitched (lsp) path from each Csr to each provider edge router. (see Figure 65.) Copyright © 2013, Juniper Networks, Inc. ¦§¦ Design Guide - Juniper Networks universal and aggregation MBH 1.0 AS 64501 ACCESS AS 64502 PRE-AGGREGATION AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/2/1 10.21.0.2/24 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/0 10.21.2.1/24 ge-1/0/2 10.21.2.2/24 VLAN 1 xe-0/0/0.1 10.21.3.1/24 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.2.2/24 xe-0/0/2 10.23.3.1/24 xe-1/0/2 10.23.3.2/24 xe-1/0/0 10.23.4.1/24 VLAN 2 xe-0/0/0.2 10.22.0.1/24 xe-0/0/1 10.22.3.1/24 VLAN 2 xe-0/0/1 10.22.3.2/24 ge-0/2/0 10.21.0.1/24 xe-0/0/3 xe-1/1/3 10.23.1.1/24 10.23.2.2/24 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 VLAN 1 xe-0/0/0.1 10.21.3.2/24 ge-0/2/0 10.21.6.1/24 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.4.2/24 xe-0/0/2 10.22.5.2/24 ge-1/0/2 10.21.4.1/24 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.1/24 xe-0/0/3 xe-1/1/1 10.23.2.1/24 10.23.1.2/24 xe-1/0/0 10.23.4.2/24 xe-0/0/2 10.23.5.1/24 xe-0/0/0 10.22.4.1/24 xe-1/1/3 10.23.5.2/24 CSR 1.4 CSR 1.5 AG 1.2 AG 1.4 AG 2.2 AG 3.2 Io0:1.1.7.1/32 Io0:1.1.6.1/32 Io0:1.1.5.1/32 Io0:1.1.9.1/32 Io0:1.1.11.1/32 Io0:1.1.14.1/32 Redistribute CSR Loopbacks to inet3 for BGP-LU Family Redistribute AG2.x and AG3.x Io0 to inet3 LDP-DOD BGP-LU RR (RFC 3107) BFD eBGP-LU BFD BGP OAM LDP-DOD LSP RSVP LSP BGP-LU LSP RSVP LSP Figure 65: Intersegment MPLS Deployment Configuring BGP-LU 1. to conigure an intersegment lsp: a. Conigure IBGp-lu on each aG 1 router to establish BGp peers with router aG 2.1 and router aG 2.2. b. Conigure each aG 1 router with an export policy to redistribute the local loopback interface routes into BGp. c. Conigure router aG 1.1 and router aG 1.2 with an export policy to redistribute the loopback interface routes from the Csrs into BGp. «¬­ d. Conigure a rIB group on all aG 1, aG 2, and aG 3 routers to export loopback interface routes from the t0 routing table into the inet3 routing table to advertise them as labeled routes using BGp-lu. use the export policy conigured in step b and step c to ilter routes for export. 2. to conigure resiliency and fast failure detection for the BGp-lu session: a. Conigure all aG 1 routers with the BFD protocol for each BGp session; set the BFD timer to 100 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. see the topic “Design Consistency and scalability veriication.” b. Conigure all aG 1 routers with static routes to the loopback (lo0) interface of router aG 2.1 and router aG 2.2. as the next hop, use the corresponding rsvp lsp conigured in “Coniguring Intrasegment Mpls transport.” the following configuration snippet shows the BGp-lu configuration for router aG 1.1; you can use it as the basis for the BGp-lu configuration of all other aG 1 routers. However, you must change the router-specific details to match a particular aG 1 router. ¨©ª Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 [edit] routing-options { rib-groups { inet3-to-inet0 { import-rib [ inet.3 inet.0 ]; } } } policy-options { policy-statement recv-route { term 1 { from { route-ilter 1.1.6.1/32 exact; route-ilter 1.1.7.1/32 exact; route-ilter 1.1.2.1/32 exact; route-ilter 1.1.3.1/32 exact; route-ilter 1.1.1.1/32 exact; } then reject; } term 2 { then accept; } } policy-statement send-lo0 { term 10 { from { route-ilter 1.1.4.1/32 exact; route-ilter 1.1.1.1/32 exact; route-ilter 1.1.2.1/32 exact; route-ilter 1.1.3.1/32 exact; route-ilter 1.1.6.1/32 exact; route-ilter 1.1.7.1/32 exact; } then accept; } } policy-statement send_inet3_to_inet0 { term 10 { from { route-ilter 1.1.0.0/32 address-mask 255.255.0.0; } then accept; } term 20 { then reject; } } policy-statement send_lo0_to_inet3 { term 10 { from { route-ilter 1.1.4.1/32 exact; } then accept; } term 20 { then reject; } Copyright © 2013, Juniper Networks, Inc. ®¯¯ Design Guide - Juniper Networks universal and aggregation MBH 1.0 } } protocols { bgp { group ag1_ag2_rr { type internal; local-address 1.1.4.1; import recv-route; export send-lo0; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; neighbor 1.1.10.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } neighbor 1.1.11.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } } } } the following configuration snippet shows the configuration of static routes for router aG 1.1; you can use it as the basis for the static route configuration of all other aG 1 routers. However, you must change the router-specific details to match a particular aG 1 router. [edit] routing-options { static { route 1.1.10.1/32 { lsp-next-hop ag1.1_to_ag2.1; } route 1.1.11.1/32 { lsp-next-hop ag1.1_to_ag2.2; } route 1.1.5.1/32 { lsp-next-hop ag1.1_to_ag1.2; } } } 134 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 3. Conigure IBGp on the aG 2 routers to be peers with the routers in the aG 1 ring: a. Conigure BGp-lu sessions between all aG 2 routers. b. Conigure the aG 2 routers as BGp route relectors for the routers in the aG 1 ring. Note that the aG 2 routers do not change the next hop for these sessions. c. add multipath to the BGp coniguration. 4. to conigure resiliency and fast failure detection for the BGp-lu session: a. Conigure router aG 2.1 and router aG 2.2 with the BFD protocol for each BGp session to the aG 1 routers; set the BFD timer to 100 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. see the topic “Design Consistency and scalability veriication.” b. Conigure router aG 2.1 and router aG 2.2 with the BFD protocol for each BGp session to router aG 2.2 and router aG 2.1, respectively; set the BFD timer to 10 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. see the topic “Design Consistency and scalability veriication.” c. Conigure router aG 2.1 and router aG 2.2 with static routes to the loopback (lo0) interface addresses of the aG 1 routers. as the next hop, use the corresponding rsvp lsp conigured in “Coniguring Intrasegment Mpls transport.” the following configuration snippet shows the configuration of IBGp and BGp-lu (step 3 and step 4) on router aG 2.1; you can use this configuration as the basis for the IBGp and BGp-lu configuration on router aG 2.2. However, you must change the router-specific details to match router aG 2.2. [edit] routing-options { interface-routes { rib-group inet inet0-to-inet3; } rib-groups { inet3-to-inet0 { import-rib [ inet.3 inet.0 ]; } inet0-to-inet3 { import-rib [ inet.0 inet.3 ]; import-policy rib_import; } } } protocols { bgp { group ag2_ibgp { type internal; local-address 1.1.10.1; bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } multipath; neighbor 1.1.11.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } } group ag1_rr { Copyright © 2013, Juniper Networks, Inc. 135 Design Guide - Juniper Networks universal and aggregation MBH 1.0 type internal; local-address 1.1.10.1; cluster 1.1.10.1; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; neighbor 1.1.4.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } neighbor 1.1.5.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } neighbor 1.1.9.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } neighbor 1.1.8.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } } } } 5. Conigure external BGp (eBGp)-lu between the aG 2 routers and the aG 3 routers: a. Conigure the aG 3 routers to be dual homed to the aG 2 routers. b. Conigure the aG 2 routers and the aG 3 routers to set the next hop to self. c. Conigure multipath for BGp sessions on all aG 2 and aG 3 routers. 136 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 6. Conigure resiliency and fast failure detection for the BGp-lu session on the aG 2 and the aG 3 routers: a. Conigure router aG 2.1, router aG 2.2, router aG 3.1, and router aG 3.2 with the BFD protocol for each eBGp session; set the BFD timer to 10 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. see the topic “Design Consistency and scalability veriication.” the following configuration snippet shows the configuration of routing policy and eBGp-lu on router aG 2.1; you can use the configuration as the basis for the routing policy and eBGp-lu configuration on router aG 2.2. However, you must change the router-specific details to match router aG 2.2. [edit] policy-options { policy-statement adv_lb { term local { from { protocol direct; route-ilter 1.1.10.1/32 exact; } then accept; } term ag1-ring { from { route-ilter 1.1.4.1/32 exact; route-ilter 1.1.5.1/32 exact; route-ilter 1.1.9.1/32 exact; route-ilter 1.1.8.1/32 exact; } then accept; } } } protocols { bgp { group ebgp { type external; export adv_lb; peer-as 64502; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; neighbor 10.23.1.2 { local-address 10.23.1.1; family inet { labeled-unicast { rib-group inet3-to-inet0; per-preix-label; rib { inet.3; } } } } neighbor 10.23.3.2 { local-address 10.23.3.1; family inet { labeled-unicast { rib-group inet3-to-inet0; Copyright © 2013, Juniper Networks, Inc. °37 Design Guide - Juniper Networks universal and aggregation MBH 1.0 per-preix-label; rib { inet.3; } } } } } } } the following configuration snippet shows the configuration of routing policy and eBGp-lu on router aG 3.1; you can use the configuration as the basis for the routing policy and eBGp-lu configuration for router aG 3.2. However, you must change the router-specific details to match router aG 3.2. [edit] routing-options { interface-routes { rib-group inet inet0-to-inet3; } rib-groups { inet3-to-inet0 { import-rib [ inet.3 inet.0 ]; } inet0-to-inet3 { import-rib [ inet.0 inet.3 ]; import-policy rib_import; } } } policy-options { policy-statement adv_lb { term local { from { protocol direct; route-ilter 1.1.13.1/32 exact; } then accept; } term rej_all { then reject; } } policy-statement metric_rem { term 1 { from protocol bgp; then { metric { minimum-igp; } accept; } } } } ±²³ Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 protocols { bgp { group ebgp { type external; export adv_lb; peer-as 64501; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; neighbor 10.23.3.1 { local-address 10.23.3.2; family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } neighbor 10.23.2.1 { local-address 10.23.2.2; family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } } group ag3_ibgp { type internal; local-address 1.1.13.1; export adv_lb; bfd-liveness-detection { minimum-interval 10; multiplier 3; no-adaptation; } neighbor 1.1.14.1 { family inet { labeled-unicast { rib-group inet3-to-inet0; rib { inet.3; } } } } } } } Copyright © 2013, Juniper Networks, Inc. ´39 Design Guide - Juniper Networks universal and aggregation MBH 1.0 to verify your BGp-lu configuration: 1. verify that BGp sessions are established and up; issue the show bgp neighbor neighbor-address command. specify the loopback address of the BGp peer for the neighbor-address option. 2. verify that all expected routes are present in each of the following routers; issue the show route table inet.3 and show route table inet.0 commands: a. all aG 1 routers b. all aG 2 routers c. all aG 3 routers 3. verify that each of these preixes is reachable from each device. Configuring LDP-DOD the following configuration for lDp-DoD relies on the configuration of rsvp. all rsvp lsps between the Csr and aG 1 routers should be configured with the ldp-tunneling option as described in Configuring Intrasegment MPLS Transport. to establish an intersegment lsp from the access segment to the provider service edge router use the lDp-DoD protocol. to configure lDp-DoD on the Csrs: 1. Conigure the preix list to allow upper layer Mpls services to request Mpls labels for the provider service edge router loopback address. 2. Conigure the lDp-DoD protocol. 3. Conigure static routes on the Csrs pointing to the loopback address of the aG 2 routers. Note: all the following configuration snippets show the policy options and lDp-DoD configurations for router Csr 1.3. You can use these configuration snippets as the basis for the policy option and lDp-DoD configurations of all other Csrs—Csr 1.1, Csr 1.2, Csr 1.4, and Csr 1.5. the following configuration snippet shows the policy options configuration for router Csr 1.3. the apply-path statement expands the prefix list to include all prefixes defined for neighbors at the [edit protocols l2circuit] hierarchy level. [edit] policy-options { preix-list dod_preix { 1.1.4.1/32 # Loopback addresses of AG1.1, AG1.2, and AG2.1 1.1.5.1/32 1.1.10.1/32 /* AG1.1, AG1.2 and AG2.1 preixes area automatically added to the preix list, see the topic “Coniguring ATM and TDM Transport Pseudowire End-to-End”*/ apply-path “protocols l2circuit neighbor <*>”; } policy-statement get_dod_preix { term 10 { from { preix-list dod_preix; # } then accept; } term 20 { then reject; } } } 140 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the lDp-DoD configuration for router Csr 1.3: [edit] protocols { ldp { dod-request-policy get_dod_preix; interface lo0.0; session 1.1.4.1 { downstream-on-demand; } session 1.1.5.1 { downstream-on-demand; } } } the following configuration snippet shows the static route configuration for router Csr 1.3: [edit] routing-options { static { /* Static routes to the loopback addresses of the AG routers connected to the RNC/BSC */ route 1.1.10.1/32 { lsp-next-hop csr1.3_to_ag1.1; } route 1.1.11.1/32 { lsp-next-hop csr1.3_to_ag1.2; install; } } router-id 1.1.1.1; autonomous-system 64501; forwarding-table { export pplb; } } to verify your lDp-DoD configuration: • verify the status of lDp sessions by issuing the show ldp session and show ldp session detail commands. Copyright © 2013, Juniper Networks, Inc. 141 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring End-to-End Layer 3 VPN Services a layer 3 vpN is a set of sites that share common routing information and whose connectivity is controlled by a collection of policies. this deployment scenario illustrates how to configure a layer 3 vpN using Multiprotocol internal BGp (Mp-IBGp) and Multiprotocol external BGp (Mp-eBGp) to distribute vpN routes across the Csr access ring and across different autonomous systems. the configuration is based on the network topology in Figure 66 and Figure 67, and can be used across the following service profiles—4G lte and Hspa. at a high level, to establish an end-to-end layer 3 vpN, you need to: 1. Conigure Mp-BGp in the network to signal Mpls labels for the layer 3 vpN service and to distribute vrF routes. (see Figure 66 and the topic “Coniguring Mp-BGp.”) 2. Conigure a routing instance for the layer 3 vpN and uNI interfaces at each service router—Csr 1.1 through Csr 1.5, aG 1.1, aG 1.2, aG 3.1 and aG 3.2. (see Figure 67 and the topic “Coniguring the routing Instance for the layer 3 vpN.”) AS 64501 ACCESS AS 64502 AGGREGATION PRE-AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/2/1 10.21.0.2/24 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/0 10.21.2.1/24 ge-1/0/2 10.21.2.2/24 VLAN 1 xe-0/0/0.1 10.21.3.1/24 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.2.2/24 xe-0/0/2 10.23.3.1/24 xe-1/0/2 10.23.3.2/24 VLAN 2 xe-0/0/0.2 10.22.0.1/24 xe-0/0/1 10.22.3.1/24 xe-0/0/3 10.23.1.1/24 xe-1/1/3 10.23.2.2/24 xe-0/0/1 10.22.3.2/24 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.1/24 ge-0/2/0 10.21.0.1/24 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 VLAN 1 xe-0/0/0.1 10.21.3.2/24 ge-0/2/0 10.21.6.1/24 VLAN 2 xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.4.2/24 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 xe-0/0/2 10.22.5.2/24 ge-1/0/2 10.21.4.1/24 xe-0/0/2 10.22.5.1/24 xe-1/0/0 10.23.4.2/24 xe-0/0/2 10.23.5.1/24 xe-0/0/0 10.22.4.2/24 xe-0/0/0 10.22.4.1/24 xe-1/1/3 10.23.5.2/24 CSR 1.4 CSR 1.5 AG 1.2 AG 1.4 AG 2.2 AG 3.2 Io0:1.1.7.1/32 Io0:1.1.6.1/32 Io0:1.1.5.1/32 Io0:1.1.9.1/32 Io0:1.1.11.1/32 Io0:1.1.14.1/32 Default NHS MP-BGP MP-EBGP (Option C) BFD RR (RFC 3107) BFD BGP OAM Figure 66: MP-BGP Deployment for Layer 3 VPN Services the network in Figure 66 has the following characteristics: 1. BGp in the Csr access ring: a. each Csr has an Mp-IBGp session (family inet-vpn unicast) to each aG 1 router in the access ring. b. BGp multipath is enabled for each session. c. per packet load balancing is enabled on all Csrs. d. each aG 1 router has an Mp-IBGp session to each Csr in the access ring. e. aG 1 routers act as route relectors for all the Csrs in the access ring. f. an Mp-IBGp session is established between all the aG 1 routers. 142 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 2. BGp between all aG 3 routers and all aG 1 routers: a. each aG 1 router has a multihop Mp-eBGp session with each aG 3 router (family inet-vpn unicast). b. each aG 3 router has a multihop Mp-eBGp session with each aG 1 router. c. BGp multipath is used on aG 3 routers for the Mp-eBGp sessions. d. per packet load balancing is enabled on all aG 3 routers. e. aG 3 routers act as route relectors for the Mp-eBGp sessions. 3. resiliency and fast failure detection for the BGp session: a. Csrs and aG 1 routers use the BFD protocol for each Mp-BGp session in the access ring. the BFD timer is set to 100 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. see the topic “Design Consistency and scalability veriication.” b. the aG 1 and aG 3 routers use the BFD protocol for each BGp session. the BFD timer is set to 100 ms. Note that in an actual network, you might need to tune this timer to it the BFD scale. see the topic “Design Consistency and scalability veriication.” c. the Csrs use static routes to reach the loopback (lo0) address of router aG 1.1 and router aG 1.2 through the corresponding rsvp lsp, as conigured in the topic “Coniguring Intrasegment Mpls transport.” d. router aG 1.1 and router aG 1.2 use static routes to reach the loopback (lo0) addresses of the Csrs through the corresponding rsvp lsp, as conigured in the topic “Coniguring Intrasegment Mpls transport.” Configuring MP-BGP this example illustrates how to configure Mp-BGp on the cell site and aggregation routers in your network based on the topology in Figure 66. to configure routing options, protocols, and policy options for Mp-BGp: 1. Conigure Mp-IBGp on all Csrs to be peers with all aG 1 routers. 2. Conigure Mp-IBGp on all aG 1 routers to be peers with all Csrs. 3. Conigure Mp-eBGp on all aG 1 routers to be peers with all aG 3 routers. 4. Conigure Mp-eBGp on all aG 3 routers to be peers with all aG 1 routers. 5. Conigure BFD over these sessions with timers of 100 ms. the following configuration snippet shows the configuration of routing options and protocols for Mp-BGp on router Csr 1.2. You can use the same basic configuration for all the other Csrs. However, you must change the router-specific details to match a particular Csr. [edit] routing-options { static { route 1.1.5.1/32 { lsp-next-hop csr1.2_to_ag1.2; } route 1.1.4.1/32 { lsp-next-hop csr1.2_to_ag1.1; } } router-id 1.1.2.1; autonomous-system 64501; } protocols { bgp { group csr_ag1_rr { type internal; local-address 1.1.2.1; peer-as 64501; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; Copyright © 2013, Juniper Networks, Inc. 143 Design Guide - Juniper Networks universal and aggregation MBH 1.0 neighbor 1.1.4.1 { family inet-vpn { unicast; } } neighbor 1.1.5.1 { family inet-vpn { unicast; } } } } } the following configuration snippet shows the configuration of routing options, protocols, and policy options for Mp-IBGp on router aG 1.1. You can use the same basic configuration for all the other aG 1 routers. However, you must change the router-specific details to match a particular aG 1 router. [edit] routing-options { static { route 1.1.3.1/32 { lsp-next-hop ag1.1_to_csr1.1; } route 1.1.2.1/32 { lsp-next-hop ag1.1_to_csr1.2; } route 1.1.1.1/32 { lsp-next-hop ag1.1_to_csr1.3; } route 1.1.7.1/32 { lsp-next-hop ag1.1_to_csr1.4; } route 1.1.6.1/32 { lsp-next-hop ag1.1_to_csr1.5; } } router-id 1.1.4.1; autonomous-system 64501; } protocols { bgp { group csr_ag1_rr { type internal; local-address 1.1.4.1; family inet-vpn { unicast; } export [ NHS summarize ]; cluster 1.1.4.1; peer-as 64501; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; 144 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 neighbor neighbor neighbor neighbor neighbor 1.1.1.1; 1.1.2.1; 1.1.3.1; 1.1.6.1; 1.1.7.1; } } } policy-options { policy-statement NHS { term 10 { then { next-hop self; } } } policy-statement summarize { term 1 { from { route-ilter 192.0.0.0/13 exact; } then accept; } term 2 { from { route-ilter 192.0.0.0/13 orlonger reject; } } } } the following configuration snippet shows the Mp-eBGp configuration on router aG 1.1. You can use the same basic configuration for all the other aG 1 routers. However, you must change the router-specific details, such as the bgp local-address, to match a particular aG 1 router. [edit] protocols { bgp { group option_c_for_l3vpn { type external; local-address 1.1.4.1; peer-as 64502; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } multipath; neighbor 1.1.13.1 { multihop { ttl 64; } family inet-vpn { unicast; } } neighbor 1.1.14.1 { Copyright © 2013, Juniper Networks, Inc. 145 Design Guide - Juniper Networks universal and aggregation MBH 1.0 multihop { ttl 64; } family inet-vpn { unicast; } } } } } the following configuration snippet shows the configuration of Mp-eBGp for router aG 3.1. You can use the same basic configuration for all the other aG 3 routers. However, you must change the router-specific details, such as the bgp local-address, to match a particular aG 3 router. [edit] protocols { bgp { group option_c_for_l3vpn { type external; bfd-liveness-detection { minimum-interval 100; multiplier 3; no-adaptation; } neighbor 1.1.4.1 { multihop { ttl 64; } local-address 1.1.13.1; family inet-vpn { unicast; } peer-as 64501; } neighbor 1.1.5.1 { multihop { ttl 64; } local-address 1.1.13.1; family inet-vpn { unicast; } peer-as 64501; } } } } to verify your BGp and BFD setup: 1. verify that the BGp sessions are established; issue the show bgp neighbor neighbor-address command and check that the BFD sessions are up. specify the loopback-address of the neighbor for the neighbor-address option. 2. verify that the static routes are installed and have precedence over Is-Is routes; use the show route terse command. 3. From each router, use the ping host command to check that the ping takes the lsp path. specify the loopback address of the remote routers for the host option. 146 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring the Routing Instance for the Layer 3 VPN this example illustrates how to configure end-to-end layer 3 vpN services based on the network topology in Figure 67. a layer 3 vpN is a set of sites that share common routing information and whose common connectivity is controlled by a collection of policies. AS 64501 ACCESS eNodeB AS 64502 PRE-AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/1 10.21.0.2/24 ge-0/1/0 ge-1/0/2 10.21.2.2/24 ge-0/2/0 10.21.2.1/24 VLAN 1 xe-0/0/0.1 10.21.3.1/24 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.2/24 xe-0/0/0 10.22.2.1/24 ge-0/1/0 xe-0/0/2 10.23.3.1/24 xe-1/0/2 10.23.3.2/24 VLAN 2 ge-2/0/0 xe-0/0/0.2 10.22.0.1/24 xe-0/0/1 10.22.3.1/24 ge-0/2/0 10.21.0.1/24 xe-0/0/3 10.23.1.1/24 xe-1/1/3 10.23.2.2/24 xe-1/0/0 10.23.4.1/24 EPC CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 VLAN 1 ge-0/2/0 10.21.6.1/24 ge-0/2/0 10.21.5.1/24 ge-0/2/1 10.21.5.2/24 ge-0/1/0 NodeB AGGREGATION xe-0/0/0.1 10.21.3.2/24 ge-1/0/2 10.21.4.1/24 CSR 1.5 Io0:1.1.7.1/32 Io0:1.1.6.1/32 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.2/24 xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.4.2/24 CSR 1.4 xe-0/0/1 10.22.3.2/24 VLAN 2 ge-2/0/0 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.1/24 AG 1.2 xe-0/0/2 10.22.5.2/24 Io0:1.1.5.1/32 AG 1.4 xe-0/0/2 10.23.5.1/24 xe-0/0/0 10.22.4.1/24 AG 2.2 Io0:1.1.9.1/32 Io0:1.1.11.1/32 xe-1/1/3 10.23.5.2/24 AG 3.2 Io0:1.1.14.1/32 Default NHS MP-BGP L3 VPN MP-EBGP (Option C) RR (RFC 2547) U-turn L3 VRF L3 VPN VRF IP-Lookup Figure 67: End-to-End Layer 3 VPN Deployment to configure a routing instance for an end-to-end layer 3 vpN: 1. Conigure a vrF routing instance on all Csrs: a. Conigure uNIs (interfaces ge-0/1/0). b. Conigure the loopback interface (lo0.1). c. Conigure a layer 3 vpN routing instance. d. add the uNIs and the loopback (lo0.1) interface to the routing instance. the following configuration snippet shows the interface configuration for router CSR 1.2. You can use the same basic configuration for all the other Csrs. However, you must change the router-specific details to match a particular Csr. Copyright © 2013, Juniper Networks, Inc. µ47 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the vlaN configuration on an ethernet interface on router Csr 1.2: [edit] interfaces { ge-0/1/0 { vlan-tagging; encapsulation lexible-ethernet-services; unit 0 { vlan-id 1; family inet { address 183.1.1.1/24; } } unit 1 { vlan-id 2; family inet { address 183.1.2.1/24; } } unit 2 { vlan-id 3; family inet { address 183.1.3.1/24; } } } lo0 { unit 1 { family inet { address 1.1.2.100/32; } } } } the following configuration snippet shows the routing instance configuration for router Csr 1.2: [edit] routing-instances { csr_l3vpn { instance-type vrf; interface ge-0/1/0.0; interface ge-0/1/0.1; interface ge-0/1/0.2; interface lo0.1; route-distinguisher 100:1; vrf-target target:100:1; vrf-table-label; } } 2. Conigure all the aG 1 routers with a routing instance (previously referred to as a u-turn vrF ): a. Conigure the loopback interface (lo0.1). b. Conigure a layer 3 routing instance. c. add the loopback (lo0.1) interface to the routing instance. d. Conigure the routing instance with the vrf-table-label statement. 148 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the routing instance configuration for router aG 1.1. You can use the same basic configuration for all the other aG 1 routers. However, you must change the router-specific details, such as loopback lo0.1 family inet address, to match a particular aG 1 router. [edit] interfaces { lo0 { unit 1 { family inet { address 1.1.4.100/32; } } } } [edit] routing-instances { csr_l3vpn { instance-type vrf; interface lo0.1; route-distinguisher 100:1; vrf-target target:100:1; vrf-table-label; } } 3. Conigure all aG 3 routers with a routing instance: a. Conigure uNIs (interfaces ge-2/0/0). b. Conigure the loopback interface (lo0.1). c. Conigure a layer 3 vpN routing instance. d. add the loopback interface lo0.1. e. add uNIs. the following configuration snippet shows the interface configuration for router aG 3.1. You can use the same basic configuration for all the other aG 3 routers. However, you must change the router-specific details to match a particular aG 3 router. [edit] interfaces { ge-2/0/0 { vlan-tagging; encapsulation lexible-ethernet-services; unit 0 { vlan-id 1; family inet { address 113.1.1.1/24; } } unit 1 { vlan-id 2; family inet { address 113.1.2.1/24; } } unit 2 { vlan-id 3; family inet { Copyright © 2013, Juniper Networks, Inc. ¶49 Design Guide - Juniper Networks universal and aggregation MBH 1.0 address 113.1.3.1/24; } } } lo0 { unit 1 { family inet { address 1.1.13.100/32; } } } } the following configuration snippet shows the routing instance configuration for router aG 3.1. You can use the same basic configuration for all the other aG 3 routers. However, you must change the router-specific details to match a particular aG 3 router. [edit] routing-instances { l3vpn { instance-type vrf; interface ge-2/0/0.0; interface ge-2/0/0.1; interface ge-2/0/0.2; interface lo0.1; route-distinguisher 100:1; vrf-target target:100:1; vrf-table-label; routing-options { multipath { vpn-unequal-cost equal-external-internal; } } } } to verify your layer 3 vpN configuration: • on aG 1, aG 2, and aG 3 routers, issue the show route table l3vpn.inet.0 extensive command, and check the following routes: a. verify that the routes advertised from all Csrs are learnt on all aG 3 routers. b. verify that the routes are load-balanced according to multipath. c. verify that there are no vpNv4 routes on any aG 2 routers. d. verify that aG 1 routers receive only a summary route from aG 3 routers. e. verify that aG 1 routers receive all the routes from aG 1 routers. • on Crs routers, issue the show route table csr_l3vpn.inet.0 extensive command, and check the following routes: a. verify that all Csrs receive only a summary route. b. verify the label stack at each Csr. c. verify the number of routes and labels at each Csr. 150 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring Layer 2 VPN to Layer 3 VPN Termination Services this deployment scenario illustrates how to configure a layer 3 vpN in conjunction with a layer 2 pseudowire in the access segment. there are various reasons to use layer 2 pseudowire in the access segment and to stitch together layer 2 services with layer 3 services on preaggregation routers (aG 1 in this sample network topology). For example, it simplifies configuration on Csrs. the configuration is based on the network topology in Figure 68 and Figure 69, which you can use for the Hspa service profile and for the 4G lte service profile. VRRP Master ACCESS Logical Tunnel (lt) Interface PREAGGREGATION AGGREGATION AG 1.1 AG 3.1 3G MP-EBGP RNC Iub IP Iub IP ge-0/1/0 NodeB CSR 1.n MP-EBGP Iub IP AG 1.2 AG 3.2 L3 VPN L2 VPN Traffic Flow Connection at the Service Level Active PW Backup PW (not in hot standby) Figure 68: Layer 2 VPN to Layer 3 VPN Termination Figure 68 shows traffic flowing from the NodeB tower to the rNC over a pseudowire, Mp-eBGp, and a layer 3 vpN, providing an end-to-end service. a backup pseudowire provides redundancy. the network in Figure 68 has the following characteristics: • layer 2 pseudowires in the access segment between Csr and aG 1 routers (see the topic “Coniguring layer 2 pseudowires in the access segment”): - each Csr has multiple ethernet and vlaN pseudowires dual homed to aG 1 routers. - active and standby pseudowires are terminated on the aG 1.1 router and the aG 1.2 router, respectively. - each pseudowire uses a Gigabit ethernet interface on Csrs and a logical tunnel (lt) interface on aG 1 routers as pseudowire end points. • Inter-as layer 3 vpNs on all aG 1 and aG 3 routers (see the topic “Coniguring Inter-as layer 3 vpN”): - MB-eBGp is used to signal an Mpls label for the layer 3 vpN service and to distribute vrF routes between aG 1 and aG 3 routes across diferent autonomous systems. - a vrF instance is created on all aG 1 routers. this instance includes the loopback interface. - a vrF instance is created on all aG 3 routers. this instance includes the uNI and loopback interface. • a layer 2 pseudowire to layer 3 vpN termination on all aG 1 routers (see the topic “Coniguring a layer 2 pseudowire to layer 3 vpN termination”: - each aG 1 router has pseudowires (multiple) to each Csr with a logical tunnel (lt) interface at the pseudowire end. - pseudowires are terminated into a vrF routing instance at each aG 1 router by including the corresponding logical tunnel interfaces to the vrF instance. - a vrrp instance is used for virtual Ipv4 addressing assignment to the logical tunnel interfaces in the vrF routing instance. - a vrF instance is created on all aG 1 routers with the loopback interface (lo0) and the logical tunnel interfaces. Copyright © 2013, Juniper Networks, Inc. 151 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring Layer 2 Pseudowires in the Access Segment this example illustrates how to configure a pseudowire and layer 3 vpN based on the network topology in Figure 69. the following service level configuration relies on the configuration of intrasegment and intersegment Mpls transport described in the topics “Configuring Intrasegment Mpls transport” and “Configuring Intersegment Mpls transport.” AS 64501 ACCESS AS 64502 PRE-AGGREGATION AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 eNodeB ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/1 10.21.0.2/24 ge-0/1/0 ge-1/0/2 10.21.2.2/24 ge-0/2/0 10.21.2.1/24 VLAN 1 xe-0/0/0.1 10.21.3.1/24 ge-0/2/0 10.21.0.1/24 ge-0/1/0 CSR 1.3 Io0: 1.1.1.1/32 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 VLAN 2 VLAN 1 xe-0/0/0.1 10.21.3.2/24 Io0:1.1.7.1/32 Io0:1.1.6.1/32 PW xe-1/0/0 xe-1/1/3 10.23.4.1/24 10.23.2.2/24 xe-0/0/1 10.22.3.2/24 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.2/24 IS-IS Level 2 ge-1/0/2 10.21.4.1/24 CSR 1.5 T-LDP xe-0/0/3 10.23.1.1/24 ge-2/0/0 RNC xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.4.2/24 CSR 1.4 NodeB xe-1/0/2 10.23.3.2/24 VLAN 2 IS-IS Level 1 ge-0/1/0 xe-0/0/1 10.22.3.1/24 xe-0/0/0.2 10.22.0.1/24 xe-0/0/2 10.23.3.1/24 VRRP Groups ge-0/2/1 10.21.6.2/24 ge-0/2/0 10.21.6.1/24 ge-0/2/0 10.21.5.1/24 ge-0/2/1 10.21.5.2/24 xe-0/0/0 10.22.2.2/24 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.1/24 AG 1.2 xe-0/0/2 10.22.5.2/24 Io0:1.1.5.1/32 AG 1.4 xe-0/0/0 10.22.4.1/24 Io0:1.1.9.1/32 T-LDP xe-0/0/2 10.23.5.1/24 AG 2.2 ge-2/0/0 xe-1/1/3 10.23.5.2/24 AG 3.2 Io0:1.1.14.1/32 Io0:1.1.11.1/32 MP-EBGP (Option C) L3 VPN L3VPN Logical Tunnel (lt) Interface PW Termination in L3 VRF Figure 69: Deployment Scenario of Layer 2 VPN to Layer 3 VPN Termination to configure a pseudowire and layer 3 vpN based on the network in Figure 69: 1. Conigure all Csrs with layer 2 pseudowires to router aG 1.1 and router aG 1.2: a. Conigure uNIs with which to originate the layer 2 vpN. b. Conigure a layer 2 pseudowire from each Csr to router aG 1.1 and router aG 1.2 by using targeted lDp (t-lDp) signaling. c. Conigure active and backup pseudowires to add redundancy. Note: Do not enable hot-standby because it does not work correctly with pseudowire to layer 3 termination. 152 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the interface configuration for router Csr 1.2. You can use these configuration snippets as the basis for the interface and layer 2 protocol configurations of all other Csrs—Csr 1.1, Csr 1.3, Csr 1.4, and Csr 1.5. However, you must change the router-specific details to match a particular Csr: [edit] interfaces { ge-0/1/0 { lexible-vlan-tagging; encapsulation lexible-ethernet-services; unit 10 { encapsulation vlan-ccc; vlan-id 20; family ccc; } unit 11 { encapsulation vlan-ccc; vlan-id 21; family ccc; } [...Output truncated...] unit 19 { encapsulation vlan-ccc; vlan-id 29; family ccc; } } the following configuration snippet shows the layer 2 configuration for router Csr 1.2: [edit] protocols { l2circuit { neighbor 1.1.4.1 { interface ge-0/1/0.10 { virtual-circuit-id 20; backup-neighbor 1.1.5.1; } interface ge-0/1/0.11 { virtual-circuit-id 21; backup-neighbor 1.1.5.1; } interface ge-0/1/0.12 { virtual-circuit-id 22; backup-neighbor 1.1.5.1; } interface ge-0/1/0.13 { virtual-circuit-id 23; backup-neighbor 1.1.5.1; } interface ge-0/1/0.14 { virtual-circuit-id 24; backup-neighbor 1.1.5.1; } interface ge-0/1/0.15 { virtual-circuit-id 25; backup-neighbor 1.1.5.1; } Copyright © 2013, Juniper Networks, Inc. 153 Design Guide - Juniper Networks universal and aggregation MBH 1.0 interface ge-0/1/0.16 { virtual-circuit-id 26; backup-neighbor 1.1.5.1; } interface ge-0/1/0.17 { virtual-circuit-id 27; backup-neighbor 1.1.5.1; } interface ge-0/1/0.18 { virtual-circuit-id 28; backup-neighbor 1.1.5.1; } interface ge-0/1/0.19 { virtual-circuit-id 29; backup-neighbor 1.1.5.1; } } } } 2. Conigure the aG 1 routers with layer 2 pseudowires to the Csrs in the access ring: a. enable tunneling services for the packet forwarding engine (pFe) of all aG 1 routers. Note that in the sample topology we use an MX platform that has only one pFe. In an actual network, you can use other MX series platforms with multiple pFes. adjust your coniguration according to the number of pFes in the router chassis. b. Conigure a pair of logical tunnel (lt) interfaces for each pseudowire terminated into the vrF. i. Conigure the irst logical tunnel (lt) interface of each pair with vlaN-CCC encapsulation, and use it as the end of the layer 2 pseudowire. ii. Conigure the second logical tunnel (lt) interface of each pair with the inet family address. use the Ip address from the range reserved for the NodeB or eNodeB peering (60.60.0.0/16 in our sample topology). iii. Conigure a second logical tunnel interface with a vrrp group, and assign to it a virtual Ip address. use the same virtual Ip address for the adjacent logical tunnel interfaces used to terminate active and backup pseudowires, respectively, on router aG 1.1 and router aG 1.2. c. Conigure layer 2 circuits on the aG 1 routers to the routers in the Csr ring by using lDp signaling. Note: In an actual network, the number of circuits could be from 1 to 10, one circuit per mobile network service—such as Iub, s1, s1-MMe, X2—or per mobile network management. the following configuration snippet shows the tunnel services configuration for the chassis on router aG 1.1. You can use the configuration as the basis for the tunnel services configurations of all other aG 1 routers—aG 1.2, aG 1.3, and aG 1.4. However, you must change the router-specific details to match a particular Csr: [edit] chassis { fpc 1 { pic 2 { tunnel-services { bandwidth 1g; } } } } 154 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the logical tunnel interface configuration for router aG 1.1. You can use the same basic configuration for all the other aG 1 routers. However, you must change the router-specific details (like family inet address) to match a particular aG 1 router: interfaces { lt-1/2/10 { logical-tunnel-options { per-unit-mac-disable; } unit 10 { encapsulation vlan-ccc; vlan-id 10; peer-unit 11; family ccc; } unit 11 { encapsulation vlan; vlan-id 10; peer-unit 10; family inet { address 60.60.1.1/24 { vrrp-group 10 { virtual-address 60.60.1.10; } } } } unit 12 { encapsulation vlan-ccc; vlan-id 11; peer-unit 13; family ccc; } unit 13 { encapsulation vlan; vlan-id 11; peer-unit 12; family inet { address 60.60.2.1/24 { vrrp-group 11 { virtual-address 60.60.2.10; } } } } [...Output truncated...] # Circuits to CRS1.1 skipped for brevity unit 108 { encapsulation vlan-ccc; vlan-id 59; peer-unit 109; family ccc; } unit 109 { encapsulation vlan; vlan-id 59; peer-unit 108; family inet { address 60.60.50.1/24 { Copyright © 2013, Juniper Networks, Inc. 155 Design Guide - Juniper Networks universal and aggregation MBH 1.0 vrrp-group 59 { virtual-address 60.60.50.10; } } } } } } the following configuration snippet shows the layer 2 circuit configuration for router aG 1.1 and router aG 1.2: [edit] protocols { l2circuit { neighbor 1.1.1.1 { [...Output truncated...] # } neighbor 1.1.2.1 { interface lt-1/2/10.30 virtual-circuit-id } interface lt-1/2/10.32 virtual-circuit-id } interface lt-1/2/10.34 virtual-circuit-id } interface lt-1/2/10.36 virtual-circuit-id } interface lt-1/2/10.38 virtual-circuit-id } interface lt-1/2/10.40 virtual-circuit-id } interface lt-1/2/10.42 virtual-circuit-id } interface lt-1/2/10.44 virtual-circuit-id } interface lt-1/2/10.46 virtual-circuit-id } interface lt-1/2/10.48 virtual-circuit-id } } [...Output truncated...] # neighbor 1.1.7.1 { interface lt-1/2/10.90 virtual-circuit-id } interface lt-1/2/10.92 virtual-circuit-id } 156 Circuits to CRS1.1 were skipped for brevity # Circuits to CSR1.2 { 20; { 21; { 22; { 23; { 24; { 25; { 26; { 27; { 28; { 29; Four neighbors skipped for brevity { 50; { 51; Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 interface lt-1/2/10.94 { virtual-circuit-id 52; } interface lt-1/2/10.96 { virtual-circuit-id 53; } interface lt-1/2/10.98 { virtual-circuit-id 54; } interface lt-1/2/10.100 { virtual-circuit-id 55; } interface lt-1/2/10.102 { virtual-circuit-id 56; } interface lt-1/2/10.104 { virtual-circuit-id 57; } interface lt-1/2/10.106 { virtual-circuit-id 58; } interface lt-1/2/10.108 { virtual-circuit-id 59; } } } } Configuring Inter-AS Layer 3 VPN to configure an inter-as layer 3 vpN: 1. Conigure MB-eBGp on aG 1 and aG 3 routers to signal Mpls labels for the layer 3 vpN service and to distribute vrF routes between aG 1 and aG 3 routes across diferent autonomous systems. (For details, see the topic “Coniguring Mp-BGp.”) 2. Conigure the vrF routing instance on each aG 3 router: a. Conigure the vrF routing instance. b. add the loopback (lo0.1) interface to the vrF routing instance. c. add the uNI to the routing instance. d. (optional) Conigure the Is-Is or BGp protocols between the uNI and the customer-facing interface. the following configuration snippet shows the vrF routing instance configuration for router aG 3.1. You can use the same basic configuration for all the other aG 3 routers. However, you must change the router-specific details to match a particular aG 3 router. [edit] interfaces { ge-2/0/0 { vlan-tagging; encapsulation lexible-ethernet-services; unit 0 { vlan-id 1; family inet { address 113.1.1.1/24; } } } lo0 { Copyright © 2013, Juniper Networks, Inc. ·57 Design Guide - Juniper Networks universal and aggregation MBH 1.0 unit 1 { family inet { address 1.1.13.100/32; } } } } [edit] routing-instances { csr_l3vpn { instance-type vrf; interface ge-2/0/0.0; interface lo0.1; route-distinguisher 200:200; vrf-target target:200:200; routing-options { static { route 1.1.100.100/32 next-hop 26.0.0.2; } router-id 1.1.13.100; autonomous-system 64502; } protocols { bgp { group vpn { type external; local-address 26.0.0.1; peer-as 65003; local-as 64502; neighbor 26.0.0.2; } } } } } Configuring a Layer 2 Pseudowire to Layer 3 VPN Termination to configure a layer 2 pseudowire to terminate at a layer 3 vpN: 1. Conigure the vrF routing instance on each aG 1 router to the routers in the Csr ring: a. Conigure the vrF routing instance. b. add loopback interface (lo0.1) to the vrF routing instance. c. add the logical tunnel (lt) interfaces (layer 3 peers) to the routing instance. the following configuration snippet shows the routing instance configuration for router aG 1.1. You can use the same basic configuration for all the other aG 1 routers. However, you must change the router-specific details to match a particular aG 1 router. [edit] policy-options { policy-statement vpn1-export { term 20 { from protocol direct; then { metric add 100; community add vpn4; 158 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 community add from_ibgp; accept; } } } community from_ibgp members target:200:2001; community vpn4 members target:200:200; } routing-instances { csr_l3vpn { instance-type vrf; interface lt-1/2/10.11; [...Output truncated...] interface lt-1/2/10.29; interface lt-1/2/10.31; interface lt-1/2/10.33; interface lt-1/2/10.35; interface lt-1/2/10.37; interface lt-1/2/10.39; [...Output truncated...] interface lt-1/2/10.127; interface lt-1/2/10.129; interface lo0.1; route-distinguisher 200:200; vrf-export vpn1-export; vrf-target target:200:200; vrf-table-label; } } to verify your pseudowire and layer 3 vpN setup: 1. verify that all pseudowires are established: a. on all Csr and aG 1 routers, issue the show l2circuit connection command. 2. on aG 1 and aG 3 routers, issue the show route table csr_13vpn.inet3 command to verify the following routes: a. Check that the csr_l3vpn routing instance advertises all the routes learned from the Csrs to the aG 3 routers. b. Check that the csr_l3vpn routing instance receives all the routes from all the aG 1 routers. c. Check that the csr_l3vpn routing instance advertises only a default or aggregate route towards all the aG 1 routers. Copyright © 2013, Juniper Networks, Inc. ¸59 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring a Layer 2 VPN to VPLS Termination Service a layer 2 vpN forwards packets in a point-to-point fashion only. For vpls traffic, packets can traverse the network in a point-to-multipoint fashion, meaning that a packet originating from a customer edge router can broadcast to all the provider edge routers participating in the vpls routing instance. the packet traverses the service provider’s network over an Mpls label-switched path (lsp), allowing you to connect geographically dispersed ethernet laN sites to each other across an Mpls backbone. the paths carrying vpls traffic between each pe router participating in a routing instance are called pseudowires. the next sample configuration is based on the network topology in Figure 70 and Figure 71, which you can use for the Hspa and 4G lte service profiles. VPLS Hub IP/MPLS ACCESS PREAGGREGATION AGGREGATION AG 1.1 AG 3.1 3G T-LDP RNC Iub Ethernet Iub Ethernet NodeB T-LDP CSR 1.n Iub Ethernet AG 1.2 AG 3.2 VPLS L2 VPN Traffic Flow Connection at the Service Level Active PW Backup PW (Standby) Figure 70: Layer 2 VPN to VPLS Termination Figure 70 shows traffic flowing from the tower to the rNC over a pseudowire in the Ip/Mpls access network, across a unicast targeted lDp (t-lDp) session, and a vpls routing instance, providing an end-to-end service. a backup pseudowire provides redundancy. the network in Figure 70 has the following characteristics: 1. a pseudowire on all Csrs in the access segment. see the topic “Coniguring a pseudowire in the access segment (vpls spoke)”: • each router in the Csr ring has multiple ethernet or vlaN pseudowires to the dual homed aG 1 routers. • each pseudowire has an active and standby termination on router aG 1.1 and router aG 1.2. • the pseudowire status type, length, variable (tlv) feature is enabled for all pseudowires. the pseudowire tlv is used to communicate the status of a pseudowire back and forth between Csr and aG 1 routers. 2. a vpls hub in the preaggregation segment on all aG 1 routers. see the topic “Coniguring a vpls Hub in the preaggregation segment”: • each aG 1 router has multiple pseudowires to each router in the Csr ring. • the status tlv is enabled on these pseudowires. • Mesh groups are used to map the pseudowire to the vpls instance. 3. an end-to-end inter-as with aG 1 and aG 3 routers as vpls service nodes. see the topic “Coniguring end-to-end Interautonomous system vpls.” 4. a vpls routing instance conigured on all aG 3 routers that receive all the pseudowire tlv mapping messages sent from all the aG 1 routers. ¹60 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 ¼onfiguring a Pseudowire in the Access Segment (VPLS Spoke) this example illustrates how to configure a pseudowire in the access segment based on the network topology in Figure 71. AS 64501 ACCESS AS 64502 PRE-AGGREGATION AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/2/1 10.21.0.2/24 ge-0/1/0 ge-1/0/2 10.21.2.2/24 ge-0/2/0 10.21.2.1/24 VLAN 1 xe-0/0/0.1 10.21.3.1/24 ge-0/2/0 10.21.0.1/24 ge-0/1/0 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.2/24 xe-0/0/0 10.22.2.1/24 VLAN 2 xe-0/0/1 10.22.3.1/24 xe-0/0/0.2 10.22.0.1/24 xe-0/0/2 10.23.3.1/24 xe-1/0/2 10.23.3.2/24 xe-0/0/3 10.23.1.1/24 ge-2/0/0 xe-1/1/3 10.23.2.2/24 xe-1/0/0 10.23.4.1/24 RNC CSR 1.3 Io0: 1.1.1.1/32 VLAN 1 ge-0/2/1 10.21.6.2/24 xe-0/0/0.1 10.21.3.2/24 VLAN 2 ge-0/1/0 ge-0/2/1 10.21.4.2/24 ge-1/0/2 10.21.4.1/24 CSR 1.4 CSR 1.5 Io0:1.1.7.1/32 Io0:1.1.6.1/32 NodeB T-LDP PW xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.2/24 IS-IS Level 2 IS-IS Level 1 ge-0/2/0 10.21.6.1/24 ge-0/2/0 10.21.5.1/24 ge-0/2/1 10.21.5.2/24 xe-0/0/1 10.22.3.2/24 xe-0/0/0.2 10.22.0.2/24 AG 1.2 xe-0/0/2 10.22.5.2/24 Io0:1.1.5.1/32 T-LDP xe-0/0/2 10.23.5.1/24 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.1/24 AG 1.4 xe-0/0/0 10.22.4.1/24 Io0:1.1.9.1/32 AG 2.2 ge-2/0/0 xe-1/1/3 10.23.5.2/24 Io0:1.1.11.1/32 AG 3.2 Io0:1.1.14.1/32 MP-EBGP (Option C) VPLS VPLS PW Termination in VPLS on LSI Interface Figure 71: Deployment Scenario of Layer 2 VPN to VPLS Termination to configure Csrs with a pseudowire to aG 1 routers: 1. Conigure a layer 2 pseudowire between each Csr to all the aG 1 routers: a. Conigure uNIs to originate the layer 2 pseudowire. use diferent vlaN tags to split between mobile services if necessary, such as s1, s1-MMe, X2, oaM. b. Conigure a layer 2 pseudowire for each service uNI from each Csr in the access ring to the aG 1.1, aG 1.2 routers by using t-lDp signaling. use a diferent virtual circuit ID for each layer 2 pseudowire. c. Conigure active and standby backup pseudowires to add redundancy. Copyright © 2013, Juniper Networks, Inc. º»º Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the interface configuration for router Csr 1.1. You can use this snippet as the basis for the interface configuration of all other routers in the Csr ring. However, you must change the routerspecific details to match a particular Csr. [edit] interfaces { ge-0/1/0 { vlan-tagging; encapsulation lexible-ethernet-services; unit 0 { encapsulation vlan-ccc; vlan-id 1; } unit 1 { encapsulation vlan-ccc; vlan-id 2; } unit 2 { encapsulation vlan-ccc; vlan-id 3; } } } the following configuration snippet shows the layer 2 pseudowire configuration for router Csr 1.1. You can use this configuration as the basis for the protocol configuration of all other Csrs. However, you must change the routerspecific details to match a particular Csr. [edit] protocols { l2circuit { neighbor 1.1.4.1 { interface ge-0/1/0.0 { virtual-circuit-id 12; pseudowire-status-tlv; backup-neighbor 1.1.5.1 { virtual-circuit-id 13; standby; } } interface ge-0/1/0.1 { virtual-circuit-id 22; pseudowire-status-tlv; backup-neighbor 1.1.5.1 { virtual-circuit-id 23; standby; } } interface ge-0/1/0.2 { virtual-circuit-id 32; pseudowire-status-tlv; backup-neighbor 1.1.5.1 { virtual-circuit-id 33; standby; } } } } } 162 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Àonfiguring a VPLS Hub in the Preaggregation Segment to configure a vpls hub in the preaggregation segment: 1. Conigure a vpls hub on all aG 1 routers: a. Conigure a vpls routing instance on the aG 1.1 router and the aG 1.2 router. b. Conigure vpls routing instance peers to span across the following routers: aG 1.1, aG 1.2, aG 3.1, and aG 3.2. c. Conigure mesh groups within the vpls instance for each mobile network service (such as Iub, s1, s1-MMe, and X2) with the routers in the Csr ring as vpls spokes. use the same vpls ID for each mesh group, as you did for the corresponding virtual-circuit-id in the layer 2 vpNs on the vpls spokes (Csrs). For details, see the topic “Coniguring a pseudowire in the access segment (vpls spoke).” d. add the local-switching statement, which allows you to terminate multiple layer 2 circuit pseudowires at a single vpls mesh group (essential for X2 connectivity). the following configuration snippet shows the dynamic profiles and vpls routing instance (virtual-switch) configuration for router aG 1.1. You can use this configuration as the basis for the routing instance configuration of all other aG 1 routers. However, you must change the router-specific details to match a particular aG 1 router. [edit] dynamic-proiles { data_proile { interfaces { “$junos-interface-ifd-name” { unit “$junos-underlying-interface-unit” { family bridge { interface-mode trunk; vlan-id-list 12; } } } } } oam_proile { interfaces { “$junos-interface-ifd-name” { unit “$junos-underlying-interface-unit” { family bridge { interface-mode trunk; vlan-id-list 22; } } } } } extra_proile { interfaces { “$junos-interface-ifd-name” { unit “$junos-underlying-interface-unit” { family bridge { interface-mode trunk; vlan-id-list 32; } } } } } } routing-instances { vs_1 { Copyright © 2013, Juniper Networks, Inc. ½¾¿ Design Guide - Juniper Networks universal and aggregation MBH 1.0 instance-type virtual-switch; protocols { vpls { no-tunnel-services; vpls-id 4514; mac-lush; neighbor 1.1.5.1; neighbor 1.1.14.1; neighbor 1.1.13.1; mesh-group data_pw { vpls-id 12; local-switching; neighbor 1.1.1.1 { associate-proile data_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.2.1 { associate-proile data_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.7.1 { associate-proile data_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.6.1 { associate-proile data_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.3.1 { associate-proile data_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } } mesh-group extra_pw { vpls-id 32; local-switching; neighbor 1.1.1.1 { associate-proile extra_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.2.1 { associate-proile extra_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.7.1 { associate-proile extra_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.6.1 { associate-proile extra_proile; 164 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.3.1 { associate-proile extra_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } } mesh-group oam_pw { vpls-id 22; local-switching; neighbor 1.1.1.1 { associate-proile oam_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.2.1 { associate-proile oam_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.7.1 { associate-proile oam_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.6.1 { associate-proile oam_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } neighbor 1.1.3.1 { associate-proile oam_proile; encapsulation-type ethernet-vlan; no-vlan-id-validate; } } } } bridge-domains { data_vlan { domain-type bridge; vlan-id 1; } extra_vlan { domain-type bridge; vlan-id 3; } oam_vlan { domain-type bridge; vlan-id 2; } } } } Copyright © 2013, Juniper Networks, Inc. ÁÂà Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring End-to-End Inter-Autonomous System VPLS to configure end-to-end inter-as vpls: 1. Conigure vpls on all the aG 3 routers: a. Conigure a vpls instance on router aG 3.1 and router aG 3.2. b. Conigure vpls instance peers to span across the following routers—aG 1.1, aG 1.2, aG 3.1, and aG 3.2. use the same vpls ID as for the vpls instance on the aG 1.1 and aG 1.2 routers. the following configuration snippet shows the configuration of vlaN encapsulation and ID of interfaces for router aG 3.1. You can use this configuration as the basis for the vlaN encapsulation and ID configuration for router aG 3.2. [edit] interfaces { ge-2/0/0 { lexible-vlan-tagging; encapsulation lexible-ethernet-services; unit 0 { encapsulation vlan-vpls; vlan-id 1; } unit 1 { encapsulation vlan-vpls; vlan-id 2; } } } the following configuration snippet shows the configuration of lDp for router aG 3.1. You can use the configuration as the basis for the configuration for router aG 3.2. protocols { ldp { interface lo0.0; } } the following configuration snippet shows the configuration of a vpls routing instance for router aG 3.1. You can use the configuration as the basis for the vpls routing instance configuration for router aG 3.2. routing-instances { vpls_1 { instance-type vpls; vlan-id all; interface ge-2/0/0.0; interface ge-2/0/0.1; protocols { vpls { no-tunnel-services; mac-lush; mesh-group ag1_spoke { vpls-id 4514; neighbor 1.1.4.1; neighbor 1.1.5.1; neighbor 1.1.14.1; } } } } } 166 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring ATM Pseudowire and SAToP/CESoPSN Services an asynchronous transfer Mode (atM) pseudowire acts as a layer 2 circuit or service, which allows the migration of atM services to an Mpls packet-switched network without having to provision the atM subscriber or customer edge device. structure-agnostic time-division multiplexing (tDM) over packet (satop), as defined in rFC 4553, StructureAgnostic TDM over Packet (SAToP) is used for pseudowire encapsulation for tDM bits (t1, e1). the encapsulation disregards any structure imposed on the t1 and e1 streams, in particular the structure imposed by standard tDM framing. Circuit emulation service over packet-switched Network (CesopsN), is a method of encapsulating tDM signals into CesopsN packets, and in the reverse direction, de-encapsulating CesopsN packets back into tDM signals. this configuration is based on the network topology in Figure 72, and can be used for the 3G and 2G service profiles. AS 64501 ACCESS PRE-AGGREGATION Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-1/0/2 10.21.2.2/24 ge-0/2/0 10.21.2.1/24 ge-0/2/1 10.21.0.2/24 ge-0/2/0 10.21.0.1/24 ds-0/0/0:1 e1-0/0/1 e1-0/0/10 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.2/24 xe-0/0/0 10.22.2.1/24 ds-1/2/5:1 e1-1/2/10 e1-1/2/6 at-0/0/16 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 ds-0/0/3:1 e1-0/0/1 e1-0/0/10 AGGREGATION xe-0/0/1 10.21.3.1/24 xe-0/0/2 10.22.0.1/24 xe-0/0/1 10.21.3.2/24 xe-0/0/2 10.22.0.2/24 at-1/2/0 RNC/ BSC xe-0/0/1 10.22.3.1/24 xe-0/0/1 10.22.3.2/24 ds-1/2/0:1 e1-1/2/10 e1-1/2/1 ge-0/2/0 10.21.6.1/24 ge-0/2/0 10.21.5.1/24 ge-0/2/1 10.21.5.2/24 ge-0/2/1 10.21.4.2/24 ge-1/0/2 10.21.4.1/24 CSR 1.4 CSR 1.5 Io0:1.1.7.1/32 Io0:1.1.6.1/32 xe-0/0/0 10.22.4.2/24 xe-0/0/2 10.22.5.1/24 AG 1.2 xe-0/0/2 10.22.5.2/24 Io0:1.1.5.1/32 AG 1.4 xe-0/0/0 10.22.4.1/24 Io0:1.1.9.1/32 AG 2.2 Io0:1.1.11.1/32 T-LDP (For TDM PW) T-LDP (For ATM PW Signaling) ATM ATM ATM PW3 CESoPSN/ SAToP TDM PW CESoPSN/ SAToP Figure 72: Deployment of SAToP and CESoPSN Figure 72 shows virtual atM (at) interfaces, channelized (ds) interfaces, and e1 (e1) interfaces connecting the raN with the Csrs Csr 1.3 and Csr 1.4. the following configuration relies on configuration of intrasegment and intersegment Mpls transport, as shown in the topics “Configuring Intrasegment Mpls transport” and “Configuring Intersegment Mpls transport.” Configuring ATM and TDM Transport Pseudowire End-to-End to configure an atM and tDM pseudowire on router Csr 1.3 and router Csr 1.4: 1. Conigure the physical properties of the channelized e1 (ce1) interfaces, and deine the NxDs0 and e1 interfaces used for tDM circuit emulation services. 2. Conigure the encapsulation type for Ds0 and e1 interfaces (cesopsn or satop). 3. Conigure inverse multiplexing for atM (IMa) on router Csr 1.3 and router Csr 1.4. 4. Conigure pseudowire layer 2 circuits for each ds0, e1, and virtual atM (at) interface. Copyright © 2013, Juniper Networks, Inc. Ä67 Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the chassis and interfaces configuration for router Csr 1.3. You can use the configuration as the basis for the routing instance configuration of router Csr 1.4. However, you must change the router-specific details to match router Csr 1.4. [edit] chassis { fpc 0 { pic 0 { framing e1; aggregated-devices { ima { device-count 1; } } } } } [...Output truncated...] interfaces { ce1-0/0/0 { partition 1 timeslots 1-2 interface-type ds; } ds-0/0/0:1 { encapsulation cesopsn; unit 0; } ce1-0/0/1 { no-partition interface-type e1; } e1-0/0/1 { encapsulation satop; unit 0; } ce1-0/0/10 { no-partition interface-type e1; } e1-0/0/10 { encapsulation satop; unit 0; } ce1-0/0/15 { no-partition interface-type e1; } e1-0/0/15 { ima-link-options group-id 16; encapsulation ima; } at-0/0/16 { atm-options { vpi 0; } unit 0 { encapsulation atm-ccc-cell-relay; vci 0.100; } } } 168 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the layer 2 circuit configuration for router Csr 1.3. You can use the configuration as the basis for the layer 2 circuit configuration of router Csr 1.4. However, you must change the routerspecific details to match router Csr 1.4. [edit] protocols { l2circuit { /* Peering with AG1.1/AG2.1 to build TDM pseudowire */ neighbor 1.1.4.1 { # AG1.1 preix included in the dod_preix preix_list, see the topic “Coniguring LDP-DOD.” interface ds-0/0/0:1.0 { virtual-circuit-id 10; backup-neighbor 1.1.5.1 { standby; } } interface e1-0/0/1.0 { virtual-circuit-id 20; backup-neighbor 1.1.5.1 { standby; } } interface e1-0/0/10.0 { virtual-circuit-id 14; backup-neighbor 1.1.5.1 { standby; } } } neighbor 1.1.10.1 { # AG2.1 preix included in the dod_preix preix-list, see the topic “Coniguring LDP-DOD.” interface at-0/0/16.0 { virtual-circuit-id 100; } } } } to configure a tDM pseudowire on router aG 1.1 and router aG 1.2: 1. Conigure the physical properties of the channelized e1 (ce1) interfaces and deine NxDs0 and e1 interfaces used for tDM circuit emulation services. 2. Conigure the encapsulation type for Ds0 and e1 interfaces (cesopsn or satop). 3. Conigure pseudowire layer 2 circuits for each ds0 and e1 interface. the following configuration snippet shows the chassis and interface configuration for router aG 1.1. You can use the configuration as the basis for the chassis and interface configuration of router aG 1.2. However, you must change the router-specific details to match router aG 1.2. [edit] chassis { fpc 1 { pic 2 { framing e1; } } } [...Output truncated...] Copyright © 2013, Juniper Networks, Inc. Å69 Design Guide - Juniper Networks universal and aggregation MBH 1.0 interfaces { ce1-1/2/5 { partition 1 timeslots 1-2 interface-type ds; } ds-1/2/5:1 { encapsulation cesopsn; unit 0; } ce1-1/2/6 { no-partition interface-type e1; } e1-1/2/6 { encapsulation satop; unit 0; } ce1-1/2/10 { no-partition interface-type e1; } e1-1/2/10 { encapsulation satop; unit 0; } } the following configuration snippet shows the layer 2 circuit configuration for router aG 1.1. You can use the configuration as the basis for the layer 2 circuit configuration of router aG 1.2. However, you must change the routerspecific details to match router aG 1.2. [edit] protocols { l2circuit { neighbor 1.1.1.1 { interface ds-1/2/5:1.0 { virtual-circuit-id 10; } interface e1-1/2/6.0 { virtual-circuit-id 20; } interface e1-1/2/10.0 { virtual-circuit-id 14; } } } } to configure an atM pseudowire on router aG 2.1: 1. Conigure physical and logical interfaces for the atM interfaces on router aG 2.1. 2. Conigure pseudowire layer 2 circuits for each atM (at) interface from router aG 3.1 router to router Csr 1.3. 170 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 the following configuration snippet shows the interfaces configuration for router aG 2.1: [edit] interfaces { at-1/2/0 { atm-options { vpi 0; } unit 0 { encapsulation atm-ccc-cell-relay; vci 0.100; } } at-1/2/1 { atm-options { vpi 0; } unit 0 { encapsulation atm-vc-mux; vci 0.100; family inet { address 111.1.1.2/24; } } } } the following configuration snippet shows the layer 2 circuit configuration for router aG 2.1: [edit] protocols { l2circuit { neighbor 1.1.1.1 { interface at-1/2/0.0 { virtual-circuit-id 100; } } } } 3. verify your atM pseudowire, satop, and CesopsN coniguration; issue the show l2circuit connection command, and check that all layer 2 circuits are established. Copyright © 2013, Juniper Networks, Inc. 171 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring Timing and Synchronization the timing and synchronization configuration described in this chapter is independent of any particular deployment scenario for a service level – 4G lte, Hspa, 3G, 2G—or any protocols at the transport level—ospF, Is-Is, rsvp, BGp-lu, or lDp DoD—which means that you can use this configuration in any of these deployment scenarios. to propagate timing and synchronization from the grandmaster to eNodeB, NodeB, or Bts across the mobile backhaul (MBH) network, you can choose between the following protocols: • Ieee 1588v2 precision timing protocol (ptp) • synchronous ethernet Configuring PTP Timing the configuration in this deployment scenario is based on the network topology in Figure 73. You can use this configuration in scenarios with 4G lte or Hspa mobile networks. eNodeB CSR 1.2 CSR 1.1 ge-0/2/0 10.21.1.2/24 ge-0/2/0 10.21.1.1/24 ge-0/1/0 AG 1.1 ge-0/2/0 10.21.2.1/24 ge-1/0/2 10.21.2.2/24 ge-0/2/1 10.21.0.2/24 ge-1/0/3 10.1.1.1/24 xe-0/0/0.1 10.21.3.1/24 xe-0/0/0.2 10.22.1.1/24 xe-0/0/0.1 10.21.3.2/24 xe-0/0/0.2 10.22.0.2/24 1588v2 Grandmaster ge-0/2/1 10.21.0.1/24 ge-0/1/0 CSR 1.3 ge-0/2/1 10.21.6.2/24 ge-0/2/0 10.21.6.1/24 ge-0/1/0 NodeB CSR 1.4 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 ge-0/2/0 10.21.4.0/24 CSR 1.5 ge-0/2/0 10.22.4.1/24 AG 1.2 Primary 1588v2 Source Secondary 1588v2 Source Figure 73: PTP Design Overview the network example in Figure 73 includes only ptp over Ipv4. the aG routers are the ptp source and the Csrs are the ptp clients. each Csr has interfaces configured to receive synchronization from either aG 1.1 or aG 1.2. Because a Csr uses only one source at any given time, the Csr selects the best or nearest source for the ptp packets. the solid and dashed lines represent the ptp sessions established between the aG routers and the Csrs. the solid lines represent the active ptp sessions. the dashed lines represent the backup ptp sessions. this network configuration has the following characteristics: 1. the grandmaster (GM) is connected to router aG 1.1. 2. router aG 1.1 acts in boundary clock mode. 3. router aG 1.2 is an Ieee 1588v2 slave to router aG 1.1 and acts in boundary clock mode. 4. each Csr acts in boundary clock mode with the following characteristics: a. a Gigabit ethernet interface facing router aG 1.1 conigured as an Ieee 1588v2 slave, with router aG 1.1 router as the Ieee 1588v2 master. b. a Gigabit ethernet interface facing router aG 1.2 conigured as an Ieee 1588v2 slave, with router aG 1.2 as the Ieee 1588v2 master. c. Interface ge-0/1/0.0 conigured as the ptp master, providing synchronization to eNodeB or NodeB. 172 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 to configure ptp timing: 1. Conigure router aG 1.1 and router aG 1.2 as a boundary clocks, with the Ipv4 ptp grandmaster located behind router aG 1.1: a. Conigure router aG 1.1 with interfaces acting as ptp slaves. b. Conigure router aG 1.1 as a ptp master for all Ieee 1588v2 peers—all Csrs and router aG 1.2. the following configuration snippet shows the ptp configuration for router aG 1.1: [edit] protocols { ptp { clock-mode boundary; domain 0 slave { delay-request -6; interface ge-1/0/3.0 { unicast-mode { transport ipv4; clock-source 10.1.1.2 local-ip-address 10.1.1.1; } } } master { interface ge-1/0/2.0 { unicast-mode { transport ipv4; clock-client 10.21.2.1/32 local-ip-address 10.21.2.2; clock-client 10.21.1.1/32 local-ip-address 10.21.2.2; clock-client 10.21.0.1/32 local-ip-address 10.21.2.2; clock-client 10.21.6.1/32 local-ip-address 10.21.2.2; clock-client 10.21.5.1/32 local-ip-address 10.21.2.2; } } interface xe-0/0/0.1 { unicast-mode { transport ipv4; clock-client 10.21.3.2/32 local-ip-address 10.21.3.1; } } } } } the following configuration snippet shows the ptp configuration for router aG 1.2: [edit] protocols { ptp { clock-mode boundary; slave { delay-request -6; interface xe-0/0/0.1 { unicast-mode { transport ipv4; clock-source 10.21.3.1 local-ip-address 10.21.3.2; } } Copyright © 2013, Juniper Networks, Inc. 173 Design Guide - Juniper Networks universal and aggregation MBH 1.0 } master { interface ge-1/0/2.0 { unicast-mode { transport ipv4; clock-client 10.21.4.2/32 clock-client 10.21.5.2/32 clock-client 10.21.6.2/32 clock-client 10.21.0.2/32 clock-client 10.21.1.2/32 } } } local-ip-address local-ip-address local-ip-address local-ip-address local-ip-address 10.21.4.1; 10.21.4.1; 10.21.4.1; 10.21.4.1; 10.21.4.1; } } 2. Conigure each Csr with boundary clock mode as follows: a. Conigure each Csr boundary clock to act as a slave dual homed to both router aG 1.1 and router aG 1.2 master clocks. b. Conigure a Csr to act as a master clock for eNodeB. the following configuration snippet shows the ptp configuration for router Csr 1.2. You can use the configuration as the basis for the ptp configuration of all other Csrs—Csr 1.1, Csr 1.3, Csr 1.4, and Csr 1.5. However, you must change the router-specific details to match a particular Csr. [edit] protocols { ptp { clock-mode boundary; domain 0; unicast-negotiation; slave { delay-request -6; sync-interval -6; grant-duration 300; interface ge-0/2/0.0 { unicast-mode { transport ipv4; clock-source 10.21.2.2 local-ip-address 10.21.1.1; } } interface ge-0/2/1.0 { unicast-mode { transport ipv4; clock-source 10.21.4.1 local-ip-address 10.21.0.2; } } } master { interface ge-0/1/0.0 { unicast-mode { transport ipv4; clock-client 10.0.3.1/32 local-ip-address 10.0.3.2; } } } } } Æ74 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 4. to verify your timing and synchronization setup, issue the show ptp clock and show ptp lock-status commands, and check the following sessions and status: a. verify that the ptp sessions are up. b. verify that the ptp lock status goes into the phase-aligned state. c. Measure the amount of time it takes to get to the phase-aligned state. d. verify that Csrs can be both Ieee 1588v2 master and Ieee 1588v2 slave. e. Make sure that all the clocking is stabilized and all the devices are in the phase-aligned state. Configuring Synchronous Ethernet synchronous ethernet is agnostic to upper layer protocols and has the same configuration for all deployment scenarios—4G lte, Hspa, 3G, or 2G—which means that you can use this configuration in any of these deployment scenarios. Figure 74 illustrates a deployment scenario for synchronous ethernet. CSR 1.2 ge-0/2/0 CSR 1.1 ge-0/2/0 ge-0/2/1 21.0.0.2/24 AG 1.3 xe-0/0/0 10.22.1.1/24 xe-0/0/0.1 10.21.3.1/24 xe-0/0/0 10.22.2.2/24 xe-0/0/0.2 10.22.0.1/24 ge-2/0/0 xe-0/0/0 10.22.3.1/24 ge-0/2/0 10.21.0.1/24 ge-0/1/0 AG 2.1 10.22.2.1/24 xe-0/0/2 10.22.1.2/24 ge-1/0/2 10.21.2.2/24 ge-0/2/1 10.21.1.2/24 eNodeB AG 1.1 xe-0/0/2 10.21.2.1/24 10.21.1.1/24 ge-0/1/0 CSR 1.3 Io0: 1.1.1.1/32 xe-0/0/0.1 21.0.3.2/24 ge-0/2/0 21.0.6.1/24 NodeB CSR 1.4 xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.4.2/24 ge-0/2/1 10.21.5.2/24 ge-0/1/0 Grandmaster xe-0/0/0 10.22.3.2/24 ge-0/2/1 10.21.6.2/24 ge-0/2/0 10.21.5.1/24 CSR 1.5 ge-1/0/2 10.21.4.1/24 ge-2/0/0 xe-0/0/2 10.22.5.2/24 AG 1.2 xe-0/0/2 10.22.5.1/24 xe-0/0/0 10.22.4.2/24 AG 1.4 xe-0/0/0 10.22.4.1/24 AG 2.2 SyncE Figure 74: Synchronous Ethernet Deployment Topology In Figure 74, you connect the grandmaster (GM) with Gigabit ethernet optical interfaces to the aggregation routers aG 2.1 and aG 2.2. after you have configured and enabled synchronous ethernet on aCX series or MX series routers, all 10-G ethernet and 1-G ethernet interfaces on the router transmit the synchronous ethernet signal to directly connected neighbors. Figure 74 shows the distribution of synchronization in the sample topology. the following configuration snippet shows the synchronous ethernet configuration for router aG 2.1. You can use the same basic configuration for all the other aG 1, aG 2, and aG 3 routers. However, you must change the router-specific details (such as synchronization source interface) to match a particular router. [edit] chassis { synchronization { network-option option-1; quality-mode-enable; source { interfaces ge-2/0/0 { wait-to-restore 1; quality-level prc; } interfaces xe-0/0/1 { Copyright © 2013, Juniper Networks, Inc. 175 Design Guide - Juniper Networks universal and aggregation MBH 1.0 wait-to-restore 1; quality-level prc; } } esmc-transmit { interfaces all; } } } the following configuration snippet shows the synchronous ethernet configuration for router Csr 1.1. You can use the same basic configuration for all the other Csrs. However, you must change the router-specific details to match a particular Csr. [edit] chassis { synchronization { network-option option-1; quality-mode-enable; source { interfaces ge-0/2/2 { wait-to-restore 1; quality-level prc; } interfaces ge-0/2/1 { wait-to-restore 1; quality-level prc; } } esmc-transmit { interfaces all; } } } to verify the status of synchronous ethernet on Csr, aG 1, and aG 2 routers, issue the show chassis synchronization extensive command. Ç76 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Configuring Class of Service In this example, the traffic from each mobile network service—such as s1-MMe, s1-u, X2 layer 2 or layer 3 vpNs; CesopsN, satop atM pseudowires; or Mpls layer 3 vpN dedicated to network management system traffic—has its own code points defined. the code points are defined according to 802.1p (rFC 2474), Ip Differentiated services (DsCp), or experimental (eXp) bits located in each Mpls packet header. all the deployment scenarios described in this guide support 802.1p or Mpls eXp bits. In addition, you can add DsCp to enforce class-of-service (Cos) distinctions in routers. DsCp is fully supported on aCX series and MX series routers. In the sample topology, a minimum configuration for Cos is included. However, an actual network might need a more sophisticated Cos design, which is beyond the scope of this guide. as far as user traffic having its own code points at the user-to-network interface (uNI) is concerned, the goals of this Cos design are: 1. preserve these code points across the backhaul network. 2. act upon these code points when faced with congestion. 3. provide priority, low latency, and so on, in the network for a certain code point to reduce the jitter. Configuring Class of Service on Cell Site Routers any node in the network can serve as a transit node serving Cos at the network-to-network interface (NNI), the uNI, or as an access node. so from the class of service perspective, all nodes have identical configurations across the mobile backhaul (MBH) network. For detailed information about Cos, see the Junos OS Class of Service Configuration Guide. the routers across the sample topology (Figure 75) have the following Cos configuration characteristics: 1. Five forwarding classes across the network—X2, s1, oaM, network-control, and default. 2. traic classiication and forwarding class assignment on the ingress uNI based on 802.1p. 3. Mpls packets marking with eXp bit on egress NNI deined by rewrite rules of the Cos coniguration of the router. 4. transit Mpls traic classiication and forwarding class assignment on the ingress NNI based on Mpls eXp. 5. traic marking with 802.1p (or DsCp) code on the egress uNI deined by rewrite rules of the Cos coniguration of the router. Copyright © 2013, Juniper Networks, Inc. 177 Design Guide - Juniper Networks universal and aggregation MBH 1.0 PRE-AGGREGATION ACCESS AGGREGATION CORE Io0:1.1.2.1/32 Io0:1.1.3.1/32 Io0:1.1.4.1/32 Io0:1.1.8.1/32 Io0:1.1.10.1/32 Io0:1.1.13.1/32 CSR 1.2 CSR 1.1 AG 1.1 AG 1.3 AG 2.1 AG 3.1 ge-0/2/0 10.21.1.1/24 ge-0/2/1 10.21.1.2/24 ge-0/1/0 ge-0/2/0 10.21.2.1/24 ge-1/0/2 10.21.2.2/24 xe-0/0/2 10.22.1.1/24 xe-0/0/2 10.22.1.2/24 xe-0/0/0 10.22.2.1/24 xe-0/0/0 10.22.2.2/24 ds-1/2/5:1 e1-1/2/10 e1-1/2/6 at-0/0/16 ds-0/0/0:1 e1-0/0/1 e1-0/0/10 ge-0/1/0 ge-0/2/0 10.21.0.1/24 CSR 1.3 Io0: 1.1.1.1/32 ge-0/2/1 10.21.6.2/24 xe-0/0/0.1 10.21.3.1/24 xe-0/0/0.2 10.22.0.1/24 xe-0/0/0.1 10.21.3.2/24 xe-0/0/0.2 10.22.0.2/24 ge-0/2/1 10.21.5.2/24 ge-0/2/0 10.21.5.1/24 ge-0/2/1 10.21.4.2/24 ge-1/0/2 10.21.4.1/24 CSR 1.4 CSR 1.5 Io0:1.1.7.1/32 Io0:1.1.6.1/32 802.1p EXP 802.1p Classifier ieee-802.1 cl_dot1p 802.1p EXP AG 1.4 xe-0/0/0 10.22.4.1/24 Io0:1.1.9.1/32 xe-0/0/3 10.23.2.1/24 xe-1/1/1 10.23.1.2/24 xe-1/0/0 10.23.4.2/24 EPC EXP xe-0/0/2 10.23.5.1/24 AG 2.2 xe-1/1/3 10.23.5.2/24 Io0:1.1.11.1/32 EXP EXP Rewrite: exp rw_exp Classify Circuit Emulated Traffic to DEF class xe-1/0/0 10.23.4.1/24 xe-0/0/0 10.22.4.2/24 EXP EXP xe-1/1/3 10.23.2.2/24 ge-2/0/0 EXP Classifier exp c1_exp EXP xe-0/0/3 10.23.1.1/24 xe-0/0/1 10.22.3.2/24 xe-0/0/2 10.22.5.1/24 Io0:1.1.5.1/32 ge-2/0/0 xe-0/0/1 10.22.3.1/24 RNC/ BSC xe-0/0/2 10.22.5.2/24 AG 1.2 xe-1/0/2 10.23.3.2/24 at-1/2/0 ds-1/2/0:1 e1-1/2/10 e1-1/2/1 ds-0/0/3:1 e1-0/0/1 e1-0/0/10 ge-0/1/0 xe-0/0/2 10.23.3.1/24 EXP AG 3.2 Io0:1.1.14.1/32 EXP 802.1p Rewrite: ieee-802.1 rw_dot1p EXP 802.1p 802.1p Classifier: ieee-802.1 c1_dot1p 802.1p Classify Circuit Emulated Traffic to DEF class Traffic Flow Figure 75: Topology for CoS to configure Cos on the routers in the Csr ring: 1. Conigure forwarding classes and assign each of the classes to one of eight possible queues. (Both network control traic and Ieee 1588v2 ptp go to queue three by default; oaM traic goes to queue two by default). 2. Conigure classiiers to map traic code points to diferent forwarding classes at the ingress uNI and NNI. the following configuration snippet shows the classifiers and forwarding class configuration for any Csr in the access segment of the sample topology: [edit] class-of-service { classiiers { exp cl_exp { forwarding-class S1 { loss-priority low code-points 011; } forwarding-class X2 { loss-priority low code-points 001; } 178 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 forwarding-class OAM { loss-priority low code-points 101; } forwarding-class network-control { loss-priority low code-points [ 110 111 ]; } forwarding-class default { loss-priority high code-points [ 000 010 100 ]; } } ieee-802.1 cl_dot1p { forwarding-class S1 { loss-priority low code-points 011; } forwarding-class X2 { loss-priority low code-points 001; } forwarding-class OAM { loss-priority low code-points 101; } forwarding-class network-control { loss-priority low code-points [ 110 111 ]; } forwarding-class default { loss-priority high code-points [ 000 010 100 ]; } } } forwarding-classes { class X2 queue-num 0; class S1 queue-num 1; class OAM queue-num 2; class network-control queue-num 3; class default queue-num 4; } } 3. Conigure rewrite rules to re-mark traic with the correct eXp or 802.1p code point at the egress uNI and NNI according to the traic forwarding class on the egress interface. the following configuration snippet shows the rewrite rules configuration for any Csr in the access ring of the sample topology: [edit] class-of-service { rewrite-rules { exp rw_exp { forwarding-class S1 { loss-priority low code-point 011; loss-priority medium-high code-point 000; loss-priority high code-point 000; } forwarding-class X2 { loss-priority low code-point 001; loss-priority medium-high code-point 000; loss-priority high code-point 000; } forwarding-class OAM { Copyright © 2013, Juniper Networks, Inc. 179 Design Guide - Juniper Networks universal and aggregation MBH 1.0 loss-priority low code-point 101; loss-priority medium-high code-point 101; loss-priority high code-point 101; } forwarding-class network-control { loss-priority low code-point 111; loss-priority medium-high code-point 110; loss-priority high code-point 110; } forwarding-class default { loss-priority low code-point 000; loss-priority high code-point 000; loss-priority medium-high code-point 000; } } ieee-802.1 rw_dot1p { forwarding-class S1 { loss-priority low code-point 011; loss-priority medium-high code-point loss-priority high code-point 000; } forwarding-class X2 { loss-priority low code-point 001; loss-priority medium-high code-point loss-priority high code-point 000; } forwarding-class OAM { loss-priority low code-point 101; loss-priority medium-high code-point loss-priority high code-point 101; } forwarding-class network-control { loss-priority low code-point 111; loss-priority medium-high code-point loss-priority high code-point 110; } forwarding-class default { loss-priority low code-point 000; loss-priority high code-point 000; loss-priority medium-high code-point } } 000; 000; 101; 110; 000; } } 4. Conigure schedulers and scheduler maps to deine rules about how to manage traic queues for each forwarding class. the following configuration snippet shows the schedulers configuration for any Csr in the access segment of the sample topology: [edit] class-of-service { scheduler-maps { mbh { forwarding-class X2 scheduler X2; forwarding-class S1 scheduler S1; forwarding-class OAM scheduler OAM; ÈÉÊ Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 forwarding-class network-control scheduler NC; forwarding-class default scheduler DEF; } } schedulers { X2 { transmit-rate percent 35; bufer-size percent 35; } S1 { transmit-rate percent 35; bufer-size percent 35; } OAM { transmit-rate percent 5; shaping-rate percent 5; bufer-size temporal 10k; priority strict-high; } NC { transmit-rate percent 10; bufer-size percent 10; priority strict-high; } DEF { transmit-rate { remainder; } bufer-size { remainder; } } } } 5. Conigure a traic shaper (optional—might be required if you use microwave lines in the access segment). 6. Conigure traic control proiles (optional—might be required if you deine shapers). 7. assign classiiers and rewrite rules to the uNIs and the NNIs. 8. attach schedulers or traic control proiles to the uNIs. 9. attach schedulers or traic control proiles to the NNIs. the following coniguration snippet shows the classiier, rewrite rule, and scheduler coniguration on the interfaces on router Csr 1.2. You can use the same basic coniguration for all the other Csrs. However, you must change the ss) to match a particular Csr: router-speciic details (such as f ÍÎÏÐÑ ÏÒÓÔ ÍÕÕÖÓ [edit] class-of-service { system-defaults { classiiers { exp cl_exp; } } interfaces { ge-0/1/0 { classiiers { ieee-802.1 cl_dot1p; } Copyright © 2013, Juniper Networks, Inc. ËÌË Design Guide - Juniper Networks universal and aggregation MBH 1.0 rewrite-rules { ieee-802.1 rw_dot1p; } } ge-0/2/0 { scheduler-map mbh; unit 0 { rewrite-rules { exp rw_exp; } } } ge-0/2/1 { scheduler-map mbh; unit 0 { rewrite-rules { exp rw_exp; } } } } } 10. Conigure classiication for tDM and atM layer 2 circuits. In the coniguration example, traic for tDM and atM pseudowires goes to a default forwarding class. In an actual network, you might need to conigure a separate forwarding class with a high-priority queue. the following configuration snippet shows the configuration of Cos on IMa group interfaces for router Csr 1.3: [edit] class-of-service { interfaces { ds-0/0/0:1 { unit 0 { forwarding-class } } e1-0/0/1 { unit 0 { forwarding-class } } e1-0/0/10 { unit 0 { forwarding-class } } at-0/0/16 { unit 0 { forwarding-class } } } } ×ØÙ DEF; DEF; DEF; DEF; Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 Ýonfiguring Class of Service on AG 1, AG 2, and AG 3 Routers to configure Cos on aG 1, aG 2, and aG 3 routers: 1. Conigure forwarding classes and assign each of the classes to one of eight possible queues. Both network control traic and ptp (Ieee 1588v2) go to queue three by default. For the aG 1.1 router, use the same coniguration for classiiers and forwarding classes that you use on the routers in the Csr ring. 2. Conigure classiiers to map traic code points to diferent forwarding classes at the ingress uNI and NNI. For the aG 1.1 router, use the same coniguration for classiiers and forwarding classes that you use on the routers in the Csr ring. 3. Conigure rewrite rules to remark traic with the right eXp and DsCp at the egress uNI and NNI according to the forwarding class on the uNI and NNI. For the aG 1.1 router, use the coniguration for the exp rw_exp rewrite rule that you use on the routers in the Csr ring. 4. Conigure schedulers and scheduler maps to deine rules about how to manage traic queues for each of the forwarding classes. the following coniguration snippet shows the schedulers coniguration for any aG router in the sample topology (Figure 75). [edit] class-of-service { scheduler-maps { mbh { forwarding-class X2 scheduler X2; forwarding-class S1 scheduler S1; forwarding-class OAM scheduler OAM; forwarding-class network-control scheduler NC; forwarding-class default scheduler DEF; } } schedulers { X2 { transmit-rate percent 35; bufer-size percent 35; } S1 { transmit-rate percent 35; bufer-size percent 35; } OAM { transmit-rate percent 5; shaping-rate percent 5; bufer-size temporal 10k; priority high; } NC { transmit-rate percent 10; bufer-size percent 10; priority strict-high; } DEF { transmit-rate { remainder; } bufer-size { remainder; } } } } Copyright © 2013, Juniper Networks, Inc. ÚÛÜ Design Guide - Juniper Networks universal and aggregation MBH 1.0 5. Conigure traic shapers (optional—might be required if you use microwave lines in the access segment). 6. Conigure traic control proiles (optional—might be required if you deine shapers). 7. assign classiiers and rewrite rules to the uNIs and NNIs. 8. attach schedulers or traic control proiles to the uNIs. 9. attach schedulers or traic control proiles to the NNIs. the following configuration snippet shows the Cos interface configuration for router aG 1.1: [edit] class-of-service { interfaces { xe-0/0/0 { scheduler-map mbh; unit 1 { classiiers { exp cl_exp; } rewrite-rules { exp rw_exp; } } unit 2 { classiiers { exp cl_exp; } rewrite-rules { exp rw_exp; } } } xe-0/0/2 { scheduler-map mbh; unit 0 { classiiers { exp cl_exp; } rewrite-rules { exp rw_exp; } } } ge-1/0/2 { scheduler-map mbh; unit 0 { classiiers { exp cl_exp; } rewrite-rules { exp rw_exp; } } } } } 184 Copyright © 2013, Juniper Networks, Inc. Design Guide - Juniper Networks universal and aggregation MBH 1.0 10. Conigure classiication for tDM and atM layer 2 circuits. In the coniguration example, traic for tDM and atM pseudowires goes to a default forwarding class. In an actual network, you might need to conigure a separate forwarding class with a high-priority queue. the following configuration snippet shows the tDM interfaces configuration for router aG 1.1: [edit] class-of-service { interfaces { ds-1/2/5:1 { unit 0 { forwarding-class DEF; } } e1-1/2/6 { unit 0 { forwarding-class DEF; } } e1-1/2/10 { unit 0 { forwarding-class DEF; } } } the following configuration snippet shows the atM interfaces configuration for router aG 2.1: [edit] class-of-service { interfaces { at-1/2/0 { unit 0 { forwarding-class DEF; } } } } 11. verify the coniguration of Cos; issue the show interface interface-name extensive command. specify the core or customer-facing interfaces for the interface-name option. Copyright © 2013, Juniper Networks, Inc. 185 Design Guide - Juniper Networks universal and aggregation MBH 1.0 Corporate and Sales Headquarters APAC and EMEA Headquarters Juniper Networks, Inc. Juniper Networks International B.v. 1194 North Mathilda avenue Boeing avenue 240 sunnyvale, Ca 94089 usa 1119 pZ schiphol-rijk phone: 888.JuNIper (888.586.4737) amsterdam, the Netherlands or 408.745.2000 phone: 31.0.207.125.700 Fax: 408.745.2100 Fax: 31.0.207.125.701 to purchase Juniper Networks solutions, please contact your Juniper Networks representative at 1-866-298-6428 or authorized reseller. www.juniper.net Copyright 2013 Juniper Networks, Inc. all rights reserved. Juniper Networks, the Juniper Networks logo, Junos and QFabric are registered trademarks of Juniper Networks, Inc. in the united states and other countries. all other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. sept 2013 186 printed on recycled paper Copyright © 2013, Juniper Networks, Inc.