Professional Documents
Culture Documents
Table of Contents
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
High-Level Overview of Mobile Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Solution Profile Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
What Constitutes a Mobile Radio Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Mobile Core: PDSN/GGSN/SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
What is a Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
What are the Available Types of Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Flat IP Network Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Requirements from an IP Backhaul Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Transport and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Reliability and Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Network Configuration and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Legacy Backhaul Networks to Carrier Ethernet Migration Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Scenario B: BS Supports Ethernet in Addition to Legacy Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Solution Profile Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Reference Solution Architecture Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Solution A: Umbrella Solution—Migration Strategy from 2/2.5 and
3G Legacy Networks + Greenfield 3G/4G Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Solution B: 3G/4G Backhaul Greenfield Deployment Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Solution-Required Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
VLAN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Timing Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Failure Recovery and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Solution-Type Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Solution A: Umbrella Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Solution B: Greenfield Deployment Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
VPN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Examples of Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
J Series as an Access Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
CTP Series as an Access Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
About Juniper Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table of Figures
Figure 1: Overview of a mobile backhaul network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2: 3GPP2 technology family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 3: 3GPP technology family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 4: Overview of a generic mobile backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 5: Subcomponents of mobile backhaul network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 6: ATM backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 7: IP/Ethernet backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 8: Services to be transported over Carrier Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 9: Components of IP RAN transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 10: IP RAN QoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 11: MPLS-based transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 12: Migrating to Carrier Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 13: Co-existence of legacy technologies and Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 14: Legacy technologies carried over Ethernet network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 15: Dual support for Ethernet and legacy technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 16: All IP-/Ethernet-based backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 17: High-level overview of solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 18: Simplified view of mobile backhaul network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 19: TDM-pseudowire-based technology migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 20: TDM and Ethernet coexistence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 21: IP-/Ethernet-based mobile backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 22: Aggregation device internal to BGP domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 23: Aggregation device external to BGP domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 24: Example—BX7000 specific design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 25: Mobile backhaul test network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 26: Logical view of mobile backhaul network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 27: VLAN tags at cell site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 28: Layer 2-based CoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 29: Layer 3 VPN-based CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 30: VPLS view of mobile backhaul network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 31: L3VPN view of mobile backhaul network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 32: J Series as an access device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 33: CTP Series as an access device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Introduction
Mobile backhaul networks have been gaining a lot of attention lately. There have been advancements in cellular
technologies and the proliferation of consumer mobile devices such as smartphones and laptops capable of mobile
broadband access. The newer cellular technologies have resulted in significant increases in connection speeds
over the air both on the uplink and downlink—that is, to and from the user device. Needless to state, there have
been a lot of improvements on the wired core network side. However, today, mobile backhaul networks that connect
the access or RF side to the core of the mobile network have to catch up with all these changes and thus tend to
counterbalance the enhancements on the rest of the network.
At present, a large number of the existing backhaul networks are hierarchical and based on legacy technologies
that are incapable of supporting higher speeds or service requirements. Most of these networks are based on
traditional T1 circuit switching and used to transmit voice traffic. The introduction of the Apple iPhone in 2007
heralded the first tolerable use of the Internet on a mobile handheld device. The subsequent smart mobile devices
and unlimited data/voice services have led to the development of technologies supporting higher bandwidth and
faster download rates. This has fueled the demand for higher backhaul network capacity and intelligence. Another
important factor to bear in mind is that the cost of a T1-/E1-based backhaul increases with the bandwidth. Hence,
there is a critical requirement to migrate the mobile backhaul network to technologies that can support quality of
service (QoS) to separate traffic streams, timing synchronization, lower packet loss, and high availability (HA).
The key drivers behind the demand for a new or reengineered mobile backhaul include:
• Increase in data traffic and number of subscribers
• Dynamically changing usage patterns
• Variation in type of traffic transported across the network
• Requirement for QoS-based prioritization of traffic
• Timing synchronization
Juniper Networks® offers mobile backhaul solutions that can be either purely IP/Ethernet-MPLS based or a hybrid
of Ethernet and other Layer 2 technologies such as ATM/T1-E1/Frame Relay. Juniper Networks products are suited
for a wide range of mobile backhaul solutions that span migration strategies from legacy technologies to greenfield
deployments that meet the requirements of the latest technologies.
The primary focus of this document is on mobile backhaul architecture based on an Ethernet/MPLS solution1. This
solution aims to describe the following concepts:
• There can be multiple migration paths from the existing legacy technology-based backhaul networks. Some
of these options can provide a migration strategy that fits with the long-term plan to move to the latest
technologies such as LTE.
• The functionality of the mobile backhaul network is independent and not influenced by the type of traffic that is
transported across the network.
• Services such as class of service (CoS), MPLS, and VPLS—coupled with features such as HA, OAM, and
Reliability—can be leveraged for mobile traffic.
• Mobile network operators that are already familiar with Juniper Networks JUNOS® Software can implement all
the IP and Carrier Ethernet2 features with considerable ease.
Figure 1 illustrates a mobile backhaul network that serves multiple generations of mobile technologies. There can
be a device acting as the access gateway from the cell sites—the access type is dependent on the mobile technology
generation. Thus the access gateway can service legacy TDM/ATM or IP/Ethernet technologies. Cell sites based on
newer technologies can directly participate in the IP/Ethernet network. A variety of VPN services and CoS offerings
are available on the Metro Ethernet network. MPLS serves as the transport mechanism for the data belonging to
all these services. An aggregation device links the backhaul network to the network controller that interfaces with
the mobile core. All the devices in the mobile backhaul need to be managed, provisioned, and monitored at node,
service, transport, and network levels.
1
The Ethernet/MPLS solution references both the MEF22 (Mobile Backhaul Implementation Agreement) and the IP/MPLS Forum 20.0.0 standard.
2
When referring to Carrier Ethernet, this paper does not include transport services such as PBB, PBT, and connection-oriented Ethernet.
Wireline
Wireline
MSC
Access Gateway
2G-GSM/CDMA Devices
ATM/TDM
2G BSC
Capable
4G-LTE/WiMax
IP/Ethernet
ATM/TDM
Scope
This document is intended to be a reference guide to those involved in planning and designing mobile backhaul networks.
The mobile backhaul scenarios described here are based on products such as Juniper Networks BX7000 Multi-
Access Gateway, EX Series Ethernet Switches, M Series Multiservice Edge Routers, and MX Series Ethernet Services
Routers. RSVP-based MPLS is used as the transport mechanism for L3VPN and BGP-VPLS services within the Metro
ring network.
3
E-Line is an MEF definition for different types of VPN connectivity. Please refer to the MEF standards for more details.
4
ELAN is an MEF definition for different types of VPN connectivity. Please refer to the MEF standards for more details.
Framework
Prior to launching into the discussion on the suggested backhaul scenarios, it is important to get familiar with the
terms and concepts of mobile networks, available backhaul network options, and requirements of a next-generation
backhaul network at a high level. This section helps provide such an understanding. The solution details are
discussed later in the document.
2G – CDMAOne
3GPP2
3G – CDMA2000 EVDO
GPRS
EDGE
2G – GSM
W-CDMA
3GPP
3G – UMTS HSPA
TD-CDMA/
TD-SCDMA
4G – LTE
3GPP Rel8
E-UTRAN
BTS
A BTS is a device that can provide communication between mobile user equipment and a mobile network. The BTS
communicates with the mobile user devices over the air interface. There can typically be as many as 50 BTS devices
controlled by one BSC. (This document uses the generic term BS or RAN BS to refer to a cell tower/BTS.)
BSC
The main function of a BSC is to communicate and control multiple BTS devices over either the Abis or Iub interface.
The BSC also controls handoffs that occur as a result of mobile devices moving between cell sites and communicates
with the mobile core (The type of communication depends on interface to core that in turn depends on technology). A
single 2G BSC can typically control as many as 50 BTS devices while a 3G RNC can control 200 NodeBs and up to 800
base stations per BSC/RNC in a 2.5G/3G network. (This document uses the generic term RNC or RAN NC to refer to
a BSC.)
Mobile Backhaul
BS BSC
The generic model for the newer backhaul networks consists of a cell, hub sites, or both connected to aggregation
devices that in turn can either belong or be connected to a Metro network. Figure 5 shows the different
subcomponents of the mobile backhaul network. The most commonly proposed metro network for 3G/4G
technologies is an Ethernet-based services network. This network should be capable of providing multiaccess to
different Layer 2 technologies such as FR/ATM/TDM and IP.
Another perspective of the mobile backhaul could lead to following
classification of functionality:
Mobile Backhaul
• Multiaccess gateway—This can consist of devices that can support
TDM/ATM or Ethernet connectivity at the cell/hub sites.
Cell Site Devices
• Transport—The data from the different cell sites is carried over
pseudowires that support circuit emulation.
Hub/Aggregation • Timing Synchronization—Clocking for the TDM data needs to be
Site Devices synchronized across the network.
• Aggregation—An aggregation device performs aggregation of all the
Metro Network incoming connections before they reach the mobile core.
The functionality and requirements of a mobile backhaul network are
Figure 5: Subcomponents of mobile discussed in later sections.
backhaul network
2/2.5G technologies were designed for voice services, which are ideal for that purpose, but not efficient for data and
video services. As of now, 8 to 12 T1s service a cell site (BTS). The requirement for T1s is directly proportional to the
cost. Added to that, scalability is an issue due to the lack of support for reuse of bandwidth and bundling of links.
RANs belonging to the 3G technology family aim to solve this problem by using either ATM or IP between the BTS and
BSC instead of TDM. This approach—combined with other enhancements on the air interface and between RNCs—
provides better scalability since it allows bandwidth reuse.
ATM is used in case of a UMTS Rel99-based 3G network while EVDO, UMTS (3GPP Rel5) and WiMAX use IP. LTE uses
completely IP-based RAN architecture. When using ATM (3GPP Rel99), T1/E1 or T3/E3/OC3 links can be used for low
and high population density areas, respectively. AAL5 and AAL2 PDUs are carried at Layer 2. Figure 6 shows an ATM
backhaul network.
AAL5 AAL2
ATM-IMA
lub lub
ATM Backhaul
BSC
3GPP Rel5 uses IP as the transport bearer. The IP packets, in cases of higher density cell sites, are carried over
Ethernet—and MLPPP links are used for lower density sites. (MLPPP is used with T1/E1 links.) Figure 7 shows an
IP/Ethernet-based backhaul.
IP Routing
Carrier Ethernet
MPLS
PWE
L2/L3 VPN
Figure 9 shows the key components that need to be transported over an IP-based RAN. All the devices in the RAN need
to be manageable either through in-band or out-of-band management. Network timing synchronization is required
when transporting technologies such as TDM over the IP network. RAN signaling messages need to be carried with
proper encapsulation applied to the IP packets. QoS needs to be applied on the user (and RAN signaling) traffic.
Detailed requirements of an IP-/Ethernet-based mobile backhaul network are discussed in detail in the following sections.
CoS
Services are offered on the mobile network end to end between the user mobile devices. The mobile network,
including the backhaul, serves as a bearer infrastructure for these services. Each service can be assigned to a
particular traffic class and prioritized. In general, services signaling, user plane transport, and management
traffic can be classified, prioritized, and scheduled using CoS. The mobile backhaul network needs to be capable
of recognizing the CoS settings, doing any re-marking of packets if required, prioritizing between the packets, and
applying CoS rules to the different traffic streams. Figure 10 shows the different types of CoS marking that can be
done to differentiate between the traffic streams.
VLAN Service
802.1p (Layer 2) DSCP (IP) EXP (MPLS)
based (Layer 2)
Backhaul networks need to be able to support the main traffic types—voice, video, network signaling/management,
and best-effort data. The network should also be able to provide low packet loss. For this, CoS definitions need to
be determined and maintained at each node in the backhaul such that the different traffic types can be prioritized
through the network accordingly.
The mobile technology standards define classes that can be used for the traffic classification but do not mandate
how many of these classes are actually to be used. This number will depend on the network implementation and
traffic profile. In general, differentiation between the traffic types is done by marking and prioritizing packets as
“High,” “Medium,” or “Low.” The prioritization depends on the traffic type.
There are four classes of traffic defined in case of the 3GPP-based technologies such as UMTS. These traffic classes
can be shared between the wired and mobile traffic streams and are all prioritized based on their CoS marking. The
different classes may either 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 by prioritizing different traffic streams within a traffic class. The level of granularity will depend on the type
of CoS guarantees, network spanning multiple domains, complexity of implementation, and the capability of the
network interfaces and equipment.
Table 3 provides a summary of the different traffic classes defined in the mobile backhaul solution test network and
the corresponding DSCP/802.1p/EXP marking.
Bidirectional traffic such as VoIP and video conferencing that require low latency is assigned to the Conversational
class. Unidirectional traffic such as streaming video (UDP/RTP streams) is classified into the Streaming class.
The Interactive class can be used for applications that use TCP-based transactions such as HTTP and Telnet. The
Background traffic class can contain a combination of both low-priority traffic from mobile or wired applications and
background data from mobile applications. The traffic streams will carry different CoS markings based on their origins.
Implementing MPLS in conjunction with VPN services in the metro provides mobile network carriers with new
revenue opportunities. The VPN services could be either Layer 2 (L2VPN/VPLS) or Layer 3 (L3VPN/MVPN) based. The
traffic belonging to different VPNs can be transported over pseudowire (and thus over MPLS LSPs). Figure 11 shows
two nodes, PE1 and PE2, which are a part of the Metro network. The provider edge (PE) routers are configured to
offer two VPN services (VPN-A and VPN-B).
Traffic belonging to each of these VPNs is carried over a separate set of pseudowires. There can be several such sets
of pseudowires carried within an MPLS LSP tunnel.
The connectivity offered by the MPLS LSPs to the VPN service can either be point-to-point, point-to-multipoint, or
multipoint-to-multipoint. Based on the MEF definitions, the services offered would be either E-Line/Ethernet Virtual
Private Line; ELAN/Ethernet Virtual Private LAN, or E-Tree. Typically, E-Line connectivity delivers unicast traffic
while ELAN can be used either for unicast or multicast traffic. Mapping connectivity to services results in typically
L2/L3VPNs using E-line connectivity while VPLS/MVPN use the ELAN or E-Tree connectivity based on the topology
and requirements.
The CoS requirements of the traffic streams being transported across the MPLS LSP can be achieved using the
EXP classifiers. Granular prioritization of streams belonging to different VPN services can also be done using a
combination of behavior aggregate (BA) and multifield (MF) classifiers.
VPN-A
PE-1 MPLS Transport Tunnel PE-2
VPN-B
Pseudowire
Figure 11: MPLS-based transport
Synchronization
The continuity of a circuit clock is lost when the circuit is transported over an IP- or packet-based network. The
fundamental difference between the two is that the circuit is synchronous while the IP network is asynchronous.
Clock synchronization in a mobile backhaul 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
wastage of frequency spectrum. Hence, timing in a mobile network can be distributed by one of the following
methods to maintain the clock synchronization:
• Using GPS or a legacy TDM network that is external to the IP-packet based network
• Packet-based dedicated streams (IEEE1588- or NTP-based )
• Using Synchronous Ethernet over the physical layer
• Adaptive clocking
• DSL clocking
The accuracy for timing delivered at the BS should be at least 50 ppb according to G.8261.
Legacy Backhaul
Network – TDM/ATM
TD
TM M
/A /A
TM
TDM
Interworking – Interworking –
TDM/ATM - Ethernet
Backhaul Network TDM/ATM - Ethernet Mobile Core
Ethernet + IP/MPLS + Network
Services
RAN BS RAN NC
Interworking – Interworking –
TDM/ATM - Ethernet TDM/ATM - Ethernet
TDM/ATM Backhaul Network TDM/ATM
Mobile Core
Ethernet + IP/MPLS + Network
Ethernet Ethernet
Services
RAN BS RAN NC
Legacy Backhaul
Network – TDM/ATM
TD
TM M
/A /A
TM
TDM
NetworksProvisioning/
TDM/ATM
Monitoring Fault Detection
2G-GSM/CDMA
3G-UMTS/
EDGE CDMA/
EVDO
BX Series
MX Series M Series
Ethernet Backhaul 2G BSC
Network (L2/L3)
J Series
Psuedowire over MPLS LSP
IP/MPLS (with PWE) + 3G RNC
VPN Services (L2VPN/L3VPN/
EX Series
VPLS/NG-MVPN) + CoS
4G SAE GW
4G-LTE/
WiMax
IP/Ethernet
IP/Ethernet
ATM/TDM
Figure 18 shows a simplified view of the backhaul solution with the BX7000 and EX Series acting as the cell site
devices. The connections from these devices to the Metro network can be either Layer 2 or Layer 3 based. The
BX7000 sets up a pseudowire across the Metro network to the M Series router (M120-PE) that has the circuit
emulation PICs. CoS can be applied across all the nodes including the EX Series in the 3G/4G scenario. As mentioned
earlier, the Metro network offers transport and services in all scenarios.
3G
M120
3G RAN
L2/L3 Ethernet NC/4G GW
EX Series-CSD
4G MX Series-2-PE
Ethernet Links
TDM/ATM Links
Backup Links
For better understanding, the umbrella solution has been described based on the migration, coexistence, and
greenfield deployment aspects:
• TDM-Pseudowire-Based Technology Migration
Figure 19 shows a TDM-Ethernet-based backhaul network. Here, the BS and RAN NC are only capable of
supporting TDM. A BX7000 is used as the cell/hub site device and has incoming T1/DS3/SDH links. It is
connected to an IP/Ethernet-based metro network that can deliver CoS, VPN services, and MPLS transport.
The TDM traffic is carried over the metro network using circuit emulation over pseudowires. As described
earlier, pseudowires involve the use of MPLS LSPs across the metro network. The pseudowires terminate on an
M Series router that acts as an aggregation device and consists of circuit emulation PICs (4-port channelized
STM1/OC3 or 12-port T1/E1) that achieve the translation from Ethernet to TDM. The RAN NC (BSC) then receives
the TDM stream from the M Series router. The Metro network can consist of a combination of M Series routers,
MX series routers, or both.
IP/MPLS LSP
Ethernet
TDM
Metro Network TDM
Mobile Core
Ethernet Ethernet Network
Cell Hub
RAN BS Site Device RAN NC
Aggregation
Device
IP/MPLS LSP
Ethernet L2/L3
Metro Network
Ethernet Ethernet Mobile Core
IP/MPLS + VPN Network
Cell Hub
RAN BS Site Device
Services CoS RAN NC
Table 4 lists the various VPN services and MPLS transport implementation options offered by Juniper. These services
and transport options can be implemented in the Metro network.
Solution-Required Devices
Table 5 shows the list of devices used in case of the migration and greenfield deployment scenarios.
Design Considerations
Certain Layer 2 or Layer 3 capabilities of the BS, RAN NC, or the backhaul equipment determine the design of the
network. Some of these factors to consider when designing a mobile backhaul network include:
VLAN Models
The VLAN tagging function may not be available on BS in case of the IP/Ethernet solution. The backhaul network
design can change depending on whether the BS can perform VLAN tagging.
A location-based VLAN can be considered to be analogous to a Layer 2 ATM or Frame Relay circuit. Packets are
tagged with the location-based VLAN information based on the site from where they originated. This location-based
VLAN tag is present all through the backhaul network and packets are handed off into the mobile core with the tag
information.
A service VLAN tag identifies the service that is being provided on the particular VLAN. The backhaul network could
be designed in such a way that each service is offered on a separate VLAN or all the services are bundled into a
single pipe that uses one VLAN—that is, one VLAN for all services versus VLAN per service. The service tag may get
popped at some point in the backhaul network and does not need to be preserved and sent to the mobile core.
The traffic in the backhaul can thus be separated either based on services or location. There are two scenarios based
on whether the frames from the cell tower are VLAN tagged:
• Tagged Frames
1. Location and Service tags (Q-in-Q)—The frames coming in from the cell tower are tagged with both location
and service information. The location tag is stripped from the frames at the cell site device. The frames are
then sent with only the service tags that are recognized all through the network into the core.
2. Only Location-based tags—The frames coming in from the cell tower are only tagged with the location
information. The service tags can be added at the cell site depending on the type of services available at
the particular site. Location-based VLAN tags are usually necessary when using a combination of Carrier
Ethernet and a legacy Layer 2 network.
• Untagged Frames
The BS is not capable of tagging the frames with the appropriate location or service information. The frames
come in untagged into the cell site device. The appropriate location and service VLAN tags are added on the
cell site device. The location VLAN tag information is determined based on the port that the untagged frames
were received.
CoS
The following factors need to be considered when designing the CoS rules:
• The traffic profile and requirement of the granular classification of the traffic streams within a forwarding class
using of MF classifiers—that is, combination of BA and MF classifiers
• Type of CoS marking—that is, DSCP versus 802.1p will depend on whether the incoming frames are VLAN tagged.
• Assigning EXP classifiers to traffic based on the VPN routing instances
MPLS LSPs
There can be either a single LSP or multiple LSPs assigned to carry the traffic within the backhaul network. The
same MPLS LSP can be used to carry different traffic streams originating and destined to the same VPN instance.
The alternative is to use multiple LSPs—either one per VPN offering or one for each traffic type.
Timing Synchronization
As mentioned earlier, there are multiple ways of distributing the timing information across the mobile backhaul
network— traditional TDM-based timing distribution, packet network-based timing distribution using Adaptive Clock
Recovery, 1588v2, and Sync-E and NTPv3/v4. When applying CoS rules, packets carrying adaptive clock recovery
timing information need to be classified into the high-priority, low-latency queue. Juniper Networks supports
multiple timing synchronization options since a single timing solution does not fit all network types or requirements.
1588v2 is a versatile fit for the IP/Ethernet-based mobile backhaul since it is topology agnostic and supports both
frequency and phase.
Solution-Type Profiles
Solution A: Umbrella Solution
This section provides the configuration snippets that support the 2G/2.5G legacy technology migration solution
information that was discussed in the earlier sections. Figure 24 shows an example of a mobile backhaul network
where the BX7000 acts as a multiaccess gateway device for legacy and Ethernet-based technologies. The
connections from the BS to the BX7000 device could be either TDM/ATM or Ethernet depending on the type of mobile
network. The BX7000 device has outgoing primary and backup Gigabit Ethernet connections to the Metro network. In
case of TDM/ATM, it sets up pseudowires to perform circuit emulation across the Metro network. These pseudowires
terminate on the M Series device that has a circuit emulation PIC. The PE and P nodes of the Metro network can
be interconnected by either Gigabit Ethernet or 10G links. MPLS LSPs can be used as a means to transport all data
within the Metro. VPN services such as Layer 2/Layer 3 VPNs can deliver unicast services while VPLS and NG-MVPN
can be used for multicast services.
Note: Please refer to Table 4 for unicast and multicast service options.
Note: When using BGP-based L2VPNs in the Metro network, the BX7000 device can perform LDP-based pseudowire
stitching. Here, LDP-based pseudowire is created from the BX7000 to the ingress PE router that is the entry point to
the BGP L2VPN domain on the Metro network. The requisite MPLS to BGP L2VPN label translation is performed on
this ingress PE. A converse action occurs on the egress PE router that is the exit point of the BGP L2VPN domain. If
the aggregation device is a part of this domain, no additional step needs to occur. Figure 22 shows this scenario.
IP/MPLS LSP
LDP-based
Pseudowire
Ethernet
Metro Network
TDM TDM Mobile Core
BGP –
Network
Cell Hub L2VPN/VPLS
RAN BS Site Device Ingress Egress RAN NC
PE Router PE Router +
Aggregation
Device
Also, LDP-based pseudowire should be created from the egress PE router to the aggregation device as shown in
Figure 23.
IP/MPLS LSP
LDP-based
LDP-based Pseudowire
Pseudowire
Ethernet
Metro Network
TDM TDM Mobile Core
BGP –
Network
Cell Hub L2VPN/VPLS
RAN BS Site Device Ingress Egress RAN NC
PE Router PE Router Aggregation
Device
Figure 23: Aggregation device external to BGP domain
The BX7000 also signals static MPLS LSPs to the M Series aggregation router to transport all pseudowires.
This option leverages the BGP L2 VPN mechanism to provide a solution for the issues previously explained. An LDP-
based pseudowire is created from the MAG to the BGP L2 VPN ingress PE, which translates the MPLS outer label
into a BGP L2 VPN label. The egress PE router then swaps the labels at the egress of the BGP L2 VPN domain. If it is
not part of the BGP L2 VPN domain, the ASG also has an LDP based pseudowire to the egress PE.
3G
M120-PE
3G RAN NC/
4G GW
EX Series-CSD
4G MX Series-2-PE
Ethernet Links
TDM/ATM Links
Backup Links
Table 6 lists the configuration snippets of the legacy migration solution using BX7000 and M Series routers that was
described in the previous sections. (Please refer to the simplified mobile backhaul view depicted in Figure 18 and
Figure 24).
The snippets show the sample configuration to set up E1 interfaces and pseudowires on the BX7000 and E1
interfaces and LSPs on the M Series router. In this example, a 12 port-Channelized T1/E1 PIC provides the circuit
emulation capability on the M Series router.
MX Series-1-PE
EX Series-1
2G
EX Series-4
EX Series-2
3G RAN NC
M120-PE
EX Series-3
4G MX Series-2-PE
Layer 2 Link
Layer 3 Link
Coon Links
Figure 26 shows a logical view of the same mobile backhaul network. When using a Q-in-Q VLAN model, the frames
coming into the EX4200 devices are double tagged with the location and service tags. The cell site devices strip the
location tag and maintained the service tag. In Figure 26, the frames received at the cell site devices contain location
tags of 175, 180, and 33, respectively. The service tags 550, 600, and 650 are carried through the network into the
core. The Multicast VLAN 1000 is used to deliver multicast streaming video to all the sites.
Note: The multicast streaming video is distributed using point-to-point LSPs as opposed to using point-to-
multipoint or multipoint-to-multipoint optimization and PIM/IP Multicast.
VLAN
550
MX240
EX3200
Cell Site
175 METRO
NETWORK
EX3200
MX240
Mobile Core
VLAN Network
EX3200
Cell Site 600
180
VPLS + L3VPN
RSVP BASED
MPLS
EX3200 VLAN
Cell Site 650 MX240
33 VLAN550
Multicast VLAN VLAN600
VLAN650
1000
VLAN550 (backup)
VLAN600 (backup)
VLAN650 (backup)
10G Links in Metro (Trunk)
Figure 27 illustrates the handling of the VLAN tags at the cell site.
Connections from Site175 and Site180 are Layer 2 Ethernet based while that from Site33 is Layer 3 IP based. As a
result the Metro network offers Layer 2-based VPLS and Layer 3-based VPN services to these sites. VPN services
in the Metro network introduce the concept of separate routing instances within the Metro network. This concept is
based on the logical partitioning of the physical nodes in the Metro network between different services. The network
implementation details are discussed in the following sections.
Routing
OSPF or ISIS can be used as the IGP to achieve network connectivity on all IP interfaces. In most cases, these
interfaces belong to a single backbone area or level. BGP is required to support the VPLS and L3VPN signaling
messages in the Metro network. Enabling BFD on both the IGP routing protocol and BGP results in better fault
detection times.
CoS
The CoS scenarios change based on the type of connectivity (that is, Layer 2/3) and services offered. Figure 28
shows the classifiers used in the Layer 2 portion of the network. 802.1p classifiers are used when applying CoS to
tagged frames. The cell and hub site devices perform queuing, scheduling, and prioritization based on the 802.1p bit
marking. When the frames need to be transported across the Metro network using MPLS LSPs, EXP classifiers are
used. Hence, the 802.1p CoS values need to be rewritten into EXP classifiers and transported over the LSPs.
The aggregation device does this in the VPLS instance on the Metro network. A rewrite back from EXP to 802.1p
classifiers is done when handing the frames from the Metro in the RAN NC. The converse actions take place on
frames destined to the cell site and BS. The CoS classifiers can be applied if necessary on each routing instance.
If the frames received from the BS are untagged, the cell site device can rewrite the DSCP value of the incoming
frames to 802.1.p. From there the frames would be rewritten with the EXP value in the Metro and back to DSCP when
sending to the RAN NC.
Typically BA classifiers are used to achieve the required CoS guarantees in a network. However, using a combination
of BA and MF classifiers introduces an extra level of granularity. Traffic streams within a particular class can be
prioritized—for example, prioritizing Web browsing over Telnet traffic within the Interactive queue. In cases where
the BS does not mark the incoming packets, the cell site gateway needs to be able to identify the traffic streams, for
example, based on port number or IP address and then perform the classification.
Note: Default Cos classifiers need to be used to classify traffic in a VPLS instance. In addition to the BA classifiers,
MF-based firewall filters can be applied to the CE-facing interfaces on the metro ring nodes to ensure that the
packets are classified based on the default EXP into the appropriate queues. The same CoS rules are applied to all
core-facing VPLS interfaces.
BS RAN NC
Layer 3 VPN-based CoS involves the use of DSCP or IP precedence marking being rewritten to EXP classifiers at the
aggregation device. Figure 29 shows the different classifiers used for the Layer 3-based traffic.
BS RAN NC
Table 7 shows salient CoS configuration steps on the EX Series cell site and MX Series aggregation devices.
}
}
}
VPN Services
The VPN services are offered in the Metro network that consists of Juniper Networks MX480 Ethernet Services Router
devices (MX Series-PE1 and MX Series-PE2 ) and an M120 (M120-PE3) shown in Figure 25. 10 Gigabit links connect
all the three nodes. The metro network highlighted by this solution offers VPLS and L3VPN services. This illustrates
the flexibility of service offerings possible when using a Carrier Ethernet- based mobile backhaul network. Both
the services use BGP as the underlying mechanism for exchange of signaling information. The routing and MPLS
information is contained in separate tables for each instance. Each of these services is discussed in the following
section.
• VPLS
VPLS offers a Layer 2-based VPN service that can be used for either unicast or multicast purposes. When using
multicast, IGMP snooping and point-to-multipoint LSPs provide optimization. Both unicast and multicast traffic
can be carried using point-to-point LSPs across the VPLS network. This example highlights the latter scenario.
Figure 30 depicts the VPLS-based logical view of the backhaul network used in the discussion. Please refer to
Table 4 for other service implementation options.
One BGP-based VPLS routing instance (VPLS-AGG1) is configured on the three nodes of the metro ring. The
VPLS-AGG1 instance is associated with the Layer2 connections from the hub site EX4. This single routing
instance can support connections from multiple VLANs (location- or service-based depending on the frames
arriving tagged at the cell site). As shown in Figure 30, there are two separate VLANs, 550 and 600, which offer
services to the sites 175 and 180, respectively. A third VLAN 1000, termed as a multicast VLAN, offers streaming
video to both sites. The hub site device EX4 is dual- homed to the two MX Series PE routers. Dual homing is
enabled within the VPLS instance to ensure that only one link is active at a given time.
Point-to-point MPLS LSPs serve as the transport mechanism between all the PE routers in the metro network.
EXP-based CoS classifiers are applied to the VPLS instance as discussed in the CoS section. In this scenario,
multicast and point to multipoint do not offer much optimization and so the point-to-point LSPs are used to
transport both unicast traffic and the multicast streaming video.
Implementation Notes:
• A tunnel PIC need not be identified on an MX Series router if point-to-multipoint/IGMP snooping and other
multicast services are not enabled on the network. The “no-tunnel-services” command can be enabled instead.
• VPLS only supports the use of default EXP values to classify any VPLS traffic.
• In addition to the BA classifiers, MF-based firewall filters can be applied to the CE-facing interfaces on the
metro ring nodes to ensure that the packets are classified based on the default EXP into the appropriate queues.
The same CoS rules are applied to all core-facing VPLS interfaces.
VLANs
550
MX Series-1-PE
EX Series-1
STE 175-550
EX Series-4
VLANs
550 and
600
VLANs
EX Series-2
STE 180-600 600 RAN NC
M120-PE
Multicast VLAN
1000
MX Series-2-PE
• L3VPN
L3VPN offers a Layer 3-based VPN service that is typically used for unicast purposes. (When using multicast,
PIM and point-to-multipoint LSPs can be used in an NG-MVPN instance.) Figure 31 shows the L3VPN view of
the mobile backhaul network under discussion.
One BGP-based L3VPN routing instance (L3VPN-AGG1) is configured on the three nodes of the metro ring. The
L3VPN-AGG1 instance is associated with the Layer 3 IP connections from the cell site EX Series-1. This single
routing instance can support connections from multiple VLANs (location- or service-based depending on the
frames arriving tagged at the cell site). As shown in Figure 31, there is one VLAN 650 that offers services to the
site 33 while VLAN 1000 offers streaming video to the sites. The cell site device EX Series-1 is dual homed to the
two MX Series PE routers. The OSPF metrics are configured in such a way that the traffic is received only from
one of the links.
Point-to-point MPLS LSPs serve as the transport mechanism between all the PE routers in the metro network.
EXP-based CoS classifiers are applied to the traffic belonging to the L3VPN instance as discussed in the CoS
section. In this scenario, multicast and point to multipoint do not offer much optimization and so the point-to-
point LSPs are used to transport both L3 unicast traffic and the multicast streaming video.
MX Series-1-PE
VLAN650
EX Series-1
STE 33-650
VLAN650
RAN NC
M120-PE
Multicast VLAN
1000
MX Series-2-PE
• OAM
Ethernet Link management OAM is configured to offer reliability and fault detection. The table below gives a
sample configuration snippet.
• MPLS Transport
RSVP-based LSPs transport the data belonging to different services across the Metro network. Either link
protection or fast reroute can be enabled on RSVP and MPLS to provide faster failure recovery. The table below
gives a sample configuration of RSVP and MPLS.
community public;
trap-options {
source-address 172.28.113.131;
}
trap-group MBHL {
categories {
authentication;
chassis;
link;
remote-operations;
routing;
startup;
rmon-alarm;
vrrp-events;
configuration;
}
targets {
172.28.113.48;
}
}
routing-instance-access;
rmon {
event 1 {
type snmptrap;
}
}
}
Conclusion
Juniper products offer mobile network operators a wide range of backhaul options. The comprehensive solutions
based on the BX7000, EX4200, and M Series/MX Series routers address both the needs of green field/new 4G
technology deployments or migration from legacy technologies such as TDM or ATM to IP-/Ethernet- and MPLS-
based networks.
Appendixes
Examples of Deployment Scenarios
J Series as an Access Device
Figure 32 shows a J Series device used as the access gateway for a 4G pure IP/Ethernet scenario. The J Series
device is capable of applying CoS, delivering VPN services and setting up MPLS LSPs. The LSPs from the J Series
can either terminate on the ingress or egress PE router of the Metro network. Similarly, the J Series device can also
participate in the VPN service based on the network design and requirements.
IP/MPLS LSP
Ethernet
Ethernet Metro Network Ethernet Mobile Core
VPN + CoS Network
J Series + MPLS
RAN BS Cell/Hub Site Device M Series/ RAN NC
CoS + MPLS + VPN M Series/MX Series MX Series
Ingress PE Router + Egress PE
Aggregation Device Router
IP/MPLS LSP
Ethernet
Metro Network Ethernet
TDM TDM Mobile Core
VPN + CoS Network
CTP Series + MPLS
RAN BS Cell/Hub M Series/ RAN NC
Site Device MX Series M Series/
Ingress MX Series Egress
PE Router PE Router +
Aggregation Device
Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters Copyright 2009 Juniper Networks, Inc. All
rights reserved. Juniper Networks, the
Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper Networks Ireland Juniper Networks logo, JUNOS, NetScreen,
1194 North Mathilda Avenue 26/F, Cityplaza One Airside Business Park and ScreenOS are registered trademarks of
Sunnyvale, CA 94089 USA 1111 King’s Road Swords, County Dublin, Juniper Networks, Inc. in the United States and
Phone: 888.JUNIPER Taikoo Shing, Hong Kong Ireland other countries. JUNOSe is a trademark of
Juniper Networks, Inc. All other trademarks,
(888.586.4737) Phone: 852.2332.3636 Phone: 35.31.8903.600 service marks, registered marks, or registered
or 408.745.2000 Fax: 852.2574.7803 Fax: 35.31.8903.601 service marks are the property of their
Fax: 408.745.2100 respective owners. Juniper Networks assumes
no responsibility for any inaccuracies in this
document. Juniper Networks reserves the right
To purchase Juniper Networks solutions, please to change, modify, transfer, or otherwise revise
contact your Juniper Networks representative this publication without notice.
at 1-866-298-6428 or authorized reseller.
8030008-001-EN Jun 2009 Printed on recycled paper.
38